-
Notifications
You must be signed in to change notification settings - Fork 47
Readingagilesamuraiinhiroshima20150819
８月１２日の予定でしたが、お盆近くでいろいろと立て込みましたので１９日にさせていただきました。２回目より「すごい広島」と共催？させていただいております、場所はムービンオンになります。
参加者は少なく寂しい一面もありましたが、しっかり読み込んで短い章だったこともあり早めに解散しました。
次回は少し開きますが、９月１６日にしたいと思います。
実際のシステム開発見積もりについて考えてみる。一度やったことのあるシステムであればそれを導入する期間などはある程度見積もれるかもしれない、しかしやるべきことは開発である。
（かいほつ）もともとは仏教用語で、仏性を開き発（ほっ）せしめること。
（かいはつ、英:development）上記仏教用語からの転用で、自然や知識を利用してより人間に有用なものを生み出す行為。本項で詳述。
人間が行なってきた経営事業の情報処理を、コンピュータプログラムを用いてシステム化する事が現在、主に言われるシステム開発の一つである。
ようするにやったことないことを、開発というのだから見積もりは当てずっぽうに決まっている。ただし、研究開発とは異なるので、そこは注意
ソフトウェア見積りの主目的は、プロジェクトの結果を予言することで はない。見積りを行うのは、プロジェクトのターゲットがコントロールによって達成可能な程度に現実的なものかどうかを判断するためである。
↑これは予算内かどうかの判断を言っている、本当は見積もり幾ら幾らで、達成確率が何パーセントとかの話ではないのか？
見積もりを出したのだから、死んでも実行しないと許されないという方がおかしいと思う。→だって初めてだし
相対見積もりだと上手くこなせる→これでも成長率やモチベーション低下は計れない
相対的な大きさの判断と、どれくらいの速度でススメかれるか（ベロシティ）を計測すれば、この二つでアジャイルな計画作りは成立する。
日数でなく、ポイントにすることで単位に関係なく見積もれる
①三角測量は、代表的なストーリーをいくつか基準として選出し、残りのストーリーを、基準になるストーリーとの相対サイズで見積もるやり方だ。→これは最小、最大、中間の３つの見積もりから全体を振り分ける感じかなあ
②プランニングポーカー、「みんなの意見」は案外正しい、一人が独裁的に見積もるよりか、みんなで見積もりしたほうが正しい結果が出る
シンプルに１、３、５のカードだけで良いというのは、粒度の問題でもあるので、前段階で整理できているかが問われることになる
もしも見積りの途中で、これまでに経験がなくてサイズの見当がつかないストーリーに出くわしたら、「スパイク」を実施しよう。
↑スパイクは実装調査で、タイムボックス化された実験（数日かけて見積もれる状態になること）
忘れないためのメモ、次回は付箋を用意して各自記入するようにする。