書評)More Effective Agile

 

感想

「ソフトウェアリーダーになるための28の道標」という副題の通り、アジャイル開発プロセスを実践する上での各所勘所が28のトピックにまとめられています。

 

冒頭で「筆者は『うまくいくもの』の提唱者であり」と述べている通り、本の内容は経験に培われた実務目線のプラクティスでした。

例えばスケジュール予測をビジネス側が理由あって必要としている場合にプロジェクト初期ではシーケンシャル開発のプラクティスを適用する話や、エピックに割り当てたストーリーポイントをそのエピックの予算として扱う考え方など。

 

一つ一つのトピックはそれほど長くない為、今課題に感じてるところを読み返して参考文献で深ぼったりという使い方で今後役に立ちそうです。

 

内容的にリーダー職の参考になる話も多く、個人的にはPDL(Professional Development Ladder)をつかってキャリアパス制度を導入する話は深ぼって業務に役立てたいトピックでした。

 

 

ポイントサマリ 

より効率的なアジャイル

  • Cynefin(クネビン)フレームワークによる考察
    • 分析を持って対処が特定できる領域はシーケンシャル開発の領域
    • 多くのソフトウェア開発は実験が伴う複雑系、そこでシーケンシャル開発がうまくいかないことがアジャイル開発を生み出すきっかけ
  • OODAループ
    • 観察を起点にジャストインタイムでプランニングから実装まで反応的に作業
    • 短期的な作業にコンテキストを与えるために長期的な計画から目を離さないようにする
    • あらゆる要因に検査と適応が必要

 

より効率的なチーム

  • 職能横断
    • チームが決定を下す能力と権限を持つ
    • 組織との間にその為の信頼とチームの成熟度に応じたサポートがある
  • テスト技術者のチームへの統合
    • 開発者は自分の作業を自分でテストする
    • テスト技術者はより高度なテストプラクティスにより付加価値を与える
  • プロダクションサポート(オペレーション)の組織化
    • サポート時間をスプリントに盛り込む
    • 割り込みを許容するポリシーを定める
    • レトロスペクティブで見直す
  • ブラックボックスとしてのアジャイルチーム
    • マネージャーは細部に首を突っ込まず、チームの方向性が明確であることを確認し、チームが責任を持ってその方向へ向かうように働きかける
    • 妨害やスプリントの中断からチームを保護する
    • 育成や採用などでチームを支援する

 

チーム文化

  • 内発的モチベーションによるチームの動機付け
    • 自律
      • 仕事をチームがマネジメントする
      • マネージャーは方向性を以ってチームをリードし、その方向性にコミットする
    • 熟達
      • 成長の機会を与える
      • 学習と挑戦を支援する
    • 目的
      • なぜ重要なのかと全体像を伝える
      • 情報の透明性を高める
      • 顧客、ビジネスと交流させる
  • 成長マインドセットを培う
    • タスクをただこなしソフトウェアを作ることだけを目的としない
    • そのソフトウェアを作るチームの成長もプロジェクトの目的の1つとする
  • ビジネスフォーカスを培う
    • 開発者が実際の利用ユーザーと直接交流することで人生が変わるような体験をすることはよくある
    • ユーザーの問題をバランスの取れた視点で捉えるには、ユーザーとの継続的な触れ合いが必要

 

分散チーム

  • 地理的に分散しているチームはフィードバックループがルーズになる
  • ベストプラクティスは出来るだけ自律的に活動できるチーム(職能横断)をそれぞれの場所に配置すること
  • 対面でのコミュニケーションを定期的に
  • 設備、ツールを充実させる
  • リモートにPOやEMの代理人を立てる
  • 地理的にチームを再編する場合、コンウェイの法則に従い、アーキテクチャと組織のGap無くすようにする

 

