アジャイルな見積りと計画づくり の商品レビュー
・ビズ側の人間が読んでおきたい本過ぎた。 ・工数とスケジュールを見積もる、という超基礎の作業が、実状的に顔色伺いで決まってるケースは多いと思う。知識がないから踏み込めない、迎合してモヤる、そんな当時の(?)自分に渡したい本。 --- ・この小話がついてるタイプの本も久々に読んだ。...
・ビズ側の人間が読んでおきたい本過ぎた。 ・工数とスケジュールを見積もる、という超基礎の作業が、実状的に顔色伺いで決まってるケースは多いと思う。知識がないから踏み込めない、迎合してモヤる、そんな当時の(?)自分に渡したい本。 --- ・この小話がついてるタイプの本も久々に読んだ。イイハナシダナア
Posted by
良書だった。 私個人の体験。 まとまった仕事を任されることがある。 その際、なんだかんだ当初の予定期日に間に合わないか、がむしゃらに頑張って間に合わせる、ということが多い。 本書の内容を、考え方から具体的なプラクティスの部分まで実行できれば、これまでのような印象の悪いプロジェ...
良書だった。 私個人の体験。 まとまった仕事を任されることがある。 その際、なんだかんだ当初の予定期日に間に合わないか、がむしゃらに頑張って間に合わせる、ということが多い。 本書の内容を、考え方から具体的なプラクティスの部分まで実行できれば、これまでのような印象の悪いプロジェクト遅延をなくせるように思う。 ここで重要なのは、アジャイルを習得することは「決まった期限に決まったタスクを完了させる」スキルを得ることではないということだ。 アジャイルでは、価値あるプロダクトを作り、ターゲットに届ける上で何が必要か?どれくらいかかりそうか?を適切な議論をもって設定する。 そうやって算出した規模に対して、必要なイテレーション数(タスク実施をする期間の最小単位)を見積もる。 そして、全体工期には幅を持たせる。 それによって取捨選択をする余地も残す。 最終章の物語調のケーススタディも、それまでの座学の内容を一本の線として繋げるためにとても有効だった。 本書から知った具体プラクティスを1つずつ習得していきたい。
Posted by
アジャイルに限らず計画する時の考え方の基盤となる本 不確実性やリスクを無視しがちだと痛感。 "コミットメントは確率ではない" という本書の言葉に感銘を受けた ソフトウェア開発における様々な手法が記載されており、明日から実践していきたい
Posted by
ネットで本書が紹介されていた。 2ヶ月でヤレみたいなスケジュールが降ってきて(できるわけがない)、応急処置に応急処置を重ねてなんとか6ヶ月後ぐらいに対応できて、最初から6ヶ月あればもうすこしマトモな手段が取れたな〜と反省するまもなく、緊急対応が休むまもなく連続する、というような...
ネットで本書が紹介されていた。 2ヶ月でヤレみたいなスケジュールが降ってきて(できるわけがない)、応急処置に応急処置を重ねてなんとか6ヶ月後ぐらいに対応できて、最初から6ヶ月あればもうすこしマトモな手段が取れたな〜と反省するまもなく、緊急対応が休むまもなく連続する、というような感じはよくあることだろうか。やっている本人は「これこそがアジャイルだ」と思っているけど、メンバーは疲弊するばかり。なんとかリリースは出すけれど実現されるものは年初計画とはどんどん離れていく。考課は推して知るべし。 本書で提唱する計画は、日数で見積もるのではなく、相対的なポイントでユーザーストーリーの大きさを見積もり、それに速度計数を掛けてイテレーションの計画を立てる。イテレーションの期間に遂行できるポイント量を割り当てて実行する、ということでもある。やってみると、これがよく当たる。スケジュールの精度が良く、将来の見通しが良くなり余計な仕事が減る。計画に用いるパラメータの具体的な計算手順や、ケーススタディも充実していて、分厚いがそのぶん実践的な本である。 自己流で工夫したやり方を重ねるよりも、外部で実績がある方法をまずは試して取り入れてみよう、となるかどうかは職場の雰囲気によるだろう。スケジュール管理・プランニングも、電気回路理論などの固有技術と同様に、理論や方法論があり、自己流の経験で苦労するよりも学んで身につけることができる技術ということを、まず理解しよう。だれしも、リンゴが落ちるのを観察して万有引力の法則を自分で苦労して再発見したくないだろう。
Posted by
# 明日から実務で使える、アジャイル開発の指南書 ## 面白かったところ - ざっくり・ふんわりしたアジャイル開発特有の「見積もり」「計画づくり」「タスクとストーリーの違い」などが明瞭に説明説明されている点 - 「やるべきこと」と「やってはいけないこと」が説明されている点 ...
# 明日から実務で使える、アジャイル開発の指南書 ## 面白かったところ - ざっくり・ふんわりしたアジャイル開発特有の「見積もり」「計画づくり」「タスクとストーリーの違い」などが明瞭に説明説明されている点 - 「やるべきこと」と「やってはいけないこと」が説明されている点 - すべてを解説した上で、ケーススタディの物語が綴られていること ## 微妙だったところ - 特になし。強いて言えば、アジャイル開発初心者にはハードルが高い点 ## 感想 業務で信頼しているマネージャから推薦された一冊。ずっと積んであってこの機会に導かれた。 自分自身、アジャイル開発に対して蓄えた知識と経験が相まっており、当書を手に取ったタイミングが神架かっていた。 僧帽筋が膨れるほど頷いた一冊。 特に、「未完成で仕掛の作業が溜まっていくと、チーム全体のスループットを低下させる」というトピックだ。 タスクもストーリーもできるだけ分割し、作業開始・仕掛・完了のペースをできるだけ短くする経験は、自分の中にあるセオリーが正しかったと答え合わせができた。 また時が来たら読み返したい一冊。
Posted by
・大規模チームの計画の立て方 ・イテレーションの長さの決め方 ・マネージャへの申告報告 ・ストーリーの優先順位付けの方法 ・プロジェクトの全体像を把握する などについての解説本。 計画したことは、ほぼ計画通りには進まず、その都度計画を見直し、再見積もりが重ねられるわけだが、それ...
・大規模チームの計画の立て方 ・イテレーションの長さの決め方 ・マネージャへの申告報告 ・ストーリーの優先順位付けの方法 ・プロジェクトの全体像を把握する などについての解説本。 計画したことは、ほぼ計画通りには進まず、その都度計画を見直し、再見積もりが重ねられるわけだが、それは予算や時間との戦いとなってくる。その鬼気迫る感覚は、「どんどん大きくなるクマとダンスする(トム・デマルコ)」ようなヒリヒリ感だ。本書はその相談役として、マニュアルとして助けてくれる。
Posted by
見積もり、計画作りで重要。 WFに比べ、スケジュールが見えにくいアジャイルですが、この本理解することで、計画を作ることができます。
Posted by
”PMBOKの計画づくりを本格的に学ぼうとしていた矢先なので、タイトルが気になり購入 --- T: P: O: --- <読書メモ>”
Posted by
具体的なやり方をなぜそうするのか含めて説明してくれているのでとても参考になった。 本に書いてあったからこうするのではなく、現場のフォースを見極めた上で適宜学んだ知識を適用していくよう心がけたい。
Posted by
従来の計画は作業完了を基準にしているが、顧客からすると価値の単位はフィーチャーである (バリューストリームマッピングは意味がある) 作業基準の計画はパーキンソンの法則により、フルで使うようになってしまう。(という暗黙の了解を得る) 計画は確率であってコミットメントではない ユ...
従来の計画は作業完了を基準にしているが、顧客からすると価値の単位はフィーチャーである (バリューストリームマッピングは意味がある) 作業基準の計画はパーキンソンの法則により、フルで使うようになってしまう。(という暗黙の了解を得る) 計画は確率であってコミットメントではない ユーザーストーリー→プロダクトバックログ→スプリントバックログ リリースプランニング→つぎのリリースのテーマやユーザーストーリーを検討 イテレーションプランニング→スプリント計画 プランニングポーカーのゴールは精緻な見積りを出すことではなく、低コストで価値のある見積りを出すこと(労力、正確性曲線の左上) プランニングポーカーの議論を長引かせすぎると曲線の右に追いやられ、労力に見合った正確性がでなくなる ベロシティは補正装置である 再見積りすべきときは相対サイズが変わったときのみ ベロシティを計測するときのポイントの乗せ方はオールオアナッシングが原則 チームが熟練してストーリーポイントが変わることはない(サイズが変化するのは例えばフレームワークを導入したとか) 目標の不確実性(なにを作るか)はいきなりなくせないことは前提にありながらも、早めに(優先的に)減らしていくべき スプリントレビューは誰でも参加可能 優先順位づけ(スプリント始まる前) スプリントレビュー(1つ前) スプリントプランニング(レビューと同日) スプリント(次のやつ) 開発はヨットで海を航海するようなもの (風向きや波によって進むべき進路が変わる) 個人のベロシティは測るべきでない
Posted by