チケット駆動開発の適用範囲part4~ウォーターフォール型開発への部分適用の注意点
以前のJSOLさんのTiDDの運用事例の記事を読み直してみて、自分の理解不足の面があったのでメモ。
ラフなメモ書き。
【元ネタ】
「チケット駆動開発」の適用について考える|コラム「ITよもやま話」|特集│株式会社JSOL
[#TiDD] チケット駆動でAdaptable Waterfall開発!: ソフトウェアさかば
「現状のソフトウェア開発は間違っていないか?」(プロセス編) - @IT自分戦略研究所
段階リリースとアジャイルリリーストレイン: プログラマの思索
僕は、チケット駆動開発をアジャイル開発へいかに適用するか、という問題意識しなかったので、従来型の開発やWF型開発への適用はあまり考えていなかった。
上記の記事を読むと、WF型開発に特有の課題に対して、チケット駆動開発をどのようように適用したら効果的なのか、という点をよく研究されているという印象を持った。
「チケット駆動開発」の適用について考える|コラム「ITよもやま話」|特集│株式会社JSOLの記事では、主に二つの課題、(1)ウォーターフォール開発でも内部にある小さな開発サイクルでの適用と、(2)プログラム改訂に関係するタスク以外のタスクや情報のチケット管理に適用した話が載っている。
(1)が意味することは、WF型開発でも短期間の開発サイクルの作業が存在しており、その作業にチケット駆動開発を適用しようとすること。
実際、要件定義、設計、実装、単体テストという工程が終わった後、ビッグバン結合で初めて大きな問題が次々に判明し、障害という名の元で短い開発サイクルの作業が生まれる。
その作業は障害管理に過ぎないけれども、障害をチケットに起票するのが起点となり、修正、レビュー、テスト、自動テスト、ビルド、リリースという一連の流れが全てチケットに作業履歴として残る。
だから、チケットにすべての情報が集約されるので、関係者同士の情報共有が楽になるし、SVNやGitなどの構成管理やJenkinsのようなビルド管理とRedmineを連携すれば、より強力に早く開発できる。
また、(2)では、設計書のレビューなどもチケットに作業履歴を残すことで、レビューの品質をあげようとする目的が示されている。
だが、(1)(2)の本当の問題点は、要件定義や設計、開発、テストの各工程で、一連の短い開発サイクルという裏プロセスが存在することにある。
WF型開発の定義では、前工程が完全に終了して次の工程に成果物が渡るので、手戻り作業や反復作業は基本ありえない。
しかし、実際の現場では、そんな綺麗事で開発できるわけがないし、リスクが高い。
だから、経験のあるプロマネは、裏プロセスという技を取る。
萩本さんの記事「「現状のソフトウェア開発は間違っていないか?」(プロセス編) - @IT自分戦略研究所」に書かれているけれど、要件定義・設計などの各工程で、PDCAサイクルを裏で回してリスクヘッジしているが、表に出さないようにプロセスを回す。
特に上流工程のPDCAサイクルは、実験的なアプリを作って画面イメージをすりあわせるプロトタイプという手法をよく取るがそれに当たる。
だが、プロトタイプはあくまでも暫定的なアプリのため、開発工程では結局一から作り直す場合も多い。
つまり、アジャイル開発における小規模リリースとは性質が全く違う。
そういう要件の検証、アーキテクチャ検証をあらかじめ実施するプロセスがあるのだが、教科書通りのWF型開発ではその認識が漏れていて、各プロジェクト独自のプロセスになりがち。
その裏プロセスを表に出すと、特に大手SIが自社で定めている開発標準とずれてしまうため、表に出さないようにわざわざする場合も多い。
だから、裏プロセスと呼ばれるわけだ。
また、別の手段として、段階リリースという方法もよく取る。
段階リリースとは、WF型開発において、サブシステム単位に複数回のWF型開発を回すこと。
大規模システムですべての機能を設計した後に開発して結合テストを実施するのはとても危険なので、意味のある業務の単位でシステムを分割し、その単位で段階的にリリースしていくプロセスを指す。
ビッグバン結合というリスクを回避するために、システムのサイズを小さくしてテストしてリリースするわけだ。
その意味ではアジャイル開発のイテレーションやスプリントの概念に似ているけれども、性質は全く違う。
イテレーションは2~4週間の定期的な開発サイクルであり、段階リリースではリリースサイクルは1ヶ月の時もあれば3ヶ月の時もあり不定期だ。
更に、イテレーション期間中は計画の変更は現状に合わせて行われるし、設計・開発・テストは並行して作業するのに対し、段階リリースの期間中はミニWF型開発なので、設計・開発・テストの工程の順に進んでいく。
だから段階リリースと言っても、結局はWF型開発であるからには最後のリリースにしわ寄せが来る。
そういう弱点がWF型開発には根本的にあるけれども、チケット駆動開発の恩恵は確かにある。
@sakaba37さんは、AdaptableWFと呼んで、WF型開発への部分適用でも十分な効果があると言われている。
とはいえ、WF型開発への適用は、WF型開発の特徴から来る根本的な問題をよく考えてみることが大事なように思う。
| 固定リンク
「プロジェクトマネジメント」カテゴリの記事
- 「スクラムの拡張による組織づくり」のScrum@Scaleの感想(2024.03.31)
- ストラテジストとプロジェクトマネージャの役割の違いは何なのかpart2~プロセスのレイヤと達成目標のレイヤが異なる(2023.02.18)
- ストラテジストとプロジェクトマネージャの役割の違いは何なのかpart1~CSFはWBSみたいなものと捉える(2023.02.14)
- PM理論では課業志向の方が関係志向よりも生産性が高いことを主張しているのではないか(2023.01.22)
- 現代日本人の弱点はリーダーシップ不足と生産性が著しく低いこと、そしてリスク許容度が著しく低いことだ(2022.12.23)
「Redmine」カテゴリの記事
- Redmineのバージョン設定でプロジェクトの設定方法が違う(2024.06.23)
- ウクライナのRedmine開発者が作ったRedmineテーマやプラグイン(2024.06.18)
- 第26回redmine.tokyo勉強会の感想~多様性はコミュニティが成功する重要な要因の一つ #redmineT(2024.06.15)
- Redmineで持ち株管理する事例(2024.04.21)
- チケットはデータでとプロセスの二面性を持つ #redmine(2023.12.24)
「ソフトウェア工学」カテゴリの記事
- アーキテクチャ設計はベストプラクティスを参照するプロセスに過ぎないのか?~Software Processes are Software, Too(ソフトウェアプロセスもまたソフトウェアである)(2024.09.22)
- 「システムアーキテクチャ構築の原理」の感想part2~非機能要件がシステムのアーキテクチャに影響を与える観点をプロセス化する(2024.05.06)
- 「システムアーキテクチャ構築の原理」の感想(2024.05.06)
- ソフトウェア工学の根本問題から最近のソフトウェア設計を考えてみる(2024.03.03)
- マイクロサービス設計は従来のアーキテクチャ設計と何が違うのか(2024.01.02)
「チケット駆動開発」カテゴリの記事
- 第26回redmine.tokyo勉強会の感想~多様性はコミュニティが成功する重要な要因の一つ #redmineT(2024.06.15)
- チケットはデータでとプロセスの二面性を持つ #redmine(2023.12.24)
- 小説活動にプルリクエスト駆動が必要になってきた(2022.05.08)
- 知識は経験よりも大切か、経験は知識よりも勝るのか、SECIモデルは相互作用を語る(2022.04.26)
- プロジェクト管理の基本はテーラリング、Redmineはプロセスをテーラリングするツール(2022.04.21)
「Agile」カテゴリの記事
- 「システムアーキテクチャ構築の原理」の感想part2~非機能要件がシステムのアーキテクチャに影響を与える観点をプロセス化する(2024.05.06)
- 「スクラムの拡張による組織づくり」のScrum@Scaleの感想(2024.03.31)
- ソフトウェア工学の根本問題から最近のソフトウェア設計を考えてみる(2024.03.03)
- 「GitLabに学ぶ 世界最先端のリモート組織のつくりかた」の感想(2023.12.10)
- 概念モデリングや設計原則は進化しているのか(2023.10.21)
コメント