個人及び対話

  • 3種類の専門的な能力を開発する
    • テクノロジに関する知識
    • ソフトウェア開発プラクティス
    • 専門分野、ビジネスに関する知識
  • PDL(Professional Development Ladder)をつかってキャリアパス制度を導入する
    • 文献: Career Pathing for Software Professionals
  • チームでの効果的な対話
    • EQ: Emotional Intelligence を向上させる
    • 性格タイプの違いを理解してコミュニケーションする
    • タックマンモデルに現れるチームの4つの成長段階
      • 今チームがどの段階にいるかを理解することでその状況が普通であると安心し、次の段階への速やかな移行を促す
    • 他者の成功をどのように手助けすればよいかについて考える発想の転換はチームに道徳的な力を育むのに役立つ
      • Rotary International の4つのテスト(The Four-Way Test)にパスする決定や対話はチーム全体の強化につながる
        • それは事実か
        • それはみんなにとって公平か
        • それは好意と友情を深めるか
        • それはみんなのためになるか

 

プロジェクト

  • プロジェクトを小さく保つ
    • 成功率と一人当たりの生産性が上がり、エラー率が下がる
  • スプリントを短く保つ
    • 新しい要求、フィードバック、改善、実験への反応性が高まる
    • リスクの顕在化が早まる
    • チームと個人の説明責任がより明確になる
  • バーティカルスライスによるデリバリー
  • 技術的負債を管理する
    • 返済のための計画を立て、ビジネスと話し合う
  • 持続可能なペース
    • 常に同じスプリントを継続することはハムスターの回し車のよう感覚を覚えることがある
    • 例えば一週間スプリントを挟み普段できない改善や学習をする

 

大規模なプロジェクト

  • 大規模なシステムにとっての理想は、そのプロジェクトに取り組むチームの作業を完全に分割できるようなもの
  • コンウェイの法則からアーキテクチャと人間組織両方に目を向ける

 

品質

  • 欠陥の挿入と検出の時間的GAPを最小限にし、潜在的(見つかってない)な欠陥を最小限にすることでリスクを最小限にする
  • 明確な完成の定義を作り使用する
    • 定義を満たしたものからQAが可能となる
  • リリース可能な品質水準を維持する
    • スプリントごとにリリース水準を維持していれば欠陥の挿入と検出のギャップが最小限になり負債の蓄積を回避する
    • またそれ以上の作業は不要であることを意味し、計画のトラッキングをサポートする

 

テスト

  • ユニットテストとユーザーレベルのテストの自動化
  • テストカバレッジ70%が現実ライン、ただそれが目的ではない
  • テストカバレッジはコードの質を担保しないのでコードメトリクスを監視する

 

要求の作成

  • アジャイルでは要求の推敲をジャストインタイムで行う
  • クネビン複雑系の問題に対して、フィードバックループをタイトにすることで不確実性による要求の仕損を最小限にする考え方
  • プロダクトバックログ(PB)
    • 複数スプリントにまたがるフィーチャーやエピック、1スプリントで完結するストーリー
    • それ以外にテーマやアイディア、技術的負債への対応など
  • PBへのアイテム追加
  • PBのリファインメント
    • 継続的に実施し予想外の展開に何度も出くわさないように
    • 十分にリファインメントされたPBLがスプリント2つ分あるようにする
  • 準備完了の定義を作成し、使用する

 

要求の優先順位付け

  • PO重要
    • 専門分野の専門知識
    • ソフトウェア要求のスキル
    • ファシリテーションスキル
    • 決定者が決める時とグループが決める時の心得
    • エネルギッシュに一貫してやり遂げる特性
  • ビジネス価値と開発コストをTシャツサイズに分類し、非技術系のステークホルダーが判断を下せるようにする
    • ビジネス価値と開発コストのマトリックスで正味のビジネス価値を数字で割り当て判断する
      • 上位のストーリーは即座に承認
      • 下位のストーリーは却下
      • 中間のものはその後の見直しで動く可能性がある
  • ストーリーマッピングにより機能を首尾一貫したパッケージにまとめる
  • MVPが難しい場合
    • Earliest Testable Product
      • 顧客が何かを試せる最初のリリース
    • Earliest Usable Product
      • 新しいもの好きの顧客が実際に使ってみようと考える最初のリリース
    • Earliest Lovable Product
      • 顧客に気に入ってもらえそうな最初のリリース

 

