6.ソフトウェア開発手法 - YukaKoshiba/MyknowledgeDocs GitHub Wiki
Software development methodologies @Japanese Version
Create Date:2024/06/12
Last Update Date:2024/06/12
要件定義を1回だけ行い、要求された機能をいくつかのサブシステムに分け、コア領域を優先的に完成させ、以降は設計~テストを繰り返して追加機能を順次リリースする開発モデル
システムをいくつかのサブシステムに分割し、その分割ごとにウォーターフォールモデルを繰り返して機能を追加していく成長型(進化型)の開発モデル
2001年にアメリカで開催されたソフトウェア開発者の会議に参加した17人のソフトウェア開発者により策定された、アジャイルソフトウェア開発におけるずマインドセットをまとめた文書
特に価値を置く事が、(1)個人と対話、(2)動くソフトウェア、(3)顧客との協調、(4)変化への対応
開発プロジェクトを数週間程度の短期間ごとに区切り、その期間内に分析、設計、実装、テストの一連の活動を行い、一部分の機能を完成させるという作業を繰り返しながら、段階的に動作可能なシステムを作り上げるフレームワーク
役割
| 役割名 | 説明 |
|---|---|
| プロダクトオーナー | チームに最も価値の高いソフトウェアを開発してもらう為に、プロダクトに必要な機能を定義し、プロダクトバックログの追加・削除・順位付けを行う |
| スクラムマスター | スクラムチーム全体が自律的に協働できる様、場作りをするファシリテーター的な役割を担う |
| アジャイルコーチ | アジャイル型開発の採用初期に経験者をコーチとして招き、チームのアジャイル導入や改善を手伝う チームのリズムを作り、改善を促す為、最初の日次ミーティング/スプリント計画ミーティング/レトロスペクティブ(ふりかえり)のファシリテータを依頼すると良いとされる |
開発反復の単位
プロセス| プロセス名 | 説明 |
|---|---|
| スプリントプランニング | スプリントの開始に先立って行われるミーティング、プロダクトバックログの中からそのスプリントで開発するものを決定する |
| デイリースクラム (日次ミーティング) |
開発チーム全員の活動共有の為、スプリント実施中に毎日15分程度行われる確認・調整の会議 昨日やったこと、今日やること、障害になっていることを各人が話す 毎日決まった時間と場所で、開発チームが全員が顔を合わせて行い、問題解決の議論をする場合は別会議体を設ける |
| スプリントレビュー | スプリントの終了時に、関係者を集めて成果物のデモンストレーションを行い、成果物を検査し、フィードバックを得る |
| スプリントレトロスペクティブ (ふりかえり) |
スプリント終了後に次のスプリントを見据えて行われる振り返り、上手くいったこと、上手くいかなかったこと、それに対する改善法・解決法を話し合う |
開発対象のシステムやソフトウェアで実現されるべき要求機能や要素をまとめたもの
振り返りの際に継続すべき良かった点(KeeP)、発生した問題(Problem)、今後試したいこと(Try)を開発チーム全員で考えるフレームワーク
定着したものには名前を付ける
アジャイル開発手法の1つ、顧客満足度の高いソフトウェアを迅速かつ柔軟に開発することを目的とした手法
トヨタ生産方式7つのムダの基本理念を発展させたリーン生産方式をソフトウェア開発に適用した手法
ソフトウェア開発のプロセスとプロセスの所要時間とを可視化し、ボトルネックや無駄が無いかどうか確認する際に用いるもの
ソフトウェアで実現したいことを顧客価値を明確にして簡潔に書き出したもの
誰の為に、何をしたいのか、なぜそうしたいのか、という3つの内容を含める
アジャイル開発の原則に基づき、チームがソフトウェア開発を効率的に行う為の具体的な方法論や手法
アジャイル開発における反復の単位、分析/設計/実装/テストの一連の活動を含む
メリット:短い期間で区切ることで、開発の工程管理がしやすくなったり、計画の変更に対応しやすくなる
開発サイクル全体を通して短いイテレーションを繰り返す手法
* 応用情報技術者試験過去問道場* IPA
アジャイル開発の進め方
アジャイルソフトウェア開発宣言の 読みとき方
* 内閣官房情報通信技術(IT)総合戦略室
アジャイル開発実践ガイドブック