◀︎其の1はこちら
◀︎其の2はこちら
◀︎其の3はこちら
◀︎其の4はこちら
◀︎其の5はこちら
◀︎其の6はこちら
◀︎其の7はこちら
◀︎其の8はこちら
◀︎其の9はこちら
◀︎其の10はこちら
◀︎其の11はこちら
◀︎其の12はこちら
こんにちは!
ラジコード編集部です 😊
アジャイルサムライを読む連載記事その9です!😃
前回は第3部 アジャイルな計画づくり の「第8章:アジャイルな計画づくり:現実と向き合う」で、マスターストーリーリストを作り、リストの規模を見極め、フィーチャの優先順位決められるようにする事で状況に合わせて計画変更に対応できるということがわかりました
それでは「第4部:アジャイルなプロジェクト運営 第9章 イテレーションの運営:実現させる」を読んでいきましょう。
よろしくお願いします!🙋♂️
本シリーズは「アジャイルサムライ − 達人開発者への道」を1〜5部を1~2記事に分け要点を解説していくシリーズです。全13記事を予定しています。
もくじ
第9章 イテレーションの運営:実現させる
第2部(その3 / その4 / その5)と第3部(その6 / その7 / その8)でプロジェクトの計画を立てることができました。
本章では計画をもとにお客さんの実現させたい思い・実際に使えるもの・動くソフトウェアを形にする方法を学びます。
さて、計画を形にしていくために肝に銘じることが3つあります。
- すべてを文書にまとめる時間はない
必要な分だけ必要なときにアウトプットできる方法が必要です。 - 開発プラクティスをプロジェクトに根付かせる
手戻りやバグ修正にばかり時間を裂けません。コード設計・テストをしっかり行い、実装開始直後から動く状態にしましょう。 - テストは開発と一緒になって進める
プロジェクト初日からシステムが適切に動作し続けるようにする。
以上の3つをチームが実践できれば、毎週価値ある成果をお客さんに届けられるようになります。
そのための枠組みがアジャイルなイテレーション(一連の工程を短期間で繰り返す開発サイクル)です。
イテレーションの期間(1週間か2週間)を通じて、顧客にとって優先順位が高いものから順番に開発を進めます。
イテレーションのゴールはお客さんにとって価値のある成果を届けることです。
イテレーションを使って作業を進めていけば、優先順位が変わった・予期せぬ事態が発生したなどの場合も、そのイテレーションが終了したときに軌道修正できます。
ここからは具体的にユーザーストーリーをリリース可能なソフトウェアに変えていく段取りを見ていきましょう。
開発中に新しい機能が必要になった。あれもこれも必要という気になってくる。
そういう時は、新しいストーリーを追加するときは必ずどれかひとつ既存のストーリーを削りましょう。
このルールを実践できると、開発側は顧客に要求変更の機会を提供しつつ、スコープをプロジェクトで作業できる範囲内に留めておけます。
- 分析と設計 : 作業の段取りをする
「必要じゃ分だけを、必要なときに」実際に作業を進めていくうえで必要な分だけを分析することです。
判断基準は、チームにとって適切なレベルで分析されているかです。余計な負担をかけてチームの速度を下げないように、最初は小さく始めましょう。
- 開発 : 作業する
リリース可能なちゃんと動くソフトウェアの実装は簡単にはできません。
アジャイルプロジェクトでは以下のことをやらないといけません。
- 自動化されたテストを書く
- 設計を継続して発展させていき、改善し続ける
- ちゃんとした動くソフトウェアであり続けるために、コードを継続的にインテグレーションする
イテレーション・ゼロ
具体的なストーリーの実装に取り掛かる前に済ませておきたい段取りを整えることがイテレーション・ゼロです。
バージョン管理をセットアップ。ビルドを自動化。コードのデプロイ先を準備。開発環境やテスト環境も用意する。
- テスト : 作業の結果を確認する
アジャイル開発者の目標は、いつでも受入テストできるようにすることです。
プロジェクトが「開発期間」の途中では、開発チームがしっかりとテストをしようと、お客さんになかなかシステムの間違いを血眼で探してもらえません。
お客さんが本気を出すのは、最終的な受入テストが迫ってきてからです。
お客さんにデモをしながら、ストーリーの受入テストをチェックしていくのはいい方法です。
カンバンはトヨタが開発した情報伝達システムに由来します。
カードを使って、組み立てラインでのパーツ補充の工程を調整する仕組みをカンバンと呼んでいます。
カンバンの狙いは、仕事の流れをスムーズにすることです。一度に取り掛かる仕事の数を少なくし、それをできるだけ早く終わらせる。この流れをボード上で目に見えるようにします。
カンバンには以下の利点があります。
- イテレーションのプレッシャーから開放される
- 1回のイテレーションに収まらない仕事にも取り組める
- 期待をマネジメントしやすい
イテレーションを回すだけがアジャイル開発ではありません。
「アジャイルである」ということは、チームに役に立つことなら何でもやるということです。
プロジェクトにあった手法を選んで前に進むことが大事です。
以上「第4部アジャイルな計画づくり:第9章 イテレーションの運営:実現させる」の解説でした。
価値ある成果を継続的に届けるための手法(イテレーション・カンバン)を選んでプロジェクトを運営する必要があるということが分かりましたね。
次回は「第10章:アジャイルな意思疎通の作戦」を読んでいきましょう😌
- アジャイル宣言の背後にある原則
- アジャイルソフトウェア開発宣言
- アジャイルサムライ − 達人開発者への道
オーム社 (2011/7/16)
著者:Jonathan Rasmusson 著/西村直人・角谷信太郎 監訳/近藤修平・角掛拓未 訳
月額固定・定額制でアジャイル開発を提供する「サブスクエンジニア」サービスを提供しています。よろしければご覧ください!