TiDDとWFとScrumとLeanの違い

開発プロセスの違いについて良い記事があったのでメモ。

【元ネタ】
[Agile]WFとScrumとリーンの違い | Ryuzee.com

WFの弱点は「計画に依存しすぎているので、計画が間違っていたらリスクが高い」「プロジェクトの終了直前のデプロイまで、何の価値も実現できない」点にある。
実際の現場では、結合テストで火を噴いてビッグバン統合に失敗する症状に全てが言い尽くされていると思う。

このWFを繰り返し型開発へ変形した場合、確かにリスクは減るが、最大の弱点は「ボトルネックが発生してしまい、それを制御できない」点にある。
全ての作業の遅れが積もり積もって、バッファを食い潰すのだ。
TOCのクリティカルチェーンの話を思い起こさせる。

Scrumではイテレーション単位に、Plan・Build・Test・Reviewが並行で動き、リリース前にReviewとDeployが行われる。
つまり、実装とテストとペアプロが一緒になっていて、実装した機能は常時統合される。

Leanの絵では、もはやイテレーションの概念が1日の単位に収まってしまう意味だろう。
Leanはアジャイル開発の究極の理想形だが、実際はなかなか実現できないだろう。

では、TiDDはどうか？
下記のようなイメージだと思う。

Tiddのライフサイクル

View more PowerPoint from akipii Oga

僕の経験では、Planでイテレーション計画、もっとスパンの長いリリース計画を立てて、イテレーション単位で機能を小刻みにリリースしていく。

当初、イテレーションにアサインされたチケットも、開発中に延期されたり、追加されたり、優先順位が変わったりする時もあるだろう。
だから、実際の作業は、チケットに従って、Plan・Build・Test・Reviewが並行で動く。
このフェーズまでは、RedmineのようなBTSで管理すればいいだろう。

そして、システムテスト、受入テストはイテレーション後半に別途実施する。
理由は、単体テストや結合テストを終えて常時統合できたからといっても、品質に不安はあるからだ。
顧客の観点からテストして、要件が実現されているか、検証するフェーズが必要だ。
そのフェーズは、全ての機能がほぼ動作するレベルが最低条件であり、Plan・Build・Test・Reviewが並行で動く最中で、システムテストや受入テストは実施しづらいからだ。
このフェーズでTestLinkを使うと有効だと考える。

本当はLeanのような開発ができれば、イテレーションのない世界、つまり、バージョンが必要なくなる。
しかし、実際のSW開発は複雑怪奇で、そんな綺麗な開発はありえない。
現実と妥協すると、アジャイル開発はTiDDに落ち着くのではないかと思っている。