『アジャイルな見積もりと計画づくり』

どうにもプロジェクトの状況が不透明になっていて現場の風通しが悪い気がして、1.5年ほど前から徐々にアジャイル開発プロセスを導入を進めていますが、どうにも手応えがなく
「もっと良い進め方があるんじゃ無かろうか?」といったことを感じています.

アジャイル関係の本は、『アジャイルサムライ』『アジャイルなゲーム開発』の二冊を読んでいるんですが、なにかのヒントになればと思い『アジャイルな見積もりと計画づくり』を読んでみました.

せっかくなので、個人的な備忘録代わりに軽くまとめておきたいと思います.

アジャイルについて思うこと

さて、先に私がアジャイル開発プロセスを導入してみて、うまく機能していないと感じている点をざっと書き出してみると以下のような点が上がりました.

  • ストーリーを優先度毎に終わらせる事ができず、スプリントの終盤に一気にとじるケースが多い
  • ストーリーの終了がスプリント終了間際になるので、スプリントの進捗に自信が持てない
  • ストーリーのステータスが次々に「進行中」になっていくが「完了」にはならない
  • ストーリー間の依存関係が強く、複数のストーリーが同時進行してしまう
  • タスクの担当者意識が強く、負荷が個人に集中してしまう
  • 企画職からの仕様書待ちの状況が発生したり、物量を増やすためのデザイナ作業が(同じチームにもかかわらず)別ラインの様に走ってしまい、チームの連携(連帯)意識が低い
  • 膨大な数のバックログと、(バックログに対して)短いスケジュールに絶望感を感じる

ストーリーの立て方や閉じ方、スプリントの組み立て方に不満を感じています.

ここから、

  • ストーリーは、どのような観点で作成すれば良いのか?
  • ストーリーは、どのように運用すれば良いのか?
  • ストーリーの優先順位はどのように決めればよいのか?
  • 開発期間に対して、実行するストーリーをどのように取捨選択すれば良いのか?

といった疑問に対するヒントが本書から得たいと感じていたのだと思います.

それぞれの疑問点に本書を読んだ観点からコメントをつけておきます.

ストーリーは、どのような観点で作成すれば良いのか?

ストーリーを機能ではなくフィーチャによって分割するべきだという話は、『アジャイルサムライ』『アジャイルなゲーム開発』でも繰り返し書かれていたこと.

「12章 ユーザーストーリーの分割」では、大きすぎるストーリーを分割する際に、機能に偏るのではなく、適切な形で分割を行うヒントが書かれていた.

特に重要だと感じた項目としては、「ストーリーをタスクに分解してはならない」「関連する変更への誘惑を断つ」は、ストーリー分割をする際に注意したいと感じた.

ストーリーは、どのように運用すれば良いのか?

そもそろも「2章 なぜ計画作りに失敗するのか?」の内容が重要だと感じた.

特に、マルチタスク化が遅れを助長していくという話は、ストーリーの運用中に強く意識しておく必要があると感じた.

この点は、『Joel On Software』でも語られていたと思う.

ストーリーの優先順位はどのように決めればよいのか?

9章、10章、11章に詳しくストーリーの優先順位付けについてページが割かれていた.

「10章 金銭価値による優先順位付け」は、なんとなく書いてあることは理解できるのだが、使いこなすのは難しいと感じた.
業務効率化にたいして、コストバランスを見るという観点はとても重要だと感じたので覚えておきたい.

「11章 「望ましさ」による優先順位付け」で紹介されていた、"顧客満足度の狩野モデル”はとても興味深かった.
これは、次回プロジェクトで是非導入してみたい.

開発期間に対して、実行するストーリーをどのように取捨選択すれば良いのか?

ストーリーに適切な優先順位があれば、取捨選択は行えそうだ.

しかし、スケジュールや予算の都合上ストーリーを捨てざるを得ないという状況で、そのストーリーを捨てることができるかが問題になると思う.

開発現場に居るスタッフ以外の、プロジェクト利害関係者を巻き込みながらアジャイル開発を進めることが重要なのは、この点にあるのだろう.

最終的には、関係者間の信頼関係をどのように構築していくかが、アジャイル開発のキモになっているのだと思う

まとめ?

アジャイル開発に興味を持ったばかりの人は、本書を手に取るのでは無く最初に『アジャイルサムライ』を読み小さなプロジェクトで(試験的に)導入を行った後に、この本を手に取った方が理解が良いかと思う.

本書を読み終わって、プロジェクトにアジャイル開発を導入・運用するためにはプロジェクト全体でアジャイルに対する理解を深め、プロジェクトの関係者がアジャイル開発をドライブするための当事者になることが重要になるという事を強く感じた.

プロジェクトに参加する人たちはそれぞれに、それぞれの思惑があるので、当事者意識を持ってもらうのはなかなか難しいとは思うが、本書を繰り返し参考にしながら実プロジェクトへの導入を進められればと思う.

アジャイルサムライ−達人開発者への道−

アジャイルサムライ−達人開発者への道−

アジャイルなゲーム開発 スクラムによる柔軟なプロジェクト管理

アジャイルなゲーム開発 スクラムによる柔軟なプロジェクト管理