Tbpgr Blog

元エンジニア 人事 tbpgr(てぃーびー) のブログ

アジャイル開発導入

アジャイル開発手法の導入のため、基本的な要素の説明をします。

アジャイルなチームは各メンバーに明確な役割はなく、
自ら動いて状況に応じて開発を行うことが必要となる。
従来の現場で時おり見かける「ここは俺の担当じゃないから」
すべての仕様とドキュメントが揃ってないと開発できない
などという人は早急にお払い箱に。

開発を開始する前に10のTough Questionに答える。
そのQuestionがインセプションデッキ。

我々はなぜここに居るか
エレベーターピッチを作る
パッケージデザインを作る
やらないことリストを作る
「ご近所さん」を探せ
解決策を描く
夜も眠れなく問題を洗い出す
期間を見極める
何を諦めるか
必要なリソースを洗い出す

これらの質問に答えることで、プロジェクト開始時点での
問題点リスクを見つけたり、全体像の把握が可能となる。

開発には様々な要素があるが、それぞれすべての優先度を最大にはできないため
相互にトレードオフの関係にある。

その中でも特に重要なのが

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

であり、スコープ以外は変更不可能とし
スコープを変更することで調整を行う。
つまり、何を諦めるか決めることである。

よくある失敗プロジェクトでは要件=スコープが追加になったが
予算も増えず、開発期間も延びず、テストを省略して品質が犠牲
となるのがよくある例。そしてリリース時に障害を起こすか
後々メンテナンスが困難になるスパゲッティ製麺システムになるか・・・

要求-設計-開発-テスト-リリースの1サイクルのこと。
これを1〜4週間程度で繰り返す。

  • マスターストーリー

従来の開発手法で言うところの要求定義書。
このシステムで必要となる機能が短い文章を箇条書きでまとめる。
箇条書きの一つ一つをユーザーストーリーといい、
システム内で完結した一つの機能を記述する。
ユーザーストーリーは実装難度によってポイント分けしておくことで
後々の作業見積もりに役立てることができる。

アジャイルサムライの紹介では、小中大で1/3/5ptで分けている。

  • ユーザーストーリーの原則

下記の『INVEST』に従って記載する。

    • Independent = 独立している
    • Negotiable = 交渉の余地がある
    • Valuable = 価値がある
    • Estimatable = 見積もれる
    • Small = 小さい
    • Testable = テストできる
  • ベロシティ

1イテレーションに開発チームが行うことが出来る作業ptの合計のこと。
これを計測しておくことで、2イテレーション移行で作業の見積もりがしやすくなる。

  • タスクリスト

ユーザーストーリーを実際の作業単位に細分化したもの。
ユーザーストーリーはあくまでお客様にとって意味を持つ単位。

  • 参考文献

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

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