アジャイルソフトウェア開発スクラム (アジャイルソフトウェア開発シリーズ)
- 桐原書店 (2003年9月1日発売)
本棚登録 : 103人
感想 : 8件
- Amazon.co.jp ・本 (183ページ)
- / ISBN・EAN: 9784894715899
作品紹介・あらすじ
本書では既存の工学的なプラクティスや方法論には関係なく、即座に加算的にソフトウェアを産み出し始める方法を学ぶ。アジャイルプロセスの実装を単純化する方法を学ぶ。スクラムラッパを通してXP実装を単純化する方法を学ぶ。アジャイルプロセスが成功する理由と、アジャイルプロセスを管理する方法を学ぶ。アジャイルプロセスの理論的基盤について学ぶ。
感想・レビュー・書評
-
スクラムガイドの初版が発表される以前に書かれたスクラムの解説書。2003年以前の話をベースに描かれているため出てくる技術やスクラムの取り組み方など若干古めではある。だが、スクラムの本質は20年前から変わっていないんだなと感じるし、ケーススタディがいくつもあって状況のイメージがしやすい。また、竹内、野中両氏によって書かれた知識創造企業の内容を踏まえたスクラムを通しての知識創造に関しても触れられており、スクラムという考え方が両氏の the new new product development gameに影響を受けているところが伺える。
スクラムガイドをより根本から理解したい人にオススメ
1
詳細をみるコメント0件をすべて表示 -
ソフトウエア開発プロセスを云々する前に、読むべき本。最低限のチーム運営努力で、非常に高い成果が得られるかも。玉石混淆であるが、C++のコーディングルール等、参考にすべき点、多々あり。
0
-
4) Motorola社 General Dynamics 社のようなCMM政府契約型の手法,
5) 方法論者による手法は､ De Marco, Yourdon, Booch, Rumbaugh, Schlaer-Mellor, Jacobson, RUP(Rational Unified Process TM) のようなプロセスフレームワークを含んだ手法など
6) ハッキング, 新人プログラマ, 60年代のMITスタイルである。
これらすべてのスタイルのソフトウェア開発を理解しているわけではない。しかし、奇妙に思えるかもしれないが次のように言える。使用する方法にかかわらず、最も生産的にソフトウェアを納品しようと考えれば、誰でも結局はスクラムにとても似たことを始めるだろう。
22ページ
この言葉に当時、とても興奮した。自分もぼんやりと感じていたことを言葉にしてくれていると感じた。
10年以上の年月が過ぎ、スクラムは本当に有益なプロセスとしてソフトウェア開発にとどまらず、いろいろな分野で応用されている。
そしてこの書籍に記載された内容はより洗練され、スクラムガイドとして17ページのPDFになっていると言ってもいいだろう。
https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Japanese.pdf
序文はボブおじさんとマーチンファウラー
2ページ マコネル、
16ページにはファウラーさんの設計の終焉が引用されてたり、
http://objectclub.jp/community/XP-jp/xp_relate/isdesigndead
42ページ ミラーのマジックナンバー 7プラスマイナス2、
70ページ スコットアンブラーのエクストリームモデリング、
131ページはイリヤフゴールドラット ザ・ゴール、
132ページ チクセントミハイのフロー、
+ ワッツハンフリーの CMM、今となってはちょっと不適切なニワトリとブタの比喩
バーンダウンチャートという名前はまだないけど、プロダクトバックログで見積もった時間による計画方法
などなど 2000年当時話題になった考え方や、作業風景などは参考になるところもあるが、
歴史的な価値が多少残る程度で、本書は役割をもう終えた気がする。
マイクビードルさんが生きていたら、どんな活躍をしてくれただろうか。
------
スプリントとかバックログとか眺めて、なんとなくスクラムをわかったような気になってたけど、かなり誤解してたらしい。
使用する方法にかかわらず、最も生産的にソフトウェアを納品しようと考えれば、だれでも結局はスクラムにとても似たことを始めるだろう。
との本文中の言葉にもある通り、本当に最小限の誰にでも思いつきそうなプラクティスしかない。やるのは簡単だが成功させるにはかなりの覚悟がいる。
世の中は思い通りにならないことばかりだが思い通りにならなかったことがすべて失敗ってわけじゃない。もう一度やり直す、次はもっと良くなるように続けることで成功する。そのための指針、プラクティスがスクラムであり、アジャイルなのかなぁと感じた。
この本で引用されている設計の終焉？(2001年) http://objectclub.jp/community/XP-jp/xp_relate/isdesigndead が名文だった。
---
iv 序文 ボブおじさん
v 序文 ファウラーさん
構築が仕事の大半を占めていて、プロセスが予測可能な場合、工学的アプローチの
核心は設計と構築の分離である。時間が経つに連れ、この分離がソフトウェア開発に
とって実は役に立たないということがわかった。設計と構築の分離は、実際の
ソフトウェア開発とは結びつきそうにない、あまりにも多くのタスクを要求した。
さらに、タスクの構築部分は実際にあまり予測できなかった。また、タスクの設計部分
は工学的アプローチが仮定したよりはるかに長かった。
経験的アプローチを使用してソフトウェア開発を制御する必要があることを悟った。
vii まえがき
ソフトウェアとは毎回毎回書き直して作りなおさなければならない、今までにはない
新しいプロダクトであるという前提がある。ひとたびこの前提を理解すれば、ソフト
ウェアには膨大な研究と創造性が必要で、それにはリスクと不確実性の両方を同時に
減らせるような自己組織化する構造を作り出す一連の新しいプラクティスがより
役立つという結論に容易にたどり着く。
ソフトウェアを「工業製品」とみなす考え方とは根本的に異なる。製造業に似せた
ソフトウェア開発方法は、プロセス、組織、開発上の役割がよく定義され、繰り返し
可能であるという前提に立った予測可能性を仮定している。これに対してスクラム
では、プロセス、組織、開発上の役割は創発するものであり、統計的に予測可能で、
それらは単純なプラクティスやパターン、規則を適用することによって生じると
している。
P3
スクラムは一種の社会工学で、協力体制を促進して、関連するすべてを充足させること
を目標としている。
P10
プロダクトバックログ、チームの能力、ビジネス条件、技術の安定性、
実行可能なプロダクトインクリメント → レビュー、熟考、組織化
→次のスプリントの目標
P11
プロダクトに特定の量の機能を盛り込む時間があるなら、特定の量の混乱とリスクを
冒してより多くの機能を盛り込む時間もある。
P12
なぜウォーターフォール型開発が今日では機能しないかを説明している。プロジェクト
が始まる前に要求が完全に理解されることはない。ユーザは、ソフトウェアの初期の
バージョンを見た後に、自分たちが何を望んでいるかを知る。要求はソフトウェア
構築プロセスの最中に変わる。新しいツールと技術は実装戦略を予測不可能にする。
P13 MIT ピーター・センゲ
Peter Wegnerは、外部入力に応答する対話型システムの仕様を定めること、または
テストすることが不可能であること、つまりWegnerの定理を実証した。オブジェクト
指向のシステムを構築するときに既知の入力だけしか使わなければ、どのような開発
プロセスもウォーターフォール手法と同じく、失敗する運命にあることが数学的に
証明された。
中断された平衡説
P16
「ゾーン」に入ったときのインパクトは生産性の向上だけではない。個人の生活も
変化した。人は、彼らがそのようなプロジェクトで働けたことを忘れず、常に
そのような別の経験を探すだろう、と言った。
P20
カオスおよび複雑性の理論における自然の結果を見て、創発的なプロセスの美を
認識し、自己組織化についてより深く理解できた。
P22
使用する方法にかかわらず、最も生産的にソフトウェアを納品しようと考えれば、
だれでも結局はスクラムにとても似たことを始めるだろう。
P27
工業プロセス制御理論
定義されたプロセス制御モデル 創造的すぎる 適用する対象ではない。
多くの予期せぬ出来事と制御の損失を発生させるか、あるいはプロダクトが完成
されない、または低品質のプロダクトを生み出すことになる
プロセス制御の経験的モデル 事前にタスクの詳細を定義していないことを想定
不完全な定義や成果が予測・再現できないプロセスに対して、頻繁な検査と適応を
通じて制御と訓練を提供してくれる。
P38
バックログ項目の優先順位が高いということは、緊急性が高く、よく考えられていて、
その価値についての共通認識もできている。より明確で、より詳細な仕様がある。
明確性が高く、詳細度も高いのでより素晴らしい見積ができる。優先度が低いと
いうことは、ようやくバックログ項目として認識されているという程度で詳細度も低い
P40
見積りはイテレーティブなプロセスである。バックログ項目をより深く理解できるよう
になるにつれて、見積りは変化する。優先順位の一番高いバックログについて明確で
信頼できる見積りを得られないとしたら、プロダクトオーナーはそのバックログ項目
について考え直したり、優先順位を下げたり、作業対象から問題点に変更した方がよい
P42
チームの規模は5人から9人でなければならない。
Miller G., The Magical Number Seven, Plus or Minus Two, Psychology Review,
1956
P45
自分たちが何を行えばいいのかを誰も教えてくれないことがわかると大変ショックを
受け、信じられない気持ちになる。しかしそのような驚きもすぐに消え、自己組織化の
生産性が定着する。
チームは自分たちの作業をどのように行うかについての決定権を持つだけではなく、
既存の特権、標準、慣習、アーキテクチャ、技術を利用し、それらに従う責任も持つ。
P53
スクラムマスターはチームのために判断を下しすぎないように注意する。ほとんどの
組織では、意思決定の移譲は今までにない経験だろう。スクラムマスターは、
コミットメントを達成するための判断をチームが自分たちで下すことができるように
手助けする。チームが意思決定を部外者に依存する度合いが増えれば、コミットメント
の制御が難しくなる。
多くの場合、誰かが判断するまで作業を中断して待つよりは即断する方がよい。
たいていは「この程度で十分」になることも多い。
P57
チームは自分たちの知恵、創造性、協調性、協力、努力を信じて実現するしかないと
悟る。真のチームとしての性格と振る舞いを身につけようと自己組織化を始める。
管理者やユーザは、チームを窮地から救ったり、代わりに決断を下すようなことを
絶対に言ったり、行ったりしてはいけない。
タスクはそれぞれがおよそ４〜１６時間で仕上げられるくらい詳細にする。
P58
最初、チームは責任を取ることに神経質になって、過小なコミットメントを行いがち
である。チームがスクラムのプロセスに慣れてくるに従って、機能と技術を理解し、
それがチームの中に浸透し始め、より多くの作業にコミットするようになる。
P59
プロセスはプロジェクトチームに大雑把な目標を与える管理者と一緒に開始される。
明確なプロダクトの概念や詳細な活動計画を手渡されることはほとんどない。
したがって、チームは多くの自由を持つ一方で、目標に内包された困難な課題に
直面する。
スクラムは予測不可能な複雑さから予測可能なプロダクトをひねり出すことを
求める。このような任務に耐えられない人もいるだろう。スプリント中、辞めたい
人は自分からやめる。チームに残った人は、自分の持てる力すべてを発揮して何かを
作り出す絶好のチャンスを味わうことができる。スクラムを使用して成功を収める
ことが出来る人は、組織の核になれる。
P60
チームをスプリントの間自由にすることはおかしい、リスクが高すぎると考えて
最初は嫌がる組織も多い。しかし、管理者が自社のチームを信頼し、自分たちで
最良／最適な方法を探させるのは、それほどおかしなことだろうか。実際、どれくらい
リスクがあるのだろうか。
チームは創造性と生産性を育む温床となる。スプリントとは社員が有能かどうか、
また自分たちの行うべきことをわかっているかどうかについての管理者のかけである。
P61
スクラムを初めて行うユーザは、スプリントの期間を例えば６０日、２週間、１週間
などに変えようとすることも多い。しかし、この誘惑に打ち克つだけの値打ちはある。
３０日というのは、押し寄せてくるさまざまなプレッシャーの絶妙な妥協点である。
期間を変更するなら、全員がさらにスクラムの経験を積んだ後にしたほうがよい。
スプリントの目標が満たされる範囲内でチームはスプリントの機能を変更する権限を
持つ。つまり、チームは引き渡す機能の範囲や奥行きを増減させて目標を達成する。
P63
チーム自体がスプリントのキャンセルを決断する場合もある。チームはスプリント中に
自分たちの能力とプロジェクトの要求を知る。スプリントの途中で自分たちには
このスプリントの目標を達成できないと悟るかもしれない。
P64
天候が悪いと、視界の悪化のために何日も続けて補正できないことも多く、船の推定
位置が次第に狂う。船が岸に近づいても、優れた補正が得られるまでの間、海岸線との
間に距離を置くことも多い。
P65
ミーティングの準備に時間をかけすぎてはいけない。この規則を守らせるために、
PowerPointなどのプレゼンテーションをすべて禁止する。チームがミーティングの
準備に２時間以上かけた方がよいと思うなら、多分このスプリントでは期待されている
ほど見せるものがないのだろう。
P68
スプリントが開始されるとマネージャは何もすることがないと感じる。何を行えば
良いかを考え、目標を達成するために自分たちを組織化するのはチーム自体の仕事で
ある。スクラム適用後のマネージャの日々の仕事は、開発チームの進行を妨げる障害を
撤去することである。
P70 エンジニアリングプラクティスを評価する。
素晴らしい場合も、チームを邪魔する場合も、風化している場合もある。
そして、システムの発展にともなって陳腐化しがちなドキュメントとしてのモデルの
価値について議論するだろう。
Scott Ambler
日次ビルドを実施しないのは危険である。
P74
プロジェクトにゴーサインが出たときは、チームのメンバが他のプロジェクトから
外れることができるように、管理者や他のプロジェクトマネージャと話し合う。
P75
なぜ他のプロジェクトマネージャのようにプロジェクトの完了予定日をいうことが
できないのかと、常務会の一部からは不満が出るかもしれない。そこで技術と要求が
複雑であることを丁寧に説明する。このプロジェクトでは学習することが多く、
開発と同じくらい多くの研究を行う必要があると説明する。この不確実性と複雑性の
リスクのために正確な完了予定日を保証することはできない。そのため、運営委員会と
月単位で協力していくと説明した。
P79
スクラムは常識的な自由の適用を求める。納品日に間に合わなければ、納品する機能を
削減する。機能を減らせなければ、各機能内の一部を削減して工数を減らして調整
する。コストを増やすと同時にスプリントを行うチームを増やすか、または専門家を
増員する。スクラムは、これらの決定を下す際に必要なすべての情報を管理者に提供
する。管理者はその情報を基にプロジェクトから最大のビジネス価値を生み出す決定を
下す。
P79
スクラムは管理者に直接観察とバックログチャートの２種類の情報を与える。管理者は
プロジェクトに君臨し、意思決定を行うために、これらの情報を積極的かつ知的に
用いる。
P81
チームはモデルや設計、アーキテクチャ、ユースケースなども開発する。しかし、
それらはチームの思考を前進させる程度にしか役立たないだろう。本当に重要なのは
納品されたプロダクトの機能である。設計を納品することはできないが、動作する
コードは納品できる。
スプリントレビューの際に、スプリントで発生したことについて議論する。技術に
関してはどのような問題が発生したか。どのような取り組みや設計の代替手段を使用
したか。それらはスプリントの目標のどのレベルまで達したか。要求の中にどのような
矛盾があったか。機能の実装はどこまで進んだか。コードのテストは十分行われて
いるか。将来機能を追加していく基盤として、安定性は十分か。チームは協調して
いるか。他にどのような専門知識を使用することができたかなどを議論する。
P81
スプリントの進捗 どの程度スプリントの目標に近づいているか。
リリース進捗 必要な品質と機能はいつリリースされるか。確実にリリースするために
変更、リソースの増強は必要か。
プロダクト進捗 どの程度市場のニーズを満たしているか
P82
ワークバックログはいずれかの時点で行わなければならない残りの作業量である。
スプリントバックログには、スクラムチーム自体がスプリントに必要だと思ったタスク
も含まれる。
リリースバックログは、リリースのために選択されたプロダクトバックログの
サブセットである。
プロダクトバックログは、プロダクトに関して予見しうる作業をすべて含んでいる。
P84
スプリントバックログのグラフ
P86
スクラムには作業した時間を追跡するメカニズムはない。チームはどれだけの時間で
目標に到達したかで計測される。スクラムは結果指向で、プロセス指向ではない。
あるチームは一貫して働き、あるチームは一気に働き、あるチームはスプリントの
終わりに奮起して働く。プレッシャーを求めるチームもあれば、規則正しさを求める
チームも存在する。
P91
経験的な性質は、要件や技術に対する開発などがそうであるように、管理者が
コスト、機能、時間、品質の調整を行うところにある。
P92
予測不能なトレードオフを取らざるを得ないこと、前もってあらゆることを知ることが
不可能であることを知っている。結局、管理者が聞きたくない（原文聞きたい）と
思っていることを聞かせる羽目になる。それはそんなに悪いことだろうか。管理者は
トレードオフが発生するとは知らず、大惨事でも起きない限り、著者たちが言ったもの
を手に入れる。失うものは管理者の参加、知識、ガイド、知恵である。トレードオフを
することに管理者が理解を示すなら、参加して協力してくれるだろう。驚くことは
ない。明言したものを正確に納品できるというと、管理者はたいへん驚く。
交渉が仕事のはじめには発生しないことを知っている。交渉は仕事中に発生する。
ソフトウェアを構築することは建物を建てるよりもさらに予測不可能である。
管理者の仕事は開発中にコスト、時間、機能、品質の４つの変数を管理することで
ある。
著者は、プロジェクトマネージャが機能や品質に問題があるプロダクトしか納品
できないとわかっている期間で契約したプロダクトを見てきた。このような
プロジェクトマネージャは顧客を失望させたいわけではない。しかし、プロジェクト
マネージャは機能や品質の低下を明らかにせず、期間だけで同意した。正直な
ところ、知っていることや信じていることを共有できるのが一番である。そうすれば
顧客とともに現在の状況に基づいて開発を進めていくことができる。また、知られたく
ないことをもみ消すために時間を浪費することもない。
P93
バックログの項目は残りの作業時間の見積りを含んでいる。プロダクトオーナーは
これらの価値を毎週更新する。
P97
スクラムは経験的プロセス制御モデルの上に形成されていて、従来のプロセスや
方法論が使用する定義プロセス制御モデルとは根本的に異なっている。
P98
複雑系の理論は雑音の原因とパターンを理解しようとする新たな方法だと見なす
ことができる。雑音は結局すべての出来事に存在し、雑音を無視するための切り捨て
というメカニズムも常に存在する。完全に正確な数字というのは、可能性を信じ
させてくれる幻想である。
P99
すべての物理的プロセスは、ある程度の雑音のある行動や予測不可能な振る舞いを
示す。著者は、雑音を選択して遮断することや、予測可能な出来事に注意をあまり
払わず、予測不可能な出来事にいっそう注意を払うことを学んだ。
IBM360 MVTのOS アセンブラ、ジョブコントロール
著者がわからないことも、部署の誰かが知っていて、マニュアルにはすべての技術が
網羅されていた。このプロジェクトには雑音がほとんどなかった。ほとんどすべての
ことが理解されていた。下級プログラマだった著者自身が唯一予測できない対象
だった。
P100
システム開発における雑音は、要件、技術、人の３つのベクトルの働きである。
雑音は要件が理解／合意されなくなると増加する。雑音は不確かな技術を採用する
ことによって増加する。
新しいプロセスを新しい技術で構築しようとする開発プロジェクトは、とても雑音が
多く、予測不可能である。
P102
すべてのプロジェクトにおいて、個人の複雑さとチームにおける個人の作業が雑音の
レベルを上げる。例えば、確実な技術と合意した機能を持つプロジェクトが単純では
なく、複雑なプロジェクトとして分類されるのは、「人」が要因だからである。
P103
大半のシステム開発において、とても単純で、ほとんど雑音がなく、定義プロセス
制御モデルが適切なプロジェクトはほとんど存在しない。
プロセスが再現可能なほど詳細に記述されず、モデル化しようとするプロセスの
結果が異なる数多くの複雑さが存在しているなら、そのプロセスは複雑なプロセスと
呼ばれる。複雑なプロセスを２回続けて行ったら、おそらくその結果は同じではない
だろう。そのプロセスの活動はとても多くの雑音を含んでいて、十分な信頼性を
もって成果を予測することができない。経験的プロセス制御モデルは複雑なプロセスを
管理し制御するために利用される。管理と制御は頻繁な検査と順応性のある応答に
よって行われる。
定義された制御のメカニズムが機能するために、これらの方法論はそれぞれのプロセス
を正確に定義しなければならない。結果として発生する雑音は再現可能性に干渉
しない、または、結果は予測可能でなければならない。
一般的または緩いものならば、そのプロセス定義は役に立たない。プロセス定義は
それが採用され、再現可能な結果を生み出さない限り、価値は少ない。
実行するごとに違った定義を要求されるようなとても複雑な活動は、プロセス定義
として抽象化できない。
P104
ニュートンの法則は１つの抽象化である。その定義が反復可能になってからは、
制御は正確な定義を適用して行われる。その加速度、力、質量の関連における雑音は
とても小さく、通常は無視できる。
P105
PERT図を機能させるには、作業時間を厳格に見積り、測定しなければならない。
そうしなければすべてのプロセスが雑音を持ち、その蓄積された雑音はプロジェクト
計画全体を沈めてしまう。
プロセスの説明を抽象化するには詳細を削るしかない。不幸にも、再現可能で
あるためには、その削られた詳細が必要である。
プロジェクトマネージャは計画を持つことによって、プロジェクトが制御下にあると
感じ、安心する。メンバは要求された作業を理解して、プロジェクトが成功して
完了すると感じている。誰もがその方法論とプロジェクト計画どおりに行い、
プロジェクトは完了する。しかし、その計画の基礎となるタスクの詳細は不完全で
ある。それは基底となるプロセスが複雑で雑音を含んでいるからである。定義が
不完全なので、依存関係も不完全である。これらの見積りは、作業の割り当てや
見積りを役立たなくする。
P108
マネージャが定義プロセス制御モデルを利用して、複雑なプロジェクトを管理
し始めるとき、罪人探しがシステム開発の現場で始まる。マネージャはプロジェクトの
制御を失い、プロジェクトの結果を予測できなくなる。
P109
罪人探しが始まり、皆が無気力になった。最善を尽くしていた開発者は、期待される
ものに従って行動することに常に失敗し、結局、最善を尽くすことをやめてしまう。
それは不適切で評価されることではない。
従来の定義ソフトウェア開発プロセスは崩壊している。ほとんどのプロジェクトが
高い確度の予測可能性を持っていると仮定すると、それは複雑なプロジェクトの
中の雑音を十分に見つけられず、雑音を評価し正確に答える経験的な対応を促進
しない。雑音が無視されているので、その結果は予測できない。
化学会社は、経験的制御を必要とするポリマープラントを促進した。いくつかの
化学的なプロセスは十分に定義されておらず、定義プロセス制御モデルを利用して
工場を安全かつ再現可能に操業できなかった。雑音は統計上の制御を効果のないもの
にする。バッチを生産するためには、頻繁な検査と県庁が必要である。化学プロセスが
理解され、その技術が向上すれば、プラントはさらに自動化される。しかし、
予測可能性をすぐに仮定することは産業的な大災害のもとになる。
P111
著者の顧客の数人は、スクラムプロジェクトにプロセス技術者を配属した。彼らは
記録、抽象化、形式化によるプロジェクトの経験を利用しようとした。
記録された活動はとても複雑で、定義したり抽象化したりできないという結論を
出した。
代案として、顧客はナレッジマネジメントによる解決策に切り替え、システム構築に
関する組織の経験のリポジトリを作成した。
P112
不完全か適当な内容かを見分けられさえすれば、抽象化されたプロセスの知識は
間違っていない。再現可能性は期待できないが、パターンは知識を提供し、問題を
解決するための枠組みを提供する。安定した技術チームは、問題を解決するために
パターン、技術、専門の技術知識を利用する。スクラムは、理性、訓練、チームメイト
仲間の技術者に頼ることをチームに教える。
P117
ソフトウェア開発は新規プロダクト開発に類似していて、製造業に類似しているのでは
ない
P118
製造業では一貫した要求、すなわち製造ラインでは全く同一の形の全く同一の形のもの
を組み立てる「再現可能で明確な」プロセスが求められるが、ソフトウェアでは
すべての処理が異なるという要求が求められる。
したがってソフトウェア開発では、新製品開発のモデルが適合する。しかし、何か
新しいものを新しいものを作成するには、調査／作成／習得が必要である。これらの
行為は全く異なった仮定の上にあり、見積り／計画／追跡／管理には製造業の
プロダクトに使われている技術とは完全に異なった方法が要求される。
アプリケーションに対するソフトウェアの要求は決して完全にはならないので、
ソフトウェア開発では常に調査がつきまとう。
P119
開発フェーズの重複。いくつかの要求の発見とともに身近な情報から何かが一斉に
つくり出されている環境の中で、新しいプロダクトの開発を首尾一貫して促進する
ために、発見／考案／実験フェースが重複するのは必須である。たいていの問題は
新たなプロダクトの開発の中でプロダクトのフェーズが分割されている時に発生する。
フェーズの重複は、責任意識を共有させ、やる気とかかわり合いを促進し、問題解決の
商店をはっきりさせる。また、自発的な活動を奨励し、多様化した能力を開拓し、
市場の状態に対する感性を強める。
P120
自己組織化、学習、そして開発フェーズの重複を必要とする数多くの調査と創造性を
含んでいる。
P121
スプリントの繰り返しの中ではすべてのスプリントの目標が完成されないという事実を
許容するが、スプリントレビューとスプリント計画ミーティングを通して目標を調整
する。
P122
ソフトウェア開発は新製品開発の結果で、研究と創造性が必要不可欠だと述べてきた。
一方で、研究と創造性の共通点は知識の創造である。
アプリケーションに対する要求を集めるのは、暗黙の方法である。そして実際に得た
知識を利用して、コードや実行可能な形としての設計を決定し作成する。この考え方
から、ソフトウェアは体系化された「形式知」に他ならない。
形式知とは、体系的な言語に変換できる知識である。例えばソフトウェア開発では
コード、ドキュメント、UML、グラフィックなどが形式知である。形式知とは、経験や
典型的な直感や反応のような、外部に現れない暗黙知とは対照的である。
ソフトウェアのユーザ、専門家、経験を積んだプログラマがよい例である。
P124
ソフトウェアは研究や創造性を必要とする新しいプロダクトで、その組織は自己組織化
されたプロジェクトチームで構成され、開発フェーズは重複していなければいけないと
スクラムは仮定している。つまり、スクラムの組織やプロセスは固定的、さらに言えば
単純な繰り返しとはいえない。スクラムのプラクティスを単に当てはめ、繰り返し
行いたいと望むかもしれないが、それは常に違った組織やプロセスの段取りを行う
ことになる可能性がある。
P125
自己組織化システムはとても広範囲で、物理学、化学、生物学、社会学、政治学、
人類学などすべての科学に見られる。
軍隊も人間組織の自己組織化だが、柔軟性がない。
P128
スクラムチーム内の序列である組織は、知識間の関係によって決まる。対象となる
ものに対してより多く知っているなら、誰もが議論で高い順序を持つ。
組織自体のタスクも短期間のフィードバックサイクルを利用して動的に
取り決められる。役割もまた短期間のサイクルで適合される。
スクラム開発者は一日の中で、分析者、テスタ、コーダ、設計者、アーキテクト、
インテグレータと頻繁かつ動的に役割を替える。
P129
固定化された組織／プロセス／役割を持つ従来のチームより、スクラムチームはより
大きな順応性を持つ。
P130
文化を変化させるのは、今までで最も難しい変化の１つである。
上層の管理者から支援を受ける。
文化は言葉は作り、言葉は文化に作られる。
バターン、リファクタリング、新しい技術など、違ったトピックを提供して検討する。
ありのままのスプリントバックログを掲示し続ける。勇気、正直さ、信頼を高める。
P131
ザ・ゴール ビールゲーム スローン校ピーター・センゲ システム力学
在庫には維持費用というコストがかかり、「アイドル（使用されずに放置されている）
状態」は決して良いことではない。一方で、与えられた時間に対する原材料を十分に
持っていないと、生産ラインを効率的に動かすことができない。つまり、最小だが
十分な在庫を持つことが理想である。
定期的にすべての在庫資源の水準を計り、短時間で開発者が使用する時間を素早く
変化させる。
開発者の役割を変化させ、不良在庫化している課題を消化する。
P135
複数のプロジェクトを同時に進めていく上で、絶対に複数のプロジェクトを同時に
開始してはならないということである。
P136
何もない状態から、あらゆる状況に適応するような再利用を意識して取り組んだり、
すべてを予見して作業を進めたりしてはいけない。しかし、使えるときはいつでも
利用できるようにお膳立てをしておく。そうすることで再利用がより簡単になる。
最初のアプリケーションにおいては、再利用についての優先順位は常に２番目で
なければならない。
P137
「再利用可能な技術」と大袈裟に宣伝された新技術を使用している開発者や管理者は
とても多い。彼らは常に最初のアプリケーションリリースの時点から、再利用のための
新技術を用いて作業をするのが習慣である。そのような人たちは、
再利用こそが開発の中で一番面白いと考えがちである。しかし実際は正反対で、２番目
以降のリリースになって始めて「再利用性」の面白みが出てくる。
P139 共有リリースチーム。複数のアプリケーションチームの要求を満たす。
アーキテクチャサービス層の違いがわずかであると予想されるため、共有は容易であ
る。ビジネスオブジェクト層の共有は困難である。通常、最新の注意を払って
抽象化に重きをおいたアプリケーションには、曖昧さと偏見が見受けられる。
異なるアプリケーションチーム間での衝突を解決するには、ビジネスモデラの
専門家による実践のミーティングが効果的である。
P140
他のアプリケーションのスクラムマスターと、共有リソースやテスト、プロダクト
サポートなどのサポートチームのスクラムマスター間で、定期的にミーティングを
開く。これらのスクラムミーティングの数々は「スクラムのスクラム」と呼ばれて
いる。普段は週に１，２回、必要であれば頻繁にこのミーティングを開催する。
P143
構成管理、テスト、リソース工程の準備が完了していない場合は、決して並行開発を
してはならない。
「ルート」ドメインオブジェクトを使用している作業を選択する。
P153
組織の「規則」を使った失敗には、いいかげんうんざりしたが、それでもまだ
自分たちを信じていた。これまで自分たちが使ってきたものが役立つという確信が
あった。それらは融通の効かない作業工程でも高価なツールでもなく、綺麗な
ガントチャートでもない。
P154
スクラムはすべての管理作業をバックログの管理に統合する。テスト、
プロダクトサポート、リリース管理、構成管理、もちろんソフトウェア開発に
ついてもチーム全員分をバックログの管理項目として含める。このプロジェクトでは、
管理作業の統合というスクラムの特徴が最も役立った。
P155
スクラムは、生産性を向上させるために組織のリエンジニアリングに利用される。
生産性に対して最適化されている組織はほとんど存在しない。組織が成長し、成熟
するに従い、非効率になっていく。
P160（スクラムを妨げる障害）
会話、冗談、冷やかしからパターンが浮かんでくる。
P161
調査、開発戦略、調達、手続き、フォーム、そして組織に課せられているプロトコルに
多くの時間を割いていた。
何が合理的かを確かめるより、組織に課せられた作業を行う方が容易になった。
作業は官僚主義に取って代わられた。
P165
コミットすること、集中すること、オープンであること、敬意を払うこと、
勇気を出すこと
主導権を握って複雑な要求や技術と格闘する
自分たち自身を信頼することを学習しなければならない。
ときには袋小路に入り込んだり、妥協を重ねたり、失敗に終わったりしてしまう
それでも仕事をこなし、約束を果たすために、真摯で毅然としていなければならない。
P169（コード、動くものに集中する）
それがコードと何の関係があるのか
P170
作業の傾向は、時間ごとに残りの作業を追跡することで目に見えるようになる。
干渉に抵抗するスクラムのプラクティスの１つは、スプリントがいったん走り出したら
誰もスプリントに作業を追加してはいけないという規則である。
P172
自分たちの目標を達成できないリスクを考えたくなかった。そこでDaveを便利な
スケープゴートに見立てた。このようなことはよく起こる。ときには収集のつかない
事態に陥り、Daveのような人物がチームにいなくなった時点で必然的に終わりを
迎える。
溺れるのも泳ぎ切るのもチーム全員である。個人としてのヒーローはいない。
チームがヒーローになるのである。
P173
個人の失敗というのはあり得ない。失敗するのはチームである。
誰かの判断を信頼する、称賛に値することを知ろうとする勇気。
ベストを尽くす度胸と決断力、あきらめない頑固さ
P174
スクラムは万人向けではない。
0
-
非常に分かりやすく、なぜスクラムが必要なのか書かれています。
「スクラムミーティングは単に情報を集めるだけのミーティングではなく、チームのためのミーティングである。
ミーティングではメンバが単に何かを行ったかを把握するだけではなく、何を行ったかをメンバの前で発表する場でもある。この方法ではメンバが何をしているかを聴き、後で助けを申し込むことも出来る。
単にメンバの前で問題を発表するだけで終わるのではなく、互いに面と向かって問題を管理する。こうすることにより、全員が勇気と正直さを持ち、問題を解決するプレッシャーに対する手段を得ることができる。
また、メンバが次に何を行うかを全員の前で約束させる。そうすれば、テストに対する信憑性と信頼性が増す。スクラムは、深い社会的な相互関係でチームメンバ間における信頼を確立する。」
P116
0
