ReadingAgileSamuraiInHDE20130709 - agile-samurai-ja/support GitHub Wiki
「アジャイルサムライ」読書会 in HDE 第二回 の記録
- 優先度をつけて優先度の高いものから処理できるように考える
- 全部優先度が高い！といわれることが多い→お客様に考えされるように出来れば良い
- 無駄なこと＝ドキュメントのイメージが強い！
- 納品物として決まっていることが多いのでなかなか・・・
- 逸話：テスト項目書の日付は手書きで！ｗ
- 総じて、顧客を巻き込んで考える★
暗黙の期待に答えるためにはどのようにすれば？（P.6)
- 期待が暗黙的に伝わるかい！
- 「暗黙的な期待」をどうやって探る？
- 期待をマネジメントする
- １週間単位など短いスパンで意見を聞いて反映
- WEB系では大体できてから、フィードバックを求めているため、フィードバックを求める機会が少ない
- 機会が少ないのは会社の風習
- 納期直前に要求が増えたりして大変になることが
- 機械を増やしたい
- フィードバックをもらうようマネジメントするのは非常に難しい
- 動くものこそ価値がある！ということを再認識
- 動くようにテストすることが必要！
- 全部テストをする必要がないこともある→必要な部分を考える←アジャイル的でない？
- 大きな問題を細分化して、個々にフィードバックを求める
- テストしてダメだった場合は・・？←アジャイルではこれは考える必要ない？
- アジャイルでのテストは動くことを保証するためのもの
- テストして動く部分を順にリリースするイメージ
- 「実際の計画」で線がぐるっともどっているのは「やっぱりその機能いらない」と言われたとか？
- 問題を細分化して、戻りを少なくする
- 「アジャイルだから」ということだけで求めていては本末転倒になりかねない
- フィードバックを求める意味を常に考えたい
- お客様に本当に必要かあやしいこともある
- 毎週などフィードバックを行うのは非常にエネルギーを使う
- それにまさるメリットがないとしんどい
1.2 アジャイルな計画づくりがうまくいく理由 (p.8-9)
- 調査だけで１週間かかることもある→これは成果なしとなる？
- 動くものありきで考えると調査っていうのは・・・？
- チームとして成果があればよい
- プロトタイプ的なものができれば
- ドキュメントも成果では？
マスターストリーリストでどうやってプロジェクト進めるのか
- ここでのフィーチャーはお客様に見せるものとして、内部的により詳細なストーリーがあってもよい
- 実際にはチケット的なやり方でやるもの？
- ユーザストーリーがそのままチケットなるイメージ
- フィーチャーはユーザ視点のもの
- 実際のチケットこの中の詳細なタスクだろう
- 職人技も大切だが、実測することによって、安定して進められる
- これを解決するために→P.140 プランニング効果
- 機能要件とどう違う？
- 機能要件とは、ここを押したらこうなる、みたいな動作に関わるもの
- 非機能要件は、レスポンスタイムなどシステム側に関わるものなど
- 作るものにもよるが、一括請負ものはアジャイルとギャップがある
- エンドによって決められていてこちらでコントロールできない場合はどうすれば？
- 8章 固定された政府向けのプロジェクトでは・・・（乞うご期待）
- できないことを説得力を持たせて説明できれば
- やれることだけをやれるようになっていくだろう！
- これを使うだけでアジャイル開発になる！？
- ぜひ使ってみてください！
⚠️ **GitHub.com Fallback** ⚠️