現場でできていない!?スクラム開発でやるべき3つのこと
ユーザーストーリーマッピング(ユーザーストーリー駆動)
スクラム開発を行うと日々の開発、日々のポイント消化に追われます。毎スプリント、バックログからノルマが決定しそれを終えることが目的となっていきがちです。 しかし、スクラム開発の目的はそこには当然ありません。そんなときに、ゴールを見失わず示してくれるツールがユーザーストーリーマッピングになります。
対象となるユーザがどのような行動を取るのかを定義し、本当にユーザに届けるべき機能・優先順位を見える化します。 開発は必ず間違った方向に進むときが来ます。何もなくうまくいく開発などありません。 それを察知し、チームで何を作っているのかを共有し軌道修正することができます。
これは継続が必要です。多くのチームでは、開発初期に数回行ってお蔵入り...となりがちです。ユーザーストーリーマッピングは、常に改善していくものです。それをやらないと、やはり日々の開発に囚われるだけになり良い製品を生み出すことは難しくなります。
www.slideshare.net
バックロググルーミング
スプリントを開始した当時を思い出して見ると... プロダクトオーナーもスクラムに注力し、皆やる気があり、バックログもきれいに管理されているかと思います。 しかし時は経ち、プロダクトオーナーもチームの掛け持ち、経営層との打ち合わせ、顧客折衝...etcに追われスクラムは手抜きになっていきます。 よって現実の開発では、バックログには雑草が生え、優先度、ゴールが見えづらくなっていきます。
これはほとんどのチームで起きます。 必ず出てくるならこれを何とかする開発手法はないのか！！（心の声） バックログ（庭）の雑草を掃除する作業が必要になります。 それがバックロググルーミングです。
バックログをチームで整理する時間にスプリントの5%を割くことが大切と言われています。 1sprint=2week=8h*10dayの場合は、4hをバックロググルーミングに割けばいいということになります。避けない時間ではありません。
ただし、これをやれる時間のあるチームは少ないです。これこそがスクラム開発が失敗する所以で、スクラムの成否を分ける分岐点だと思っています。
レトロスペクティブ(KPT)
Kepp、Problem、Tryを出し、Keepでともに喜びあいモチベーションを保つ。Ploblemでは現場の問題を全員、そしてプロダクトオーナーが把握する。そして、今やるべきことや将来のためにやっておいたほうがいいこと、開発者のモチベーションを保つためにTryを次のスプリントでいくつかこなす。 これがよくあるKPTかと思います。これはやって損はありません。ただし形骸化しやすので注意が必要です。 スプリントが進むと破綻することが多いと感じています。 KPTが出てこない。出てきても少ない、同じ人しか出さない。
KTが出ないというのは、チームが衰退、マンネリしているということ。ファシリテーションする立場のスクラムマスターが疲弊しているとき（チームをうまく回せていない）と思っています。 そんなときこそ開発者が舵をきるときです。開発者には、リーダー層が見えない様々なチームの小さな貢献者が見えます。残念ですが、多くのリーダー層はメンバーのことを知ろうとしません。 そういった貢献を全員で見落とさない努力をしなければなりません。小さな評価の積み重ねこそ、開発者のやり甲斐です。
過去のKPTは資産です。その中にやるべきことやチームの状態があり、見えてくる場合があるので、うまく使うことができるとチームは強くなります。
まとめ
3つとも完璧ではありません。 しかし、やってみないとわからないという精神でこういった手法をやってみるのが大切だと思っています。 失敗して当然、すべての現場に合うものはありません。
やるべき3つのことというので書きましたが、こういった手法をどんどん導入して失敗〜改善していく(+楽しさを知る)ことこそが スクラム開発でやるべきたった1つのこと なのかもしれないです。
