今年会社の開発にはスクラム開発が本格的に導入されました。
弊社ではいくつかの開発チームがあり、それぞれ担当しているサービスが違うのですが、各チームでやっていて概ね良さそうな雰囲気を感じています。
ただ自分が参加しているチームでこの辺が問題だなーとか、改善したいなーとか、これってどうなんだろって思うようなところがいくつかあったので、そこをまとめてみたいと思います。
これはポエムのため問題は解決してなかったり、今度からこうしよう、みたいなフェーズのものが含まれます。
なので具体的な解決策を期待して読んでも、期待外れになってしまうかもしれません。
皆さんが今後のより良い開発体制を考えるきっかけ みたいになればいいなと思います。
少々特殊な事情があるため前提として
プロダクトオーナーは1人だが、複数サービスにまたがったスクラム開発をしている
というのがあります。
関連タスク問題
バックログを詳細な作業レベルのタスクまで落とし込み、それをメンバーがタスクをとっていくのですが、単純に優先度の高いバックログのタスクをとっていこうとすると 「CのタスクはAタスクとBタスクが完了しないとできない」 というようなものが多数生まれてしまいます。
ある程度でてきてしまうのはしょうがないとは言え、スクラム開発をちゃんと進めるのであれば優先度が高いバックログのタスクからとっていけるといいなと思っているので、うまい方法がないものかと考えています。
最低限、Aのタスクをやっている人が休んでしまったりとか、Aのタスクの進捗が悪いからBとCのタスクができない
みたいな状態だけは避けるように常に状況の共有をデイリースクラムや〆スクラムでおこなうようにしてます。
複数サービスにまたがったスクラム開発の場合に、優先順位付けが難しい
優先順位をつけるのはプロダクトオーナーの仕事であり、基本的にエンジニアである自分は関わらないところではありますが、結構ここがプロダクトオーナーの悩みどころになっています。
スクラム開発ではスプリント期間が始まる前に、バックログを用意してプロダクトオーナーがバックログの優先順位を設定する必要がありますね。
これが複数サービスにまたがると、優先順位付けの難易度が上がります。
もちろん優先順位を先に決めた上でスプリント計画会議にはのぞんでいるのですが、結局スプリント期間中に優先順位が変わることが結構ありますし、サービスの状況からしてどっちも最優先、みたいな状態になることもあります。
ここに関しては正直どうするのがいいのかは見えてないところがあります...
そもそもスクラム開発が複数サービスに向いていないところはあるかと思いますが。
リリース日が設定されている場合の優先順位付けが難しい
スプリント期間中の特定の日にリリースしたい、みたいなのが出てくると優先順位付けが難しい場面が出てきます。
「Aを最優先でやっていたが、Bはhoge日にリリースしなければならないため、明日から取り掛かる必要がある」
という状態よくありました。
リリース日がスプリント後半ものでも、どうせスプリント期間中に完成させなくてはいけないので、基本最優先でやるようにしましょう。
さっさと終わらせてあとはデプロイするだけ、みたいな状態になっているのがベスト。
スプリントが始まっても手をつけられないタスクが出てきてしまう
やりたいことがあるけど、やるための材料がまだ揃っていない状態がよく発生しています。
素材、テキスト、ワイヤー等々...
タスクに取り掛かってから、「あれどうなっていたっけ...？」みたいなことが頻発してしまうと、開発をすることに集中できず、開発効率がDOWNしてしまいます。
スクラム開発はタスクの優先度を決めて、その日にやるべきことをはっきりさせることで開発効率を上げることができる開発体制のはずですが、残念ながらまだそういう状態にはなっていないことも...
なので、まずは スプリント計画会議が始まるよりも前にバックログを作成してもらい、エンジニアがチェック して開発を進めるに必要なものがそろっているかどうか、というのをチェックするのを徹底してやっていこうと思っています。
まだ揃っていない状態でも今回のスプリントに入れたい場合は、いつになれば必要なアイテムがそろうのか、というのを確認が取れた上で開発に入るようにしようと思います。
差し込みが発生してしまう
あるあるですが差し込みが発生してしまい、本来集中すべきこと以外のタスクをやってしまっていることがあります。
ここはだいぶ改善されてきている感じがあるのですが、それでも差し込みの割合が比較的多いです。
ここに関しては差し込みが発生してしまうことは様々な要因があるため簡単に減らすことはできないのですが、以下の対応をすることで状況の改善を図っています。
差し込みはオープンの場でやり取り
こっそり依頼をされて、こっそり解決しているという状態はチームにとって良くないので、タスク依頼はオープンな場でやるようにしています。
いわゆる いい人 がいると、お願いされやすいのでサイレントタスクが発生しやすいです。
お願いしやすい、されやすい関係性というのはすごくいいことではあるのですが。
〆スクラムで報告
定時10分前に今日は定時に帰れるかどうかを判定する〆スクラムをやっているのですが、この時に差し込みタスクがあったかどうかを発表してます。
差し込みタスクを通常タスクと別の色の付箋でカンバンに貼る
カンバンで日々のタスクを管理するようにしています。
今は
青・・・通常タスク
オレンジ・・・差し込みタスク
として差し込みタスクがどのくらいの割合行なっているのかをわかるようにしています。
ベロシティをどうやって上げるか
何回かスクラム開発を続けていくと、おおよそ何ポイントまでこの開発チームでできるのか、というのが見えてきます。仮にスプリントで100ポイント消化できる開発チームとした場合、毎回100ポイントを目指して開発をすることになるのですが、そうすると今回は100ポイント、次回も100ポイント、その次も100ポイント...となって（もちろん多少のブレは発生すると思いますが）よりチーム力が伸びなくなってしまいます。
もちろんこれは極端な例なのですが...
とはいえより 開発スピードを上げてベロシティを上げていくことをチーム全体でもっと考えていく必要がある はず。
そこでまずはチームの目標ベロシティを出して、それを意識して開発するようにしようと思っています。
スクラムやってよかったこと
問題点をいくつか上げてきましたが、もちろんスクラム開発をやってよかったことはあります。最後にこちらを紹介します。
属人化が排除できる
これは本当にすごく大きないいポイントです。
同じサービス内でもここはhogeさん、あそこはfugaさん、みたいな暗黙的な担当割り振りみたいなことが発生してしまいがちです。
ですがスクラム開発では、優先順に並んだタスクを上から取っていくのが基本。
なので得意とか不得意とか、知ってる、知らないはあまり関係ありません。
とはいえそんなにうまくいく話ではないので、全員の知識レベルと統一にするためにいくつかやっていることがあります。
設計をみんなでやる
全員が仕様を理解できるようになるまで、設計をみんなでやります。
スクラム開発でバックログをタスク化するのに必要な作業ではあるのですが、途中で仕様変更などが発生した場合もすぐにみんな集まって設計会議をやって全員が同じ認識になるようにしています。
ペアプロ
ここはAさんがやったほうがはやい、みたいな場面のときはほっておくとAさんに同類のタスクが集中してしまいます。
そんなときは迷わずペアプロ。
Aさんと誰かがペアプロすることで、コードを理解して属人化を排除できます。
改善のサイクルが回せる
スプリント毎に開発チームで振り返りをしているので、その度に考えるきっかけが生まれ、より良い開発体制にすることができるようになってきました。
今までの話にあった〆スクラムや差込タスクの可視化もこの改善サイクルの中ででてきたものでした。
他にもいくつかあるので紹介します。
デイリークエスト
スクラム開発にのせるまでのもない細かいタスクをデイリークエストとしてピックアップしてやる
聞いた人がドキュメントに残す
ドキュメントをみて作業をした人が、よくわからない事があった場合、よくわからないと思った人がドキュメントに追記
コードレビュー時間をプルリクコメントに残す
LGTMを出すついでにコードレビューにかかった時間を記入します。
15m
みたいなノリ
会社のブログの方にも記事があるのでお暇な方は読んでみてください。
https://tech.basicinc.jp/articles/107