More Effective Agile “ソフトウェアリーダー”になるための28の道標 [Kindle]
- 日経BP (2020年6月11日発売)
本棚登録 : 86人
感想 : 7件
- Amazon.co.jp ・電子書籍 (429ページ)
感想・レビュー・書評
-
コメント0件をすべて表示
-
アジャイル開発の現場での実践的な進め方というよりも、概念だったり、ディレクターやマネージャーなどリーダーの考え方や振る舞い方に焦点を当ててある点は興味深いなと。
メモ
司令官の意図
0
-
・No467：1.3 他のアジャイル本との違い
本書は、アジャイルを「正しく」行う方法ではなく、各自の業務に適したアジャイルプラクティスからできるだけ大きな価値を引き出す方法について書かれている。
本書は、うまくいくことが実証されているプラクティスに焦点を合わせている。
・No655：3.1 Cynefin[クネビン]
作者のデビッド・スノーデンいわく、クネビンはセンスメイキングフレームワークであり、このフレームワークは状況の複雑さや不確実さに応じて、効果が期待できる戦術の種類を理解するのに役立つ。
クネビンフレームワークは単純系、煩雑系、複雑系、混沌系、無秩序系の計5つのドメイン(系)で構成される(図3-1)。ドメインの特性や推奨する対処法はドメインごとに異なる。
各ドメインはカテゴリとみなすのではなく、むしろ「意味の群れ」とみなす。ソフトウェア開発に最も関連があるのは「煩雑系」と「複雑系」である。
・No676：煩雑系
煩雑系では、問題の全体像、質問すべき内容、そして答えを得る方法はわかっている。アプローチは把握、分析、対処の順。
プロジェクトの大部分がクネビンの煩雑系に含まれる場合は、事前のプランニングと分析に大きく依存する線形のシーケンシャルなアプローチがうまくいく可能性がある。
・No699：複雑系
複雑系の決定的な特徴は、専門家をもってしても因果関係がすぐにはわからないことである。アプローチは調査、把握、対処の順。
複雑系はアジャイル開発と反復型開発の領域である。プロジェクトの大部分が複雑系に含まれる場合、実際にうまくいくアプローチには実験が組み込まれていなければならず、問題を完全に定義するには調査が必要となる。
・No781：3.2 複雑系のプロジェクトを成功させる：OODA
図3-4に示すように、「OODA」はObserve[観察]、Orient[方向付け]、Decide[意思決定]、Act[行動]を表し、通常はOODAループとして説明される。
・No892：第4章 より効果的なアジャイルの始まり-スクラム
コード&フィックス開発とは、事前の見通しや計画を立てずにコードを書き、そのコードが動くまでデバッグする手法のことである。
シーケンシャルアプローチは官僚主義でつまずくが、アジャイルアプローチは無秩序でつまずく。
・No918：4.3 スクラムの基本
スクラムはよく、「イベント、役割、作成物、そしてそれらを結びつけるルールで構成される」と言われる。イベントはミーティングまたはセレモニーとも呼ばれる。
・No1021：4.5 スクラムの一般的な失敗モード
いわゆる「アジャイル」に括られる膨大な数のプラクティスとは異なり、スクラムはワークフローを管理するための最小限のプロセスである。すでに最小限であるため、スクラムではいかなる部分も省くことは出来ない。
・No1042：無能なプロダクトオーナー[PO]
■POが手を広げすぎている
スクラムチームに与える要求が不足している。POが担当できるのは1つか2つのチームで、それ以上になることは滅多に無い。
・No1100：バーティカルスライスよりもホリゾンタルスライスを重視
「バーティカルスライス」とは技術スタック全体にまたがるエンドツーエンドの機能のことである。
「ホリゾンタルスライス」とは、イネーブリングケイパビリティのことであり、実際にデモすることが可能なビジネスレベルの機能は直接生成されない。
作業をバーティカルスライスで行うと、フィードバックループがよりタイトになり、ビジネス価値の提供を早める事が出来る。
・No1153：スクラムアンド[Scrum-and]
最初は、スクラムの他には何も必要ない。ペアプログラミングも継続的インテグレーションもスクラムには必要ではない。ペアプログラミングや継続的インテグレーションを導入しなくてもスクラムが導入できることを知った後、その組織はスクラムの用途を広げる事が出来る。
・No1154：無能なスクラムマスター[SM]
■SMが開発者を兼任している
SMがSMの仕事よりも自分の開発作業を優先する。
・No1180：4.7 スクラムの成功要因
・No1203：4.9 一般的なスプリントの時間配分
1スプリントあたり60時間の理想時間のうち、約20%はプランニングとプロセスの改善に充てられる。開発作業に充てられるのは残りの約80%である。
・No1326：5.1 基本原則-横断的機能チームの結成
効果的なアジャイルチームは、チームが独立して(つまり、十分な自己管理のもとで)作業を行うために必要な役割や原理原則を採用している。
プロダクトの詳細(要求)、技術的な詳細、プロセスの詳細を含め、チームはそのその作業のほとんどについて自力で判断を下さなければならない。
自己管理できる機能横断的チームでは、通常は少なくとも次の専門性が求められる。
(中略)
1つのチームの推奨人数は5〜9人だが、このサイズを保った上で必要なスキルをすべてそろえたチームを編成するのは容易なことではない。
スキル以外にも、仕事の出来る機能的横断チームには、時宜にかなった拘束力のある決定を下す能力と権限の両方がなければならない。
・No1343：決定を下す能力
5〜9人の編成のチームでは、専門知識の数に限りがある。一般的な適応策は、2〜3回のスプリントごとにユーザエクスペリエンスやアーキテクチャといった分野の専門家に臨時メンバーとしてチームに加わってもらうことである。
アジャイルの実践の成否は、意思決定のほとんどを自分たちだけで下すのに必要な人材をアジャイルチームに積極的に配属するかどうかにかかっている。
・No1398：5.3 基本原則-テスト技術者を開発チームに統合する
ほとんどの開発者はテストツールにこだわるが、テストの基本的な考え方を理解していないため、高度なテストプラクティスはおろか、基本的なテストプラクティスすら適用しない。テストの専門家は依然として以下の様な様々な役割を担っている。
(中略)
本章で説明しているように、効果的なアジャイル開発は機能的横断チームの編成にかかっており、テストもそうした専門知識の一つである。
・No1746：5.5 ブラックボックスとしてのアジャイルチーム
スクラムのアジャイルプラクティスは、スクラムチームは「ブラックボックス」として扱う。組織のリーダーであるあなたには、チームへのインプットとチームからのアウトプットを見ることができるが、チームの内部事情にあまり首をつっこむべきではない。
マネージャがやるべきことはチームの方向性が明確であることを確認し、チームが責任をもってその方向に向かうように働きかける事である。リーダーとして「ブラックボックス」に配慮すべき点は次のようになる。
・No1557：6.1 基本原則-自律、熟達、目的によるチームの動機付け
生産性に関するほとんどの調査では、生産性は他の何よりも大きく左右するのはモチベーション=動機付けである事が確認されている。そのうち、ソフトウェア開発にとって重要となるのは内発的なモチベーションだけである。
・No1574：自律
表6-1 自律性を養うプラクティスと損ねるプラクティス
・No1585：熟達
開発者にとって成長の機会は他のどの要因よりも強力なモチベーションになることがわかっている。アジャイルにおいて経験からの学習が重視されることは、チームの熟達感を養うのに貢献するだろう。
表6-2 熟達を支援するプラクティスと損ねるプラクティス
・No1585：目的
アジャイルでは、チームの責務と説明責任を強調することで仲間意識が強くなり、チームの目的意識が養われる。
表6-3 目的意識を養うプラクティスと損ねるプラクティス
・No1596：6.2 基本原則-成長マインドセットを養う
リーダーがチームの成長に目を向けていないと、プロジェクトが進行する過程でチームがバーンアウト=燃え尽き症候群に陥り、プロジェクトの開始時点よりもキャパシティ=生産性が低下するという事態が容易に起きてしまう。
スプリントが持続可能なペースで進行していないと、スクラムチームが「スプリント疲れ」を起こすことがある。
動くソフトウェアを作ることはもちろんプロジェクトの目的の一つだが、そのソフトウェアを作るチームの能力を向上させること=成長マインドセットも目的の一つである。
・No1629：6.3 基本原則-ビジネスフォーカスを培う
開発者とユーザのふれあいと、「自律、熟達、目的」の「目的」部分との間には強い相互作用がある。このプラクティスはプロダクトの品質とモチベーションという恩恵の両方をもたらす。
ここで重要となるのは、ユーザとの交流が一回限りの体験ではなく、継続的なプログラムとして実施されることである。
・No1773：7.2 分散アジャイルチームの成功を目指して
・No1954：8.2 基本原則-個人のキャパシティを向上させることでチームのキャパシティを向上させる
3種類の専門的な能力を開発する
■テクノロジに関する知識
■ソフトウェア開発プラクティス
■専門分野に関する知識
・No3667：16.3 基本原則-活動ではなくスループットに焦点を合わせる
効果的でありたいと考える組織は、作業を開始するペースや活動レベルを最大化することではなく、スループット=作業が完了するペースを最大化することを目標にすべきである。
・No3687：16.4 基本原則-鍵となるアジャイルな振る舞いをモデル化する
有能なリーダーは自分がリードしている人々に求める振る舞いを具体的に表現する。そうした振る舞いには次のようなものがある。
・No3687：17.1 基本原則-間違いを許す
アジャイル開発は「検査と適応」に依存する。検査と適応は、計算尽くしの間違いを犯し、それらの間違いから学習し改善するという学習サイクルである。
「計算尽くしの間違い」とは、結果に自信がないことを承知の上で決定を下し、どれくらいよい結果になるかにかかわらず、その結果から学ぶことに目を向けることを意味する。
・No3945：18.2 作品の品質を計測する
手戻り率(R%)は、手戻りに投入する作業と新しい開発に投入する作業の割合を表す。ストーリーポイントの使用は手戻りを計測するための基盤となる。ストーリーは新しい作業か手戻り作業のどちらかに分類できる。
・No4031：19.2 生産性を向上させる
生産性に関する組織の影響
スクラムのエキスパートの口癖は、「スクラムは問題を解決しないが、何が問題かわかるようにそれらを照らし出す」である。
・No4099：19.3 原理原則に従って仕掛り作業をマッピングし、監視する
組織が基本的なスクラムを卒業して次のレベルに進むときには、品質と生産性の向上を後押しする手段としてリーンを組み合わせるといいだろう。
カンバンは、バリューストーム全体のワークフローの可視化とマッピングというリーンの要件を実装するために最もよく使われるリーン手法である。カンバンは、仕掛かり作業（WIP）を調べて、現在システムにWIPがどれくらいあるかを明らかにした後、スループットを制限している遅延を明らかにするためにWIPに徐々に制限を課していくことに重点を置いている。
0
-
Clean Agileの続きとしても読める実践書。Clean Agileがどちらかというと原理原則を痛快に書き下ろしているのに対し、こちらは実際にアジャイルを進めて行く人のための本という印象。特に医療系など規制業種への対応など今までの本にはなかったように思う。翻訳の質もよくオススメ。
0
-
実にマコネルらしいアジャイル本。
マコネルと言えば、アジャイル・マニフェストの数年前に書かれた『ソフトウェアプロジェクトサバイバルガイド』という本がある。その本では、ウォーターフォール型開発を前提に、後工程で発生した手戻りがどれだけコストが高いかが述べられ、それを最小限するためにリスク管理やアーキテクチャ設計などの重要性が協調されていた。
そのマコネルによってアジャイルをテーマに書かれた新作が本書である。アジャイルが世の中に登場して随分と時を経た今、マコネルが書いた本である。その辺によくあるアジャイルホントは一味違う。実に科学的なアプローチでアジャイルを解説し、そして実践主義である。
マコネルはアジャイルに対して積極的、肯定的であるとともに、批判的でもある。アジャイルを手段と捉えて、価値のあるソフトウェアを生み出すために活用しようというスタンスなのである。例えば、プロジェクトや環境の特性によっては、シーケンシャルなプロセスとアジャイルなプロセスとの併用もありだとしている。
『Do Agile』から脱却し、『Be Agile』を目指すエンジニアにとって非常に参考になる本だと思う。
0
著者プロフィール
Steve McConnellの作品
