Day: February 17, 2021

5.7.2 良いストーリーを書くための７つの戦略 内容 プレースホルダーとして見るストーリーは詳細な要求ではない。議論の本筋を掴むためのプレースホルダーとして使うと良い。 目的に注力する開発者はコードを書きながらやり方を模索すべきだが、まず機能の目的を理解すべき 「誰」を擬人化する誰のための機能かを知ることで、使われ方の理解が深まり、設計の改善ができる。 なぜ機能が必要とされたのかを知る機能の目的の経緯をしることで、より良い選択肢に至ることができる。 シンプルに始めて、あとで追加するリファクタリングと創発設計ができるようになると理想的な設計になるので、始めはシンプルに考えすぎない。 エッジケースを考えるストーリーはハッピーパスを表すが、他のパスもあるのがほとんど。浮かび上がったパスはメモしてあとでテストする。 学び コミュニケーションによって要件の詳細を詰めていき、ドキュメントはなるべくコードに寄せるというイメージでした。 学びを活かすアイディア・行動 特になし

5.7.1 プロダクトオーナーのための７つの戦略 内容 SMEになるその分野、プロダクトにおける専門家になる。 開発を発見のために利用する開発中の機能を何百というユーザーに触ってもらい、正しく進んでいるかを確認する。 どうやって手に入れるかより、何が欲しいかを説明する開発者には何が欲しいかを説明し、やり方は裁量を与える。それにより保守性が高くなる。 質問をすばやく答えるPOはボトルネックになりやすいので質問が来たら早く答える。 依存性を取り除く誰かが何かにかかりきりにならないようにタスク分割し優先順を変え、チームが柔軟に動けるようにする。 リファクタリングを後押しする機能要求だけでなく、保守性にも敏感である必要がある。 学び イメージが沸かないことが多いので具体的な経験を積む必要がある 学びを活かすアイディア・行動 ユーザーのABテスト

5.3 プロダクトオーナーをおく 5.4 ストーリーで目的、理由、誰のためかを語る 5.5 明確な受け入れ基準を設定する 5.6 受け入れ基準を自動化する 内容 プロダクトオーナー（PO）はプロダクトに一番精通している人で、この人が監督のようなもので、正しく進んでいるか確認しながら進める。プロジェクトマネージャーとか、呼び方はさまざま。 POは「誰が」「何を」「何のために」が１文でわかる「ストーリー」を作る。これが要件を表す「かろうじて分かる最低限のドキュメント」で、これをもとに開発を進める。ストーリーの例）・映画を見る客が・オンラインでチケット購入する・映画館でチケット購入のために待ち時間を作らないために ストーリーができたらPOは受け入れ基準を明確にする。・それは何をするはずか・それはいつ動くか・どうなったら次に進むことができるかこれがハッピーパスとなり、例外やその他の分岐はこれが基準となる。 受け入れ基準が明確になったら、ふるまいのIN/OUTを明確にしてプログラムレベルで検証できるようにする。ここまで明確になれば、不要な作り込みは起きない。 学び ちょっとまだ具体的なイメージがわかないので、学習が必要だと感じた。 学びを活かすアイディア・行動 ストーリー作りから作り込むことについて学習

5 プラクティス１ やり方より先に目的、理由、誰のためかを伝える 5.1 やり方は言わない 5.2 やり方を目的に転換させる 内容 ソフトウェア開発では半分を要求収集に使っていると言われている。そして、顧客から開発者までに情報が流れるなかで情報は欠落したり歪んでいったりしていく。 開発に精通していない顧客やマネージャーが要求の「やり方」まで伝えることがあるが、これは良くない。情報が専門知識が無い前提のもので、開発者は専門知識を前提に見るので混乱を招く。 なので「やり方」は専門家である開発者に任せるべき。 また、「やり方」も開発者によって千差万別で、似たようなものもあれど完全に同じやり方をするということは無いが、これはこれで良さがある。新しいアイディアが生まれるから。 細かいやり方を統一することは難しいので、原則・パターン、プラクティスを共通認識として持ち、その域を越えて標準化しなくてもよい。 学び やり方は細かすぎるものは標準化しなくてよい。 学びを活かすアイディア・行動 現場のコーディング標準