Agileでやってるけどデスマったw

 2009/11/08

Agileでデスマになったのでそのログです。

この後同じことを繰り返すと馬鹿なので、まだデスマ中だけど、問題点と反省点を書いておこうと思う。 こういうのは渦中にやっておかないと終わった後だと「大変だけど終わって良かったね」で終わってしまいがちなんだよね。 これを読まれている方は反面教師にしてください。

契約と総生産量の関係性

  • 期間と費用が決まっている場合、総生産量には当然上限がある。生産量はチームのベロシティが分かっていれば、ストーリーポイントに換算できるので、開発開始時点で、総生産可能ストーリーポイントについては明示すべきだった。土日出て頑張れ!とか残業して頑張れ!とかいうのはAgileを知らない証拠。
  • 上記に関連して、プロダクトバックログにストーリーを追加することが出来るのは、プロダクトオーナーの権利なのだけれども、優先度高としてストーリーを追加したところで、バーター可能なストーリーがなければスプリントへの組み込みが難しいことを明示すべきだった。
  • さらに、スプリント完了後に手前のストーリーの仕様を変更した場合も、総生産量制限がある以上、バーターがあることを明示すべきだった。
  • こういう話がされないで顧客と契約されることがないようにしておかないといけない。契約書で明記できないなら、提案書なりでパターン化した記述を常に入れた方が良い。前の会社で嵌ったパターンは、契約書や提案書にこの手の話が書いていないために、無尽蔵に仕様変更を受け入れざるを得なくなるパターン。死人も結構でた。

プロダクトバックログの話

  • パワーポイントの画面遷移図みたいなものをベースにして仕様を決定していくのはデスマパターンの第一歩(散々認識しているけどね)。とにかく最初に止めるべきだった。
  • 画面UIを見ないと仕様が決められないのだとすると、本当に提供したいものは何?というのがプロダクトオーナー側で固まっていない可能性あり。この徴候があった場合はむしろスクラムマスターが、徹底的に顧客にヒアリングして、「誰々はhogehogeできる。それによってfugafuggaを得る」の形で要求を整理しにいくべきだった。画面を見てあっている/間違っている、というレベルよりも、前提は合いやすい。
  • 今回はUIの案からバックログを抽出してしまったので、UIでは見えてこないモデルや状態遷移、非機能要件が見えにくく、画面のUIが変わるたびにバックログのストーリーが変わってしまうという問題が起きている。
  • UIの議論が先行すると、本当に必要なことが見えにくくなる。というのは何度も言っているが意外と理解されない。

プロダクトオーナー、スクラムマスター、Proxy、体制とか

  • 間にProxyな人が挟まるパターンではProxyをやる人にScrumの知識が必要。中途半端に誤解されているパターンは危険。Agileだから早く安くできるんだろ?は聞き飽きる。
  • そういう状況であれば、スクラムマスターはProxyを通さないように行動するべきだった。
  • Agileでは対面のコミュニケーションを最重要視するのだが、分散Agileで全体的にコミュニケーションが不足。
  • スクラムマスターが他の仕事を多数かけもちしているため、後手を踏みやすい。

さ、ガンバろ。この話に関連する話をいくつかあげておこう。

 2009/11/08

著作

寄稿

Latest post: