ジェフ・サザーランドのレビュー一覧
-
-
Posted by ブクログ
# スクラムの作成者による“スクラム”
スクラムの共同開発者の一人である、ジェフ・サザーランド氏による”スクラム”。
本書を読むことで、スクラムの役割、イベント等が、このようなかたちになっていことが理解できる。スクラムで表現されることを外側をなぞるだけではわからなかったことが、本書でわかるようになる。
特に印象深かったのは、以下の点である。
■目指すチームはオールブラックス
> ハカを踊り相手サイドに攻め込むオールブラックスの映像を見て考えた。なぜこうなれないのか。こういうスピリットを持てないのはどうしてか。私たちは単なるいいチームではなく最高のチームを目指していた。
（”第四章 時間”）
■元々、プロダクトオーナーという役割がなかったが、チームの仕事が思いの他進んでしまい、サザーランド氏がバックログを書く時間が間に合わなくなったため、必要に迫られてプロダクトオーナーという役割を追加した、とのこと。
(“第八章 優先順位”)
■理想のデイリースタンドアップミーティングは、アメリカンフットボールのハドル
> ミーティングについてときに見受けられる問題が、デイリースタンドアップを個人の進捗報告の場にしてしまう点だ。(中略)効果的なアプローチとしてはフットボールのハドル〔訳注 次のプレーを決めるために選手がフィールド内で行なう作戦会議〕に近い。ワイドレシーバーが「あのディフェンシブラインマンに困ってる」と言うと、オフェンスのブロッカーが「こっちで何とかするよ。俺がラインを崩す」と答える。(中略)チームの勝利を導くために何をすべきか、短い時間で協議するのが目的だ。この「勝利」はスクラムでいえば「スプリントを計画どおりに終了する」ことだ。
（”第四章 時間”）
------
本書は、スクラムに関する、一段深い理解を与えてくれるのは間違いない。一通り、スクラムを学んだら、次に読んで欲しい一冊である。 -
Posted by ブクログ
私が見積もりが苦手（リスクが読めない）なのもあるが、ある程度精度の高い見積もりをする場合、もう作ってしまった方が早くない？といつも思っていたので深く共感出来る内容だった。いつもこうすればスムーズにいくと感じていたことが書いてあってこれはスクラムと名前がついていることを知れた。イイぞもっと言ってやれ！って感じで読むことが出来た。全てを業務に適応させるには厳しいかも知れないが一部のみ適応しつつ実績をつむことで、スクラムのファンを増やすことが出来ればいずれはそういう社風になっていくかと考える。ウォーターフォールしか知らない方は是非読んで欲しい書籍です。
-
-
-
-
-
Posted by ブクログ
アジャイル開発フレームワーク「スクラム」の生みの親である、ジェフ・サザーランド氏の著書。
スクラムはプロジェクトにおける無駄を徹底的に排除し、チームに幸福をもたらす。生産性を高めるツールとして、今最も熱いフレームワークだ。
本書はスクラムの方法論を教科書的に説明するものではない。米国人特有のやや冗長なストーリー主体の書籍であり、豊富な事例でもってスクラムがチームを変えてきたことを証明する。
開発手法と言うよりも、プロジェクト管理手法であり、ソフトウェア開発のみならず様々なシーンで適用できる。オランダの高校の化学の授業でさえ、スクラムを取り入れているという。
1週間のスプリントの最後には、何ができたかではなく、どう仕事を進めたかをチームで話し合う。次のスプリントではどうすればもっとうまく皆で仕事を進められるだろう？今回のスプリントで進捗の妨げになったのはなんだろう？チームのベロシティを下げた障害物はなんだろう？
1章 過去のやり方は通用しない
2章 スクラムが誕生するまで
3章 チーム
4章 時間
5章 無駄は罪である
6章 幻想を捨て現実的なプランニングを
7章 幸福
8章 優先順位
9章 世界を変える。
キーフレーズ
・チームがうまくいかない時、他人を責めるのではなく、システムを変えることを考えよ
・ソフトウェア開発のために作られたというが、高校の教育現場にも広がりを見せている
-
Posted by ブクログ
普段チームでアジャイル開発をしているが、「バックログ、ベロシティの計測、デイリースタンドアップ、レトロスペクティブなど」が、なぜ必要になったのか？という背景が、効果が上がった事例と共に紹介されており、発見が多い本だった。
以下は特に気づきがあった部分。
- チームのスピードアップを妨げる要因となっている「障害」を見つけ、改善し、ベロシティを上げていく。（KPTの P -> T で何気なくやっていたことが「障害」を潰すことをしていた、ということに改めて気づいた。）
- デイリースタンドアップでは、個人の進捗報告だけに終わりにせず、「チームの全てのタスクを終わらせる」というスプリントのゴールに向かって、チーム全員で協力する姿勢が大事。（「あなたは1日かかると見積もったが、私が加われば1時間で終わるから協力します」、などと積極的に申し出る）
- レトロスペクティブでは、「何ができたか？」ではなく、「どう仕事を進めたか？」をチームで話し合い、次スプリントではどうすればもっとうまくみんなで仕事を進められるか？進捗の妨げになっている「障害」はなんだろう？を見つけて改善していくことが大事。 -
Posted by ブクログ
アジャイルソフトウェア開発宣言執筆者の一人である著者が、プロジェクト管理の手法であるスクラムが、システム開発以外にも応用できることを説いている。プロジェクトにかかわるすべての人にぜひとも読んでほしいと思った一冊。
冒頭、FBIが第二の同時多発テロを未然に防ぐプロジェクトのストーリーから始まる。４億５００万ドルを費やしたが、まだ半分しか進んでおらず、すでに予定より１年遅れていて、完成まで６年から８年を要し、さらに３億５０００万ドルを投入する必要があるという危機的な状況を打開するというものである。この後、スクラムを導入して打開していくのだが、進め方を間違えると、巨額と長い期間を無駄にしてしまうということは、他人事とはどうしても思えない。
ちなみに、ガントチャートは１９１０年ごろに発明されたものらしい。確かに、今時このお古にこだわる必要はあるまい。
・プロジェクト最初の週、二人はおそらく誰でもここから始めるだろうという作業から着手した。要求事項が書かれた文書をすべてプリントアウトすることだ。…二メートルほど積み上げられた書類の山がいくつも並ぶようなプロジェクトの例は後を絶たない。…そんな膨大な量の文書をすべて読む人はいない。実際、全部読むことはできない。ポイントはそこだ。現実とはかけ離れたものを承認させるしくみなのだ。
・アジャイルソフトウェア開発は次の四点に価値を置く。プロセスやツールよりも個人と対話、包括的なドキュメントよりも動くソフトウェア、契約交渉よりも顧客との協調、そして計画に従うことよりも変化への対応。
・彼が考える、スクラムの一番の強味とは？「デモですね。デモンストレーション可能なプロダクトをこまめに完成させていく点です」二週間のスプリントごとに、開発チームはその時点で完成したもののデモンストレーションを行った。この「見せて説明する」相手は自分たちチームの中だけではない。できたものを、実際システムを使う人たちに動かしてもらうのだ。
・スクラムで大事なのは開発側じゃありません。顧客とステークホルダーです。
・ロッキード・マーティンが予算の９割と１０年の年月をかけてできなかったことを、私たちは予算の５パーセントで２０カ月後に完成させる、と議会に言ったんです。
・第１章 過去のやり方は通用しない まとめ
・計画は有効だが、何も考えずに計画に従うのは愚かだ
・検査と適応
・変わるか、つぶれるか
・早い段階で失敗し、早いうちに修正する
・世界の優れた企業のチームにみられる特徴
１．境界や限界を越える
２．主体性
３．機能横断的
・機能横断的なチームが結果を出せるといっても、…あらゆる方面から二人ずつ連れてきてチームを作ればいいわけではない。チームの力をうまく発揮するためには、チームは小さくなくてはいけない。標準的な人数は５人から９人までだが、わずか３人で高いレベルの成果を上げたチームもあった。非常に興味深いのは、９人を超えるチームになると、プロジェクトのスピードは落ちることがデータにも表れている点だ。つまり、人を投入しすぎるとチームの機動力は下がってしまう。
・コミュニケーションを妨げるのは、仕事を専門化することだ。グループ内の役割や肩書の数と言ってもいい。何かに特化した肩書がつくと、人は概してその名前に合致した仕事しかしなくなる。そしてその役割についてくる権限を守ろうとして、自分の持つ知識にしがみつこうとするものだ。
・デイリースタンドアップ
１．チームがスプリントを終了するために、昨日何をしたか
２．チームがスプリントを終了するために、今日何をするか
３．チームの妨げになっていることは何か
・必ず全員が参加すること
・長さを１５分以内に収めること
・全員が能動的に参加すること
・私たちは常に最初から完璧にできるわけではない。私たちは人間だ。人間は間違いを犯す。この間違いにどう対処するかによって、どれだけすばやく仕事ができるか、どれだけ質の高い仕事ができるかに非常に大きな違いが生まれてくる。…トヨタでは工場で働く誰もがラインを止められる。そこには、工程は常に改良できる、問題の解決には後からではなく問題を発見したその場であたるのがベストである、という考え方が根底にある。
・パームでは社内全体に何百といるマットのような開発者を調査し、バグが見つかったときにすぐに修正するのと数週間後に修正するのではかかる時間がどう違うのかを分析した。…
なんと、その差は２４倍だった。バグに気づいたその日のうちに対処した場合、１時間で修正できたとすると、３週間後では２４時間かかるのだ。バグの大小や複雑さの程度に関係なく、どんなバグでも３週間経ってからとりかかると２４倍の時間がかかったのだった。…
人間の脳には限界がある。私たちが記憶できる量は限られている。真に集中できるのは一度に一つのことだけ。物事を修正するプロセスは時間が経過するほど困難になるというこの事実も、同じく人間の限界を示している。…それぞれのタスクにはそれぞれ理由があることを常に頭に置いている。…ある決定をしたときに考慮した要素をすべて思い出さなくてはいけない。その決定に至るまでの思考プロセスを再構築する必要がある。…これには相当な時間がかかる。
・活力がなくなると人は正当な判断をしにくくなるのだ。
この現象は「自我消耗」と呼ばれている。何についてであれ、何かを選択し決断する行為は消耗する、というものだ。…身体は疲れたとは感じていないけれど、正しい決断をする力が衰えてしまう。
・第五章 無駄は罪である まとめ
・マルチタスクは失敗の元
・「半分できた」はできていない
・最初から正しくやる
・仕事のしすぎは悪循環を生む
・無理はしない
・ヒーローはいらない
・無駄なポリシーはいらない
・困り者は無用
・流れるような境地をめざす
・ストーリーを書くとき、あるいはやるべき仕事のリストを作るときに大切なのが、次の二つを問いかけてみることだ。「ストーリーが準備できているか」「完了したかどうかをどう判断するか」だ。
・ストーリーができているかをみるのに私がいつも使う基準がある。
Indepedent(独立している)
Negotiable(交渉できる)
Valuable(価値がある)
Estimable(見積もり可能)
Small(小さい)
Testable(テスト可能)
・プロダクトオーナーに必要な要素
?仕事の領域に精通していること。
?決定権を行使できること。
?すべきことは何か、またなぜそれが必要なのかをいつでもチームに説明できること。
?価値を説明できること。
・顧客にとって高い価値のある機能や特徴だけを提供するというこの考え方を、新しいレベルで実践している企業がある。数年前、スクラム導入支援を行なうある会社が、大手建設会社にソフトウェアを提供するプロジェクトで１０００万ドルの契約を結んだ。期間は２０カ月で合意したが、スクラム支援会社は契約書にこんな一文を入れた。建設会社側が契約を終了したい場合は、契約の残り期間分に相当する料金の２０％を支払えばいつでも終了できる、という条件だった。希望どおりにソフトウェアが動いた時点で、建設会社側が開発作業を終了できるという内容だ。
-
Posted by ブクログ
ここ数年で、日本のほとんどのITエンジニアに名前は浸透していると思われる、スクラム。
本書は、スクラムの生みの親のジェフ・サザーランドによるスクラムの解説書になる。なぜスクラムが生まれたか、スクラムを導入すると何が起こるのか、なぜ導入すべきかが、筆者の経験・実例を交えてわかりやすく説明されている。
オランダの学校でスクラムのやり方を取り入れた授業、エデュスクラムは、生徒の主体性を育てる素晴らしい実例で、非常に羨ましく思った。
自分は過去に実験的にスクラムを導入するプルジェクトに参加したことがあるが、チーム全体のスクラムに対する理解が浅いためか、うまくいかなかったことがある。
ただ、スクラムが起こす変化の力を非常に感じたのを鮮明に覚えている。
またスクラムをしたいもんだ。
-
-
Posted by ブクログ
ネタバレスクラム関係の本は５、６冊は読んだが、その中でも必読の本。ウォーターフォールとの対比が分かりやすい。
・チームの重要な要素
個人のパフォーマンスだと１０倍ほどの開きが出る。これをチームで見ると２０００倍ほどの開きが出ることがわかった。これから分かることは、メンバー個人の力量に注目して、生産性を上げるより、チームに注目して生産性を上げる方が効果がある。その大事な要素が自律的なチーム。
・ブルックスの法則：遅れているソフトウェアプロジェクトへの要素追加はプロジェクトをさらに遅らせるだけ。
・根本的な帰属の誤り：自分んは状況に判断して行動をきえめていると考える一方で、他者についてはその人の性格的な傾向が行動を左右しているのだと捉えること
＝＞なのでスクラムでは犯人探しではなく、取り巻くシステムの問題点を探すようにすること
・仕事量を減らすと成果が倍増する
なぜか？人は長時間仕事をし続けるとミスをするようになる。１からやるより修復する方が労力がいる。働きすぎると集中力を欠き、他の人の気を散らすようになる。
・不確実性のコーン
計画を立てても、４倍かかることもあるし、1/4しかかからないこともある。その差は１６倍。いくら時間をかけて見積もっても最大４倍の開きがあった。
＝＞相対式に見積もって、見積もりにかかる時間を減らそう。（フィボナッチ数であれば、人間は悩まずに違いが感覚的に分かる）
・タスクではなくストーリーを
まずは誰のためのものなのかを把握する。誰の目で見た世界なのか？を把握する。次に、何を。次になぜ。
・プロダクトオーナーに必要な要素
1.仕事の領域に精通していること
2.決定権を行使できること
3.すべきこと、なぜ必要かをチームに説明できること
4.価値を説明できること
・OODA（ウーダ）ループ：
観察から入る。速い変化についていけるようにするためのもの。（F86とMiG15戦闘機の戦いからの発想：F86の方が性能が低いがコックピットの窓が丸型で視界が良く速く反応でき撃墜されにくかったことから） -
-
Posted by ブクログ
アジャイル開発のひとつであるスクラムについてを考案者が自ら解説する本です。従来のウォータフォールモデルの開発の弊害を考察しつつ、スクラムの優位性を語っています。スクラムというのは仕事のしかたの方法論、フレームワークです。スクラムマスター・プロダクトオーナー・ディベロッパーの3つの役割があり、それぞれが協調して仕事をすることによって効率良く、熱意を持って働けるとしています。また、スプリントと呼ばれる期間に区切って仕事をすることで振り返り
、軌道修正が速やかに行われ、工数見積もりの評価もやりやすくなります。読み物としても大変面白く、著者の経験に裏打ちされた説得力ある説明になっています。 -
Posted by ブクログ
スクラムの特徴を端的にまとめた本。
変化の多い中でお客さまの
ニーズに合ったものを提供するには、
ウォーターフォール型ではなくアジャイル型が適切。
とはいえ、変化に都度対応しつつ、
ニーズに合わせて対応するのはかなり難易度が高い。
それをこなすために何をすればよいか？を書いています。
また、うまくチームを回すにはどうすればよいか？
についても書いています。
使ったことがない人は一度読んでみるとよいと思います。
【勉強になったこと】
・変化に対応していくためには、早い段階で失敗し、
修正することが大切。
・チームは少人数であるべきだが、
同じ能力を持った人ではうまくいかない。
色んな能力を持った人で組むのがよい。
・会社の仕事の85%は無駄と思え。
・マルチタスクができているのではない。
シングルタスクを切り替えてやっているだけ。
その切り替えロスを考えるとマルチタスクは止めるべき。
・タスクを整理するときは、
見積もれること
小さいこと
が重要。
・主体性、目的意識、スキルアップが
良いチームの三大条件
・スクラムを行うには、徹底的な可視化が重要。
あとは何よりも主体性を持ったメンバーが揃っていること。 -
Posted by ブクログ
仕事に幸福感を感じる事は凄いことだと思う。
スクラムを導入することで、コミュニケーションが増え
無駄を省く点が満足間を与える部分があるかもしれない。普段から自分の範囲のみで仕事をしてれば、抜けや漏れに気づかず進めてしまう。
全員の仕事の見えるかができれば、アドバイスもできるし、各自の成果が見えて厳しくなるかもしれないけどチーム全体にとっては問題点が見えて改善しやすくなると思う。小規模チーム向けのスタイルなので組織へ導入する場合、全体を統括する人の能力が次第。
日本の官僚的な組織に導入すると中間管理職以上の人から既得権を守る為に猛反対を受けるのは間違いない。 -
-
Posted by ブクログ
当たり前ですが速くなりません。
銀色のように見える本ですが、銀の弾丸にはなりえません。
スクラムのいいところを得たいと思って読んだものの、
ちょっと言いすぎなんじゃないと思うところが多く・・・。
その一方で書かれていることは正しいのだろうと思うところもあったのはあった・・・。
実際にスクラムをやるとなると、この本ではできません。
（以下抜粋。○：完全抜粋、●：簡略抜粋）
○1968年に『ハーバード・ビジネス・レビュー』誌に掲載された、
二人の日本人経営学者、野中郁次郎と竹内弘高の論文だった。
タイトルは「新たな新製品開発競争（The New New Product Development Game）」といった。
（P.50）
●会計事務所の業務や戦艦用のソフトウェア開発、IBMのIT関連まである、
3800のプロジェクを分析した結果、
仕事の遅いチームが同じ仕事をするのにかかった時間は、仕事の速いチームの2000倍。（P.62）
○遅くまで働くのはコミットメントのしるしじゃない、うまくいっていないことの表れなんだ。（P.132）
●プロダクトーなーに必要な要素（P.230-232）
1．仕事の領域に精通していること
2．決定権を行使できること
3．すべきこと、その理由をチームに説明できること
4．作ったものの価値をきちんとして説明できること（週40ポイント使って、xx円の利益になるとか）