[アジャイル開発] 基準は明確にする👀
Hideyuki Fujihara『スクラムブートキャンプ』を読んで気になった部分であったり、つらつらと考えたことについてまとめてみようと思います。
以下、そのまとめです。
Hideyuki Fujiharaスプリントそのものだけでなく、
日々こなすチケットやスプリント内で作る成果物、
それをレビューでお見せするまでの段取り、
そもそものプロジェクトの完了基準であったり、
開発チームの開発スコープであったり、
他のステークホルダーの役割であったり、
プロダクトや機能・非機能の受け入れ基準は明確になっていないといけません。
開発だけでなく運用に乗せる際の戦略や設計も考えないといけません。
期限もそうですが、この辺りが明確になっていて、
かつ合理的な理由が無いと中々うまくいかなかったりします。
Hideyuki Fujiharaたとえばスプリントゴールについてもそうです。
単にチケットをやるのではなく、何のために、最低限何をこなして積み上げないといけないのかを明確にしないといけません。
スプリントゴールの定め方については僭越ながら以下の記事を参照ください。
Hideyuki Fujiharaスプリントやプロジェクトで作る成果物もそうです。
ここで騙し絵を作ってはいけません。
騙し絵を作らないためにも、何を作るのか、何故作るのかは明確に定まってないといけません。
ついついどうやったら出来るかにフィーチャーしがちになってしまいがちなものほど、前提から疑う必要があるのかも知れません。
Hideyuki Fujihara以下の日米のチェックリストの違いを見てみましょう。
アメリカのチェックリストが具体的であるのに対して日本のそれは抽象的な内容になっています。
作業効率上どちらが速いかは明白ですが、
それ以上にプロダクトや機能・非機能の受け入れ基準が明確か否かによって引き起こされる問題も容易に想像され、
それによるプロダクトやプロジェトの品質保証上のリスクを孕んでもいます。
テストの文脈で言えばチェックリストベースドテストというものがありますが、
ハイレベルコンテキストなチェック項目による一貫性や再実行性の問題があるため、
テストケースの設計時はそれを留意して明示的に、かつあまりに一般的なものは排除するなどの冗長性の解消を意識して作成される必要があります。
このようなものだからこそ適当にしてはいけないのです。
画像引用元:
Hideyuki Fujiharaこのような騙し絵作りのリスクが潜んでいるからこそ、先ずは受け入れ基準から定めないといけません。
BDDなどはそのためのフレームワークでもありますし、
JSTQB FLのシラバスやその解説書の中でも受け入れ基準についてページを割いて解説されています。
Hideyuki Fujiharaチケットについても考えてみましょう。
チケットにタイトルだけ書かれていても、
それがなぜ生まれて、何をどこまでするのか、
またはどんな手法をとって、成果物が何かなどの情報が無ければ
有意義な振り返りやプランニングポーカー時の見積もり時にも参考にすることが出来ません。
何か欠陥があった際のトレーサビリティーも効きません。
もし上記のような内容をチケットに書いていれば、そもそもそのタスクは必要ではなかったり、
または別の解決策の方が良いことに気付いてそのチケット化に繋がったりするチャンスが生まれます。
取り組むにしても優先度が低かったり、依存関係の問題で直ぐには取り組めないなど時期を改めた方が良いチケットであることに気付きやすくなります。
このようなメリットもありますので、チケットには上記のような内容をキチンと書いておいた方が良いでしょう。
『デザインドキュメント』という開発者の頭の中の整理のためのドキュメントライティングのフレームワークが世の中にはありますので、
これをチケット作成やそのメンテナンスにも応用してみるといいかもしれません。