[#TiDD] マイルストーンを定める - ソフトウェア開発で重要なこと その1 -
チケット駆動開発やアジャイル開発はもちろんのこと、オブジェクト指向もあまり知られていないころに、先輩技術者からソフトウェア開発で重要なことを色々と教わりました。今にして思うと、そのころ教わった古(いにしえ)の知恵は、チケット駆動開発やアジャイル開発の理解につながっています。
<マイルストーンとは>
マイルストーン(リンク先はWikipedia)とは距離標識の一種で、日本風にいうなら一里塚です。マイルストーンがあることで、全体の行程の中でどの場所にいるのかを知ることができます。また、目印にもなりますので、待ち合わせにも用いることもできるでしょう。
ソフトウェア開発に限らず、人は目標がないとうまく作業ができません。いつまでに何をするか、期限や成果物あるいは中間成果物を定めることで、目標ができるのでその目標に向かって作業を進めることができます。また、あらかじめ定められた行程のなかでそのマイルストーンの位置をあらかじめ知っていつなら、現在の状況を定量的に把握できるようになります。
<マイルストーンの教え>
作業をより進めやすくし、より詳細な状況を把握するには、小さな作業に分割してマイルストーンを定めます。細かに分かれた各マイルストーンに向けて作業を実施し、その状況を管理することで、作業がより明確になるのです。
一方、作業に依存関係がある場合は、マイルストーンに達するのを待って、次の作業を始めます(一里塚のメタファで言うなら駅伝のイメージでしょうか)。大きなマイルストーンは、工程の切れ目としての段階的な品質保証のタイミングや、他のチームと連携するためのリリースタイミングとして用いられ、開発全体の整合性が保たれていました。
<現代のマイルストーン>
現代風にいうならば、小さなマイルストーンはタスクカードやチケットの完了、大きなマイルストーンはスプリント(イテレーション)の完了、あるいは、アジャイルリリーストレインの連携ポイントとなるリリースにあたるでしょう。
本来のマイルストーンは、必ずしもプロジェクト全体で共通のものであるとは限りません。チケット駆動開発ではチケットの完了日を個別に定められることが細かなマイルストーンに当たります。もちろん全体のマイルストーンとして、BTSのバージョンやマイルストーンの機能によって、プロジェクト共通のマイルストーンを定めることもできます。
<マイルストーンで重要なこと>
昔も今もにおいてもマイルストーンで重要なことは変わりません。それは以下の3つです。
(1) タスクのゴールを明確にすること
何をいつまでに作成するのかを明確にしなければ、マイルストーンとして意味がありません。共通の理解が可能な明確なゴール(期日と成果物/中間成果物)を定める必要があります。
(2) 管理が容易なタスク粒度
詳細なマイルストーンは、作業に集中でき、管理が容易なように、一定の粒度以下に分割しなければなりません。具体的な粒度は、プロジェクトの規模や開発対象によって、スプリント(イテレーション)期間と共に決めればよいでしょう。
(3)リリース計画を定めて整合性を保つ
それがアジャイル開発であるかどうかにかかわらず、最終的なゴールに対してリリース計画の整合性が保たれていなければいけません。特に複数のチーム/タスク間で依存関係がある場合は、後続の作業に影響を与えないように計画しなければいけません。
<おわりに>
このようにマイルストーンの重要性は、昔から変わりません。どのようなプロセスで開発するか、どのようなツールを使うか、ということも、もちろん重要です。しかし、なぜマイルストーンが必要か、何が重要か、をきちんと理解して実践することも、ソフトウェア開発に重要なことだと思います。
« スクラムを味方につけろ! - SEA関西プロセス分科会 - | トップページ | [#TiDD] アジャイル開発への壁 #RxTstudy »
「私のアジャイル」カテゴリの記事
- One fact in one placeとチケット駆動開発 - Software Processes are Software, Too -(2021.12.21)
- マルチスレッド処理と進捗管理・配員・作業分割/割り当て- Software Processes are Software, Too -(2021.12.20)
- カプセル化と組織パターン - Software Processes are Software, Too -(2021.12.20)
- Greedy algorithmと2割8割の法則 - Software Processes are Software, Too -(2021.12.12)
- 「任せて、任せず」「魚を与えるのではなく"釣り"を教えよ」(2021.08.16)
「ソフトウェア」カテゴリの記事
- One fact in one placeとチケット駆動開発 - Software Processes are Software, Too -(2021.12.21)
- マルチスレッド処理と進捗管理・配員・作業分割/割り当て- Software Processes are Software, Too -(2021.12.20)
- カプセル化と組織パターン - Software Processes are Software, Too -(2021.12.20)
- 論文研修会(導入編)- 論理的思考のすすめ -(2019.12.01)
- デブサミ関西でNode-REDとペンギンと勇気の話をしました #devsumiB(2018.10.28)
「プログラミング」カテゴリの記事
- Greedy algorithmと2割8割の法則 - Software Processes are Software, Too -(2021.12.12)
- 論理的に考え伝える – SEA関西「開発現場で役立つ論文の書き方のお話」 -(2021.05.09)
- 論文研修会(導入編)- 論理的思考のすすめ -(2019.12.01)
- スクリプト言語入門 - シェル芸のすすめ - 第2回クラウド勉強会(2019.01.27)
- デブサミ関西でNode-REDとペンギンと勇気の話をしました #devsumiB(2018.10.28)
「チケット駆動開発」カテゴリの記事
- One fact in one placeとチケット駆動開発 - Software Processes are Software, Too -(2021.12.21)
- マルチスレッド処理と進捗管理・配員・作業分割/割り当て- Software Processes are Software, Too -(2021.12.20)
- カプセル化と組織パターン - Software Processes are Software, Too -(2021.12.20)
- [#TiDD] ポケモンGOにチケット駆動開発のポイントを学ぶ(2018.05.01)
- [#TiDD] プロジェクトを成功させるチケット管理(2017.07.02)
« スクラムを味方につけろ! - SEA関西プロセス分科会 - | トップページ | [#TiDD] アジャイル開発への壁 #RxTstudy »
コメント