Tales of Verifier

テストエンジニアが自分の将来に不具合が起こらないことを確かめ合うRPG

アジャイルサムライ読書メモ 第5章 具現化させる

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

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

  • 作者: Jonathan Rasmusson,西村直人,角谷信太郎,近藤修平,角掛拓未
  • 出版社/メーカー: オーム社
  • 発売日: 2011/07/16
  • メディア: 単行本(ソフトカバー)
  • 購入: 42人 クリック: 1,991回
  • この商品を含むブログ (245件) を見る
第4章で「なぜやるのか」をはっきりさせて共有できた。
第5章では「どうやって」を明らかにしていく作業。

解決案を描く

開発者が集まって、作るもののアーキテクチャの図を描いてみる。

  • システムをどう構築しようとしているのか
  • どこにリスクがありそうか
  • リスクの解決方法に皆が同意しているか

を確認

夜も眠れなくなるような問題は何だろう?

リスクについて話し合う。
プロジェクト開始時点で話し合っておけば、課題が最初から明らかになるし、言いたいことを言いやすい。
リスクのうち、「取り組む価値のあるリスク」を見極める。
メンバーがチームから抜けてしまうリスクへの対策として、特定の1人しか知らない領域がないように潰しておくのは取り組む価値がある。経済が破綻して職を失うリスクに対策していても仕方がない(自分ではどうしようもないから)。

期間を見極める

プロジェクトにどのくらいの時間が必要なのか「ざっくり」考える
開発サイクルは6ヶ月を超えないほうが良い。プロジェクトの期間が長くなるにつれリスクは増大する。*1

何を諦めるのかをはっきりさせる

トレードオフ・スライダーを使って顧客に優先順位を決めてもらう
プロジェクトは

  • 時間
  • 予算
  • 品質
  • スコープ

の影響を受ける。ところが、一般に

  • スケジュールは圧縮さる
  • 予算は削減さる
  • バグのリストは長くなる
  • やるべきことは際限なく湧き出てくる

アジャイルサムライとしてやるべきは、時間・予算・品質を固定する。その上で、スコープを柔軟に扱う。

捉えどころのないものを忘れない

上記4つ以外にもプロジェクトに影響を及ぼす要素が存在し、それを「捉えどころのないもの」と呼んでいる。
捉えどころのないもの例:

  • コールセンターへの問い合わせ時間を20%削減する
  • 顧客が自分で問題を解決できる

何がどれだけ必要なのか

期間や費用がどれだけ掛かりそうなのかをスポンサーに説明する。

チームメンバー

チームのメンバーと人数、強みや期待することを説明
プロジェクトには「顧客」が大事だが、顧客がプロジェクトに積極的に参加する文化が根付いていないことも多い。だからこの段階で、プロジェクトに対して時間を割いて、必要な決定を下すだけの覚悟と権限があるかどうかを確認する。

ジョジョの奇妙な冒険 覚悟はいいか?マグネットホルダー

ジョジョの奇妙な冒険 覚悟はいいか?マグネットホルダー

最終判断を下すのは誰か?

いろんな方向からそれぞれの勝手な指示が来るようだとまずい。
「バスの運転手」が誰なのかをはっきり。

コストがどれぐらいかを見積もる

メンバーの人数にプロジェクト期間中の時間あたりのコストを掛ける

最後のスライドを仕上げる

いつ終わるのか、いくらかかるのかは「いい線いってる当てずっぽう」程度にしか信頼できない。この段階ではまだわからないことが多いから。

*1:機能追加が止まらなかったり