スクラムからみるXPとカンバン
モチベーション
日常的にスクラムをベースに開発を進めているが、スクラムガイドでは技術的な手法や開発プロセスの改善方法について具体的な実践方法は明記されていないため、日々起きる課題について引き出しが足らないと感じていた。 より実践方法の引き出しを増やすために、以下のXP本とカンバン本を読んでみることにした。
エクストリームプログラミング 第2版
https://www.amazon.co.jp/dp/B012UWOLOQ
リーン開発の現場 カンバンによる大規模プロジェクトの運営
https://www.amazon.co.jp/dp/427406932X
結果的に言えば、どちらの本も参考にできる事例が多くあり、読んで良かったと思う。
どちらの本もスループットとプログラムの欠陥にの対処方法ついて触れられていて、うまく活用することで、より良い開発を実践できる可能性を感じた。
試しに日常的に実践しているスクラムをベースにそれぞれの事例を捉え直してみたので、残しておこうと思う。
WIPを制限してボトルネックに向き合う
カンバン本では、開発フロー全体に着目して、ボトルネックを特定しながら、チームのマルチタスク制御をして開発を進める手法が中心に書かれている。
例えば「11章：WIPをマネジメントする 」では、WIP の制限の目的は、 過剰なマルチタスクを避けるためと、 後続のプロセスに 負荷をかけすぎないためだ。と書かれており、もし、 テスターたちが大量のやるべき作業を抱えて いたなら、 開発者が新しい機能を開発し続けて、 テスターの仕事をさらに増やす のは避けたいはずだ。 代わりに、 機能開発チームはテストチームの支援に集中すると続く。
書籍は大規模開発の事例がベースになっているため、チーム間の支援の事例になっているが、これはスモールチームでも転用できる考え方のはずだ。例えば、3人作業者がいて、それぞれABCのタスクを進めていたとする。
誰か一人が作業を完了し、コードレビューに出したあと、新たにタスクDに着手すると仕掛かり中の作業は4つになる。
この開発の流れに対して、何も制約をつかずにいた場合に極論すると、以下のように合計6つ(あるいはそれ以上)の仕掛かり作業をチームが持つことになる。
仕掛かり中の作業に上限がある場合は、これを避けられる。 例えば、コーディングとレビューの数に3つまでの上限を設けることで、他の人の作業の支援に回ったりレビューを終わらせることに力をかけることが可能になるからだ。
これをスクラムガイドから捉えなおして、以下のような整理をした。
共同作業を通じて、スループットと欠陥に向き合う
XPの価値・原則・プラクティスを中心にソフトウェア開発の進め方が紹介されている。特に具体的な技術的なプラクティスが書かれていることが、特徴的だ。
先の例に主要プラクティスの一つであるペアプログラミングを当てはめた場合、そもそもの仕掛かり中の数をペアプログラミングを実施して減らすこともできるし、仕掛かり上限を越えるタイミングでペアプログラミングやペアレビューを実施し、他のメンバーの支援をすることもアプローチを取りやすくなるように思う。
| 最初からペアプロ | ペアレビュー |
|---|---|
 |
 |
いずれにせよ、チームの仕掛かり中の作業は2つか3つになり、チームのキャパシティを超えて増えていくことには対処ができそうだ。
そしてペアプログラミングは別の効用もある。「第8章：始めてみよう」には以前、あるチームをコーチしたときに、開発後の欠陥を確認してもらったことがある。その結果、すべての欠陥が、単独でプログラミングしたときに生み出されたものであることが判明した。という記述がある。
これは共同作業をすることで、ケアレスミスを減らせるということや、より良い設計についてその場で議論することができることが効果を生んでいるように思う。
これをスクラムガイドから捉えなおして、以下のような整理をした。
- 品質基準を満たすインクリメントを素早く作るために
- 共同作業を通じてタスクに集中しながら、システムの改良について意見を出し合う。
最後に
自分の思考整理のために、スクラムをもとにそれぞれの本から学んだことを整理してみた。
XP本にもカンバン本にも、今回紹介した以外にも書ききれないほどの、実践事例が載っているので是非読んでみてほしい。
