Scrumは、スプリント時に最小限の中断にとどめることで、チームが目標達成に向けて効果的に取り組むことができると話している。Scrumの専門家 は、チームの流れを乱す障害を取り除く責務を負っている。しかしながら現実の世界では、チームがデプロイ可能な機能を量産している場合、新機能のデプロイ のサポートと共に生産の問題についてもサポートする必要がある。こうした割り込みはチームを分裂させてしまうように思えるかもしれないが、システムユーザ や製品所有者にとっては重要である。既存のシステムが正常に動作しないと、製品所有者はシステムへ新たな機能を追加することには何の価値も見出さない。
Scrum Alliance(リンク) wikiは、割り込みの例(リンク)を以下のように定義している。
- 第一線のサポートテクノロジーでは処理できないテクノロジーサポート
- システムメンテナンスタスク
- ワイヤードシステムの振る舞いの調査を要求
- 容易には利用できず、デベロッパが取得する必要のあるシステムデータを要求
- カスタマーによるカスタマイズの要求
- デベロッパが配慮する必要のある生産の問題(たとえば、システムの停止または望ましくない成果)
上記のシナリオすべて、新機能の開発よりさらに重要になる可能性を秘めている。そこで、スプリントにおけるそうした割り込みをどのように扱うべきであるか?
Geoff Watts氏(リンク)は、こうした割り込みをScrumで処理する方法(リンク)について自身の考えを述べた。
2つのバックログアプローチ– 1つは開発機能のアプローチで、もう1つは生産サポート問題のアプローチである。製品所有者は、各バックログで完了できるように作業の割合を定義する。
このシナリオでは、チームは開発ストーリーにバーンダウンを必要とし、生産サポートにバーンアップを必要とする場合がある。
機能の要求としてのバグ – 予想されるビジネス価値およびサイズ付きの生産バックログに、割り込みは置かれる。Geoff氏は他の機能に関して生産サポートの割り込みを優先する上 で、このアプローチを好んでいる。Geoff氏はここで重要なことは、何が生産サポートで、何が違うのかということに関して議論になるのを避けるというこ とであると述べている。完全に線引きをするよりむしろこの議論を吸収することができるチームは、より効率的であり、かつ生産的である。
緊急事態 – 即座に解決されなければならない割り込み。Scrumの専門家および製品所有者は、緊急時、最も正しい判断をすることができる。
問題が本当に急を要しているならば、製品所有者は「緊急カード」を出すことで生じる犠牲 ‐計画していたタスクが完了に至らなかったり、潜在的にスプリントの目標を危険にさらすこと‐について認識している限り、そうする権限を所有する。
もう1つの重要な疑問は、「誰が割り込みを取り扱うのか?」である。生産サポートは退屈で、一般的にそれをすすんでしようという意識がチームメンバーには ない。それならサポートチームがするのが良い考えなのか?Geoff氏は、「サポートチームにそうさせると、それに関連した混乱と共に不必要な分裂を招 く」。選択肢としては、スプリントごとまたは、週ごとにサポートをおこなうことである。これによりチームにおける機能の枠を超えた振る舞いを増加させる一 助となり、システムの全体的なナリッジを増幅させるという二次的な利点もある。
Alistair Cockburn氏(リンク)によって提示されている割り込み処理の他の選択肢としては、「Sacrifice one person」(リンク)という名前による、プロジェクト管理パターンの形式でおこなうことである。Alistair氏によると、その問題に対するソリューション は、割り込み専門の担当として1名割り当てることである。そうはいうものの、この1人は自分が犠牲になったと感じてしまい、チームの残りのものたちは重要 な作業に取り組むことで前進することができる。
要約すると、割り込み処理の方法を決定する際には、製品バックログに置き、ビジネス価値に基づいて優先順位を付けることを検討することである。これにより つねにチームが適切に作業をおこなっていることが確認できる。しかしながら割り込みが緊急であり、コストが絡んでくる場合、コスト対緊急の決定を比較検討 することに基づく。
原文はこちらです：