ARCHIVE  ENTRY  COMMENT  TRACKBACK  CATEGORY  RECOMMEND  LINK  PROFILE  OTHERS
<< September 2020 | 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 >>
2016.02.05 Friday

スポンサーサイト

一定期間更新がないため広告を表示しています

2012.11.08 Thursday

【アジャイルサムライ】#15 見積もり:当てずっぽうの奥義

アジャイルの見積もりについてです。

プロジェクトで最初に出す見積もりは当てずっぽうである。
→要件が確定し、ある程度の設計がないと何をどうやるか決まらない

以下を満たす見積もり手法が必要である。
・今後の計画を立てられる
・見積もりは当てずっぽうだという前提を踏まえている
・ソフトウェア開発の複雑さを認めている

見積もり技法
・三角測量
代表的なストーリーをいくつか基準として選出して、残りのストーリーを、基準になるストーリーとの相対サイズで見積もるやり方

・プランニングポーカー
ひとつひとつのストーリーを各人で見積もり、それらの数値を見せ合ってチームとしての見積もりを出すやり方

2012.11.04 Sunday

【アジャイルサムライ】#14 ユーザーストーリーを集める

アジャイルサムライ第6章「ユーザーストーリーを集める」より

計画に最新の情報を反映し続ける方法とは?

■従来の要求は文書化していた
・情報は変化する
・顧客の欲しいものではなく、仕様が書かれている
・誤解を招く
・そもそも時間の無駄
→難しい。ユーザーストーリーを作ろう。

■ユーザーストーリー
→顧客がソフトウェアで実現したいフィーチャ(特徴)を簡潔に記述したもの
インデックスカードに記述していく。(フィーチャの本質を捉えるキーワードを留めておくため)

■ユーザーストーリーの○
無駄がない、正確、必要な分を必要なときに
対面でのコミュニケーションを促す
計画がシンプルになる
低コスト、素早い、手軽
最新の情報が反映されている
チームが学習するということを踏まえている
フィードバックを即時反映できる
見積り精度の高低を当てにしない
チームの協調作業や新しい取り組みを歓迎する

■要件定義書と仕様書の×
重厚、不正確、最新じゃない
憶測や誤った前提を招き寄せる
計画が複雑になる
コストがかさむ、遅い、手間がかかる
情報が古くなったまま、放置される
チームが学習するということを考慮しない
フィードバックを即時反映できない
さも見積り精度が高いかのように取り繕う
オープンな協調作業や新しい取り組みを歓迎しない

■こんな流れで作業
ユーザーストーリーをたくさん書く
ブレインストーミング
ブラッシュアップ

文書化は目的ではなく、顧客がソフトウェアで実現したいことは何なのかをつかむことこそが重要。
そのためのユーザーストーリー

2012.11.03 Saturday

【アジャイルサムライ】#13 何がどれだけ必要なのか

インセプションデッキの続き(10) です。
インセプションデッキ完結。

・何がどれだけ必要なのか
今までのインセプションデッキでプロジェクトの見通しをたてた。
どんな人員が必要かをまとめる。
その中には顧客も含まれる。
開発チームからの質問を受ける時間があり、プロジェクトにまつわる最終決定が下せる顧客。
顧客が積極的に関われないとまずいということをアジャイルサムライは何度も述べている。
で、コストを見積もる。

いまやっている私の仕事も設計書の完成度が低いので、質問が山積みになり、回答頻度、内容がどんどん悪化してきた。
スケジュールに余裕があるからまだいいものの、ありがちな、よくない状況。

2012.11.01 Thursday

【アジャイルサムライ】#12 何を諦めるのかをはっきりとさせる

インセプションデッキの続き(9)です。

・何を諦めるのかをはっきりとさせる
プロジェクトでは、予算と期日は変わらないが、スコープだけは広がる。
なんでもできるわけないので、そこをはっきりさせよう。
優先順位をつけて、顧客と調整する。
顧客は優先順位を決められないことがある。
そういう場合は、こちらから提示してあげる。

