- Amazon.co.jp ・電子書籍 (454ページ)
感想・レビュー・書評
-
詳細をみるコメント0件をすべて表示
-
やる気が出る書籍。
-
改めてアジャイルについて学ぶ必要があったため再読。
とても読みやすくかつアジャイルの基本的な考え方が網羅されていて非常に良い!
名著です☺️ -
読みやすかった
-
アジャイル開発の最高の解説書です!
-
インセプションデッキやプランニングポーカーなど、なんとなくやっていたプラクティスの詳細について知ることができます。
-
怠惰な自分が途中でしばらく読むのをやめていたせいで(YouTubeにかまけていた)、読了まで時間を要してしまった。
内容は文句なし。
アジャイルという概念、そしてその裏にある「思い」が、面白おかしく学べる一冊。
本書の内容を常に頭に置いた上で、実務に必要なところだけ応用できるようになりたい。
それが一番難しいけど。。。 -
・P20: 2.2 チームをアジャイルにするためのコツ
同じ仕事場で働く
積極的に深くかかわる顧客の存在
自己組織化
成果責任と権限委譲
職能横断型チーム
・P63: 4.4 やらないことリストを作る
うまくやるには
・P66: 4.5 「ご近所さん」を探せ
大規模プロジェクトでやらかした大失敗
進め方
次章予告
・P80: 5.3 期間を見極める
小さく考える
プロジェクトの長さへの期待をマネジメントする
・P84: 5.4 何を諦めるのかをはっきりさせる
試験
荒ぶる四天王
トレードオフ・スライダー
期日と予算を守るだけでは十分ではないのだ
プロジェクトには、守らなければならない決まりや、無視できない影響力を及ぼす力(フォース)が存在している。例えば、予算と期日は厳守すべきとされる傾向が強く、スコープは見境なく気ままに広がり続けていきがちだ。そしてもちろん、品質は常に最優先事項だ。
こうしたフォースのそれぞれは対立する事も多い。どれか一つのフォースに圧倒されると、残りのフォースに手が回らなくなる。フォースのバランスが欠けた状態が続くと、プロジェクトへの負荷がどんどん高くなっていく。最終的には、それが原因となってプロジェクトは完全に空中分解することになるだろう。
だから何かを諦めなきゃならない。問題は、何かを諦めるかだ。
荒ぶる四天王
太古の昔より、あらゆるプロジェクトは4つの固く結びついたフォースによって統治されている。それが荒ぶる四天王、すなわち時間、予算、品質そしてスコープだ。どんなプロジェクトにもこれらが待ち受けており、いつも必ず破壊と混乱を起こす。すなわち、
スケジュールは圧縮される
予算は削減される
バグのリストは長くなる
やるべきことは際限なく沸き出てくる
荒ぶる四天王のパワーは圧倒的だ。しかしこれらを手懐けることも出来る。その為には、プロジェクトにおいて四天王の一人一人と調和を保ちながらうまく付き合っていく方法を学ばなければならない。
時間、予算、品質。アジャイルサムライはこの三者のいずれをも固定する。するとたった一つだけ、動かすことのできるフォースが残る。それがスコープだ。
やるべきことが多すぎるとき、アジャイルサムライはどうするか?やることを減らすのだ。計画が現実にそぐわなくなっているのであれば、アジャイルサムライは計画を変える。現実を変えようとしてはいけない。
期日を動かすことは無理かもしれない。だからといって、計画も動かせないとは限らない。
トレード・オフ・スライダー
アジャイルサムライたるもの、時間、予算、品質について、顧客がどう考えているかをきちんと把握しておきたいものだ。スコープを柔軟にしておくことの重要性についても、ある程度はあらかじめ顧客に納得しておいてもらいたい。
これを実現する為には、プロジェクトのToDoリスト(マスターストーリーリスト)に載っているフィーチャ(ユーザストーリー)だけに囚われすぎないように気を付ける必要がある。
スコープは諦めてもらう場合があることに納得して貰うのだ
こうやって四天王たちにラベルをつけて、一目見ればすぐわかるようにしておくのだ。こうしておけば、相対的な重要度の順にツマミを調整することを顧客に頼めるはずだ(これなら、「どれも最優先」にはできない)。
「どれも最優先」はまかりならない!
同じ目盛りの項目があってはいけない!
・P150: 8.2 アジャイルな計画づくり
・P154: 8.4 初回の計画づくり
ステップ1:マスターストーリーリストを作る
ステップ2:プロジェクト規模を見極める
ステップ3:優先順位をつける
ステップ4:チームのベロシティを見積もる
ステップ5:期日を仮決めする
・P165: 8.5 バーンダウンチャート
バーンアップチャート
・P198: 9.7 カンバン
次章予告
・P213: 10.6 デイリースタンドアップ
・P226: 11.3 チームの意思を明確にする
「チームの約束(Working Agreements)」はチームとしてまとめる為の取り決めであり、「私たちはチームとしてこうやって作業したい」という宣言を文字にしたものだ。これは、現在のチームメンバーにとってはどんなチームを目指しているかを言葉で表すことになるし、これからチームに参加するメンバーにとってはチームメンバーとして求められる条件を明示するツールになる。
もうひとつは「チームが大事にすること(Shared Values)」だ。趣旨はチームの約束と同じだが、もっと感覚的な表現になる。もしも過去にプロジェクトが炎上した経験があって、品質を危うくするような窮地にはもう追い込まれたくないとか、手を抜いたグダグダなコードは二度と書きたくない、といった思いがチームにあるのなら、それを「チームが大事にすること」として目に見えるかたちにしておくとよい。
ex)チームの約束
午前9時から午後4時までがコアタイム
デイリースタンドアップは午前10時丁度に開始
テストを済ませたら完了
ビルドをだいじに
誰かに助けを求められたら「はい、よろこんで」と返事しよう
毎週火曜日午前11時からデモをする
午後1時から3時まではお客さんが時間を割いてくれる
ex)チームが大事にすること
手を抜かない
「割れ窓」を放置しない
異論は認める
真実と向き合う
勝手な想定をしないで確認する
疑わしいと思ったらテストを書く
フィードバックを求める
我を張らない -
"お客様に価値を提供し続ける"のは口で言うほど簡単なことではないと思う。だかこそ、そのためにどうすべきか、どう考えるべきか、を追求し続けることこそが"アジャイル開発"なのではないかと感じた。
-
これは何回も読み返したい数少ないビジネス書(まあ技術書のジャンルに入るんだろうけど)になりそう。
根本的な考え方から進め方、それを改善していくことも含めてわかりやすい言葉で書かれている。
特にインセプションデッキ、プロダクトオーナーの話が刺さった。この手のことって概念としては知っていても、その重さを共有できていることが少ないから失敗するんじゃないかと思う。