こんにちは、最近自作キーボードに夢中な @kasumi8pon です。
最近 Rails アプリケーションを 2つ、 Rails 4 系 からバージョン 6.0 にアップデートするプロジェクトをやっていました。 1月に入社してから9ヶ月が経ち、初めてわたしがメインとなって進めたプロジェクトでした。 いろんな方のご協力のおかげで無事に Rails 6.0 のアップデートがリリースできました 🎉
話はかわりますが、現在アジャイル事業部では週に一度のペースで アジャイルサムライ の読書会が開催されていて、わたしも参加しています。 読書会では現実のプロジェクトで起こっている実際の話を聞けて、とても面白い会になっています。
今回わたしが担当したプロジェクトではアップデート作業のみという特殊な状況であったため、ユーザーストーリーを出して、見積もりをして、イテレーションの計画を立てて…といういわゆるアジャイル開発をしようとは思ってはいませんでした。 それでも、ふりかえってみると アジャイルサムライ で学んだ視点から見てよかったと思う点があったので、それらをあげてみようと思います。
スコープを調整することができた
アジャイルサムライの第5章に、「何を諦めるかはっきりさせる」という節があります。 プロジェクトにおよぶ様々なフォース(影響)のうち、すべてを最優先にしようとすると、プロジェクトはうまく行かなくなってしまうというお話です。 ここでは、特にプロジェクトと固く結びついたフォースとして、時間、予算、品質、スコープが紹介されています。
このプロジェクトでは、時間、予算、品質は固定されており、スコープを調整しました。 基本的にはゴールは Rails のバージョンを上げて、テストを通し、チェックリスト通りアプリケーションが動作することでした。 しかし、アップデートをする際には、バージョンを上げるために影響範囲が大きい gem や、Deprecated であり、本来は他の機能に置き換えるべき gem が存在しました。 すべてに対応することは不可能であったため、どこまで対応するか相談した結果、今回のプロジェクトではデータ移行等の作業が不要な範囲でできる限り、 gem のバージョンを上げることにしました。 最終的には、Rails 自体のバージョンアップ作業は完了し、バージョンが古いままだった多くの gem も最新までアップデートすることができました。
関係者との意思疎通がうまくできた
10章のアジャイルな意思疎通の作戦では、イテレーションで開催すべき4つのミーティングと、1日の始まりに行うデイリースタンドアップが紹介されています。
このプロジェクトでは、「前週でやったこと」、「次週でやること」、「課題」の3点を週次で共有していました。 これはイテレーション計画ミーティングやミニふりかえりに少し似ているかもしれません。
一方、デイリースタンドアップは行いませんでした。なぜなら、問題があったときにすぐ相談できる環境にあったからです。マスターセンセイも、『いつでも気軽にチームメンバー同士やお客さんとの間で相談できるなら、別に毎朝スタンドアップミーティングをやらずともうまくいくかもしれん』と言っていましたね😉
おわりに
こうしてみると、"アジャイル開発"をしよう！と思っていなくても、アジャイル開発のよいところを取り入れることでうまくいくことがあるかもしれないです。 "アジャイル開発"自体を目的にするのではなく、チームにあった方法を模索しながら、これからもやっていきたいと思います。
