Readingagilesamuraiinshimane20120223
← Readingagilesamuraiinshimane
- 期日通りにソフトウェアを届けることが居たって苦手、なぜ？
- そもそも開始当初から変わらない計画なんて無かった…。
- やってみないとチームの速度は分からなかった…。
- 見つもりの精度もいまいちだった…。
- 以上のような不確定要素だらけでプロジェクトは走りだす。だから苦手意識がある。
- 回避する方法
- お客さん側も変化に対応できるような計画づくりをしてもらう。
- 過剰な期待を抱かせない。
- 厳格なコミットメントはしない。
- スコープ、期日を計画を立てた後でも自由に入れ替えれるようなプロジェクトですということを両者共有しておく。
- そうすることで、苦手意識が無くなる。
- 質疑応答
- Q.プロジェクトの完了は期日ベースがいいの？フィーチャーセットベースがいいの？
- A.いいかどうか分からないが、期日ベースが好きです。ズルズル進んでいくと、開発にリズムが生まれない。期日を決めて成果物で判断した方がふりかえりやすく、一定のスピードが保てる。
- 素人目線ですが、フィーチャーセット固定だと小さいウォーターフォールみたいで、不健康になっちゃわないか心配。期日が後ろ倒しになってしまうと、「まだ終わらない、まだ終わらない…。」モチベーションを維持できない。
- この日を乗り切れば飲みに行ける！期日を一回伸ばしちゃうと心が折れる。甘えてしまう。速度が上がらない。
- たけしま藩からのメッセージ
- アジャイルを始めるには、自分達がどれくらいの価値を届けれるかお客さんに伝えれていることが前提。
- 実践する為には、開発をしている私達が誇りをもってお客様と向き合っているのかが前提。
- 質疑応答
- バーンダウンチャートをやる為には事前の計画づくりに時間がかかるけど、それをしっかりやれば、その後の実測する動きができていくけど、最初の計画づくりに時間をかけすぎると、お客様から何やってんだと言われかねない。やはり、価値を提供して信頼関係を得ることが必要だね。
- 価値が重要であるという話は、お客さんのステークホルダーに対して、もう無理、伸ばしてよ！と言う為に必要。その為に信頼貯金を溜めておく必要がある。でないと、そうは言ってもやれよ、お金出すけん。できないよって言えることが信頼を持っているということ。
- ユーザーストーリーポイントの積み上げバーンダウンチャートを作ることはメリットがある。一方、ウォーターフォールだとざっくり過ぎる。まったく同じ画面なんてあるハズ無いのに、画面数で掛け算して見積もったりするから。
- 一つの納品までが長い場合、６か月とか。お客さんに納得してもらうことを諦めて、最後にどかんとデスマがくるぐらいなら６カ月分のストーリーポイントを見積もる時間を割くことに価値はある。１カ月単位でリリースを区切ることができるお客さんに対してはユーザーストーリーを見積もる時間は分散されるが、６カ月後のリリースに対してバーンダウンを作る為には、受注した後のポイント見積もりフェーズに時間をかける必要がある。それは痛みを伴うが、できないから勘弁してと早めに伝える、デスマが来る前に伝えることができるというメリットがある。
- 私は事務系の仕事していて、事務系の仕事ではやると決めていたことをやらないのは気持ち悪いと感じる。
- ソフトウェア開発ではこの機能は次のサイクルでってのをやっていると知り、自然なことなんだと感じた。
- スコープと期日について、会社によるかもしれないが、僕が知ってる会社では、スコープではなくて期日を調整しがち。IT業界だからスコープを調整できるというわけではないように思う。
- スコープを調整することのいいところ、悪いところは？
- 本当に必要かどうかは置いといて、お客さんの要件に対して期日をずらしてでも成果物としてお渡しできることはいいこと。
- 往々にして、期日もスコープも守って、不健康に過ごすことが多い。
- どちらか調整できる開発チームはいい方、現状はどっちも固定、ダブル定額が多い。
- フィーチャーは途中で入ることはあっても出て行くことはない。フィーチャー増えたけど期日は変わらないという開発を経験したことがある。
- ダブル定額はお客様には喜ばれるよね、一見。では、それは良くないとアジャイルサムライで言っているのはなぜだろう？
- そもそも不確実な事に向かって走っている途中で、たまたま一回で来たからといって次できるわけではない。でも一度できたら、お客さんも入れれるかもと思ってしまう。それは真のベロシティではない。
- 開発者の不健康についてアジャイルサムライは言っている訳ではないと思う。お客様しったこっちゃないと言われかねない。お客様への不利益があるからでは？なんでどちらか一方を固定した方がいいのか？
- スコープと期日をダブル定額にすると、品質が崩れからではないか。それがお客様への迷惑に繋がるのではないか。
- シナリオに対して感じたこと
- シナリオその１
- お客さんにスコープか期日を選択してもらうことが重要だが、現実ではどちらも要求されることが多い。
- 難しいね。
- あるといいなリスト
- お客さんとの関係が良くなると思う。
- 一方で、立場が違うのでとらえ方が違うので関係が悪くなることもあるのではという意見も。
- スコープ外ですと言えないといけない。
- シナリオその２
- ベロシティが上がらないことにお客様は納得してくれるだろうか…。
- シナリオその１
- 質疑応答
- Q.バーンダウンチャートを使って良いと感じたことがあれば？
- A.デイリーバーンダウンチャートを使っていたが、開発の進捗状況を見える化することでチーム内の対話が生まれた。また、開発が想定より遅れた場合、それを瞬時に察知し、お客さんへ報告することができた。
- バーンダウンチャートについて
- チームの状態を確認する為のバーンダウンチャート（タスク時間の積み上げ）とお客さまと共有する為のバーンダウンチャート（ストーリーポイント）がある。
- 何を使ってやっていた？
- A3の紙を使って。
- 消化したポイントが形になってる。タスクが増えた時は上へ、消化した時は下へ、バーンダウンチャートは嘘をつく為のものでは無いよ。
- 今週のTRYが定着してきた。
- 直前になって参加者が増えてとてもありがたかったです。
- 議論が白熱してしまうとどうしても時間の箱に収まらなくなる。
- 読書会に参加して自分の言動がどう変わったか、知りたい。
- 次回は『一番議論が深まった内容についてだけ発表する』というのをTRYに挙げる。
- とりあえず出席できた。
- 実際に経験上「これが大事！」という話を聞くことができた。（説得力がある）
- 初参戦できた。
- 参加＆発言
- ページ順に付箋を一斉に貼り、付箋の多い箇所を議論することで、深い議論ができた。
- 飲み会より読書会を選んだ。
- 色々な意見が聞けて良かった。
- 開始5分前には会場に着いた。
- 冷静に意見する。
- 実践している方の話が聞けて、具体的なイメージができた。
- 遅れて出席した。
- 事前に読めてなかったので、まとめの発表をうまく伝えることができなかった。
- 魅せる白い板にできなかった。分かりやすさにも欠けていた。
- 白い板へのまとめ方が難しい。
- 討論の進行役だったが、きちんと話を各人に振ることができなかった。
- 予習できなかった。
- タイムキーパーの役割だったのを忘れてた…。
- 時間内に読み切ることができなかったのでまとまった意見が出せない。
- ディスカッションのまとめ方
- 時がきちゃない。
- 開始から参加できなかった。途中参加ですいません。
- ホワイトボードを分かりやすくまとめようと試みましたがイマイチでした… orz
- 久々の参加で、間が空いてしまったので、過去の章を読んでおく。
- ビジュアル的にも分かりやすい、白い板の書き方を調べる。
- 付箋をもっと活用する。
- 予習する。
- バーンダウンチャートを実践で活用してみる。
- 次回までに一通り読んでおく。
- 分かりやすいホワイトボードのまとめ
- 普遍的な話もあったので実生活に活かしたい。
- ホワイトボードには、最終的な結論とか発表で主張したい事を大きく書く。
23.1 → 第7回読書会 → 18.6
参加者10名
Readingagilesamuraiinshimane20120209 ← → Readingagilesamuraiinshimane20120308