アジャイルサムライ(要約) その9
1.価値ある成果を毎週届ける
ユーザーストーリーをリリース可能な動くソフトウェアに変換するため、肝に銘じておかなければならない3つ。
- 全てを文書にまとめる時間はない。要求・分析は必要な分だけアウトプットとして残す。
- ひっきりなしに手戻りやバグ修正している時間的余裕はない。コードは常にきちんと設計し、ばっちり結合テストを行う。
- テストは開発と一緒に進め、プロジェクト初日からシステムが適切に動作し続けるようにしなければならない。
2.アジャイルなイテレーション
イテレーションの期間を通じて、顧客にとって優先順位の高いものから順番に、開発チームがストーリーをちゃんと動くソフトフェアへと変換する。
予期せぬ事態が発生した場合は、そのイテレーションが終了した時点で軌道修正を行う。ただし、イテレーションの途中では作業対象のストーリーを変更しない。
- 1:分析と設計:作業の段取りをする
-
アジャイルな分析には2つの重要な柱(必要な分だけを、必要なときに)がある。
必要な分だけ分析するにあたり、顧客もチームも同じ職場にいるならば、インデックスカード(ストーリー)と会話(あとちょっとした図)で事足りる。
もう少し規模が大きくて、いくらか場所が離れているチームの場合は、概要を1ページくらいに短くまとめた文書、ストーリーをタスクに分解したリスト、テスト条件の一覧などはあったほうがよい。
最初は小さく始め、作業を増やすのは、本当に必要になってから。
必要なときに分析する―ジャストインタイム分析とは、ユーザーストリーを実装するタイミングが近づいてきてから分析する。
具体的にはストーリーの実装を予定しているイテレーションの1つ前のイテレーションで分析することになる。
ジャストインタイム分析を実践すると次の3つの効果が得られる- 最新かつ最も充実した情報に基づいて分析できる。
- プロジェクトが進むにつれて分析がうまくなっていく。
- 手戻りが大量に発生することを避けられる。
- 1.フローチャート → 目に見えるかたちで、システムの動作や必要な手順が分かる
- 2.ペルソナ → ソフトウェアのユーザを役割ごとに説明
- 3.ペーパープロトタイプ → デザインをたくさん作る
- 4.受入テストシナリオ → 顧客と相談してストーリーの満足条件を定義する
- 2:開発:作業する
-
リリース可能なソフトウェアを実装するのは簡単なことじゃない。アジャイルプロジェクトではやらなければならないことがいくつもある。
- 自動化されたテストを書く
- 設計を継続的に発展させていき改善し続ける
- ちゃんと動くソフトウェアであり続けるために、コードを継続的にインテグレーションする
- 顧客がシステムについて語る言葉に合わせてコードを書く
イテレーションゼロという期間を設けて、開発作業の準備を整える(ソースコード管理のセットアップ、ビルドの自動化設定)
- 3:テスト:作業の結果を確認する
-
アジャイルなプロジェクトでは何もかもテストしているが、リリース前の正式な受入テストは必要。アジャイル開発の目標はいつでも受入テストできるようにすること。
結局、顧客に本気を出してもらえるのは最終的な受入テストのスケジュールが迫ってきてからなので、正式な受入テストは無くさない方がよい。
3.カンバン(本書では7項となっている)
運用やサポートといった業務にうまく適用できるアジャイルな仕事の進め方の流儀
※カンバンのサンプル
カンバンでは仕掛り(WIP:Work In Progress)にできる作業に上限を上限を設けている。
チームが同時に着手する作業の数はこの制限を超えてはいけない。 WIPの上限が4の場合はチームとして同時に着手して構わない作業は4つまで。後回しにした作業に優先順位をつけて、手が空き次第、次の最優先作業に取り掛かる。
カンバンではイテレーションが必要ない。チームが気にかけるのは作業リストにある優先順位の最も高い作業だけで、手が空いたら最優先の作業に着手する。
カンバンでは仕事の流れをスムーズにすることが狙いである。
※カンバンのサンプル
カンバンでは仕掛り(WIP:Work In Progress)にできる作業に上限を上限を設けている。
チームが同時に着手する作業の数はこの制限を超えてはいけない。 WIPの上限が4の場合はチームとして同時に着手して構わない作業は4つまで。後回しにした作業に優先順位をつけて、手が空き次第、次の最優先作業に取り掛かる。
カンバンではイテレーションが必要ない。チームが気にかけるのは作業リストにある優先順位の最も高い作業だけで、手が空いたら最優先の作業に着手する。
カンバンでは仕事の流れをスムーズにすることが狙いである。
0 件のコメント:
コメントを投稿