-
Notifications
You must be signed in to change notification settings - Fork 47
Readingagilesamuraiinhiroshima20150916
いろいろと立て込んでいましたので少し期間が空いてしまいましたが、１６日に開催させていただきました。２回目より「すごい広島」と共催？させていただいております、場所はムービンオンになります。
まさかの、ひむひむが風邪で欠席となってしまいましたが、何とか開催しました、会費は次回に払います。じつは日曜日にひむひむとあったのですが、そのときに風邪を移してしまったのでは？と少し気になっております。もしそうであれば、そーとー長引いて咳が止まらないので、ここで謝っておきます。「ごめんね、ひむひむ」]
次回は、９月３０日にしたいと思います。
「変化と向き合うための戦略」がなければ、君の暮らしは荒れ狂うプロジェクトに翻弄されるがままになってしまう。相手によって変わるのは戦略ではない、戦術のような気がする、言葉だけの問題か？
それを猛々しく言うとおかしくなるような気がする、変化ありきを受け入れることは戦略ではない。
主力開発者が他のプロジェクトに引き抜かれてしまった。→これは痛い！でもよくある話だ。上層部とうまくやっていないとPMに連絡なしで決まっていることさえある、怖い話だ。
思っていたほど開発速度が上がってこない。→見積もりの時に考えた生産性は最終段階での生産性だったりする、そうしないと受注できないとか言われたり考えたりして、そうなるともう終わりかねー
構えー撃てー狙えー狙えー狙え vs 構えー狙えー撃て この図は打った後に狙って方向性を調整できることを意味しているのか、狙わずに撃てはある程度理解できるが、打った後には修正できないよね
アジャイルな計画作りとは、チームの開発速度を計測して、その速度を元にプロジェクトの完了時期を見通せるようにすることでしかない。
イテレーション数＝作業量の合計÷チームの予想ベロシティ
スコープを柔軟にするは、見積もりを明確にしないことと同じ、と考えてはいけないのだろうなあ。まじめまじめ
事実をありのままに、ユーザーに打ち明ける。お客さんが折れるまで、ひたすら耐える、頭をさげる、お手紙（状況概要、理由書）を書き続ける。
過去４０年にわたって続けてきた、ひどい誤魔化しに加担するんじゃない→そのとおり
１、マスターストーリーリスト、このサブセットを「リリース」と呼んでいる。リーリースはお客さんにとって意味のある単位でストーリーをまとめたものだ。１リリースで実装して本番環境にデプロイする価値があるように編成しよう。MMF(Minimal Marketable Feature Set)
２、プロジェクト規模を見極める、大雑把な規模感で全体の規模を、プランニングポーカーなどで把握する。
３、優先順位をつける、ビジネスインパクトが大きいものや、技術リスクが高いものなど、重要度を優先順位をつけよう
４、チームのベロシティを見積もる、チームのベロシティ＝完了したストーリー数÷イテレーション数。３−４イテレーション回さないとベロシティそのものが落ち着かない。
５、期日を仮決めする、期日固定（期日は動かさず、多少の積み残しを検討）とフィーチャセット固定（フィーチャを固定化し期日を動かすことを検討）のどちらか
途中での帳票追加など作業量の変更がわかりにくい、バーンアップチャートとの組み合わせも面白いと思った。
途中からアジャイルに変えていく、それは結構困難だと思うけど、何からやればいいのだろう。目的をはっきりさせるためにインセプションデッキなども有効だと思える。「そんなことより進めたい」と言われるかもしれないが。
いよいよ理論を実践に移す番だ、
１、お客さんが新しい要求を発見したら、あるといいなで残すことは気持ちの問題だ、次期プロジェクトか別予算にしてとはっきり言おう。
２、思っていたほどは早く進んでいなかった時、悪い知らせは早めに伝えるのがアジャイルの流儀だ。→これは正しいが、伝え方を間違えるといけない、「大変だ、大変だ」ではないのだから。
３、大切なチームメンバーがいなくなったら、ベロシティは下がる確実に下がる、交代コスト、説明コスト、慣れコスト、教育コスト、様々な不要なコストがかかる、変えないのが一番と理解してもらえない。たまに遅れる理由にすることもあるよね
４、時間が足りなくなったら、スコープを調整するしかない→これは正しい、ただし言い方を間違えるとまた可笑しなことになる、そのためにスコープの内容を熟知しておく、顧客の優先順位、顧客の価値を把握して提案できるようにしておく必要がある。
忘れないためのメモ、次回は付箋を用意して各自記入するようにする。