綴ります。プログラミング、アプリ開発について。
6.13.2 ストーリーを分割する７つの戦略 内容 複数のサブストーリーを要素に分解する複数のサブストーリーで構成されている場合、分けることでモジュール化しやすくなる 複雑なストーリーは既知と未知で分ける分けることで既知の部分が効率的に進む 未知のことをわかるまで繰り返す未知の課題を解決する。そのまま 受け入れ基準をもとに分解するストーリーの受け入れ基準と整合性を保つ必要があるので、受け入れ基準をベースに分解する 依存関係を最小限にするストーリー同士の依存関係を少なくし、それぞれが独立してリリース可能にする 意図を１つにするそのまま ストーリーをテスト可能に保つそのまま 学び そのまま 学びを活かすアイディア・行動 これらをチェックリストに、バックログを見る・分解する
6.13.1 ソフトウェア開発を設計するための７つの戦略 価値実現までの時間を計測する価値実現までの全体プロセスの時間を知ることで全体像に注目できるため コーディングに使った時間を計測する品質改善に使える時間が少なすぎないかチェックできる 欠陥密度を調べるコード1000行あたりのバグの数は品質改善のための指標となる 欠陥検出までの時間を計測する欠陥発生から時間が経てば経つほど修正コストは上がる 機能ごとの顧客価値を計測する価値の高いものから時間を費やすことができるため 機能を提供しない場合のコストを計測するその機能がないとどのようなコストが発生するかが、機能を作る理由になる場合がある フィードバックループの効率を計測する失敗から改善までどれくらいかかっているかを知り、プロセスが改善されているかを知ることができる 学び そのまま 学びを活かすアイディア・行動 まだ具体的な行動は思いつかない
6.9 バックログを作る 6.10 ストーリーをタスクに分解する 6.11 タイムボックスの外側を考える 6.12 スコープを管理する 内容 アジャイル開発の進め方の重要なポイントはスコープを管理しながらリリースできるかどうか。 そのための方法として、バックログ（ストーリーをリスト化したもの）を作る。最初に優先順を決めて進める。なにか良いアイディアが出れば、途中でそれを入れる。優先順は入れ替えれば良い。 ストーリーは実際に行うタスクに分解する。理想は最大で4時間程度。8時間の労働時間の場合、4時間が理想。稼働率１００％の高速道路は、駐車場のようにびっしり車がつまってしまっていて、まったく機能していない状態を指す。ある程度のゆとりがあるからスピードを出すことができる。人間も同じでバッファがないと逆に動きづらくなる。 ある程度、小さな時間のタスクを消化し、リリースすることに慣れたら、機能をスコープにしてリリースすることにシフトしよう。 学び ビジネスに対して主体性が伴ってこその方法だと感じた。 やらされてやっているようではその意味を感じられない可能性がある。 学びを活かすアイディア・行動 大きなタスクを分解するときに、概算見積もりをつける
6.5 分割統治 6.6 フィードバックを短くする 6.7 ビルドを高速化する 6.8 フィードバックを早くする 内容 大前提として、私たちは常に間違うようにできている。だから問題は発生するし、どのように問題を解決するかがポイント。 問題は小さいうちのほうが単純でわかりやすく解決しやすい。だから複雑な問題を分解するスキルは重要。 複雑さは未知から生まれる。 未知に対するアプローチは２つ。 未知のことを既知になるように理解する カプセル化して、置いておく 複数のタスクをこなす場合、一度に取り掛かるタスクが多いと作業切り替え時の無駄が発生するので、カプセル化して置いておくと有効。 また、問題を常に小さく保つためには、常にビルドして統合しておくことが重要。ビルドのフィードバックは開発中の失敗を検知するのに非常に有効。間違いを検知すればそこから間違った原因を探すことができる。なので、ビルドに時間をかけてはいけない。3秒以内のビルドを目指そう。できないならメモリを増やそう。それでもできないなら設計を見直そう。 そして、フィードバックを得られたなら、フィードバックに対応しよう。そのためのフィードバックだ。 学び 未知のことは理解できるようになることが、１ｓｔステップ。 複数の未知がある場合は、カプセル化できるところまで進めて、あとは置いておく。 全体統合ビルドは常に高速を目指す 学びを活かすアイディア・行動 まだ思いつかない
6.3 ケイデンスがプロセスを決める 6.4 小さいことは良いこと 内容 作るものを小さくするほうが良い理由は 理解しやすい 見積もりやすい 実装しやすい テストしやすい 結果、早く作れて早く顧客に価値を届けられる。 リリースサイクルが長ければ長いほど1機能ごとに完成するまでのプロセス効率は悪くなる。人員の変動の可能性が出たりして、引き継ぐためのドキュメント作成の必要性が高くなり、正式なテストフェーズや統合フェーズを必要とするようになり、結果、ウォーターフォールとやってることは変わらなくなる。 また、価値提供の効率も悪くなる。全10機能を10ヶ月で一度にリリースすると、機能は価値を提供するまでに10ヶ月かかるが、1ヶ月ごとに1機能をリリースすれば、早くからリリースされた機能は早い段階から価値を提供できる。 ウォーターフォール開発は開発効率をコード行数で表すが、そもそもソフトウェアは顧客にどれだけ価値を与えたかで計測できなければならない。ベロシティ、コード行数が圧倒的にすごくても顧客に価値を与えていなければ意味がない。これらは顧客への価値を計測するための二次的な参考値にすぎない。 学び 顧客への価値を計測することが重要 生産性だけにフォーカスしても意味はない 学びを活かすアイディア・行動 KPIを意識することが重要と思うが、具体的な行動は思いつかない
6 プラクティス２ 小さなバッチを作る 6.1 小さなウソをつく 6.2 柔軟に進める 内容 タイムボックス、スコープボックスという枠を使って進める。作業単位ごとに結果が見えるように自分たちにとって正しいサイズにする。 タイムボックスは時間内にタスクを入れる。スコープボックスは時間ではなく機能単位で作る。 大きなタスクよりも小さなタスクの方がリスクが小さくて済む。タスクの見積もりが確実になることはないため、１年間で見積もりの誤りを隠しながら積み上げて大きくするよりも、小さな間違いを露見しながら軌道修正しながら進もう。 生産性を上げるために人を増やすことをするが、一概に正しいとは言えない。例として、子どもを産むのに９ヶ月かかるが、９人集めれば１ヶ月で産める、とはならない。ソフトウェア開発で大量の要求をさばかないといけない場合も、人数が増えたからといって大量の要求がスムーズに決まり、課題がスムーズに解決するとは限らない。多くの場合、人を増やすとコミュニケーションラインが増え、複雑化し、速度が落ちるか止まるかする。リリース日が決まっているのであれば、スコープを絞るべき。 学び 要求は人が集まれば解決するものでもない。必要最低限の有識者が課題を解決しながら決まるため、不用意に人数を集めるとリスクになる可能性が高い。 人を増やすよりも、有識者になるための情報共有する仕組みが必要 学びを活かすアイディア・行動 定期的な勉強会で有識者を作る