謎の集団zenelo内は最近スクラムについて盛り上がっています。ちょうど自分が2年前別の集団でScrumをやってたので、当時の理解が今見たら、いくつか誤解した点がある、もしかしたら他の人がScrumやる際の参考になれるかもしれませんので、まとめてみたいと思います。

0. Scrum ってなに？

Scrum is the leading Agile product development framework. It provides a foundation and path to delivering business goals in a collaborative, sane, and enjoyable manner. When was the last time you put "collaborative, sane, and enjoyable" in the same sentence with "business goals"? You may not remember unless you already use Scrum, but with Scrum you can, indeed, enjoy your work again!

スクラムはAgileの主要な製品開発フレームワークです。これは、コラボレーティブで、まともで楽しい方法でビジネス目標を実現するための基礎と道筋を提供します。あなたが「ビジネス目標」を持って同じ文章で「協調的で、気楽で楽しい」を最後にしたのはいつですか？既にスクラムを使用していない限り、覚えていないかもしれませんが、スクラムを使うと実際にもう一度楽しむことができます！(by Google 翻訳)

Scrumの詳細についていろんな資料がありますが、本記事は Core Scrum をベースにしています。

1. PO が全てを決める

POの責務はバックログアイテムのやる順番を考えることで、ROI（投資対効果）を最大化すること。それは決めることとはちょっと違うのは、その情報をチームに与えるし、時にチームから考える材料をもらわないといけない。
最終的何やるか、どうやるかを決めるのはチームになります。

2. 決められることしかできない

これが半分正しい、半分半分間違いました。
正しいのはSprint Planningでチームがやることを決まったら、そのスプリントは決めることを完成させるため、全力を尽くさないといけない。
間違いと思うのは、プロダクトや市場の状況は常に変化するので、前やりたいと思うこと（バックログに溜まったアイテム）であっても、状況によって実際やらなくてもいいかもしれませんし、逆にもっと優先度をあげて対応しないといけないので、スクラムはそれらをスプリント単位で常に見直さないといけないです。

3.１スプリントで終わらせないといけないので、必要最小限のソリューションになりがち

スクラムでは製品品質と技術品質両方満たさないと、出荷できないと考えています。
Doneの定義によって技術品質を担保するので、全部満たさないといけないし、スプリント中終われないと、それがUndoneとして定義し、単独のアイテムを切り出し、リリースまで必ず対応しないといけない様になっています。
品質要件が削れないため、バックログアイテムを１スプリントに収まるため、要件を分割しないといけない、その分割された要件を先に出すことによって、結果早期フィードバックをもらえて、PDCAを早く回せることができるです。

4. チーム誰でも実装できるタスクが望ましいので、優れた設計・実装ができない

前述通り、スクラムはDone定義で技術品質を担保するので、設計・実装などの内部品質もチームが合意すれば、必ず満たさないといけない基準として定義できる。
一方で誰でも実装できるのが望ましいが、必ず最初からそうじゃないといけない、チームメンバーにはチームの生産性を向上する責務があるので、一番低いところに合わせるより、Planningのときしっかり全員で設計したり、あとでTDD、ペアプロなどの手法によって、知見を広げ、チーム全員のレベルをあげることの方が望ましいと考えています。

5. スクラムがバグ対応、技術的負債解消には消極である

ここまでで既にわかると思いますが、この辺も主にDoneの定義によって担保されます。

まずバグについて、まずそのバグが機能品質が足りないか、技術品質が足りないかを判断する。

機能の場合、その機能が必要かどうかを考えて、必要ならバックログに入れて、優先順位をつけて対応する。
技術品質の場合も同じ対応ですが、それプラスに、Doneの定義にあるかどうかを判断する。
- Doneの定義にない場合、それを追加し、今後チェック必ずチェックする。
- Doneの定義にあるが、漏れた場合、漏れないようにどうするかを考えた上で対処しないといけない。

技術的負債はもっとシンプルで、Doneの定義が満たされたら、負債が残さないと思いますが、それが漏れた場合として対応すればいいと思います。

（リスト更新中）

まとめ

スクラムみたいなフレームワークは、価値観と原理原則が重要で、実践のルールはあくまでそれらを実現するための手段にすぎないですが、人々は抽象的な概念より、具体的なHowを覚えやすいので、本当にやりたいこと、解決したい課題を忘れがちです。そならない様に、しっかり概念の部分を理解し、その理解を基づいて、Howを常に振り返ることで、フレームワークを有効活用することを常に自分に言いつつ、これから集団の仲間と楽しく過ごしていきたいと思います。

※ まだまだ実践経験が少ない、勉強している途中なので、何か間違ったことを言いましたら、ぜひコメントしていただいて、その間違いを正したいと思います。