初めてのアジャイル開発を終えてのふりかえり

こんなエントリを書いて早4ヶ月。
なんでアジャイルに取り組みたいか - kaji_3's blog

BtoBで対価を頂いてアジャイル開発として遂行した案件が先日終わったのでKPT形式でふりかえります。

前提

• 期間一ヶ月半
• Scrumを参考にしてプロジェクト運用
• イベント用WEBアプリケーション
• 案件の内容をぼかして書いているので、一部整合性の合わない記述があるかも知れませんがご了承ください。

Keep

高い顧客満足度

プロダクトオーナーから「自分たちの意志が反映できた物を作ることができた」とコメントを頂きました。フィードバックから実際のものができるまでのスプリントという考えについても好評でした。顧客の社風として良い物を最後まで模索するという考えがあるとのことで、仕様凍結後の変化は、仕様変更として好まれないウォーターフォールには不満があったとのことでした。

育つシステム

当初想定されていたシステムの姿とは大きく変わりました。当初よりビジネスでの価値（社内システムから将来売上、利益を生むチャンス）が増え、システムを提供する範囲（利用者の種類、組織）が拡大する事になりました。

企画、営業部門と協力して「アジャイル開発」を定義できた

所属部署での初めての取り組みであり、組織として「アジャイル開発って何？」からスタートしました。私としても勉強会、書籍からの知識だけであり経験はありません。そのため、Scrumをベースにしたプロセスを作り、顧客をどのように巻き込むか、どのようにプロジェクトを組織として管理するか話し合う事でアジャイル開発への偏見もなくなった気がします。顧客への見積、契約書についても作成したため、今後顧客から「アジャイル開発でやってよ！」と言われてもこれらをブラッシュアップして適用する事が出来ます。

Problem

フラジャイルになった

間違った「最大限の努力をする」の結果、本番直前は徹夜頻発など、チームのオーバーコミットが発生。当初ルールとして用意していたスプリントの期間、運用方法も守られない状態になってしまいました。顧客と弊社のパワーバランス、あるイベントで利用するという本番一発勝負という状況から「絶対」に失敗が許されないというプレッシャーとなり、オーバーコミットを発生させる事になりました。後半は混沌の極みでした。アジャイル開発なんて呼べるようなものではなくなってしまいました。プロジェクト期間も短く一ヶ月半。チームが慣れる間もなくプロジェクトは終了しました。

品質

一日一回リリースをするという状況になった時、テストの自動化ができていない部分についてデグレが発生しました。一日一回というリリースになった時、受入テストも自動化しておかなくては短い間隔でリリース出来ないと頭で理解していても、テストコードを仕事で書き慣れていないメンバでは、手動テストを実施する事が後半ではほとんどでした。

アーキテクチャの限界

最大ユーザ数が3桁ほど増えるバックログが発生。このバックログは今の作りでは負荷に対応できませんでした。立ち上げを早くするため、アーキテクチャを十分検討していなかった事、システムが変わりすぎた事から大きな技術負債となってしまいました。

Try

秩序を守る人「スクラムマスター」の役割を明確にする

顧客に説明するのではなく、確固たる意志をもってサイクルを守るスクラムマスターが必要です。チームと兼ねていましたがタフな顧客と推進するためには独立した役割でないとだめだと思いました。

自動テストスキル、テストコードの経験値を上げる

知っていると実施できるはまったく違います。自習だけではなく業務という限られた時間でどんどん書いて経験を増やしていきたいです。

技術負債を解消しやすいアーキテクチャの模索

自分に答えがあるわけではありませんが、模索していきたいと思っています。後から変更しにくいから構造、アーキテクチャと呼ばれるわけなのでスプリント０として十分に検討して次回に臨みたいです。

終わりに

学びを実践した結果、ズタボロになりました。顧客満足度は高かったものの、気持よくスプリントを回せることはせず、典型的なフラジャイルになりました。幸いな事にこのシステムを継続して開発する動きがあり、アジャイル開発で予定なのでその時に活かそうと思います。