Backlogのスクラムでうまくいっている取り組み2選。

by kawakami

2017年12月28日

このチームではアジャイルソフトウェア開発手法の1つであるスクラムを取り入れており、そのなかでいくつかの改善をおこなってきました。今回はスクラムを用いたBacklogの開発改善のなかでも、うまくいっているものを2つ紹介します。

取り組みその１. ペアプログラミング

遡ることプロジェクト立ち上げ時、チームにはBacklogの実装や開発に使うプログラミング言語であるScalaに明るくないメンバーもいたため、どうにかしてそれぞれの知識を伝達する必要がありました。

そこでペアプログラミングを取り入れたところ、無事メンバーそれぞれが一人でも不安なくやっていけるようになり、当初の問題は解決。追加メンバーにも同様にすることで導入がスムーズにいきました。

backlog スクラムペアプログラミングの様子。

最初はコーディングだけで行われていたペアでの作業でしたが、ふりかえりなどで挙がった

といった、問題や考えから多くの作業がペアで行われるようになりました。現在でも設計からリリースまでのほとんどの作業をペアで行っています。

また、できるだけ毎回違うメンバーとペアプログラミングするようにしたところ、

などの効果が感じられました。(※あくまで個人の感想です。効果には個人差があります。)

細かい仕様などでこの人しか知らないといったことが少ないので、私はとても気に入っています。

メンバーが複数の拠点に別れているため、ペアプログラミングの際には遠隔で画面共有しながらということが多いです。

ここで大事なのが、見ている側が間違いなどを指摘するのがどれだけ簡単かということです。「ここ！」と指差すのと近い体験でないとなかなか辛く、「○○クラスの×行目の名前が…いえ、そこではなくて」みたいなことを続けていたら、今ペアプログラミングはいいぞなどとは言っていなかったかもしれません。

私たちのチームではいくつか画面共有できるものを試し、現在は主にZoomかSlack Callsを使用しています。

各ミーティングが時間内に終わらないなど、会議に関する問題が大きい時期にふりかえりの際の改善案として挙がり、早速そのふりかえりの終わりにふりかえりをすることになりました。

そこでふりかえりが時間通りに終わらない大きな理由として、プログラムの実装の細かい話に時間を取られていることが挙げられ、「仕事をする上で障害になるような問題にフォーカスする」ことをふりかえりのルールに追加しました。

次のスプリントのふりかえりでは、追加したルールに基づき実装上困ってるというようなことは別の場で話すこととし、それ以外の問題について話すことで時間通り終えられました。

ふりかえりのふりかえりはその後も続き、いくつかの改善をすることで今ではふりかえりが問題を解決できる場に戻ってきた気がします。

もちろん、ふりかえり以外の会議(プランニング、レビュー、リファインメント)にもミーティングの最後にふりかえりをすることがルールとなりました。ふりかえりで挙がった改善案は、他の会議にも取り入れられています。

このふりかえりでいろいろ取り組んだなかでも、会議のルールや次第を明記しておくというのが私は特に気に入っています。これのおかげで物忘れの激しい私が物忘れたままでいられるだけでなく、誰でも進行できるようになるため進行役が特定の人だけにならないで済むようになりました。

backlog スクラムスプリントレビューのルール

今回ご紹介したものは正直大したことではないのですが、私たちのチームにとってはとても有効な取り組みでした。

今後も「大した」ものかどうかは気にせず改善を続けて、チームとしてより多くの価値をユーザの皆様に届けられるよう、頑張っていきたいと思います。

（Photo By Mr Thinktank）

ヌーラボではプロセス改善も自分達でやりたい！というエンジニアを募集しています。

プロジェクト管理とは？目的や項目、管理手法について徹底解説！ | Backlogブログ

プロジェクト管理の基本や主な項目を紹介。CCPMやWBSなどのプロジェクト管理の代表的な手法やプロジェクト管理全体の流れを解説。これからプロ…