- 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)チームが大事にすること
手を抜かない
「割れ窓」を放置しない
異論は認める
真実と向き合う
勝手な想定をしないで確認する
疑わしいと思ったらテストを書く
フィードバックを求める
我を張らない -
"お客様に価値を提供し続ける"のは口で言うほど簡単なことではないと思う。だかこそ、そのためにどうすべきか、どう考えるべきか、を追求し続けることこそが"アジャイル開発"なのではないかと感じた。
-
これは何回も読み返したい数少ないビジネス書(まあ技術書のジャンルに入るんだろうけど)になりそう。
根本的な考え方から進め方、それを改善していくことも含めてわかりやすい言葉で書かれている。
特にインセプションデッキ、プロダクトオーナーの話が刺さった。この手のことって概念としては知っていても、その重さを共有できていることが少ないから失敗するんじゃないかと思う。 -
■関連サイト:https://pragprog.com/titles/jtrap/the-agile-samurai/
●ソフトウェア開発の3つの真実
・プロジェクトの開始時点に全ての要求を集めることはできない
・集めたところで、要求はどれも必ずといっていいほど変わる
・やるべきことはいつでも、与えられた時間と資金よりも多い
●ソフトウェアの64%の機能は、ほとんどあるいは全く使われていない。
--->このことからも、本当に重要なことだけに集中すべき
●アジャイル開発の原則として、ビジネス側の人と開発者は、プロジェクトを通じて日々一緒に働かなければいけない
■プロジェクト運営
●インプレッションデッキでの10の質問
①我々はなぜここにいるのか
顧客は誰で、このプロジェクトが始まった目的は何なのか?
②エレベーターピッチを作成する
2センテンスでプロジェクトをアピールするとしたら何?
③パッケージデザインを作成する
何気なくめくった雑誌に自分のプロダクトの広告を入れるならどんな内容?
④やらないことリストを作る
⑤「ご近所さん」を探せ
プロジェクトの関係者範囲は自分たちの想定以上に広いもの。積極的に情報を
shareしFB機会を得る。
⑥解決案をかく
チーム全体の認識が揃っているかを確認するために、概念レベルのアーキテクチャ
設計図を書く。
⑦夜も眠れなくなるような問題は何か
プロジェクトが暗礁に乗り上げるとしたらどんなリスクか?目を背けず話し合う。
⑧期間を見極める
1ヶ月なのか半年なのか1年なのか?
⑨トレードオフスライダー(何を諦めるのか)
期間、スコープ、予算、品質。譲れないものは何で変動しうるのは何?
--->スコープ以外は基本的に固定。
⑩何がどれだけ必要か
必要なリソース(期間、人員、コストなど)
●良いユーザーストーリーの6つの要素:INVEST
✓独立している(Independent):ストーリーが互いに独立していると、必要に
応じてスコープを柔軟に調整しやすい
✓交渉の余地がある(Negotiable):予算などに応じて実現方法を選択できる
✓価値がある(Valuable):顧客が対価を払っていいと思えるもの
✓見積もれる(Estimatable)
✓小さい(Small):1週間や2週間といったイテレーションに収まるようにする
✓テストできる(Testable):完了の基準が明確になる
●ユーザーストーリーのテンプレート
〈ユーザーの種類〉として、〈達成したいゴール〉をしたい。なぜなら〈理由〉だあから。テンプレートを使うことで誰が/何を/なぜ、という重要な疑問を明確にできる
●ベロシティはチームとしての生産性を計測する。個人の生産性を測るのは良くない。個人の生産性を測ると、協調しようとか知見を共有しようという気持ちがなくなり、各人が何としても自分自身の生産性を確保しようと躍起になってしまう
プロジェクトの完了時期の見通しを立てるにはバーンダウンチャートが便利。ただ、バーンダウンチャートだと途中でのストーリー追加がわかりづらいので、途中でのストーリー追加をわかりやすくしたければバーンアップチャートが便利
●リスクは経過時間(プロジェクトサイズ)に比例する=小さく区切って考える
●継続的インテグレーション:ソースコードリポジトリ(単一のコードベース)に対して機能追加・性能改善・バグの修正・ライブラリの新バージョンなどを順次追加