無料ブログはココログ

« 2011年7月 | トップページ | 2011年9月 »

[#TiDD] ツールでできること

チケット駆動開発を検討されてる方にお話をした際に、あまりにも積極的な方に

「チケット駆動開発で解決できる問題がない場合や、イメージできない場合は失敗するのでやめてください。まずは障害管理から始めてください。」

とお話をしたことがあります。チケット駆動開発は、単に「BTSを入れれば開発が楽になる」といった類のものではありません。BTSを導入した上で、その機能を生かしてチケット駆動開発を実践し、プロジェクトの問題を解決しなければ、効果は得られません。

もちろんチケット駆動開発で解決できる問題が、存在していなければ効果はありませんし、よくわからないままプロジェクトに導入しても、改善できたかどうか、たぶんわからないでしょう。幸いなことに、もし障害管理ツールを初めて導入されるなら、それだけでも情報の一元化や情報共有、履歴の保存、構成管理ツールとの連携など、様々なメリットがあります。まずは障害管理ツールの導入から初めて障害管理ツールに慣れていただければ、チケット駆動開発の良さをきっと理解していただけると思います。

さて、先日のRyuzeeさんの記事「[Agile]アジャイル開発でツールを導入する5つのステップ」の最後にこう書かれていました。

「チームがアナログで出来ないことはデジタルで出来るわけがない」

この言葉は、私が上で述べたことにつながるもので、おおむね賛成できます。デジタルでできるものであれば、規模の制約や検索能力を除くとアナログでもできるからです。そして、本質的な問題の把握したうえで解決しなければ、プロジェクトの改善はできないからです。しかし、この言葉が表面的にとらえられて一人歩きするとチケット駆動開発に可能性を見出している私としては、困ったことになりますので、問題を整理しておきたいと思います。

私の思うに「アナログで出来ないことはデジタルで出来るわけがない」と言うのは、どちらにしろできない理由があるのだと思います。

どっちにしろできない理由
・問題意識がない
・問題が分かっていない
・解決法を知らない
・そもそも概念や目指しているもの、理論がわかっていない

このような状況では、何をやってもうまくいくはずがありません。試してみる以前の状況で、ごっこ遊びをしているだけです。明確な目的なしにプロセスを無理やり変えても、現場が大変なだけです。

これ以外にもツールから始めることで、失敗してしまう可能性もあります。具体的には以下のような場合です。

ツール(デジタル)から始めるとできなくなる理由
・ツールの利用が目的となり、目的と手段が入れ替わる
・規模の制約がないので、バランスが取れなくなる

アナログの良いところは、人に近い道具であることです。ツールを学ぶ負担も少ないので、ツールを学ぶだけで力尽きることもありません。ツールの先にある方法論に力を割くことができます。また、タスクボードやタスクカードのように制約があることによって、人間の管理できる範囲に情報がまとめられるという良さもあります。

その反面、アナログならではの難しい問題もあります。

アナログでは難しい問題
・規模の制約
・検索能力の問題

これは、BTSというツールが必須であるチケット駆動開発にはない問題です。アナログですと、まずはタスクボードが必要ですし、置き場所にも困る場合があるでしょう。さらに、大きさにも限界があって、管理できるタスクカードには限界があります。カードが増えてくると検索したくなりますが、配置や色などを工夫して探しやすくするぐらいが限界で、そこで表現できる情報にも限界があります。

この制約は、上にも述べたようにアナログの良さでもありますので「だからデジタルが良いのだ」などと言う訳では必ずしもありません。しかし、チケット駆動開発に限るならば、実践しなければ感じにくい良さもあります。

使ってみてわかること
・情報の一元化は重要
・チケットの抽出・並べ替えや検索は良く使う
・集中とリズム

情報関係の方なら、データベースの設計に正規化が必要なことはご存知でしょう。でも、社内文書になると、報告先や打ち合わせに合わせて似て非なる資料を作ることが多いでしょう。面倒とは思っても、情報の遅延という問題には必要悪だと思われていないでしょうか?チケット駆動開発を実践すると、すべてがチケットを中心に回ります。一覧やガントチャートなど、表現方法は色々あっても、そのデータは一つです。誰もが最新の情報を遅延なしに知ることができるのです。

また、チケット駆動開発は忘れずきちんとやる仕組みです。忘れてしまいそうな出来事が多いほど効果的です。そこで、何かあるたびにチケットを抽出して並べ替えたり、検索します。これをアナログの付箋で実現することは困難でしょう。

そして集中とリズム。これはやってみないとわかりにくいと思います。口頭での情報共有は朝会が中心で、それ以外はチケットで作業指示やQ&Aが行われます。朝会後にチケットを参照して予定を立て、作業が終わればチケットを更新する。その様な日々の作業の中で都合の良い時にチケットを確認する。そのようなリズムの中で、作業に集中できます。

これらのうち「抽出・並べ替えや検索」を除けば、アナログでも実感できるものです。これらはこだわるべきものではありますが、明確な問題として認識されていなければ、それを理由に新しい方法論を導入することは難しいかもしれませんが、チケット駆動開発ならほかの理由で導入して実感することができるのです。

結局、大事なことはデジタルとかアナログとかそういう問題ではなく、今、プロジェクトでどのような問題が起きているか、どのようにすれば解決できるかということです。効果が見込めないのに、ツールや方法論を導入しても無駄です。

チケット駆動開発には多くのメリットがあります。もし、チケット駆動開発で解決可能な問題がプロジェクトで発生しているなら、ぜひチケット駆動開発の導入を検討してください。チームのメンバーで問題意識を持って取り組めばきっと効果が出るでしょう。そうすれば、気づかなかった問題点やチケット駆動開発の良さに、気づかれるかもしれません。

[#TiDD] チケット駆動でAdaptable Waterfall開発!

前に書いたようにチケット駆動揮発の特徴はプロジェクト改善です。そのプロセスはアジャイル的で、アジャイル開発においても効果的であるほか、従来型の開発においても管理上の問題を補完して効果を発揮するものです。これらはそれぞれ、完全型、補完型のチケット駆動開発と呼ばれています。ここでは、補完型のチケット駆動開発をAdaptable Waterfall 開発として再定義したいと思います。

1.Extreme Waterfallの限界

品質管理を強化した日本的な従来型開発をExtreme Waterfallと呼ばれています。実装に至るまでの課題をあらかじめ検討しておいて、定量的な数値(メトリクス)を用いて管理することで安定した開発を行うというものです。

このような従来型の開発において混乱の原因となるのが、仕様変更や予想外の不具合、実行環境の変化です。これらは、昔からある混乱原因です。それぞれ変更管理、障害管理、課題管理として帳票で管理され、それらの具体的な作業計画と実施が行われることで、一定の成果を上げていました。

しかしオブジェクト指向技術の発展、フレームワークなど開発環境による生産性の向上、ハードウェアの性能向上によって、対象業務の多様化、実現する機能数の増大、想定外の事象の多発という事態が恒常化しています。そして開発スピードの向上も伴うことで、帳票による管理は限界に達しています。

そこで、チケット駆動開発によって従来型開発の適応力を向上させます。仕様変更や不具合、想定外の事象をチケットで管理するのです。帳票による管理では難しいこれらの作業を、チケットに一元化し、リアルタイムな情報の共有と管理を可能にします。

従来型の開発では仕様変更や追加の作業を厳密に管理することで、プロセスの安定化を図っていましたが、その管理をBTSのチケットで効率化してAdaptable Waterfall開発を実現するのです。

2.なぜ、アジャイル開発できないのか

繰り返し開発やアジャイル開発では、仕様変更を受け付けるタイミングを明確にすることで、仕様変更を制御しています。開発を混乱させないために、それぞれのイテレーションには、変更の取り入れ、変化する作業の管理、リソースの配分、リリース、という一連のプロセスが必要です。

しかし、それは時として困難な場合があります。たとえば以下のような場合です。

(1) 作業を開始するには一括承認が必要
開発チームとシステムを企画・予算化する部門が異なるなど、予算を決済する権限が開発チームから遠い存在の場合、開発中のソフトウェアの仕様(スコープ)を随時変更することが困難になります。

(2) 他のシステムとの連携や必要なデータの入手が開発終盤になる
連携する複数のシステムが並行開発される場合や、別チームで画面デザインが行われるなど、実装を優先することが困難な場合があります。特にハードウェアとの並行開発では仕様変更が難しい場合があり、仕様段階での検証に多くの時間が取られます。

(3) 機能の実装に必要なタスク集合の粒度が大きい
タスクの分解が可能であってもタスク間に順序性があり、一つの機能の実装期間が長期になる場合、どうしても段階的な開発になってしまいます。仮に見かけ上だけ繰り返し開発を行ったとしても、その機能の取捨選択は初期のイテレーションでのみ可能です。

このように適度な粒度の実行可能なタスクの集合でない場合、アジャイル開発は困難です。

3.Adaptable Waterfall

そこで、現状の問題を解決してくれるのが補完型チケット駆動開発です。補完型チケット駆動開発では、計画外の作業をチケットで管理することで、従来型の開発を補完してAdaptable Waterfallを実現します。

チケットで仕様変更や障害を管理できるほか、それらを具体化したタスクや想定外のタスクを管理することができます。チケットの更新は関係者に通知され、リアルタイムな情報が共有されます。チケットは実現可能な期限と担当者が記録され、プロジェクト全体や担当者ごとの一覧、ガントチャートなどの形で可視化されます。チケットは、進捗率だけでなくその状態でも管理されます。チケットの種類によって状態を変更可能な権限が決められていますので、レビューの徹底や他のチームとの連携といったことも容易になります。

チケットは情報の中心であり、開発を助けます。チケットには、上記の情報のほか、関連する議論やチケットの詳細を表す様々な属性が記録されます。これらのの変更や、関連するソースコードの変更などもチケットに記録され、プロジェクト改善につながる現状分析のほか、障害発生時の参考情報になります。

Waterfall開発をAdaptableにする上で重要なものにリリース計画があります。原理主義的なWaterfall開発では開発の最後に一度だけリリースが計画されますが、必ずしも現実的ではありません。仕様書に表しきれない挙動を確認するには、なるべく早くユーザに操作してもらうことが効果的です。また、複数システムで連携する場合には、現物による早めのすり合わせは欠かせません。このような外部組織へのリリースなど、目標となるタイミングをマイルストーン(あるいはバージョン)として定めます。

プロジェクト全体を繰り返し開発にできない場合でも、段階的なリリースをマイルストーンと定めることは重要です。チケットはマイルストーンごとに一覧や集計ができますので作業の遅延が見える化されるほか、開発者のモチベーションに大きくかかわります。「今のうちに早く帰ろう」という発想は遅延が顕在化しないからできるのです。制約に合わせて作業を適切に配分し、見える化することが大切です。

4.まとめ

このようにアジャイル開発でなくても、あらかじめ計画が困難な、仕様変更、障害、想定外の作業をチケットで管理して、適切なリリース計画を立てれば、従来型の開発を改善することができます。それは、組織プロセスとしてだけでなく、進行中のプロジェクトの改善としても可能なものです。今のプロジェクトではアジャイル開発を実践できないから、とあきらめるのではなく、問題を見極めた上でチケット駆動開発を導入すれば、きっとより良い開発が実現できると思います。


今のところ唯一のチケット駆動開発の本です。

[#TiDD] チケット駆動開発でプロジェクト改善!

1.従来のプロセス改善

組織の能力を高めるにはプロセス改善が有効であると思います。しかし、現場で開発しているとプロセス改善に協力しようという気持ちよりも、何とかチェックがア厳しくならないようにしようとか、面倒くさいとか鬱陶しいなど後ろ向きな気持ちを抱いてしまいます。このことを考えると、プロセス改善と称して行われていることに以下の特徴を感じています。

義務的
作業の抜けが問題であると考えており、ルールとそのトレーニングにより解決しようとする

大変なプロジェクトほど負担が大きくなる
管理に用いられるメトリクスが既定の範囲であることが求められる。範囲を超えると手戻り的な作業の追加や、管理の強化が行われる

プロジェクトへの即効性がない
プロセス改善で改善されるのはプロダクトの品質と組織のプロセスである。進行中のプロジェクトの効率化が図られない

一定のテーラリング(プロジェクトごとの微調整)は認められるものの、管理の効率化などの工夫はなかなか認められないと思います。標準プロセスは強化され続けますので、時折効率化が図られる以外は、基本的にヘビーウェイトになって現場の負担は増え続けます。

2.チケット駆動開発の特徴

チケット駆動開発はBTSによるタスク管理で現場の負担を減らすものです。たとえば、このようなことがあります。

作業漏れ防止
忘れてしまいそうな作業をチケットとして管理し、備忘録として使う

ワークフローによる管理
承認の必要な作業などで、ユーザの権限によって更新の権限を変えることができる

トレーサビリティの向上
構成管理ツールと連携してソースの更新情報を残すので、過去の修正理由の解析が容易になる

コミュニケーションの向上
プロジェクト全体や各担当者のの残作業や進捗が共有でき、作業の融通ができる

チケット駆動開発は、現場の負担を減らす目的で

  • ・組織の標準として採用することもできる

だけでなく、上記項目のリスクが増大しているようであれば、

  • 進行中のプロジェクトに導入して現場の負担を減らす

こともできます。後者を私は「プロジェクト改善」と呼ぼうと思います。

私はこのような「プロジェクト改善」と呼べるような技術を、現場は待ち望んでいたのだと思っています。そして「チケット駆動開発」がもっと広く知られるようになればと思っています。

今のところ唯一のチケット駆動開発の本です。

[#Redmine] 我、なぜRedmine贔屓となりしや

どのBTSを選ぶかという議論になると、ついつい機能比較になりがちです。しかし、Redmineには機能では比較できない特徴があります。それは「後発」であることです。後発ということは「後出しジャンケン」ならではの有利点があり、後発が追いつく際の「ベロシティ」(速さ)が維持されていることです。

Redmineはその設計にTracの影響を受けていると言われています。このため、類似点も多く、プラグインを含めて議論すると、あまり違いはなくなってしまいます。

しかし、Redmineには後発のメリットを生かした(Tracにない)以下のような特徴があります。

・後出しジャンケン
 - 標準機能の充実
 - トラッカー

・ベロシティ
 - さらなる機能追加
 - Ruby on Rails

1.後出しジャンケン

後発の有利点は何と言っても後だしジャンケンです。先発のソフトウェアでは、すでに広く使われるようになり変更が難しくなった点があるのに対して、それらを含めて新たな設計ができるからです。

1.1 標準機能の充実

たとえばTracは豊富なプラグインが特徴である反面、プラグインがなければ利用できるのは基本的な機能に限られます。一方のRedmineは、プラグインも多くあるものの、TracではPluginが必要な機能が、標準機能となっています。ガントチャートもそのような標準機能の一例です。

標準機能が充実していることは、オールインワンパッケージのリリースを早くする効果ももたらしています。プラグインを含めたオールインワンパッケージでは利便性が向上する反面、プラグイン同志が競合することもあって動作確認に一定の時間が必要になり、バージョンアップに機敏に対応することが難しくなるはずです。

Redmineにも最近日本語化されたBITNAMI(http://bitnami.org/stack/redmine)をはじめとするオールインワンパッケージが存在すますが、それらはRedmineの基本パッケージが中心です。同梱されるのは、疎な結合を持つバージョン管理システムSubversionなどとの組み合わせですので、Redmineのバージョンアップ後の比較的早い時期にオールインワンパッケージがリリースされています。

1.2 トラッカー

Redmineはトラッカーごとにワークフローを簡単に変更することができます。一般にチケットの種類(トラッカー)はチケットの一属性にすぎませんが、Redmineではトラッカーを特別な扱いにすることで、各トラッカーのワークフローとして、ユーザのロールごとに現在のチケットの状態から遷移可能な状態を設定することができます。このワークフローの特徴によって、障害管理とタスクの管理のワークフローを別々に設定するなど、業務に合わせた柔軟な管理が可能になります。このワークフローはとても柔軟ですので、ソフトウェア開発以外の業務においてもRedmineが使われています。

2.ベロシティ

Tracはとても手になじむツールです。Versionというたった一つの属性であっても、コミュニティの意見をうまくまとめながら仕様変更が行われています。一方のRedmineは最近のChiliProjectの騒動に見られるように、全員の合意よりもさらなる機能向上を求めているような雰囲気があります。これは、後発プロジェクトの勢いそのままに、追いつけ追い越せと言った感じで、現在も素早い機能アップが続いています。それは、基盤にRuby on Railsを用いていることも影響しているのでしょう。

2.1 さらなる機能追加

Redmineは独自機能も充実しています。特徴的な標準機能だけでもサブタスキング、PDF出力、プラベートチケット、などがあります。サブタスキングとはチケットの階層化のことで、大規模プロジェクトのタスクをWBSのように階層化してチケットで管理できるようにします。階層化されたチケットはガントチャートで表示できるだけでなく、さらにPDFで出力することも可能です。プライベートチケットは最新バージョンの1.2.0からサポートされた非公開のチケットです。セキュリティの更新などRedmineプロジェクトのタスク管理に必要なことから生まれたようですが、チケット数が膨大になる大規模なプロジェクトでも効果的に使うことができるでしょう。

2.2 Ruby on Rails

Redmineの実行環境は、基盤であるRuby on Railsの思想を受け継いで柔軟に選択できます。特にバージョン管理システムの対応に関しては充実していて、CVS、Subversion(リモートも可能)、Git、Mercurialなど6種類以上の環境に対応しています。もちろん、データベースもMySQL、PostgreSQL、SQLiteといったものに対応しています。

このような感じで、仕事上ではあまり使っていないRedmineですが、贔屓(ひいき)の障害管理ツールになっています。


[#TiDD] 記録する - ソフトウェア開発で重要なこと その3 -

ソフトウェア開発で重要なことの一つに「記録する」があります。ソフトウェアはたとえ同じ仕様・同じメンバーであっても、2度と同じように開発できません。なぜなら、人は学習するからです。

そこで、ソフトウェア工学の実験はとても複雑なものになります。たとえば2つの方法を比較する場合でも、2グループで順序を変えてそれぞれ2回実行するなどして、学習効果の影響を受けないようにしなければなりません(そのほかにも、メンバ構成などいろいろ考えないといけません)。

実際の開発現場では一つのプロジェクトは1度きりです。2階も開発することはできませんので、その貴重な情報を失わないように、記録することがとても重要になります。それはプロジェクトのためであるのはもちろんですが、自分自身を知り、身を守るためのものでもあります。

記録の利用方法
開発時の情報を記録したなら、以下のように利用できるでしょう。

 - 作業のエビデンス・報告
  - トレーサビリティを高める(状況・経緯を開発・保守に利用)
  - やり方を再実行可能にする
 
メトリクス(定量的なデータ)を集める
さらに記録する対象が定量的なデータであったなら、以下のようにも利用できるでしょう。

 - 傾向(生産性・品質)を知る
  - 経験値を参考に状況を知る・伝える
  - 類似のものを探す
 - 見積もり・未来の予想
  - 予実管理

このような、記録やメトリクスの特徴は、そのままチケット駆動開発のチケットの特徴にも当てはまります。先日のRxTstudy(Facebook)で、あきぴーさんが「タスクカードを電子化したくなる」といわれたのも、このような特徴があるからでしょう。


[#TiDD] コミュニケーション - ソフトウェア開発で重要なこと その2 -

ソフトウェア開発で重要なこととして、コミュニケーションほど古くから言われている言葉はないでしょう。ソフトウェア開発の神話(人月の神話)には、旧約聖書からバベルの塔の話が引用されて、コミュニケーションの重要性が語られています。旧約聖書ですからコミュニケーションの重要性は数千年前から認識されていたことになるのでしょう。

重要性が語られる一方で、これほど色々な意味でつかわれる言葉もないでしょう。仲良くする、あいまいにしない、詳細に説明する、情報共有、など色々なイメージを思い浮かべられると思いますが、最も重要なのは、コンセンサスを得ること、それとコミットメントでしょう。

コンセンサスを得るというのは意見を一致させて合意するということで、コミットメントというのは責任(感)を伴う約束です。プロジェクト内で共通の理解に達すること、その合意に従って責任を持って約束をしてきちんと達成すること、それなしにプロジェクトは運営できません。

プロセスもソフトウェアであるオスターワイル氏は言いましたが、多くのオブジェクトが正しく連携して動くには、各オブジェクト間のインタフェースが正しく実装・認識され、正しく動作しなけれあなりません。同じようにプロジェクトもコンセンサスが得られずにコミットメントもなければ、一つのチームとして協調作業ができないのです。

さて、先日のスクラムワークショップで教わった内容には、このコンセンサスとコミットメントの仕組みがありました。一つは意思の表明による多数決、もう一つは計画ゲームです(きっと、他にも色々あると思います)。

アジャイルというと、過去の開発法をのアンチテーゼのようにとらえられる方もおられるかもしれませんが、このように昔から重要と言われたものが大切に実現されている面もあるのだと思います。

逆にいうと、コミュニケーションという価値を実現するには必ずしもアジャイル開発である必要はありません。リーダーが勝手に見積ってメンバーに強制するのではなく、メンバーと共に見積もったり、レビューしてもらう、計画の感想を聞いた上で、それを参考にプロジェクトを運営する、とったことでコンセンサスを得ることができると思います。また、進捗にばらつきが出たときに、どうすべきかの判断を求めた上で自主的に担当を変更ができtなら、コミットメントを得たことになると思います。

コミュニケーションというと見える化や情報共有を思い浮かべがちだと思います。コンセンサスやコミットメントを得ることを考慮すると、やらされ感を減らしてより自律的なプロジェクト運営に近付けるのではないでしょうか。


[#TiDD] アジャイル開発への壁 #RxTstudy

ついに「Redmineでのタスク管理を考える勉強会@大阪(RxTstudy)」が立ち上がりました。Twitterに話題が出てから約2日で企画され、募集から1日程度で30人の定員に達しました。しかも満員になってからも補欠(キャンセル待ち)が20人以上で鵜など、企画者側もびっくりの盛況ぶりでした。東京でもRedmineのコミュニティが発足するようですので、チケット駆動開発がいよいよ盛り上がると期待しています。

恥ずかしながら私も、今年のデブサミでベストスピーカ賞をいただいた発表を再演しました(資料Ustream)。

勉強会の概要

今回お勉強会では、あきぴーさんのアンチパターンのお話(資料)、中村さんのRedmineの事例発表(資料)やLTのほか、Redmine本の著者4人によるパネル(Ustream)や、そのうちのお一人である倉貫さんの基調講演(資料Ustream)もあり、活発な意見交換が行われました(Ustream @bufferingsさんによるtogetter @akipiiさんによるtogetter)。

取り上げたい内容は多々あるのですが、ここでは以前から気になっているアジャイル開発への壁という観点で、最近考えていることをまとめたいと思います。

契約

多くのソフトウェア開発は請負契約で行われていることから、契約時に仕様(スコープ)を決めた上で、開発が始まるといういかにも従来型開発向きな契約になっています。準委託契約、いわゆる期間契約であれば、スコープを後から変更することもできるのですが、一度に発生する費用を減価償却できないという問題が生じてしまいます。

この点、倉貫さんの基調講演の請負をクラウドで実現して、納品をなくすという方法は、一定額を常に払う契約ですので、顧客・開発双方にWin-Winの関係が築けるかもしれません。類似の契約には永和システムさんの「価値創造契約」がありますが、クラウドに限定することで納品をなくし、リリース後のサービス向上も容易になりそうです。

レイヤ構造

これは先日のSEA関西でのスクラムワークショップで教わったことです。開発者が一つのタスクに集中できるように作業を割り振るには、作業分担がレイヤごとになってはいけないというお話から気づきました。

ワークショップでのお話の趣旨は、画面担当、ビジネスロジック担当、DB担当のように担当を分けると、常に作業を割り当てることが難しくなり、複数のプロジェクトを掛け持つ必要が出てくるというものでした。

このことを拡張して考えると、フレームワークなどしっかりしたアーキテクチャが別にあり、その上の薄くて広いところの開発だと開発する機能に単純な優先順位をつけることができますが、別のレイヤに分けてしまいがちな別サーバとの通信やハードウェアとの並行開発だと単純な優先順位をつけることが困難です。アジャイルリリーストレインやスクラムオブスクラムという方法があるものの、依存関係によって、スコープの変更に制約を受けてアジャイルのメリットを生かしにくいように思います。

顧客との関係

最後に、一番難しいのは顧客との関係ではないでしょうか?ソフトウェアが企業の命運を握っていることは間違いないはずなのですが、やはり「おまかせ」のお客さんも多いように思います。また、協力的な顧客であっても、ステークホルダー(利害関係者)が多くて、意思決定が困難な場合などは、アジャイル開発が難しくなると思います。

これは、顧客の予算どりや契約とも関係しています。詳細な仕様を決めずに商品化(リリース)までの予算を決定できるかどうかが、難し意場合もあると思います。また、意思決定が遅れると、作業が止まってしまいますので、請負開発では開発側の大きな負担になります(その点、一定の金額をいただける契約は、開発側のリスクを減らしてくれる宇土思います)。

おわりに

チケット駆動開発は、残念なアジャイル開発と呼ばれることがあります。これはアジャイル開発がある程度有効だと思われるのにアジャイル開発できない、上記のような場合に有効であることを示している言葉だと思います。

関西の勉強会(RxTstudy)はRedmineだけでなくタスク管理がその名前に入っていることから、大いに期待しています。

« 2011年7月 | トップページ | 2011年9月 »