スクラム開発に参加して
こんにちは、Burroughsです。
今回は、新米の自分が現在携わっているプロジェクトについて述べていこうと思います。
スクラム開発については以下の記事を参考にして頂ければと思います。
プロジェクト概要
今回参加したプロジェクトは、スクラム開発を試験的に導入した、以下のようなプロジェクトです。
- プロジェクトの目的：
特定業種向けのサービスサイト作成。
- チーム構成：
・プロダクトオーナー 1名
・スクラムマスター 1名
・開発メンバー 1名
自分は開発メンバーとしてプロジェクトに参加。
- プロジェクトの進め方
・1週間～2週間を1スプリントとし、約2ヶ月がプロジェクト全体の期間。
・スプリントの初日にスプリントプランニング、最終日にスプリントレビューと振り返りを行う。進行は開発メンバーが行う。
感想
スクラム開発は「理解は容易だが、習得は困難」と言われています。今回、プロジェクトに試験的に導入することになったのですが、自分を含めて参加者全員がスクラム開発の経験がありませんでした。そのため、形だけ真似ただけのものになってしまい、以前挙げたメリットを享受できませんでした。（そもそもプロジェクトと呼べる代物になっていない気もする…）
発生した問題点
以下にプロジェクトで生じた主な問題点と改善策（実現できるとは言ってない）を挙げたいと思います。
1.バックログが適切な順番で優先順位づけされていない
→ 影響：
重要でない工程に時間をかけてしまったり、作り直しが必要になったりなど、余計な工数が発生した。
⇒ 改善策：
優先順位付けされていない項目には手をつけない、優先順位の理由をメンバーと必ず共有するなどのスクラムのルールを設ける。
2.デイリースクラムを毎日欠かさずに行うということができなかった
→ 影響：
メンバーの情報共有が不十分になり、プロダクトの問題点が見つけ辛くなってしまった
⇒ 改善策：
自分以外のメンバーが他のプロジェクトに関わっていたりして忙しいのが原因なのでどうしようもない。強いて言えば、企画段階でプロジェクトに集中して取り組める人を集めるべき。
3.スプリント進行中での作業の差し込み
→ 影響：
スプリント内の予定が不明瞭になり、プロジェクト全体の進捗の把握が難しくなってしまった
⇒ 改善策：
スプリントの期間を短くし、差し込みのリスクを下げる。メンバー全員にバックログの共有と見直しを義務付ける。
まとめ
スクラム開発を上手く進めていくには、
・メンバー全員が各プロセスの意義を理解する
・スプリント毎に振り返り、問題点を見つけたらその都度改善を行う
以上、2点が非常に重要です。（自分も実践できてませんが…）
残りの開発期間は少しでも改善できるように取り組みたいと思いますが、新米の自分に発言権はほとんどないので難しいでしょう。
今回の記事は以上になります。
ありがとうございました。
