この記事はプログラミング学習者が学習した内容を備忘録として記事におこしたものです。内容に不備などあればご指摘頂けると助かります。
アジャイル開発とは？
アジャイルマニフェストの４つの価値
- プロセスやツール < 個々と対話
決められたことを只管こなすのではなく、個々人同士でコミュニケーションをとり、自発的に課題を見つけて取り組んでいくことが重要。
ウォーターフォール開発ではフェーズが段階的に進み、自分で課題を見つけるというよりもマネージャーからタスクを割り振られるのでアジャイル開発のように自発的とは言い難い。
- 包括的なドキュメント < 動作するソフトウェア
ドキュメントを作っても相手が全て理解できるとは限らないので、実際に動くソフトを作って顧客に披露することで理解を求める必要がある。
ウォーターフォール開発では分厚い仕様書が事前に用意され、それに沿って開発が進められる。
- 契約交渉 < 顧客とのコラボレーション
最初の契約時で打ち合わせた通りに作っても顧客が求めているものではない場合が往々にして
起こり得る。一方で顧客と協力してソフトを作り上げることができれば生産性が上がる。
ウォーターフォール開発では基本的に最初の打ち合わせ通りに製品を納品する。
- 計画に従順 < 変更への対応
計画に忠実に進めることも重要ではあるが、顧客を取り巻く経済環境や顧客が必要とするソフトの形も変わっていくので、必要とされる変化へ柔軟に対応していくことで顧客の満足度も高めることができる。
一方でウォーターフォール開発は要件定義→設計→開発と１フェーズずつ着実に完了させていくスタイルなので、最初以外のフェーズでの変更受け入れは難しい。
アジャイルの12の原則(マニフェストをより細かく噛み砕いたもの)
- 顧客満足度
1, 早期且つ継続的に納品することを優先して顧客を満足させる
ウォーターフォールと異なり、機能別に開発し、顧客へ納品することができる。
全ての機能で納期までに納品することはできないかもしれないが、優先順位を設けて優先度の高いものから機能別に納品して、最低限の機能だけでサービスをローンチすることもできる。
2, 開発のあらゆる段階で変更を歓迎する
ウォーターフォールでは最初に仕様打ち合わせした内容から変更や追加を行うことは受け入れられないことが多いが、後から発生する変更を受け入れることで顧客の満足度を向上させることができる。
これにより顧客を取り巻く変化し続ける経済環境に対して顧客が適応し続けて、高い競争力を持続させる支援をすることができる。
3, 動作中のソフトウェアを頻繁に納品する
ウォーターフォールは完成した後にソフトを顧客に披露するが、完成したソフトが顧客の満足するものではない可能性がある。これを避けるために途中経過を顧客へ共有することで顧客が希望するソフトへ近づけられるに取り組む
- 品質
4, 動くソフトウェアこそが進捗で最も重要視されること
仕様通りに制作しても期待通りに動作しないと品質上は不適合なので、動くソフトを途中経過で顧客と共有することで必要であれば修正を加えられる
5, 技術的に優れた柔軟性と拡張性がある設計に注意すること
顧客を取り巻く環境や顧客のニーズは日々変わっていく、それらの変化に対応できないような設計だと融通の効かないソフトになってしまう。
6, シンプルさを求め、ムダなく作れる量を最大限にすることが本質であること
顧客が使わない無駄な機能を追加してしまう可能性がある。
必要ないことを捨てる勇気も大事だし、必要だけど何度も使っているような機能は関数などへ切り出して毎回実装している時間を省くといった改善作業も重要。
- チームワーク
7, ビジネス側と開発者は日々一緒に働くこと
経営者やプロジェクトマネージャーなどは開発チームにソフト開発を依頼したらその後は一緒に仕事をすることは少ないが、両者が密に連携を取り、成果物であるソフトの完成イメージを擦り合わせることが重要
8, 意欲に満ちた人々でプロジェクトを構成し信頼すること
言われたことばかりをやるのではなく、自発的に課題を見つけて取り組むこと
また、自発的に責任を持ってタスクに取り組んでくれる人でチームを構成することで安心してタスクにアサインすることができる
9, もっとも効果的なFace-To-Faseで対話をすること
最初の仕様決めで内容が決まったので後は会話をしないままだと顧客がイメージしていた製品は完成しない可能性がある。
仕様決めして文章として残しても文章で読み取る内容が必ず顧客のイメージと同じとは限らない。
定期的に途中経過のソフトウェアを見せながらコミュニケーションを交わすことで完成度の高い製品に近づけることができる。
- プロジェクト管理
10, 持続可能で一定のペースで継続的に維持できるようにすること
アジャイルは決められたリソースと時間の中でやりくりするので、一定のペースで開発することは重要。
そのためには優先順位をつけて本当に必要な機能だけに絞っていく必要がある。
ウォーターフォール開発では最初のフェーズでは手持ち無沙汰だったり、最終段階では期限が迫っているため逆に大忙しだったりと一定ではないことがある。
11, 最良のアーキテクチャ・要求・設計のために、自己組織的なチームづくりをすること
優秀な人材を集めるだけでプロジェクトがうまくいくわけではない。顧客の要求やチームワークを理解していない人がチームに入るとうまくいかない。自発的に責任を持って業務へ取り組める人が必要
12, チームがもっとも効率を高めることができるかを定期的に振り返り、やり方を最適に調整していくこと
開発後の定期的な振り返りで必要な改善を取り入れていく。ウォーターフォールだと長い期間をかけて開発が終わった後に振り返りをするので、改善結果が反映されるまでに時間がかかり過ぎてしまう。
ウォーターフォールとアジャイルの違い
件のマニフェストや原則で少し触れていたウォーターフォールとアジャイルの違いは下記のように整理してみました。
| ウォーターフォール | アジャイル |
|---|---|
| 仕様の変更は開発前のみ対応可 | 仕様の変更は開発途中でも対応可 |
| 全タスクが終わった後にサービス提供開始 | 各機能実装後にサービス提供可能 |
| 膨大な量のドキュメントが必要 | ドキュメントは必要に応じて必要最低限 |
| 主にメールを使ったコミュニケーション | 対面が好まれる |
| 不定期で長いミーティング | 決められたミーティングだけ参加 |
| ドキュメントによる細かい製品説明 | 動くソフトを見せる |
| 最初に仕様が決まるため見積もりしやすい | 変更を受け付けるので見積もりが難しい |
スクラムとは？
スクラムはアジャイル開発を行うフレームワークのうちの１つを指す。
スクラムの理論と価値
スクラムの理論
-
透明性
全員が共有情報にアクセスできること
プロジェクトの現状を容易に把握できること
良きも悪きもオープンにすることが求められる(障害発生や技術的課題など) -
検査
問題や望ましくない変化が潜伏していないか検査する
検査対象は、成果物、進捗状況や過程など
現在だけでなく、過去実績も対象になる ※開発後の反省会では過去が対象 -
適応
計画から外れることは最小限に抑えるため修正が必要
より優れた方法を探索・実践することで改善していく
チームの権限を超える事象は管理できないので適応が難しい
スクラムの価値
- 確約
チーム全員でゴールを達成するためにタスクへ集中して取り組むこと - 集中
ゴールに向けてできるだけタスクに集中できる必要がある - 公開
理論の透明性に関わるところで、開発者と利害関係者はタスクや課題を公開することが求められる - 尊敬
全てのメンバーは意思決定に関与する権利があり、自分だけでなく同じメンバー全員を尊重すること - 勇気
正しいことを行ったり、困難な課題に取り組むための勇気を持つ
スクラムにおける役割
スクラムチームはプロダクト・オーナー、スクラム・マスター、開発チーム(4〜6人)で構成
大規模な開発を行う場合は開発チームの人数を増やすのではなく、スクラムチームの人数を増やして小さくしたタスクをそれぞれのチームに割り振っていく。
プロダクト・オーナーの役割
- 社内外の利害関係者(顧客や社内上層部)と常にコミュニケーションを交わし、彼らの意向をスクラムチームと共有して利害関係者が望むプロダクトに近づけていく
- 製品開発に関わる全ての計画について責任を負う
- 利害関係者を取り巻く経済環境は常に変化しているので、タスクの優先順位を決めて利害関係者の利益になるよう動く。予算と支出の管理も行うので、自社開発であっても何でも作るのではなく、不景気になれば機能を削ったり状況に合わせた取捨選択と優先順位の決定が必要
- 開発中に開発チーム内で発生する製品に対する質問へ答える
- 開発が終わったら成果物のレビューに参加し利害関係者が必要とする物が実際に制作されているかチェックし、反省会も参加して次の開発に活かせる部分は反映させる
スクラム・マスター
- 常にプロジェクトの進行状況を確認してタスクが期日までに終わるか見極め、難しい場合は次に必要なアクションを選択する
- 開発チームをサポートし、アジャイルプロセスが確実に実行されるようにする
- 開発チームに対するディストラクション(散漫すること)を排除する 例：他部署からエンジニアへ直接依頼があることで開発に集中できない。代わりに窓口となって開発チームを開発に集中させる
- １イテレーション中に行う会議全般ではファシリテーターとして会議をリードし、開発チームから不満や改善点などをヒアリングして社内へ共有、必要があれば上層部へ報告して開発チームのパフォーマンスが上がるように取り組む
開発チームの役割
- 製品の制作に取り組み、タスク選定や計画検討時には意見を出し、時には開発者だから分かる内容をプロダクト・オーナーに提案して製品をより利害関係者が求める物へ仕上げられるようにする
- 管理者が居なくてもプロジェクトを自分事として捉え、主体的に取り組むことにより、どうやったらタスクが円滑に進むかを考えながら取り組む
- 一つの技術を深掘りするだけでなく、チームメイトの不在を補強するために他の技術も広く扱えるようにする。逆に自分が不在の時は助けてもらうこともある
- 理想は同じ場所で全員集まって仕事をすること。面と向かってのコミュニケーションを重要視する
チーム構成
-
フィーチャーズ・チーム
ユーザーの要望を直接解決するようなエンドツーエンドの機能を完成させるチームでクロスフィーチャーチームやクロスコンポーネントチームとも呼ばれる。 -
コンポーネントチーム
特定の機能を提供するシステム部品を作り、他のチームからも再利用することができて、システム全体の中で横断的な機能要素を作るチーム。
スクラムのワークフロー
1. プロダクト・ビジョン どのような製品を作るか？
製品の使用者、達成したい目標、製品を使う理由・解決したい課題、競合他社の有無、差別化するに至る特色はあるか
抽象的過ぎず、具体的過ぎない内容にすること
製品設計の大元であり、関係者や開発チームと共有して必要があれば修正し、全員が理解できることを目標にする
制作にあたり役立つソフト：Jira confluenceなど
2. プロダクト・ロードマップ 製品をどれくらいの期間で完成させる必要があるか
製品の目標、優先順位、計画といった製品を作る上で必要な要件を整理
顧客がどのようなサービスを最初に提供したいか。それにあたり開発側だけでなく、顧客は対応する必要があることはあるか。
機能ごとの依存関係などを把握して、制作する順番に反映させる。
最後に上記の内容を鑑みてリリースの日程を決める
制作にあたり役立つソフト：Aha!など
3. プロダクト・バックログ 製品制作に必要なものを細かく分けていく
関係者でブレインストーミングを行い、バックログ候補(アイデア)を出し合う
関係者のプロフィールが載ったペルソナを作ることでお互いを知れて交流の契機になる
バックログ候補を元にユーザーストーリーを作る
ユーザーストーリーは一人称をユーザーとし、顧客が理解できる内容で書くこと。
なぜならユーザーストーリーは後に顧客へ開発途中の経過を説明する時にも開発した内容の名称として使われるので、開発者だけが理解できる内容で書いても意味が無い。
顧客のためには何が必要になるかを定義する
-
モック(製品の試作品)を作る
-
アーキテクチャー設計を行い、サーバーなどのリソースの配置を決める
-
ユーザーストーリーを作るための要件 INVEST
Independent(独立性) 個々のストーリーを順番を考えずにリリースできること
Negotiable(交渉できる) ストーリーの内容は開発中にプログラマーと顧客が協力して決めること
Valuable(価値がある) ストーリー内の機能は顧客(ユーザー)にとって重要・価値があること
Estimable(見積もりできる) プログラマーは適切な見積もりができること
Small(小さく) ストーリー実装の必要時間は短くし、1回のスプリントで2〜3のユーザーストーリー完成が理想
Testable(テストできる) 目的のストーリーが正常に機能することを確認するテストを実施すること -
ユーザーストーリーの見積もり
見積もりにはあまり時間をかけずに簡潔に行う
予定通りにいかない時は具体的な日数を決めずに完了できるかどうかで決める
スプリントが進むにつれて慣れてくるので少しずつ見積もりに正確性が反映されてくる
詳しい調査が必要なものはスパイクを付与する(1スプリントで終わりそうもない等)
見積もり手法：プランニングポーカー(人気)、Tシャツサイズ、ドット投票など
制作にあたり役立つソフト：Visual Paradigm、draw.io、Jiraなど
ユーザーストーリーは通常ユーザーが理解できる内容で記述するが、技術的な話しかしないような部署であればユーザーストーリーを技術者寄りの内容で記述しても良い。
例：3000番ポート開放でサーバーを設置する
※但し、アジャイル開発の原則からは外れるので例外扱い
4. リリース・プランニング プロダクト・バックログから製品リリースに必要な期間を計画
複数のチームで取り組む場合、各チームともリリース日はできるだけ合わせる。
5. プロダクト・バックログの整理
ユーザーストーリーの中で優先順位を決める
6. スプリント・プランニング 細かく分けたバックログの１つずつについて期間、人材などを決める
スプリントの期間で完了可能なユーザーストーリーについて優先順位を基準に選択し、個別にエンジニアへ割り振っていく、若しくはエンジニア側が積極的に手を挙げて対応するユーザーストーリーを決める。
必要であればサブタスクに細分化して取り掛かる。サブタスクの内容は開発に際して細分化しているだけなので、エンジニア側が内容を理解できれば良い。
7. スプリント・バックログ プランニングの中で作業対象となったタスク
スプリント・プランニングを通してユーザーストーリーの中から優先順位を考慮して１回のスプリント(例：2週間くらい)で完了可能と計画・選択した作業内容
8. スプリント 実際に開発に取り掛かる
スプリント・プランニングで選択したスプリント・バックログの内容を実際の開発で実装していく。
スプリント中で自分のタスクが終わったら、同じスプリント内で完了を計画されている他の人のタスクを手伝って、期間内に決められたタスクが終わるように調整する。
9. デイリー・スクラム 開発の進捗などを共有する
昨日のタスク内容、今日予定しているタスク内容、仕事での困りごと(バグ、リファクタリング要素)を共有する。
全体を通して15分前後で行うので、立ったまま行う。
バーンダウン・バーンアップチャートを逐次更新してスクラムの進捗状況を監視する。
10. インクリメント 完成した機能などの成果物をインクリメントと呼ぶ
11. スプリント・レビュー 完成したインクリメントを関係者と共有してフィードバックを受ける
スクラムのスプリント・バックログ上で対象のタスクを説明し、コードとアプリを見せて実際に動作することを見てもらう。
フィードバックを受けてアプリの修正や新しいバックログを追加する
12. スプリント・レトロスペクティブ 反省会
完了したスプリントについて振り返り、改善が必要なところがあるか議論する
改善したいことについて議論して決めたことは議事録として残しておけば後からも情報共有ができる
結論まで至らない議題はアクションアイテムとして残し、担当者と期限を決めておく
進行にあたり役立つソフト：Jira confluenceなど
13. 次のスプリントへ
スプリントに割り当てていたタスクが全て完了していたら次の新しいタスクを割り当てて新しいスプリントを開始する。
タスクが未完了の場合は現在のタスク内容を新しいスプリントに持ち越して継続して開発を進める。
参考にした記事
Jira を使用したスクラムの詳細
スプリント レポート
スクラム プロジェクトのバージョンを設定する
スクラムの「三本柱」と「価値基準」について