5
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 1 year has passed since last update.

スクラムが「高速ウォーターフォール」ではないことを説明した資料 (DoD, 完成の定義)

Last updated at Posted at 2019-06-15

はじめに

  • つい最近組織の偉い方と1 on 1 をさせていただく機会があり、そのとき表題の件を説明した内容をメモも兼ねて書き起こしたいと思います。
  • その方はしきりに「1ヶ月のウォーターフォールを何回も繰り返すのとスクラムの違いがわからない」とおっしゃっていたので、これを期に自分なりの理解を説明しようとして作ったのがきっかけです。
  • なるべくエンジニアではない方にもわかりやすいように抽象的な表現も使っています。組織をアジャイルにしていこうという方などの一つの参考となれば幸いです。

スクラム と ウォーターフォールの違い

  • スクラム と ウォーターフォールでは「品質」に対する考え方が大きく違う

Screenshot from 2019-06-15 11-11-22.png

お茶をプロダクトとした場合の例

  • ウォーターフォール...

  • お茶の「美味しさ」「デザイン」を先に追求し、「飲み物としての安全性」はその後できる限り対応する

  • スクラム...

  • お茶の**「飲み物としての安全性」は常に担保**しつつ、「美味しさ」「デザイン」を追求する

  • 誤解を恐れずにすごく極端な例でいうと、「味はとても美味しいし、見た目の色もラベルのデザインもめちゃめちゃキャッチーだけど、毒があります。でも毒はなるべく取り除きました。」というのがウォーターフォールで、「飲み物として暗黙的に守られている品質や安全性はいつでも担保してあります。味とか見た目とかデザインは徐々に良くしていきます。」というのがスクラムの考え方

スクラムには Done と Undone という考え方がある

  • 上の例のように、技術品質を担保しつつ毎スプリントごとに「出荷可能」なプロダクトをリリースするには、Doneの定義 (Done + Undone) を守り続けなければいけない。Doneの定義を満たしていないプロダクトはリリースしてはいけない。

Screenshot from 2019-06-15 11-16-54.png

  • しかし現実は、各スプリントごとにすべてのDoneの定義を満たすのは不可能である。
  • よって各スプリントごとに達成できるものを**「Done」とし、そうでないものを「Undone」**と分ける
  • 繰り返しになるが、**プロダクトをリリースするためには「Done」と「Undone」**の両方を満たす必要がある。

リリーススプリント (炎上スプリント)

  • リリースするためには、直前に「リリーススプリント」を実施し、Undone のものを実行しなければいけない。しかし長く放置されたUndone は期限内に間に合わず炎上の原因になる。

Undone
出典: https://less.works/jp/less/framework/definition-of-done.html

Undone の扱い方

  • スクラムでは定期的(各スプリントごと)にUndoneを実行する必要がある。Undoneは上図にあるように、放置すればするほど作業規模が曖昧になり、予定していたリリース日に間に合わないというリスクが大きくなる。
  • しかし、Undoneは後半まで放置してしまいがちである。Undone をやらずにプロダクトバックログアイテムの消化を進めていけば、進捗していると錯覚してしまうからである。もっというとそこには、**「早く進捗させないといけないという周りからの外圧」**があるのかもしれない
  • 定期的にUndone を実行するよう、スクラムマスターはPOと開発チームを促していく
  • ウォーターフォールは工程の後半にUndoneに相当するもの実行するという点でスクラムとは大きくアプローチが異なる
    ※ 余談ですが、私も様々な要因からUndone を溜め込みまくり、リリース直前になって遅延報告するという「いきなり赤信号問題」を経験しました。特にスクラムを組んで間もないことはよく起きがちなのかなと思います。

Undone は Done にしていかないといけない

  • 世の中はいかにUndone をDone にするかでせめぎ合っている
  • Undone がなくなれば、スプリントごとに品質担保されたプロダクトがリリースできる
  • 更に進化すると「リモートブランチへのPush」がリリースの単位になるかもしれない
  • Undone を Done にする典型的な例は、品質課によるテストを自動化するというもの

Screenshot from 2019-06-15 11-38-47.png

これから考えたい課題

  • 偉い方からは一定の理解を得られたかなと思いましたが、「アジャイルで開発しても、社内の連携先がアジャイルではないのでボトルネックになってしまうことが多い。開発チームが可愛そうだ。」というフィードバックをいただきました。
  • 確かにそれなりに大きい組織だと、システム間がスパゲッティ状態になっており「Aシステムを使いたいのに、Aシステムが連携しているBとCシステムが不安定だから今は連携しないでほしい」みたいなことがあったりします。
  • また、連携したいシステム先の工数のキャパシティが一杯で、作ったシステムに遷移できるよう、リンクを貼ってもらう修正作業に5ヶ月待ちという状態も発生したりしています。
  • こうなるとボトルネックとなりうるシステムと連携するシステムは延々と開発できない(というかリリースできない) ことになってしまいます。
  • 今現在この課題の解決案を私は持ち合わせていません。組織をアジャイルにするためには、こういった課題にアプローチしていかないといけないんだろうなあと思う今日この頃でした。
5
2
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
5
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?