- 作者:ＪｏｎａｔｈａｎＲａｓｍｕｓｓｏｎ,西村直人,角谷信太郎
- 発売日: 2017/07/14
- メディア: Kindle版
漠然とプロジェクトマネジメントに関する理解も深めたいなと考えていて、評判が良かったのもあり読んでみた。
エンジニア組織論への招待よりも、アジャイルに関する情報が1段階深く、かつアジャイルに必要な考え方を分解して書かれている印象。
読むと真似したくなるTipsが多く、少しずつ実務に取り入れていきたい。
以下は各セクションに関するメモ
第I部 「アジャイル」入門
第1章 ざっくりわかるアジャイル開発
- 価値ある成果を毎週届ける
- 成果 = 動くもの
- 1週間で終わらなそうな場合は、もっと小さい単位に分解する
- ただし、どうしても分割できないものもあるので、そこは柔軟に考える
- 毎週、にこだわらず、タイムボックスも柔軟に決める
- ソフトウェア開発の大前提
- 要求は初期段階で全ては揃わない
- 要求は変わる
- 確保できる時間より、要求されているタスクのほうが多い
第2章 アジャイルチームのご紹介
- 役割に仕事をふるのではなく、仕事に必要な役割を演じる
- 開発完了まで担当するので、品質保証も自分たちでやる
- 自己組織化されたチームに必要なのは、役割ではなく目的達成のために動ける人
- その人に、適切な権限を移譲する
- 役割を固定しないほうが良いが、理解への第一ステップとして各役割のアジャイルな状態を説くのも良い方法(ex,アジャイルなプログラマ)
- スクラムマスター = PM + アジャイルコーチ
第II部 アジャイルな方向づけ
第3章 みんなをバスに乗せる
- 適切な人を集めず、前提を共有しないまま開始したPJTは失敗しやすい。ここで理解が異なる状態でコミュニケーションミスが発生するから
- インセプションデッキを参考にチームで議論を進めて理解を深めることで、改善できる
- 我々はなぜここにいるのか、という問いは、なぜこのPJTに集められたと思うのか?なぜこのPJTが始まったと思っているか?を問いている
- なぜ自分がこの会社に所属しているのか?という問ではない
- 以前チームジャーニーが会社で流行った時、同様の質問をチームで考えていて出てきた意見がそういうのばかりだった。その時聞いてて感じていた違和感はこれだったんだ!と気づけた。
- なぜ自分がこの会社に所属しているのか?という問ではない
第4章 全体像を捉える
- インセプションデッキの前半について。なぜ?の理解をすすめる
- PJTのゴールは与えられるものではなく、議論してチームで理解するのが重要
- そのためにも、PJTの課題を現場で体験して状況を理解する必要がある
- 顧客が知りたいのは機能の変更点ではなく、自分にとって何が良くなったか?
- プロダクトのパッケージデザインを話し合うのは、楽しいこともありチームビルディングに向いているトピック
- 自分が思っているよりもプロジェクト関係者は多い、ということを念頭に置く。その人達を大事にして信頼関係を構築しておくこと。
- いざという時に助けてくれる味方になる
第5章 具現化させる
- インセプションデッキの後半。どうやってを理解する
- チームメンバーを決めるということは、その後決めるアーキテクチャの方向性も決めるということ
- 自分の得意分野を表明しておく
- 早めにリスクについて話すメリット
- 早いタイミングであればあるほど、対応できる余地が増える
- それについての議論をすることで、メンバー同士の理解が進む
- 抱えているものを吐き出すことで、スッキリする
- 個人的には、作業に集中できるかどうかが変わるので結構大事なこと
- 6ヶ月以上の期間を要するPJTは、届けられる成果が曖昧になりやすく、失敗の確率が高いと言われている。避けるか、小さく分解すべき
- QCDの他にスコープがあり、スコープは他に比べ変更がしやすい
- スコープ→featureの内容
- プロジェクトで重要視するものを決める際はQCDスコープの他に、各チームメンバーが大事にしていることも議論の対象にすること
- チームの生産性にも寄与するから
- 自分は何を大事にしているか?を考えたが、成長できるかどうか?しか思いつかなかった。逆に他に何があるんだろう。。。
- 定期的に考え直してみたほうが良いかも
- チームの中で、顧客に求められる役割についてはなぁなぁになりがちなので、気を付ける
第III部 アジャイルな計画づくり
第6章 ユーザーストーリーを集める
- 要求をすべて文書にするのは難しい
- 文書とのコミュニケーションができないのと、他人の文章は誤解を招きやすい
- 文書がすべて、となるのは良くない
- ユーザストーリーとしてまとめ、それを実現できることをターゲットにする。テスト対象は、ストーリーを実現できるか?
- 顧客が理解できる書き方で書くこと。
第7章 見積り：当てずっぽうの奥義
- 概算見積もり ≠ 正確な見積もり
- 事前に正確な見積もりをするのは不可能
- ptで相対見積もりをする。一定のタイムボックスで対応できるptを算出する。イテレーションを繰り返していくと、ベロシティが安定する
- 三角測量
- 小中大のストーリーを決め、それを基準に割り振る。割り振れなかったものはそれらと相対的に見積もり、ptを算出する
- サイズを算出できないものは、期間を決めてスパイク(雑に言うと調査)して算出
- プランニングポーカー
- 関係者みんなで見積もりし、議論しながらすり合わせていくことで精度が上がる、という理屈
- 合意できるように議論することで、理解が進む
第8章 アジャイルな計画づくり：現実と向きあう
- 計画も変化するもの
- 計画の立て方
- マスターストーリーリストを作る
- 見積もる
- 優先順位を付ける
- ベロシティを仮で決定する
- 期日とfeatureを調整する
- 立てた計画は、バーンダウン(アップ)チャートで可視化する
第IV部 アジャイルなプロジェクト運営
第9章 イテレーションの運営：実現させる
第10章 アジャイルな意思疎通の作戦
- ストーリー計画 : ストーリー開始可能かチェック
- ショーケース : デモをしてフィードバックを受け取る
- イテレーション計画 : ベロシティの確認
- 振り返り : どうすればもっとよくやれるか?
- kptをすると、pを文字通りただの問題と捉えてプロジェクトと全く関係のないことを上げる人がいて、直近の悩み。(天気が悪い、みたいな内容)
- デイリースタンドアップ : 自分のコミットメント対象を宣言する
- チームに合うものを、合う形でやること。合わなかったものは無理してやらない
第11章 現場の状況を目に見えるようにする
- チーム外に対する期待値のマネジメント
- リリースボード : 終わっているストーリーの把握
- ストーリーボード : 現在のイテレーションで取り掛かっているもの
- チームのベロシティ : 開発速度
- バーンダウンチャート : 今のペースだとどのくらいに終わるのか?
第V部 アジャイルなプログラミング
各章読んだが、今となっては基本的なこと、+もっと深い内容を知るべきなので別の本で理解をすすめることに。
