Webシステムの受託開発のディレクター（PjM）として、
アジャイル開発案件に関し、現場で実際にどういう動きをしているか整理、考察してみました。
利用ツール
- backlog
- タスク管理用
- Googleドキュメント
- 進捗報告用の議事録
１週間の流れ（プロジェクト毎）
（例）スプリントが1週間単位の場合
| 曜日 | ディレクターの行動 |
|---|---|
| 日 |
 しっかりと休養しましょう |
| 月 |
 進捗報告MTG（クライアント含む） 今週のタスクと優先度をエンジニアに共有 次週の報告議事録を作成（今週分をコピー） |
| 火 |
 エンジニアに開発を集中してもらう |
| 水 |
エンジニアに開発を集中してもらう |
| 木 |
 エンジニアの進捗状況を確認遅れが出ているタスクがある場合、どこまで進行できるか、いつまでに対応が可能かを確認 |
| 金 |
次週の報告議事録を最終更新 |
| 土 |
しっかりと休養しましょう |
進捗報告MTG（Delivery）
- 各タスク（backlogのチケット毎）の進捗状況を報告
- 先週に進行予定としていたタスクについて
- 遅れが発生しているタスクについては、どこまで進行したか、次週までに対応が可能かを連絡
- 新たに発生した要望や課題をヒアリング、仕様検討、タスク化
- 新規タスクと進行予定タスクを合わせて、優先度を確認し、次週までに実施するタスクを確認
QAについて（Quality）
- テスト環境へアップ後に随時実施
考察（改善点など）
※ スプリントが1週間の場合
- ビルドトラップにハマってしまう
- １週間だと期間が短く、より良いプロダクトを作るということよりも、いかにタスク進行できたかにフォーカスしがちになってしまう
- QAの実施計画が立てられていない
- 現状だと、テスト環境へアップ後にQAを実施している。
- プロジェクト専任のエンジニアやテスターがいるわけではなく、１週間の中でQA実施までは回せないため。
- プロジェクト自体の予算が多く、専任のリソースを確保できる場合には、QA計画まで立てていけることが理想
できるだけ、スプリントは2~4週間で回したほうがより良いプロジェクトになる場合が多いと思います。
スプリントが短くなっている理由は、早く機能をリリースしたい、細かく進捗を確認したい、という意図があると思うのですが、これは開発する機能や状況によって変わってくるところなので、基本は長めに期間を取っておき、必要に応じて細かく状況報告の時間を確保していくかたちが、現時点のプロジェクトでは良さそうではないかと考えています。