デリバリー

  • ソフトウェア作業はデプロイに近いほど自動化に適している
  • 自動化が不可能な要求、設計、構築を自動化が可能なデリバリーとデプロイから切り離すことが鍵
  • 頻繁な統合により欠陥の挿入と検出のギャップを最小限にする

 

リーダーシップ

  • リーダーはチームとスプリントをブラックボックスとして扱い、スプリントのインプットとアウトプットだけを管理する
  • リーダーはチームの決定を導くための「司令官の意図」を伝える
    • プロジェクトの理由と動機、背景の明文化
    • 求められている最終状態を可視化
  • リーダーは優先順位を決めて伝える
  • チームは自分たちの責任と裁量でスループット、作業が完了するペースにフォーカスする

 

組織文化

  • 必要な間違いを素早く犯し学習することを良しとする
  • チームに心理的安全性があるか、阻害する要因がないかに注意し、有れば取り除く
  • 圧力ではなくキャパシティの計測に基づいてプランニングする
  • チームの学習と成長を後押しする
    • 持続可能なペース
    • ラクティスコミュニティなどの機会
  • 発展途上なら組織の他のリーダーを参加させる

 

計測

  • ベロシティと共に手戻り率にも注意し改善する
  • 計測の目的について透明性を保つ
    • チームの自己改善を支援することも1つ

 

プロセス改善

  • 人ではなく仕組みを改善する
  • 改善を取り入れた前後数回のスプリントのペロシティの平均を取れば生産性の向上がわかる
  • チーム間のベロシティの比較は意味がないが、向上率は比較できる
  • スループットを低下するWIPのネックを改善するにはカンバンとリーンが役に立つかもしれない
  • アジャイルの焦点はチームにあり、個人のベロシティは外部変数が多すぎて意味のある計測はできない

 

予測可能性

  • シーケンシャル開発は固定したフィーチャーに対してスケジュールを予測することに焦点
  • アジャイル開発は固定したスケジュールの中で最も価値の高いフィーチャーをデリバリーすることに焦点
    • ただ、バックログを定義した後は見積もりを予測することが可能
  • 予測可能性のサポート
    • ストーリーポイントの割り当て
    • ベロシティの計算
    • 小さなストーリー
    • バックログリファインメント
    • 短いイテレーション
    • リリースバーンダウン
    • ベロシティのばらつきから信頼区間を予測する
  • 実際には予測の対象が絶えず変化するため、予測とコントロールの組み合わせである
  • エピックのストーリーポイントをそのエピックの予算と考える方法もある
    • エピックが55ptであればその中で価値を最大にするストーリーを選ぶ
  • 予測を重視するのであれば初期作業をシーケンシャルに取り組む
    • ただし複雑系の要素が多いのであれば確実に予測するのは不可能になる
    • 複雑系に分類された作業は予測から調査に切り替える
  • 見積もりを必要としているビジネス側を否定することは、顧客とのコラボレーション原則に反する

 

規制産業

  • ドキュメントの作成、リリースサイクルの変更などが必要になるがアジャイル開発は不可能ではない、という話
  • 完成の定義や自動化などのプラクティスは規制の目的、品質を後押しする
  • 規制上の要件が、法律ではなく古い企業文化に基づく場合は改善の可能性がある

 

ポートフォリオマネジメント

  • WSJF: Weighted Shortest Job First
    • CoD: Cost of Delay を突き止め CoD / 開発期間 = WSJFの高いものから開発することで機会損失を最小限にする考え方
  • 全てを平行し最後に一度にリリースするのは機会損失ワースト
  • コストが明確でない場合もストーリーポイントやTシャツサイズの考え方を流用できる

 

導入

  • ドミノ変革モデル: 次の順で1つでも欠けるとうまくいかない
    1. ビジョン: なぜやるのか、どうよくなるのか
    2. コンセンサス
    3. スキル
    4. リソース: 時間、専任者、ツール etc.
    5. インセンティブ: 自律、熟達、目的
    6. アクションプラン
  • 導入にもキャズム理論が当てはまる
    • 最初の導入はイノベーター、アーリーアダプターのような人が良い
    • 組織の人々の大多数は後期のアダプターでありより多くの支援を必要とする