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

読んだメモです。

 

アジャイルについての書籍としては有名も有名な本書、今更ながら手を付けてみました。文体がゆるく挿絵も多いのでサクサク読める。

前半はアジャイルの概要、計画、実施と時間軸に沿った流れ。

後半はTDD、リファクタ、CIと開発寄りの話もあるため非常に網羅的です。

 

開発の話はこの本でなくても触れられることは多いと思うため、開発者の視点でアジャイルとはなんぞやのポイントをメモします。

なお、言葉尻は勝手に噛み砕いたもので、本書内の文面とは異なります。

 

アジャイルの原則

  • 目標をどうやって達成するのかをみんなで客観的に考える
    自己組織化されたチームビルディングを目指す仕組み
  • 自己組織化とは自らのエゴを押し出しすぎないようにチームで力を合わせること

ビジネス側の人間と開発者はプロジェクトを通して一緒に働かなくてはならない

  • アジャイル手法によって異なるが顧客 = オンサイト顧客 = プロダクトオーナー
  • スクラムにおける顧客はプロダクトオーナーと同義
  • 顧客:何を作るかを決める、優先順位をつける、スコープを決める
    開発チーム:どうやって作るかを決める

アジャイルチーム

  • 職能横断型チームをつくる
  • 役割分担をきっちりしない

プロダクトの効能

  • ユーザにはフィーチャを伝えない
  • 関心を持つのは、そのプロダクトでどれだけ楽になるか

荒ぶる四天王

  • 時間、予算、品質、スコープ
  • 時間、予算、品質は動かすことが難しいので固定する
  • スコープ(計画)が現実にそぐわないなら変更する

ユーザーストーリー

  • 要求の収集の目的はフィーチャのありとあらゆる詳細を聞き出すことではない
  • 本質を捉えるキーワードをユーザーストーリーとして書き留める
  • 詳細は必要になったときに検討する
  • ユーザに価値をもたらす言葉でストーリーを書く
  • それぞれのストーリーは独立し、価値があり、見積もりができ、小さく、テストができる
  • ストーリー収集はすべてを実装するのではなく全体像をつかむため
  • 優先すべきは深さではなく幅
  • ストーリーが数百もある場合は遠くまでの計画を立てているか詳細すぎる

見積もり

  • 見積もりは当てずっぽうだという前提を踏まえる
    前もって正確に見積もるのは不可能
  • 見積もるのは達成可能な程度に現実的かを判断するため
  • 時間をかけてストーリーそれぞれ互いを相対的サイズで見積もる

アジャイルな計画

  • 途中でストーリーを追加するときは既存のストーリーを削る
  • 最初のリリースは「最少であること」「市場価値があること」が柱
  • システムは端から端までつないでエンドツーエンドで確認しておく
  • 個人の生産性を測るのはプロジェクトマネジメントのダークサイド
    協調、知見の共有の態度が薄れる
  • バーンダウンチャートで状況を可視化
    完成させた仕事、残っている仕事、ベロシティ、いつすべてが完了するか

アジャイルな運営

  • ユーザーストーリーに対して分析して設計開発テストの3ステップ
  • スプリント前に分析と設計をして詳細を掘り下げる
  • ユーザーストーリー単位のテスト条件(受け入れテスト)を決める
  • テスト条件をプロダクトーオーナーと合意する
  • 完成していないストーリーはゼロとして扱い次のスプリントへ持ち越し
    テストまで終わったストーリーだけベロシティに追加

 

主観だと実施や運用につい目がいってしまい挙げていませんが、インセプションデッキの意義、アジャイルチームの意識の統一、役割ごとのふるまいなど参考になるポイントが多く間違いなく良書でした。
さっそく取り込めるものから少しずつ改善していきたい。

受け取り方が間違っているものがあれば指摘してもらえると幸いです。

 

アジャイルサムライ−達人開発者への道−

アジャイルサムライ−達人開発者への道−