アジャイルサムライ 第2章 アジャイルチームのご紹介

アジャイルサムライの第2章へ進みます。特に決めていませんが1日1章くらい進みそうなのでいつもの章毎に書影を貼るのは、今回は部の始めごとにしておきます。

  • アジャイルチームには役割分担がない
  • 分析、設計、製造、テストなどの工程が連続的に(並行して)行なわれる
  • チーム一丸となって成果責任を果たすことを重視
    • 成果責任という言葉がまた出てきましたね。「成果責任」と「期待のマネジメント」はまだよく意味が理解できていない語彙です
    • 縦割りの組織ではなく、誰もが成果物の品質に責任を持つ
  • 同じ仕事場で作業する。できるだけ直接集まってコミュニケーションとれる機会を持つ
  • 開発に積極的にかかわる顧客
  • 自己組織化
    • 役割に人を合わせるのではなく人を役割に合わせる
    • 自分から動ける人でないとアジャイルチームに向かない
    • 成果責任と権限委譲
    • 顧客へのデモ → 成果責任に自覚的になる
  • 職能横断型チーム
  • アジャイルチームにおける役割 - 役割分担あるじゃん
    • 「顧客」と「開発チーム」 - ごめんやっぱなかった
    • 「アジャイルな顧客」
      • 「feature を決める」「feature の優先順位を決める」「やらないことを決める」
      • やっぱりこの「顧客」の役割が超重要そう。そしてこの「顧客」はかならずしもエンドユーそのものでなくても良いのかもしれない
      • 顧客のフィードバックを得ようとすることと信頼を得ることが重要
    • 「アジャイルな開発チーム」
      • 誰もがなんでもやる
      • 「アジャイルなアナリスト」
        • 顧客が feature を書くのを手伝う
        • 分析、調査
        • モックアップ・プロトタイプの作成
      • 「アジャイルなプログラマ」
      • アジャイルなテスター
        • feature のテスト(受入試験)を書くのを手伝う
        • feature の実装が期待通りに動くことを確認する
        • テストの全体像を考える
      • 「アジャイルなプロジェクトマネージャ」
        • 進捗を確認し、「伝える」←ここ重要ね
        • チームの障害を取り除く
        • 「指示」をすんじゃなくチームが思う存分機能できるように地均しする
      • 「アジャイルなUXデザイナ」 UX=User eXperience かな
      • アジャイルコーチ - アジャイル開発手法をチームに浸透させるための指導者的役割
  • チームメンバを探す
    • ゼネラリスト
    • 曖昧な状況に抵抗がない人
    • チームプレイヤー

第2章を読んで、アジャイルなチームを構築するということは、今のメンバを育て上げているというだけじゃなくて、場合によっては不適者を放逐し必要な新メンバーを招き入れるなどの方法も必要なんだなぁとあたりまえのことを思いました。あたりまえではあるけど、これ通すの結構大変ですよね。人材の移動がプロジェクトマネージャの権限の及ぶ環境でないと。