- アジャイルの文献の大半は最先端に目を向けている
- 特定のビジネスにとって何が最善かに重点を置く
- モダンなアジャイルプラクティスは最先端でなくてもうまくいく
- アジャイルプラクティスのほとんどがうまく実践されていない
- 平均的なスクラムチームでいえばデイリースタンドアップだけ
- アジャイル開発を採用していて、その結果に満足していない場合
- 「正しく」行う方法についてではなく、大きな価値を引き出す方法について書かれている
- 筆者はアジャイルのエバンジェリストではない
- 「うまくいくもの」の提唱者
- 最先端のアジャイルプラクティスでなく、うまくいくことが実証されているプラクティスに焦点
- アジャイルマニフェストや原則は20年前
- 成熟とともに、アジャイルの価値を正確に描写しなくなっている
- アジャイルの対比が工程による開発（ウォーターフォール）からシーケンシャル開発に
- 違いは表にまとまっている
- 順調に進むプロジェクトには共通点がある
- 管理をきちんと行うこと
- 顧客とのコラボレーションを重視する
- シーケンシャル開発は、ベストな状態ではうまくいく
- 多くの状況でアジャイル開発の方がうまくいく理由がある
- 恩恵は表の内容を重視した結果
- どのアジャイルプラクティスに焦点を合わせるかは組織ごとに異なる
- 安全性が最優先のソフトウェア開発なら、創発的な設計を採用しない
- 「すべてを採用するか、全く採用しないか」という考えから脱却する
- アジャイルの境界がどこにあるのかを理解しておく
- 組織全体
- 技術系の組織全体
- あなたのチームだけ
- 現在の境界と望ましい境界はどこにあるのか
- 全ての組織には境界がある
- アジャイルソフトウェア開発とアジャイルではない法規制
- アジャイルな営業とアジャイルではないソフトウェア開発
- アジャイルソフトウェア開発とアジャイルではない企業顧客
- あなたのビジネスにとって何が一番効果的だろうか
- 💭 検査と適応の項目があり、実際にやってみるとよさそう
- 不確実さや複雑さを理解するための Cynefin (クネビン) フレームワーク
- 不確実さや複雑さを前にして意思決定を行うためのモデルである OODA
- 5 つのドメイン (系) で構成される
- Cynefin は「生息地」を意味する
- ドメインはカテゴリではなく、「意味の群れ」
- ソフトウェア開発に最も関連があるのは「複雑系」と「煩雑系」
- 問題は十分に理解されており、解決策はわかりきっている
- レストランで注文を取る
- 車にガソリンを給油する
- 把握・分類・対処
- 「hello world」を超えるプログラムに関しては、ソフトウェア開発に単純系の問題は存在しない
- 問題の全体像、質問すべき内容、答えを得る方法はわかっている
- エンジンのノッキング音の原因を調べる
- グルメ料理の支度をする
- 成熟したシステムのユーザー要求の優先順位を決める
- 正しい答えは複数存在する
- 把握・分析・対処
- シーケンシャルなアプローチがうまくいく可能性がある
- 問題を明確に定義できない場合、課題に直面する
- 専門家をもってしても因果関係がすぐにはわからない
- プレゼント選び
- 真新しいシステムのユーザー要求を引き出す
- 前進するには実験が必要となる
- ある程度の失敗を織り込む
- 調査・把握・対処
- 多くのソフトウェア開発は複雑系に分類される
- 因果関係は入り乱れていて流動的
- 自然災害中の救助活動
- 政治的な圧力下にある環境でフィーチャーセットを定義する
- 行動・把握・対処
- ソフトウェア開発の場合、プロジェクト規模の混沌系の問題を見つけるのは難しい
- 目の前の問題がどのドメインにあてはまるかわからない
- 個々の要素に分解し、各要素がどのドメインに属するかを評価する
- プロジェクト規模のソフトウェア開発のほとんどは、1つのドメインにきれいに収まらない
- 実際のソフトウェアプロジェクトは、大部分が煩雑系・複雑系・無秩序系に分類される
- 煩雑系を複雑系であると考えていた場合、プロジェクトに対する理解が深まり改善している
- 複雑系を煩雑系であると考えていた場合のほうが深刻
- 煩雑系であるという確信がなければ、複雑系として扱うほうが安全
- 複雑系のプロジェクトに対処するのに役立つモデル
- Observe (観察)
- Orient (方向付け)
- Decide (意思決定)
- Act (行動)
- OODA では非常に重視される
- 観察と経験に商店を合わせる実証主義的アプローチ
- 観察の結果を自分の状況と関連付ける
- 情報があなたにとって何を意味するのかを判断し、利用可能な選択肢を特定する
- Apple の iPhone
- 「従来の携帯電話」としてはすべての面で劣っていた
- 方向付けステップで特定された選択肢に基づいて決定を下す
- 敵の作戦を妨害する何か
- 速いボールを予想している打者にチェンジアップを投げる
- 行動の影響(明らかになった状況)を確認し、観察に戻る
- 十分な OODA には暗黙の誘導と制御がある
- どのステップからでも行動または観察へのショートカットが可能
- 雨が降っているので、徒歩ではなく車で移動する
- OODA では意思決定の速さが重要視される
- 現在のソフトウェアの問題では、横断的な特性が次々現れる
- シーケンシャルアプローチではそもそも対処できない
- "アジャイル開発は短期的な作業を重視し、短期的な作業にコンテキストを与えるために長期的な計画から目を離さない"
- シーケンシャル開発は「プランニング、予測、制御」
- アジャイル開発は「観察、対処、改善」
- アジャイルチームはすべてのものを定期的に検査し、適応させる必要がある
- プランニング、設計、コード品質、テスト、プロセス、チーム内でのやりとり、組織内でのやりとり
- 検査なしの適応は決して認められない
- 一番の難題は「コード＆フィックス開発」を避けること
- 事前の見通しや計画を立てずにコードを書き、そのコードが動くまでデバッグする手法
- 作業量の半分以上が欠陥の修正に費やされる
- アジャイル劇場を防ぐ
- アジャイルという化粧で「コード＆フィックス開発」を覆い隠させない
- "シーケンシャルアプローチは官僚主義でつまずくが、アジャイルアプローチは無秩序でつまずく"
- スクラムはアジャイルアプローチの中でも最も規律的
- うまくいくことも実証済
- 圧倒的に多いのは2週間のスプリント
- スプリントの途中で想定外の事態に陥った場合
- スプリントゴールが再度話し合うための基準となる
- 💭 バーンダウンチャート使いこなせたことないんだよな
- タイムトラッキングのフォースが強すぎる気はしてる
- リファインメント
- 現在の済みのバックログアイテムをスプリント２つ分用意しておく
- 十分な時間が確保されていれば、スクラムマスターはチームに技術的に貢献できる
- 💭 兼務の話っぽさ
- スクラムバット (Scrum-but)
- 肝心なプラクティスの一部を省略している
- スクラムは最小限のプロセス
- いかなる部分も省くことはできない
- "完璧とは、付け加えるものがなくなったときではなく、削るものがなくなったときのことである"
- 💭 アンチパターンをまとめてあるのはいいな
- 💭 準備完了の定義の解説に期待
- 第13章で扱う
- 有益なガイドライン
- スプリント期間の半分に渡って、チームの半分以上が１つのストーリーにかかりきりになる、という状態を作らない
- スプリントごとに 6 ~ 12 個のストーリーを完成させることを目指すべき
- 現在のベタープラクティスは 1 ~ 3 週間
- ほとんどのチームは 2 週間
- バーティカルスライス
- 技術スタック全体にまたがるエンドツーエンドの機能
- ホリゾンタルスライス
- イネーブリングケイパビリティ
- デモ可能なビジネスレベルの機能は生成されない
- スケジュールに過剰な圧力がかかると、実際の進捗よりも進んでいるように見せかける
- 最初は、スクラムの他には何も必要ない
- ペアプログラミングや継続的インテグレーションを導入しなくてもスクラムは導入できる
- "効果的なスクラムの実践にとってスクラムマスターがなくてはならない存在であることはわかりきったことに思えるかもしれないが、組織がこの役割を不当に扱っているのをよく見かける"
- 💭 有能なスクラムマスターをアサインしていないことが多いからのような気がする
- まずやるべきことは、スクラムを忠実に実践すること
- プラクティスが実践されるような社会的または構造的支えが必要
- スプリントレベルの目標
- 実際に使用できるインクリメントの提供
- インクリメントの価値が1つ前のスプリントよりも高くなる
- スクラムチームのプロセスが1つ前のスプリントよりも改善される
- 自分たちのチーム、仕事、プロダクト、または顧客について何かを学ぶ
- モチベーションが1つ前のスプリントの終わりと同じか、それよりも高くなっている
- 💭 ふりかえりで聞いてみるとよさそう
- 💭 イメージはしやすいかもしれない
- 最初のスクラムの実践では、スピードの低下を感じることがある
- 見えていなかった作業に直面するタイミングが早まるため
- プロジェクトの終わりに溜まっていたような作業
- 単に見えていなかった作業
- 💭 これもやってみるとよさそう
- デイリースクラムの質問をカスタマイズする
- 幅広く適用できると実証されていないものの中で、代表的なプラクティス
- エクストリームプログラミング
- アジャイル開発に不可欠な技術的プラクティスの原点
- カンバン
- 煩雑系の作業に適している
- 煩雑系は優先順位とスループットが最優先の課題
- 複雑系は全体目標に向かう小さなステップの繰り返しに焦点
- チームは作業のほとんどについて自力で判断を下せなければならない
- プロダクトの詳細（要求）
- 技術的な詳細
- プロセスの詳細
- 機能横断的なチームに求められる専門性
- アプリケーションのさまざまなレイヤーを経験していて、異なる専門知識を持つ開発者
- アプリケーションのさまざまなレイヤーのテスト技術者
- テクニカルライター
- 開発プロセスのエキスパート（スクラムマスター）
- 特定分野のエキスパート
- ビジネスエキスパート（プロダクトオーナー）
- "決定を下す能力と権限の両方がなければならない"
- 少数チームでは専門知識が足りないことがある
- 臨時メンバーに数スプリント加わってもらう
- "組織がチームを十分に信頼していて、失敗を許すことがわかっていてれば、チームにとって大きな励みになる"
- アジャイル開発と自動テストの台頭で、開発者が自分でテストするようになった
- テストの専門化を完全にやめるのは的外れ
- ソフトウェアのテストは深い知識が要求される領域
- アジャイルの「スリーアミーゴス」にはテストがいる
- 開発・ビジネス・テスト
- テストは機能横断チームの専門知識のひとつ
- テスト技術者は開発者と一緒に作業すべき
- 問題がまったくない方法は1つもない
- サポート時間をスプリントに盛り込む
- スプリントへの割り込み作業に関してポリシーを定める
- スプリントレトロスペクティブでプロダクションサポート計画を見直す
- プロダクションサポートの構造はチームごとに異なっていてよい
- オープンフロアオフィスはおすすめしない
- 1人または2人用の個室の他に、チーム用のオープンスペースが推奨環境
- ヘッドホンや在宅勤務の頻度はオフィスにいるときは集中できないことの現れ
- 生産性を大きく左右するのはモチベーション
- ソフトウェア開発作業で重要なのは内発的なモチベーション
- 人生や仕事を直接管理する能力
- 💭 人ありきか、仕事ありきか、っての大事なんだよな
- 学習と改善を強く願うこと
- 開発者にとって成長の機会は他のどの要因より強力なモチベーション
- 取り組んでいる問題がなぜ重要なのかを理解すること
- 💭 これめちゃめちゃ大事だよな
- 実際の顧客との接触
- ビジネス担当者との接触
- 現実世界への影響
- 有効性とモチベーションは相互作用する
- プロジェクトの目的をソフトウェだけにすると、チームがバーンアウトする
- 結果としてキャパシティが低下する
- チームの成長に目を向ける
- 改善に時間を使うことが許可されてなければならない
- プロジェクトはどれも「急ぎ」のプロジェクトである
- 開発者が実際のユーザーと直接交流する
- 💭 電話に出るのは嫌だな
- 継続的なプログラムとして実施する
- 対人スキル
- チームでうまくやっていく能力は対人スキルに左右される
- 自己実現と役割
- ベルビンのチームロール理論
- 地理的に分散しているチームが同じ場所にいるチームに匹敵することはほとんどない
- 分散チームの存在は大企業にとって避けがたい
- フィードバックループをタイトにすることが、効果的なソフトウェア開発の原則
- 分散チームではフィードバックループがルーズになる
- パフォーマンスの問題は個人のせいではない
- 典型的な間違い
- 開発とテストで分ける
- プロダクトオーナーと開発チームで分ける
- 共通の機能を半分ずつ開発する
- ベストプラクティス
- 自律的に活動できるチーム毎に分ける
- 高凝集、疎結合
- 対面でのコミュニケーションを定期的にスケジュールする
- "信頼の半減期は6週間だ"
- 分散チームの後方支援を強化する
- 💭 リモート代理人というのはいいな
- 自立、熟達、目的を活用する
- 拠点間の立場が異なることが一般的
- オンショアとオフショア、親会社と子会社、etc
- 自律的に取り組める作業を各拠点に与える
- それぞれの拠点の作業がなぜ重要なのかを積極的に伝える
- 拠点間の立場が異なることが一般的
- コンウェイの法則に従う
- コンウェイの法則は双方向に作用する
- 技術的な設計も人間組織の設計に影響する
- 技術的なアーキテクチャが分散を支援していない場合、苦労することになる
- コンウェイの法則は双方向に作用する
- アジャイルチームをブラックボックスとして扱う
- 高い品質を維持する
- リリース可能な品質を保つために必要な作業は、分散のコストを浮き彫りにする
- "解決策は収束の頻度を下げることではない"
- 文化の違いを意識する
- 検査と適応
- 組織は仕組みレベルのレトロスペクティブについても支援すべき
- チームには課題に対処する変更を行う権限がなければならない
- 多くの組織は分散チームを発足させたそもそもの目的を達成できていない
- "この期におよんで近道をするものは禁物である"
- 💭 これは分散チームじゃなくてもそうだよなぁ
- 分散チームの効率が低下している時、メインの拠点でも同じ課題がないか調べる
- 地理的に近いと、埋め合わせが容易なので、気付いていない可能性がある
- チームはプロジェクトを終了するたび開始時よりも有能になっているべき
- 学習のための時間を設ける必要があり、そのための計画が必要
- 優秀な人が一夜にして優秀になるわけではない
- メンバーの育成を支援するチャンスがある
- 個人の能力を伸ばすための明確なガイドラインを提供する
- テクノロジに関する知識
- ソフトウェア開発プラクティス
- 専門分野に関する知識
- Professional Development Ladder
- 知識領域
- 能力レベル
- プロフェッショナルデベロップメント活動
- 役割ごとのキャリアパス
- 💭 構成図よさそう
- EQ (感情知性、Emotional Intelligence)
- 技術上の些細なことで口論になっていたら EQ を向上させる必要がある
- RULER モデル
- Recognizing: 自身と他者の感情を認識する
- Understanding: 感情の原因と結果を理解する
- Labeling: 感情を正確に表す言葉を選ぶ
- Expressing: 感情を適切に表現する
- Regulating: 感情を効果的にコントロールする
- ソーシャルスタイルモデル
- 💭 いろんな人がいる、っていうのを理解するのが大事ってことかな
- 💭 ハードなコミュニケーションに役立つモデル？
- 本があるみたい
- 経営陣の性格タイプを識別する
- 意思決定スタイルを理解する
- 反応を予測する
- タックマンモデル
- チームが経験している状況が普通のことだとわかると安心する
- リーダーも理解しておく必要がある
- 解散と再招集は再び機能期を迎えるまでにコストがかかる
- 4つのテスト(Four-Way Test)
- それは事実か
- それはみんなにとって公平か
- それは好意と友情を深めるか
- それはみんなのためになるか
- 大きなプロジェクトには多くの人が関与する
- コミュニケーションの複雑さが増す
- 要求、設計、コーディングの誤りにつながる
- 規模の不経済
- 規模と生産性の逆相関は40年以上研究され、実証されてきた
- 💭 ステークホルダーが要求追加を我慢できる期間がスプリントの期間として妥当なんだろう
- フィードバックサイクルの話
- 進捗の透明性の話
- ふりかえりと改善サイクルの話
- "特定の質問への答えをできるだけ少ない量の作業で見つけ出す"
- パーキンソンの法則
- 作業量は与えられた時間をすべて使い切るまで膨張する
- 期限が区切られていることが大事
- 当初の計画よりも作業がかかることが、すぐに明らかになる
- 「プリマドンナ」開発者の問題はない
- 進捗の気配がないまま何か月も暗い部屋にこもって作業する気難しい開発者のこと
- 毎日スタンドアップミーティングで説明しなければならないため
- "デリバリーの広さはいかなる点においてもデリバリーのスピードにはかなわない"
- "ホリゾンタルスライスに焦点を合わせているチームは数スプリントにわたって姿を消してしまう"
- バーティカルスライスはフィードバックループをよりタイトにする
- バーティカルスライスはより高いビジネス価値を提供する
- 非技術系のステークホルダーにとって理解しやすい
- 動く機能をユーザーが手にする機会も増える
- ホリゾンタルスライスは、アーキテクチャをプロダクトとして捉える開発心理を生む
- バーティカルスライスの実装に必要なもの
- テクノロジスタックをカバーするスキル
- 設計や実装に対する考え方の転換
- チームの作業がバーティカルスライスとして指定される
- そうなるようにバックログリファインメントを行う
- 技術的負債の返済
- 明示的に管理することが重要
- 開発サイクルの一部を一定の割合で返済に充てる
- プロダクトバックログにアイテムを追加する
- etc
- 明示的に管理することが重要
- 技術的負債の種類と対処法
- 💭 いい感じにまとまった表がある
- 技術的負債について話し合うことの価値
- ビジネス職は技術的負債の代償に気づいておらず、技術職はビジネスベネフィットを意識していない傾向
- 延々と続くスプリントが疲れを引き起こす
- 長さを変えてみる
- 6 * 2 + 1 (2週間のスプリントを6回、1週間のスプリントを1回)
- 「残業や休日出勤が全く無い状態」を「持続可能」とするのは短絡的
- "「持続可能なペース」の実態は誰しも同じではない"
- 💭 これは面白い視点で、納得感もある
- プランニングの割合を増やす必要がある
- リファインメントの開始から実装の完了までの時間が長くなる
- エラーと再設計のコストが高くなる
- 作業を完全に分割できるのであれば、ブルックスの法則は当てはまらない
- 簡単ではない
- "コンウェイの法則を理解せずして、大規模なプロジェクトとそれらのアジリティを最大化する方法を理解することはできない"
- 大規模なシステムにとって理想のアーキテクチャは、プロジェクトに取り組むチームの作業を 完全に分割できる ようなもの
- 事前にアーキテクチャの作業を行う必要がある
- 小さなプロジェクトのアプローチを大規模なプロジェクトに適用するためのトレードオフ
- 分割された領域内であれば、チームは創発的な設計を行える
- アプリケーションと人間組織の構造化
- マイクロサービスアーキテクチャ
- 疎結合、モジュール化が基本
- ビジネスニーズをサポートできるだけの柔軟性があればよい
- 💭 マイクロにしたいだけのマイクロサービスとかあるよね
- モノリシックなデータベースを回避する
- キューを使用する
- 契約による設計を使用する
- 口頭伝達だけでは成立しなくなる
- 事前の作業を増やし、文書化をする
- プロジェクトが大きくなれば、コーディング以外のすべてで、より多くの作業が必要になる
- 協調性の問題は要求で最も頻繁に起きる
- 平均的な大規模プロジェクトは、平均的な小規模プロジェクトのパーマンスよりもはるかに悪い
- 小さなプロジェクトでうまくいかないとしたら、大きなプロジェクトではもっとひどいことになる
- スクラム・オブ・スクラムも SaFe も実践に満足することは稀
- うまくいっているところも高度にカスタマイズしている
- "大きな企業は長い年月をかけて、ならではの技術プラクティス、ビジネスプラクティス、ビジネス文化を醸成・熟成させている"
- スクラムは小規模なプロジェクトのテンプレートとして優れている
- SaFe は統合フレームワークというより、便利なツールが揃っているものとして考えるほうがいい
- 欠陥の挿入は作業時間との相関があるが、検出と除去に作業時間との相関はない
- バグフィックス作業が計画に含まれていることは滅多にない
- 欠陥のギャップと挿入を最小限に抑える
- 欠陥をいち早く検出するためのプラクティス
- ユニットテスト
- ペアプログラミング
- 静的解析
- コードレビュー
- 継続的インテグレーション
- 完成の定義が複数必要になる場合がある
- 数種類の DoD
- 複数段階の DoD
- １つのスプリントですべて終わらない
- ハードウェアとソフトウェアを組み合わせる環境
- 別のチームや請負業者のソフトウェアに依存している
- なるべく避けるのが賢明
- １つのスプリントですべて終わらない
- "「完成」と宣言されたらそれ以上何もしなくてもリリースできる、というのが DoD の主旨である"
- "ほとんどの開発者が作業をペアで行うことを望まない"
- アジャイルのもたらしたテストの変化
- 開発者によるテストをさらに重視する
- 機能を作成したらすぐテストする
- テストの自動化をさらに重視する
- 要求と設計を改善する手段として重視する
- "開発作業の品質に最も責任を負うのは開発者である"
- p161:
- 私は＜ユーザーの種類＞として、＜利益＞のために＜目標／要求＞を望んでいる
- p163:
- 💭 フィーチャーやエピックなどの用語を整理している。便利
- ユーザー要求を実装しない開発指向の作業は「イネーブラー」と呼ばれる
- p164:
- バックログリファインメント
- 現在のスプリント作業とは別に、十分にリファインメントされたバックログアイテムがスプリント２つ分あるとよい
- p165:
- 質の高い要求が重要
- 要求の知識のチェックリスト
- 💭 要求分析、出来ないところ多い気がする
- p172:
- 有能なプロダクトオーナーの特性
- 特定分野の専門知識
- ソフトウェア要求のスキル
- "プロダクトオーナーは「何をするか(What)」に焦点を合わせ、「どのようにするか(How)」は開発チームに任せる"
- ファシリテーションスキル
- 利害の対立を調整する、緊張関係の妥協点を探る
- ビジネス目標と技術目標
- ステークホルダー同士の対立
- 勇敢さ
- "有能なプロダクトオーナーは独裁者ではなく、「決定権者が決める」ときと「グループが決める」ときを心得ている"
- 個人の効果性
- 有能なプロダクトオーナーの特性
- p173:
- Tシャツのサイズ分け
- ビジネス価値と開発コストで分類する
- "ソフトウェアでは「ノー」と即断することに高い価値がある"
- Tシャツのサイズ分け
- p181:
- ストーリーマッピングが紹介されていてうれしい
- MVPの代わりになるものよい
- MoSCoW 便利
- p185
- 新しい作業に取り組んでいる間もシステムをデプロイ可能にすることを優先する
- p187
- 苦痛を伴うのであれば、むしろ頻繁に行って痛みを先に味わってしまう
- p201
- 計算づくの間違いを犯す
- p203
- 間違いの情報は、間違いを修正するのに必要なレベルまで自由に伝わるようになっているべき
- p213
- 計測値は、なぜ計測し、どう使用するかの透明性が肝心
- p214
- 計測できるものは達成できる。ゆえにバランスを計測できるもので取っていく
- ツールが集めたデータの使用は慎重に
- p217
- fix systems, not individuals
- 「間違いを許す」ことは「間違いを無視する」という意味ではない
- p218
- 計測によって何を質問しどこを調べれば良いかは明らかになるが必ずしも答えが分かるわけではない
- p224
- 変更の効果が出るには時間がかかる
- p225
- 計測ごっこに注意
- p226
- プロセスの変更案をプロダクトバックログに追加する成功例
- どんな分野でも、個人の生産性を計測する有効な手段は存在しない
- 優秀な医者は治療の難しい患者を担当する
- p240
- 計画を変更することは、何も悪いことではない
- p256
- プロジェクトポートフォリオをマネジメントする
- WSJF
- 遅延コストと時間で優先順位を決める
- リーンの合言葉は「始めるのをやめよう！終わらせることを始めよう！」である
- p260
- ドミノ変革モデル
- 図が分かりやすい
- p261
- ビジョンは望ましい最終状態をはっきりと表現するものでなければならない
- p263
- 明確な許可と明確に承認された時間、みんなが思っているよりはるかに大事だと思う
- p267
- パイロットチームの後が続かないのは、メンバーがイノベーターやアーリーアダプターだから