【読書記録】アジャイルサムライ

ざっくりわかるアジャイル開発

「価値ある成果を毎週届ける」

・大きな問題は小さくする ・本当に大事なことに集中して、それ以外のことは忘れる ・ちゃんと動くソフトウェアを毎週届ける ・フィードバックを求める ・必要とあらば進路を変更する ・成果責任を果たす

3つの真実

・プロジェクトの開始時点にすべての要求を集めることはできない ・集めたところで、要求はどれも必ずといっていいほど変わる ・やるべきことはいつだって、与えられた時間と資金よりも多い

アジャイルチームのご紹介

チームをアジャイルにするコツ

・同じ現場で働く ・積極的に深く関わる顧客の存在 ・自己組織化 ・成果責任と権限移譲 ・職能横断型チーム

アジャイルなプログラマ

・たくさんテストを書く ・プロジェクトの進行中にも、アーキテクチャの設計と改善に継続的に取り組む ・コードベースをいつでもリリースできる状態にしておく。

常に自分に問いかけるもの

・自分は何が得意なのか? ・自分はどうやって貢献するつもりなのか? ・自分が大切に思う価値は何か? ・チームメンバーは自分にどんな成果を期待しているかと思うか?

  • 入社までにここを文言化しておく。(採用面談時の発言とズレが起きていないかチェック)

みんなをバスに乗せる

プロジェクトを成功させるにはチームの認識を揃えていく必要がある。さらに、それはプロジェクトが始まった早い段階で行う必要がある。

インセプションデッキ

・我々はなぜここにいるのか?(目的、目標の確認)

・エレベーターピッチを作る(要点をまとめる、覚えやすく)

・パッケージデザインを作る(要点をビジュアル化する)

・やらないことリストを作る(作業の集中)

・「ご近所さん」を探せ

・解決案を描く(認識の確認)

・夜も眠れなくなる様な問題は何か?(心配事の共有)

・期間を見極める(スケジュール、工数の把握)

・何を諦めるのかはっきりさせる(優先順位の確認)

・何がどれだけ必要なのか?(コストの確認)

全体像を捉える

全体像を捉えるにはインセプションデッキの以下の5つを揃える必要がある

  • 手を動かし始める前に「なぜ」を明確にする

・我々はなぜここにいるのか?(目的、目標の確認)

  • ポイント 自分自身が現場でニーズを確かめること 司令官の意図を掴むこと

・エレベーターピッチを作る(要点をまとめる、覚えやすく)

  • 得られる効用 ・明快になる ・チームの意識を顧客に向けさせる ・核心を捉える

・パッケージデザインを作る(要点をビジュアル化する)

・やらないことリストを作る(作業の集中)

・「ご近所さん」を探せ

  • 意識すること プロジェクトコミュニティは考えているよりも常に大きい

具現化させる

インセプションデッキの後半5つを揃えていく

  • 「どうやって」の理解を深めていく

・解決案を描く(認識の確認)

  • 確認すべきこと3つ ・どんな風にシステムを構築しようとしているのか図で伝えること ・どこにリスクがあるのかを明確にする ・みんながその解決策に同意しているのかを確認する

・夜も眠れなくなる様な問題は何か?(心配事の共有)

  • チームにとって取り組む値打ちのあるリスクを見極める →チーム内で取り組み可能なリスク(情報共有、ツール統一など)に取り組む

・期間を見極める(スケジュール、工数の把握)

  • 6ヶ月以内に収める(長くなるほどリスクが増大する)

・何を諦めるのかはっきりさせる(優先順位の確認・トレードオフ)

  • 「時間・予算・品質・スコープ」 時間、予算、品質は固定すること。スコープを柔軟にさせることでコントロールする

・何がどれだけ必要なのか?(コストの確認)

  • 顧客が欲しい答えは2つ ・いつ完了するのか? ・いくらかかるのか? →メンバー構成を決めて、最終決定者が誰なのか確認して、工数からコストを計算する

ユーザーストーリーを集める

ユーザーストーリーとは、顧客がソフトウェアで実現したいことを簡潔にまとめたもの

・顧客が理解できるストーリー(非エンジニアでもわかる内容) ・1つ1つのストーリーが独立している ・交渉の余地がある(実現する方法に複数の選択肢がある) ・テストできる(数値目標になっている) ・小さく、見積もりできる(全体像が容易に把握可能なスコープ)

見積もり:当てずっぽうの奥義

見積もりの目的 プロジェクトのターゲットがコントロールによって達成可能なのか判断するため

見積もり方法

・小さなタスクのコストを1として、相対的にタスクのコストを計算する ・見積もりは当てずっぽうという前提を踏まえている ・ソフトウェア開発の複雑さを認めている

アジャイルな計画づくり:現実と向き合う

初回の計画づくり

