"agilejedi"はアジャイルでの"スウォーミング"(チーム全員でひとつの作業を行う方法)の実践について質問をしている。
ひとつのストーリーをチーム全員で手がける方法がどうして最高のやり方なのか分かりません。XPのペアプログラミングがやりにくいのはわかります。でもチーム全体でプログラミングのはどうなんでしょう。ほんとうにうまくいくんでしょうか。
この質問に答えて、Dave Rooney氏は、氏が考えるスウォーミングの最も重要な点について強く主張している。
人間がマルチタスクが苦手なのは実証されています。これは、従来の作業が"全体の75%の作業が80%終わった"という状況になってしまうことでも明らかです。しかし、結果としては、作業の80%が100%完了している方が、作業の100%のうち、80%終わっているという状況より価値があります。スウォーミングの背後には、チームが集中して、仕事を完了させることで価値を生み出すようにしようとする考えがあります。100%完了させること、それは例えば、ひとつの仕事から手を離しても大丈夫になってから、次の仕事に移行することです。従来の考えでは、活動していることが分かるだけでしたが、スウォーミングでは進化していることが分かるのです。
Ron Jeffries氏も本質的には同じ答えをしているが、観点は面白い。
まだ完了していないストーリーがひとつ以上残った状態でイテレーションが終わりそうなときは、最も重要なストーリーにも、最も重要でないストーリーにも時間を使ってしまっています。そういうときは、完了できそうな最重要ストーリーにもう少し力を注げばなあと思います。
Adam Sroka氏はスウォーミングの品質について力説しているが、
いいえ、スウォーミングの目的は完了していないストーリーを扱うことではありません。チームがなるべく始めから実現すべきストーリーの近くで作業することで、品質と一貫性を向上させることがスウォーミングの目的です。スウォーミングで品質と一貫性を向上させられれば、ひとつの小さな時間枠の中でどのくらいの作業ができるのか分かるでしょう。この知識は自分がどれだけできるのかについての見積もりにも利用できますし、完了させられる以上のタスクを引き受けなくなります。
並列で作業するよりも、スウォーミングで作業したほうが品質と一貫性を向上させるのは、ひとつの作業に対してチーム(顧客も含む)のすべてのスキルや能力を使うことができ、成功する可能性を最大にできるからです。もちろん、これは恊働の方法をしっかり学んだ小さなチームの場合に限られますが、こう言うチームにとってはこの方法はとてもうまくいきます。
ひとつのチームがどのくらいの数のストーリーに群がるのがいいのだろう。Dave Rooney氏はスウォーミングの大まかな基準を述べている。
チームの構成によっては、ひとつ以上の項目を同時に対処できるかもしれません。チーム内の品質保証担当者の数よりも多いストーリーを同時に対処するべきでないというのが私のおおまかな基準です。この基準が効率的でないと感じるなら、スプリントの間のタスクボードを見てみるといいでしょう。スプリントの最後にはタスクが積み上がっているはずです。品質保証担当者が少ないと、スプリントが終わる前にすべてのテストを完了させようとして尻餅をついてしまいます。これにどのように対処するのか。チームの各メンバがタスクのひとつひとつが完了しているか検証するのがいいでしょう。これがチームが仕事に群がっている状態と言えるでしょう。