顧客が理解があるといいのだけれど、力関係とか信頼関係とかいろいろな背景が絡んでくる。
管理者の腕のみせどころ。

2012.10.22 Monday

【アジャイルサムライ】#11 期間を見極める

インセプションデッキの続き(8)です。

・期間を見極める
期間の見積もりは「最善を尽くした当てずっぽう」である。
お客さんにこの提案がコミットメントであると思われないようにする。
何かを作ってそれがどれくらいかかるかを計画へフィードバックしていくしかない。

期間はなるべく小さい単位で考えたほうがよい。
開発サイクルは6ヶ月以内にする(超えると危ない)
(HP CIOランディ・モットの経験則による)
→開発が長期化するほど失敗リスクが増加

2012.10.16 Tuesday

【アジャイルサムライ】#10 夜も眠れなくなるような問題は何だろう?

インセプションデッキの続き(7)です。

・夜も眠れなくなるような問題は何だろう?
プロジェクトのリスクを洗い出す。
・現場監督に時間を割いてもらえない
・チームの作業場所が分散している
・初挑戦のセキュリティアーキテクチャ
・物流追跡システムの切り替えタイミング
など。。

アジャイルプロジェクトに必須な要素
・チームが同じ仕事場にいる
・顧客を巻き込む
・自分の開発環境をコントロールする
・プロジェクトを成功させるために自分が必要だと思うものがある
どれかが欠如することはすでにリスク。

リスクを早めに話し合うことの利点
・プロジェクトの課題を早い段階で明らかにできる
・おかしいと云えるチャンス
・気持ちがすっきりする

取り組む価値のあるリスクとそうでないリスクに整理する。

これは、いわゆる課題の洗い出し、整理ですね。
リスクのないものごとなんてないけれど、無意味に楽観的なのはだめだ。


2012.10.11 Thursday

【アジャイルサムライ】#9 解決案を描く

インセプションデッキの続き(6)です。

第5章「具現化させる」に章立てが変わり、ここからはインセプションデッキ1−5で整理したプロジェクトの背景を具体化していきます。

・解決案を描く
アーキテクチャを図で示します。
 -どんな風にシステムを構築しようとしているのかを図で伝える
 -どこにリスクがあるのかを明確にする
 -みんながその解決策に同意しているかを確認する

オープンソースやフレームワークの採用も検討する。
得意分野にしたくなると思うけれど、それでいいんだと思う。


2012.10.09 Tuesday

【アジャイルサムライ】#8 「ご近所さん」を探せ

インセプションデッキの続き(5)です。

・「ご近所さん」を探せ
プロジェクトの他チームとも良好な関係を築きましょう。
他チームとは、
・運用保守サポート
・データベース管理者
・ヘルプデスク
・インフラ担当者
・セキュリティ担当者
などプロジェクト関係者全部

他者と関わりを持たずにプロジェクトが円滑に進むことはないから。。
仲良くやりましょう。

以上のインセプションデッキ前半(1−5)で、プロジェクトの背景を整理する。
続く後半(6−10)で解決案を決めていく。

2012.10.05 Friday

【アジャイルサムライ】#7 やらないことリストを作る

インセプションデッキの続き(4)です。

・やらないことリストを作る
何をやるかということと同じくらい何をやらないかということは重要である。

「あとで決める」もあってよい。
あとでやるかやらないかを決める。

リストを視覚化することで、スコープ内、スコープ外を一目瞭然にできるとのこと。
何でも出来るわけではないから、要件定義や追加要望があったときにこれは普通にやっていることだと思う。

2012.09.29 Saturday

【アジャイルサムライ】#6 パッケージデザインを作る

インセプションデッキの続き(3)です。

・パッケージデザインを作る
顧客がそのプロダクトを必要な理由と価値は何かということを整理し、チームでなぜそれを作るのかということを意識づける。
→目的、ゴールの共有。

パッケージデザインは、プロダクト名に加えて、
・プロダクトの効能を3つ挙げる
・キャッチコピーを決める
・素敵な画像、写真
を記述した書面である。

Powered by
30days Album
PR