Zenn
💬

書籍「More Effective Agile」を読んだので"超ざっくり"でまとめてみた

2021/05/30に公開
チーム開発
tech

購入リンク

より効果的なアジャイル

1章-2章

アジャイル開発とシーケンシャル開発を比較している
主に違う下記は

シーケンシャル開発 アジャイル開発
長いリリースサイクル（数ヶ月、数四半期） 短いリリースサイクル（数日、数週間）
開発を"大きく"区切って行うよ 開発を"小さく"区切って行うよ
事前に詳細なプランを立てる ギリギリで詳細を決める
最後にテスト 継続的にテスト
不定期にに共同作業する 頻繁に定期共同作業する
理想、制御思考 臨機応変、改善

3章

cynefin（カネヴィン？クネビン？）フレームワーク、状況に適した戦術がわかるよ

  1. 単純系・・・問題がわかってて、解決策もある状況👉把握、分類、対処
  2. 煩雑系・・・問題の全体像はわかってて、解決の糸口もある状況👉把握、分析、対処
  3. 複雑系・・・専門家を持ってしても、すぐにはわからない状況👉調査、把握、対処
  4. 混沌系・・・問題が流動的で、解決方法もわからない👉行動、把握、対処
  5. 無秩序・・・何に当てはまるかわからない👉問題を細かく分けて、上記の4つに当てはめてみる

複雑系の問題を解決したい！OODAを試そう
OODA・・・観察、方向づけ、意思決定、行動のサイクルをぐるぐる回すこと（ショートカットしてもええんやで）

より効果的なチーム

4章

スクラムの流れ

  1. プロダクトバックログ（重要度と緊急性が高いものから書かれる）を作成
  2. 見直しでスプリントプランニングミーティングを行う
  3. スプリントバックログ（タスク）に取り込む
  4. スプリントを進める（1~3週間）
  5. デイリースクラムの実施
  6. スプリントレビュー（スプリント中の機能をデモ、FBをもらう）を行う
  7. インクリメント（開発した機能）の提供
  8. スプリントレトロスペクティブ（振り返り）を行う

スクラムが失敗する大きな理由は上記を正しく行わないことが挙げられており、規律正しく行うことが重要とされている
スコアカードなどを使い改善に繋げる

5章-7章

アジャイルチームで必要なもの

  • 決定をくだす能力がある👉専門知識があるチーム
  • 決定を下す権限👉チームの決定が外部から覆されないようにする
  • テスト技術者は起用させる👉テスト専門知識は必要
  • ブラックボックス化👉要点だけを伝える、首を突っ込みすぎない
    チームの内発的なモチベーションの維持、動機付け
    自立・・・信頼と結びつくもの、自立性を養うことで機能横断的チームを築きあげることができる
    熟達・・・学習と改善を願うことを指し、基準を満たすことに満足せず上達していこうという考え方
    目的・・・なぜそれを行うのか、理解するために必要、仲間意識が強くなり、目的意識を養われる
    分散チーム構成を正しく行う
    開発とテストが別のところで行われたり、プロダクトオーナーと開発チームが別の場所にいたり、テストチーム、開発チームのように分けないようにする
    機能ごとに別れ、似たような構成のチームが分散されるように設定、リーダーはチームの後方支援を強化する
    👉コミュニケーションの質、頻度をあげること

8章

チームメンバーの役割の密度を高くする

  • テクノロジに関する知識
  • ソフトウェア開発プラクティス
  • 専門分野に関する知識
    チームのEQ（こころの知能指数）をあげよう
    色々な役職、性格タイプとのコミュニケーションをこなそう
    win-winな対話を志そう

より効果的な作業

9章

プロジェクトを小さく保ち、スプリントを短く保つことでエラーを最小限に抑える
プロダクトに対するフィードバックはバーティカルスライスによるタスクの切り分けが必要、捉える単位を作業そのものではなく、ユーザーの視点に近づける
技術的負債を管理することが重要

10章-12章

大規模なプロジェクトはスクラムから始めよう
欠陥のギャップをできるだけ小さくするために、完成定義などを用意しておく
リリース可能な品質の維持と手戻りを減らすこと
👉ペアプロやモブプロを検討しよう
開発チームが作成した自動テストを使用し、開発者が自分のコードをテストする責任をもとう
👉もちろんテストコードを記述する際は慎重に

13章-15章

アジャイルでは多くの要求は完全に定義されていない
cynefinの複雑系では下記が課題になるため、要求を定義しすぎると無駄になる

  • 要求が変化する
  • 要求が取り下げられる
  • それほど必要ではない要求が実装される
  • 要求が見落とされているか、プロジェクトの途中で明らかになる
    プロダクトバックログには下記を配置
    しっかりと要求の優先順位を決める
    自動化できるところはどんどん自動化していこう

より効果的な組織

16章-23章

リーダーは細部ではなく、成果を管理し、明確なビジョンに基づく成果を期待する
チームの自立性と目標の明確性を高め、優先順位を決定し、それを伝える
間違いを許容し、それを期間内に正す
エスカを許す文化を作り、メンバー心理的安全性を高めよう
チームのキャパシティ、品質の計測をきちんと行い、期待値を設定する
スプリントレトロスペクティブなどを利用して検査を行ったり、ワークフローをきちんとマッピングする
コストとスケジュールを予測し、大まかな対処法を考え柔軟に対応する
規制産業には「シーケンシャル型」と「アジャイル型」をコラボさせる方法も有効で、アジャイルに拘らず、ビジネスを最も効果的に支援するにはどうするかを常に考えよう
スクラムの導入は、キャズム理論に紐づくため、アーリーアダプターの意見を取り入れつつアーリーマジョリティへの展開を考える

GitHubで編集を提案

Discussion