チケットを書くうえで絶対に気をつけたい事
実現したい状態を書く。何をやるかではない。
JIRA とかでチケット駆動開発してたりとか、まあ付箋でもなんでも同じなんですが、気をつけなきゃいけないのは、付箋に書いても大抵伝わらないので、完了条件で揉めることが多々あるということ。
依頼した A さんにとっての期待値と、依頼された B さんにとっての 予測値は大抵ずれる。
壊れるほど愛しても 1/3 も伝わらないのにチケットに書いただけじゃもっと伝わらないのが人生。
で、だいたい揉める場合は、
「＊＊＊する」
みたいな書き方をされてる。
これだと、やったかどうかを評価しがちで、やった後で、出来てる出来てないといった達成度を厳密にするために中世フラスコ画もビックリなレベルで異様に細かい Acceptance Criteria を書き込む羽目になる。
なので、そのチケットを実行した結果、どういった状態になっていて欲しいのかを明確にして、共有するのがおすすめ。
というか、それを実現するための手法は正直どうでもよくないですかね ＞ 依頼する側の人
とはいえ、どういった状態になっているか、という話も、認識ずれがまだ起こりやすい。
作った人「僕はこれで使えると思う」
みたいな不毛な主張と戦う羽目になってつらい。
なので、誰にとって？っていう視点を明確化するために、ペルソナとかを定義しておくといい。おすすめ。
ついでに言えば、実現手法について変なデザインをしないためにも、
「なぜそれが欲しいのか？」
まで表現しておくと、効率よく伝わる。
何故ならその欲求を満たしているかが判断基準になるから。
ってな情報をシンプルに描き起こせるので、ユーザーストーリーの書き方のテンプレートは、
＊＊＊として（ペルソナ）
＊＊＊したい（達成したい状態）
何故ならば＊＊＊（理由）
っていう形にできてて、広く使われてる。
よく一部（または豪快に全部）の要素を吹っ飛ばしてチケットを書く人も多いけど、その分伝わらないリスクがあるのをゆめゆめ忘れないようにしないと後で泣く。
相手に伝わるかどうかのリスクは、エンジニアリング組織論への招待にて、”通信不確実性” って形で紹介されてた。
エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング
これまでだと Perfect なドキュメントを書く！みたいになりがちだけど、会話の方が情報量多いし、コスパがいいと個人的には思うので、無駄なことしないで、チケット書いて対話するのが一番。
認識する事象と表現された表記が異なるってのはソシュールのシーニュ・シニフィアンと同じ話。
ここに書いている内容もきっと Web 経由では 1/3 も伝わらない。
めっちゃどうでもいいけど、スクラムの用語は一般的に伝わりやすい言葉を使っているので、取っ付きやすい反面、誤解されてクソみたいなプラクティス運用されている場面もよく見かけるけど、これもまたスクラムガイドからは伝わりきらない通信不確実性の一つ。（スクラムマスターが機能していなともいう）