ステップ1:マスターストーリーリストを作る(顧客が実現したいモノ、リリースを定義する) ステップ2:プロジェクトの規模を見極める ステップ3:優先順位を決める(インパクトの大きいモノ、技術リスクの高いものから順に) ステップ4:チームのベロシティを見積もる(ベロシティ=完了させたストーリーポイント/イテレーション数) ステップ5:期日を仮決めする

1:もし、お客さんが新しい要求を発見したら

  • それをどうしたいのか確認。期日を伸ばして対応するのか・他のタスクをスコープから外して対応するのか

2:もし、思っていたほどは早く進んでないとき

  • 顧客に「計画を過信しないで欲しい」と早期に伝えて、期日の再確認を行う

3:もし、チームメンバーがいなくなったら

  • 2,3イテレーションを対応し、速度を計測する。その結果による影響度を顧客に伝える

4:もし、時間が足りなくなったら

  • スコープを調整する(品質、期間、予算は変化させない)

イテレーションの運営:実現させる

価値のある成果を毎週届ける

・分析:必要な分だけを、必要なときに ・開発:しっかりと! ・テスト:はやめにこまめに

ステップ1:分析と設計(作業の段取りをする) ステップ2:開発(作業する)→コード管理、ビルドの自動化、開発環境の用意 ステップ3:テスト(作業の結果を確認する)

  • カンバンで進捗を管理する

アジャイルな意思疎通の作戦

イテレーションでやるべきこと ・期待をマネジメントすること ・フィードバックを得ること

イテレーションごとに4つのMTGを定期的に実施する ・今回のイテレーションの作業に備える(ストーリー計画ミーティング) ・今回のイテレーションのフィードバックを得る(ショーケース) ・次回のイテレーション計画を立てる(イテレーション計画ミーティング) ・次回のイテレーションで改善できる余地を探す(ミニふりかえり)

  • デイリースタンドアップで毎日すばやくチーム内の情報を同期する

現場の状況を目に見えるようにする

ストーリーボードを作成する

  • チームの意思を明確にする プロジェクトで使う言葉を共有する

ユニットテスト:動くことが分かること

メリット ・素早いフィードバックが得られる ・極めて低コストにリグレッションテストを実行できる ・デバッグ時間を大幅に削減できる ・自信を持ってデプロイできる

  • テストの網羅度は重要でない。運用しやすくなることが大切。

リファクタリング:技術的負債の返済

技術的夫妻は蓄積していくと機能追加、改修するのにかかるコストが増していく>

  • 毎日小さくリファクタリングを続けていく

おおがかりなリファクタリングを実施しようか迷うときは2つのポイントで考える

  • プロジェクトは終了間近か(→間近ならリファクタリングの恩恵は得られない) 少しづつ進めることはできないのか(→できないのであれば、おすすめできない)

テスト駆動開発

・1つ1つのテストを通すように開発するので、同時にたくさんのことを考えずに済む ・テストの粒度を小さくしておけば、素早いフィードバックが得られる

継続的インテグレーション:リリースに備える

ソフトウェアに加えた変更を取り込んで、ソフトウェア全体として統合する作業を途切れることなく続けること

・ソースコードリポジトリ ・チェックイン作業 ・ビルドの自動化 ・作業単位を小さくしようとする姿勢

アジャイルソフトウェア開発宣言

プロセスやツールよりも個人と対話を、 包括的なドキュメントよりも動くソフトウェアを、 契約交渉よりも顧客との協調を、 計画に従うことよりも変化への対応を

アジャイルソフトフェア開発の12の原則

1.顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します。 2.要求の変更はたとえ開発の後期であっても歓迎します。変化を見方につけることによって、お客様の競争力を引き上げます。 3.動くソフトウェアを、2~3週間から2~3ヶ月というできるだけ短い時間間隔でリリースします。 4.ビジネス側の人と開発者は、プロジェクトを通して日々一緒に働かなければなりません。 5.意欲に満ちた人々を集めてプロジェクトを構成します。環境と支援を与え仕事が無事終わるまで彼らを信頼します。 6.情報を伝える最も効率的で効果的な方法はface to faceで話すことです。 7.動くソフトウェアこそが進捗の最も常用な尺度です

8.アジャイル・プロセスは持続可能な開発を促進します。一定のペースを継続的に維持できるようにしなければなりません。 9.技術的卓越性と優れた設計に対する不断の注意が機敏さを高めます。 10.シンプルさ(ムダなく作れる量を最大限にすること)が本質です。 11.最良のアーキテクチャ・要求・設計は、事故組織的なチームから生み出されます。

12.チームがもっと効率を高めることができるかを定期的に振り返り、それに基づいて自分たいのやり方を最適に調整します。

まとめ

自分はこれまでアジャイル開発の経験が無かったため、この書籍からアジャイル開発のゼロから学ぶつもりでいたのですが、開発現場全般的にも当てはまることが多っかたのが印象的でした。 特に「時間・予算・品質・スコープ」の考え方は、自分もプロジェクト進行する中で大切にしていることなので、何度も頷きながら読んでいました。

また、時間を空けてから読み直したい素敵な書籍でした。

先頭に戻る