スクラム道バーストに参加した感想＆doneの定義の話

2011/06/24にスクラム道バーストに参加してきました。申し込みを忘れていたのですが、当日行けそうに無かった方のご好意で代わりに参加してきました。@ledsunさんありがとう。

内容は過去のスクラム道の再演とトピックに対する議論の場でした。詳しい内容は他の方の素晴らしいレポートがあるのでそちらをご参照くださいw

選手ってなに？ってことが良くわからないまま選手として参加してしまいましたが、壇上に上ってもそんなに緊張しないものですね。変なこと言っても殴られたりしないので、このような形式があったらどんどん選手として名乗りをあげるといいと思います。

---

スクラム道バーストで「doneの定義を拡大/縮小することの是非」がトピックに上がりました。思い返すとストーリーのdoneの定義なのかタスクのdoneの定義なのかがあやふやだったので、それぞれ検討しました。

結論としては、拡大するにしろ縮小するにしろ、スプリントバックログをいじるのでプロダクトオーナーの判断が必要。拡大は（こなせるのであれば）問題になることはあまりないが、縮小はリリース時期や提供価値に影響が大きいので要注意。となりました。

ストーリーの場合

ストーリーのdoneの定義を変更するのはプロダクトオーナーの承認が必要。ストーリーをスプリントバッグログにいれる判断はストーリーが提供する内容に対する判断なので、doneの定義が変わった場合はストーリーが提供する内容が変わるはずだから。

doneの定義を拡大したい場合

スプリント内で追加するタスクが達成可能かの見積もりをした上でシステムに価値が向上するかをプロダクトオーナーに確認する（ストーリーのdoneの定義が拡大するということはタスクが追加されるはず）。プロダクトオーナーはもしかすると他のストーリーをスプリントに追加したいかもしれない。

doneの定義を縮小したい場合

縮小するということはストーリーのタスクをいくつか落とすことを意味する（ストーリーのdoneの定義に影響しないならタスクはチームの判断で落としてよいが、その場合は「ストーリー」のdoneの定義の縮小にはあたらない）。タスクを落とした結果、ストーリーの提供する価値がどのように変化するのかをプロダクトオーナーに提示して判断を仰ぐ。

• 他のストーリーのスプリントバックログから落とすことで当該ストーリーをdoneさせる
• 当該ストーリーを落として他のストーリーに入れ替える
• ストーリーを分割して、達成できないストーリーをプロダクトバックログにいれる
• あるタスクがブロック要素となっている場合はスクラムマスターにブロック要素の除去を要請する

などの判断などがありそう。

タスクの場合

タスクのdoneの定義の縮小がストーリーのdoneに影響を与える場合の対処は、ストーリーのdoneの定義の縮小と同じ。ストーリーのdoneに影響を与えない場合は縮小して問題ない。この場合はタスクを分割して不要なタスクを落とすことと同義。いまは必要ないという場合は他のストーリーのタスクとする場合もある。

doneの定義を拡大したい場合

タスクの所属するストーリーがスプリント内でこなせるなら、特に問題なし。しかし、そもそものタスクのdoneの定義がdoneしたとするには弱かったのではないか？という気もする。追加でこれもやっておきたい、はタスクの追加になるのではないか。

doneの定義を縮小したい場合

縮小したとして、それはそのタスクがdoneしたと言えるのかが問題。もし言えるのであればタスクが余分なものを含んでいたということ。言えないのであれば、それは縮小したからといってdoneしたということに意味が無い。ストーリーのdoneの定義に影響を与えるので、対処はストーリーのdoneの定義の縮小と同じ。タスクをdoneできない原因の対処はもちろん必要。

Scrum Boot Camp横浜に参加した感想

6/18(土)に横浜で開催されたScrum Boot Campに参加してきました。Scrumの説明と演習でScrumへのとっかかりを体験できる勉強会です。休憩時間や懇親会でいろいろ感想を話したり、疑問点に対する意見を聞いたりできて有意義でした。以下、思ったことや感想や学んだことを雑多に書きます（あたかも最初から知っていたかのような口ぶりで書いている部分もあります）。

演習について

演習はテーブルごとに分かれてチームで行うのですが、自分のいたチームはほぼ違和感無く演習することができました。他のチームがどうだったのかに興味があったので、懇親会で別のチームの方々に感想を聞いて回ったところ、まったくうまくいかなかったチームは無いようでした。いろいろなバックグラウンドを持つ人々が初対面で演習可能というのは「Scrumの取り組みの一つ一つは誰でも可能なこと」と感じました。

勉強会に参加するということは、Scrumに興味がある、勉強しようとする意思がある、人の話を聞く気がある人が集まっている状態なので、そもそも成立する可能性が高いのは事実です。おそらく、参加者は自分の所属組織に戻って、勉強会で得たものを取り入れようとした際に相当のギャップを感じてしょんぼりするかもしれません。

感じたこと

自分を変えるのと他人を変えるのを比べると自分を変えることは自分自身の努力で可能ですが、他人を変えるのは自分の手の届かない部分が多いので、チームに導入するのは相当に難しいはずです。しかし、Scrum（じゃなくて他の開発手法でも）かどうかは、true/falseの二値で表されるのではなく、度数で表現するものなので、導入して成果が上がっている状態を想像して、その状態と現在の間を埋めていけば、ちょっとScrumからだいぶScrumに、そしてほとんどScrum、完全にScrumという風になるはず。

「うちの組織のメンバーはScrumを実施できるレベルにない」という質問がありました。確かに設計や実装、試験などのスキルの他にも「自動化されたテスト」「継続的インテグレーション」「ソフトウェア構成管理」「バグトラッキングシステム」「ペアプログラミング」「リファクタリング」「様々な活動の集計の自動化」などの様々な開発プラクティスを身につけた人々だけでチームが構成されていないとScrumできないと考えがちですが、Scrumを導入しはじめると必然的にスキルの向上や習得が必要になるはずです。これは「できるからやる」のではなく「できるようになるためにやる」そして「やるからできるようになる」と考えると良いのではないかと感じました。

Scrumにはいろんなツールがあります。プランニングポーカーとか朝会とかふりかえりとかバーンダウンチャートとか。全てのツールは可能な限り素早く最大限の価値を提供するための道具なので「何をどうする？そしてどうなった？」を明確にして「それは目的の達成に向かっているか？」を意識して取り組みたいと思います。

話は変わりますが、エリヤフ・ゴールドラット博士が亡くなりました。この人は「制約条件の理論」を生み出した人です。「制約条件の理論」というのは「システム（目的（ゴール）」を継続的に最大化するためのメソッド（といっていいのかな？管理哲学？）です。この制約条件の理論を達成するために「TOC思考プロセス」といういろいろなツールがあります。Scrumの導入のために役に立ちそうなツールが満載なので、まずは『ザ・ゴール ― 企業の究極の目的とは何か』という小説仕立ての書籍でどのようなものなのか一読することをおすすめします。