#概要
半年ほど前にアジャイルサムライー達人開発者への道を読んだタイミングで案件を引き継いだので、適用してみました。
本記事では、アジャイルを導入するためにやったことを中心に書こうと思います。
※タスク管理はバックログを使ってます
#対象
アジャイルでやってみようかなと思ってる方。
本で紹介されている以下の３つの真実に「ああ、コレあるわー」と思う方。
真実１：プロジェクトの開始時点に全ての要求を集めることはできない
真実２：集めたところで、要求はどれも必ずといっていいほど変わる
真実３：やるべきことはいつだって与えられた時間と資金よりも多い
#アジャイルサムライ？
それはソフトウェアを顧客に届ける猛々しきプロフェッショナルだ。
（本書より）
#アジャイル
よくある勘違いですが、ドキュメントを作らないのがアジャイルではないです！
ものすごく端的な説明ですが、**「三角測量」で見積もって、「イテレーション」を回し、計測した「ヴェロシティ」**を元に次のイテレーションで対応するタスクを決める」といった流れになります。
・三角測量：基準となるタスクを選び、他のタスクはそれを元に相対的に見積もる。
・イテレーション：開発サイクルのこと。 設計・試験・調査・改善という一連の工程。
・ヴェロシティ：イテレーションを回す速度。
#やったこと
1.バックログ
・ 親課題登録（マスターストーリー）
・ マイルストーン作成
2.開発チームへの共有
・三角測量のやり方、サイズ感のすり合わせ
3.お客さんへの説明
・簡易的なデモンストレーション
#やり始めてから改善したこと
正直に言うと最初は見積もりの精度が低く、１イテレーションの期限よりも先にタスクが完了していました。
その時は「調整用タスク」として仕様が確定しているタスクやデザイン修正をしていました。
#大切なこと
1.見積もりに幅をもたせること
予め「最短で〇〇人日、最長で〇〇人日」と伝えておくと後々調整しやすいです
2.プロジェクト全体でアジャイルのルールを守ること
イテレーションを回している際は、緊急対応以外ではタスクの追加を行わない等、ルールを徹底する必要があります
3.正直であれ
予定より先にタスクが完了したら、そのことをお客さんに伝えましょう
#感想
今のイテレーションで対応しているタスクと、マスターストーリーを分けて管理すると、基本的には対応中のタスクに関して仕様追加が発生しないので、リリーススケジュールに影響しなくなります。
（導入後、１０回以上リリースをしましたが、直前に稼働が上がったことは一度もないです）
アジャイルの導入にあたっては、開発手法の理解はもちろん、やったことに書いた２と３が結構大事かなと思います。
開発チームだけが関わることではないので当たり前ですね。