石垣賀子のレビュー一覧
-
-
-
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 ブクログ
テンポよい語り口と困難を明るく乗り越えていく著者の生きる姿勢のおかげで読後感が非常に爽やかだった。 朝、目が覚めて、今から始まる一日にわくわくできないのなら、あるいは間違った道にいると感じているのなら、この先進むべき道は見えてこない。ここに立ち返るべきだと僕はいつも思っている。それが何かを言葉にしてみる。報酬のことではなく、こんなこと考えてみる。どんな人が周りにいるか。その人たちはどんな仕事をしているか。職場へはどうやって行くか。自分の仕事を、他の人がどんな言葉で形容しているか。
・・・この本を読んでこの部分に出合えたことも本当にラッキーだと思う。 -
-
-
-