真にアジャイルな開発チームになるために 〜プラクティスを実践する〜 by プログラミングをするパンダ

■ 発表内容
チーム開発に効果的なアジャイルのプラクティスとその実践例を紹介します。

■ ストーリー
「ゴールデンウィーク明けまでにこの機能を作ってほしい」と社内向けの新規機能の開発を任されたとあるチーム。このチームは4月頭に組成されたばかりであり、開発する機能はビジネスの成長ドライバーになることを期待されている。期間は1ヶ月しかない。ただし、その1ヶ月に根拠はない。

チームの構成はプロダクトオーナー1名、エンジニアマネージャー1名、エンジニア6名。不確実性に対処しつつ円滑にリリースを行うべく、アジャイルのプラクティスを実践して開発に立ち向かっている（6月上旬にリリース予定日が立てられて、6月下旬にその日通りにリリースできた）。確かに当初の予定よりは遅れている。

しかし、チームのエンジニアの誰一人として疲弊しきっていない。むしろ、組織の中で偉いAさんは「遅れていても、着実に進んでいることがわかる上に、遅れの理由が納得できるので安心感がある」と言い、スクラムマスターBさんは「このチームではスクラムがうまく回っている。もしそうでなければ、リリースはさらに1ヶ月以上遅れていただろう」と述べている。

なぜそれが可能なのか。何がうまくいっているのか。チームで実践したアジャイルのプラクティスとその実践例を紹介します。

■ 発表内で登場するキーワード（予定）

• DevOps → セキュリティのシフトレフト、トランクベース開発、同期レビュー、継続的なデリバリ
• XP → 全員同席、ペア・モブプログラミング、TDD、インクリメンタルな設計、コードの共有、本物の顧客参加
• スクラム → プロダクトバックログ、プロダクトレビュー
• 実装 → クリーンアーキテクチャ、戦術的DDD
• その他 → 荒ぶる四天王（時間・スコープ・予算・品質）、リファクタリング、イテレーション、フィードバックサイクル