「アジャイルサムライ」

アジャイルサムライ

読むの2度目。前回よりも実戦経験を得た上で読む。

メモは、改めて意識したいと思った部分や気づいた部分、だけ。

3つの真実

  1. プロジェクト開始時にすべての要求を決めることはできない
  2. 決めたところで、どれも必ずと行っていいほど変わる
  3. やるべきことはいつも、与えられた時間と資金よりも多い

だから、アジャイル開発を選ぶのだ。 計画→フィードバック→改善のサイクルをちゃんと回すことで変化に対応しやすく、よりよいプロダクトへと軌道修正しやすいから。

開発チーム

開発チームにはクロスファンクショナルなメンバーで構成されていて、テクニカルライター、ビジネスアナリスト、プロジェクトマネージャ、プログラマ、データベース管理者、UXデザイナー、テスターなどが含まれる。

アジャイル開発を始めると、プログラマとプロジェクトマネージャくらいしか開発チームにいない、ということはよくあるけど、テスターを追加するというのはやったことがないかも。結構別働隊的に動いているかな。。

インセプションデッキについて

プロジェクトがどんなものであるかを短い10個程度の質問によって明らかにし、すべてのステークホルダーに見えるようにする、というもの。 プロジェクトを立ち上げると、いろんなマネージャーや企画方面からの夢が大きくなりがちですが、対立点やバランスを考慮した上で、こういったものを予め決めておく事は重要ですね。途中で、絶対に、根本を揺るがすことを言ってくる人がでてくるので、そういうブレそうになったときに皆でみるものとして使えます。

特に重要なのは、

  • 期間を見極める(いつリリースするか)
  • やらないことリスト
  • 何を諦めるか

あたりかなと思いました。 ちなみにインセプションデッキ上の期間および費用の見積もりは超適当で、精度なんてあてにならないもの。

開発期間を見極める

小さく始めるためには、プロジェクトを6ヶ月にするのがリスクとのバランスの上では最長という考え方があるらしい。 あくまでも、アジャイル開発という点からすれば、ということであるけれど。

これは与えられた制約条件の中にすでにリリース時期がある程度固定されてしまう場合があると思うけど、たしかに「サイクル」ということを意識すると、短いほうが良さそう。

ユーザーストーリーの単位はINVEST

  • Independent
  • Negotiable
  • Valuable
  • Estimatable
  • Small
  • Testable

POを企画とか開発しない人がやったりするとこのあたりは絶対と言ってよいほど守られないので、スクラムマスターや開発チームからしっかり監視する必要がありますね。Jiraのテンプレートに反映させるべきかもしれない。

見積もりは不確実である

いわゆる不確実性コーンであり、遠いものほど不確実性が高まるので、スコープのコミットする時期を遅くするほうが良さそう。