ブログ

10月28日に日本オラクルさんで行われたスクラム道EXPOに登壇しましたので資料をさらしておきます。 登壇時間が20分ということで非常に駆け足でDoneの定義について話をしました。 大事だと思うことは最後にまとめておきましたが、これについて補足しておきます。

プロジェクト開始時点で決める

完成の定義の内容によってプロジェクトの所要期間や見積りは影響を受けます。たとえばプロダクトバックログアイテムの完成の定義でテスト対象ブラウザを定義することを考えてください。Mac上のChromeだけでテストする場合と、IE、Firefox、Chrome、Safari、OperaでテストしてさらにWindows7とWindows8とMacとUbuntuでテストする場合とでは、タスクの見積り時間も異なります。 必然的にスプリントで完了するプロダクトバックログアイテムの量も異なります。 この合意がないままに進めると、後で大変な目に会うことになるでしょう。

スプリントで全部やろうとしない(最初はムリ)

チームの技術的成熟度が低い場合、特に最初からたくさんのことをスプリント中に完了させることはできません。 例えばユニットテスト、カバレージN%、重複チェック、複雑度チェック、○○チェックする、といったことを完成の定義に入れた場合に、チームがこれらのことをまったくやったことがなければ、しばらくの間すべてのプロダクトバックログアイテムは完了せず、ベロシティ０を達成することになったりするかもしれません。しかもそれがしばらく続くこともありそうです。 できないものを無理に積んでもスプリント内では終わらないので、リリーススプリントなどで作業をすることも検討します（ただし問題先送りの可能性やビッグバンの可能性はあります）。

チームが成熟してきたら拡張する

だんだんチームが成熟してきたら本来リリーススプリントでやろうと思っていたことをスプリント内でもできるようになったりするでしょう。その際はふりかえり等を使って定期的に見直しをしていくことがオススメです。

品質は固定パラメータ。途中でスコープ実現のために縮小しない

一度決めた定義を縮小するということは、品質を下げることに繋がることを理解しておかないといけません。品質の定義はプロダクトオーナー、スクラムマスター、開発チームで、プロダクトの背景をもとに決めたものであり、スコープ達成のために縮小していくことは問題を起こす可能性があります。 例えば医療用のソフトウェアの完成の定義を縮小した場合にどういう問題が起こるのかを想像してください。

できているかどうかを自動で検証

例えば、コーディング基準への準拠、複雑度やコピー・ペーストの検出は自動化できますし、性能測定も自動化できます。確認環境に配置すること、という完成の定義であれば、capistrano等を使って自動で配置することもできます。エンドツーエンドテストの自動化であればRobotFrameworkやSeleniumを使って自動化できます。 自動化のよいところは、OKかNGかを自動で判定できることです。そうやることで、自分たちが集中すべきことに時間を使えるようになってきます。また自動化できれば、完成の定義から外しても大丈夫です。

定義をみんな知っている

いくら定義をつくってもみんなが中身を知らないと意味がありません。中身を知っているというのは定義の指す内容や意味そしてなぜその定義があるのかを知っているということです。表面的に定義を知っているだけではその後の改善に結びつかず、見直しも行いにくく、単に盲目的に従うことになりかねません。印刷したり壁にはったりしていつも見えるところにおいておく、新しいメンバーが入れば説明する、分かりにくい内容だったら見直すといったことを続けていく必要があります。

ということで何か質問があれば遠慮なくどうぞ。