スクラムを初めて3ヶ月たったので振り返る
スクラムについて
スクラム（英: Scrum）は、ソフトウェア開発における反復的で漸進的なアジャイルソフトウェア開発手法の1つである。この方法論は「柔軟かつ全人的なプロダクト開発ストラテジーであり、共通のゴールに到達するため、開発チームが一体となって働くこと
一定の周期で計画会議→開発（スプリント）、スプリントレビュー、クロージング（振り返り、リリース）を繰り返すことが大事
スクラムを始めたきっかけ
前まで
- マネージャーの管理コストが高い
- 開発メンバーが今なにやってるかを把握するのが大変
- リリースサイクルが決まっていない為開発、営業、運用の連携が困難
- 開発したものが放置されやすい
- 突発的な開発対応に追われる
- 開発者は言われたものだけをひたすら開発するというサイクルになりがち
スクラム体制後
- マネージャーの管理コストが下がる
- 開発チームがなにやってるかを把握できる
- リリースサイクルが決まる為営業、運用、開発の連携がしやすい
- 品質が上がる
- 振り返りによりチーム力が上がる
- 開発が考えるシナリオを推進することができる
- 開発チーム個々が自発的に行動できる
デメリット
- 運用などの担当者が必要で担当者がかたよる
スクラム体制について
- 1スプリント2週間、クロージング1週間とする
- プロダクトオーナー
- スクラムマスター（自分）
- 開発チーム4人
- ミドルエンジニア
- 若手ベトナムエンジニア
- 新卒ベトナムエンジニア
- 新卒エンジニア
スプリント振り返り
1月中旬から始めて3スプリントを実施した。
スプリント1（1/16〜1/27）
機能概要
- データ解析+グラフ化
Good/Keep
- 設計レビューにより実装前の軌道修正ができる
- 開発チーム+スクラムマスターのレビューにより各自の実装の認識をあわせる
- プロダクトオーナーレビューにより更に違った目線からの指摘があり最終的な実装の認識をあわせる
- 設計段階で認識を合わせることにより品質があがる為トータルコストがよい
- 画面を伴う機能は特に設計レビューによる効果が大きい
- 設計レビューでアウトプットの認識があうのでビジネスへのアプローチがしやすくなる
- テスト環境すら整ってない新卒エンジニアがモックテストまでできるようになった
- 局所的なハンズオンやペアプロは効果が高い
- スクラムは各自のスキルアップに効果的
Problem
- プロダクトオーナーとスクラムマスター以外がスクラムの取り組みにおいて受動的
- ドキュメント・テストケースの書き方の各自の認識が違う
- Trelloの更新がうまくできなかった
- JavaScript処理が複雑
Try
- GitFlowに切り替えるにあたりバージョニングを検討した
- セマンティックバージョニングにしたかったがメンバー全員に周知し徹底することが難しいと判断し文字列でタグ付けすることとした
- チームメンバ全員がモックを使ったPHPUnitが書けるようになったので全員UTを書く開発体制にした
- ドキュメントの書き方の認識をあわせた
- JavaScriptの構成やフレームワーク変更を検討する
スプリント2（2/6〜2/17）
機能概要
- 画面レイアウト変更
- レポート系
Good/Keep
- クロスブラウザ・端末テストなどマンパワーを要するテストをみんなで分担してできる為テストが楽で早く終えられる
- チームメンバー全員がモックテストがかけて開発コードのほとんど（不要な部分は除く）のカバレッジをカバーできている
- 設計レビューの恩恵
- 要件定義時に認識があっていたと思っても設計すると認識がずれていたりするがレビューの中で最適な解を見つけることができる
- 実装前のレビューで懸念点をつぶしてながら設計できるのが気持ちいい
- 実装前にの実装イメージが具体的に湧く為テストが書きやすい
- 設計後実装の分担をするとテストを先に書けるケースが出てくる
- 開発チームが各自自発的に行動するようになった
Problem
- ドキュメント作成に時間がかかる
- コーディングスタイルの指摘が多い
- 最初に作成したスプリントバックログの作業量をオーバーした
- タスクの粒が大きいと初日のスプリントバックログ作成の時間だけでは正確な見積もりができないことがわかった
Try
- 計画会議とプロダクトバックログ作成を1日で実施した
- 翌日以降の個人の動きが明確になり個々人が個別に自主的に動ける
- デイリースクラムにスクラムマスターが参加しないようにした
- コードフォーマットチェック(phpcs-fixer)をgitのpre-commitに導入した
- WIPを導入した
- 次回以降はもっとIF・クラス設計に重点を置いて開発する方針にした
スプリント3（2/27〜3/10）
機能概要
- 機能の外部埋込プラグイン
Good/Keep
- 失敗覚悟でギリギリのベロシティのタスクを設定したところ色々新しい課題がみえた
- 開発メンバ各自の実機テスト環境を改善した
- 既存バグの修正ができた
課題
- タスクの難易度があがるとコミュニケーションコストがかなり高くなる
- 受け入れ条件の範囲を超えた作業をした為余計に時間を費やした
- 2週間という期間にしばられて品質を落とす形になった
- コミュニケーションコストを見積もりに入れてなかった
- 結果的にチーム力と品質向上の取り組みをせずプロダクトができてしまった
- スプリントレビューの対応でデグレを引き起こした
- クロージング期間をテストのバッファ期間として使ってしまった
取り組み
- スプリント予定外の作業はしない
- まだまだチームが成熟していないのでじっくりやるべきことをやる
- スプリントレビューの指摘は（話し合いの元）基本的にはクロージングでは対応しない
- 実装の前に設計にもっと時間をかけることにした
- 必要に応じてペアプロをする
- IDEの使える機能は使う
- ステークホルダーとの確認を怠らない
まとめ
今は下の画でいうところの、形成期と混乱期を行ったり来たりしている状態で、このプロセスをしっかりふんで統一期・機能期に進んでいく計画。スクラムをはじめて以前までのデメリットが解消し、開発チームが積極的に要件定義・設計・開発をする体制になってきた。次は開発チーム全員でフロントエンドの強化をする予定。