「アジャイル開発に関する書籍等を数冊読んで、知識やスキルの補強と向上を図ります！」の3冊目です！
「エンタープライズアジャイル開発実践ガイド」の実践編の前半である、Chapter5〜Chapter7です。
導入編で解説されている基本が実践でどのようにテーラリングし利用されているのか、その辺りを中心の読み進められればと思います！
いつものように、私が特に勉強になったと思った内容と個人的な感想を、備忘録としてまとめています。
Chapter5 要件管理
キーワード
- プロダクトオーナーは、ユーザー部門よりも開発部門から選出した方がメリットが大きい場合が多い。
- インセプションデッキは、プロダクトオーナー・開発チーム・スクラムマスター全員で作成して、共通認識を持つ。
- プロダクトバックログで整理する項目として、アイテムの内容・価値・受入条件・見積り・優先順位は必須である。対象者とビジネス価値の見積りも記載できると良い。
- 調査系の作業は完了の判断が難しいので、時間（タイムボックス）を決めてその枠でできるところまで実施する方法も良い。
- プロダクトバックログの作り方の流れ
- ユーザーに届けたい価値を整理する
- リーンキャンバスなどを活用して、ユーザー像と合わせて整理する。
- ユーザー層の深掘り
- アーリーアダプター層を想定したプラグマティックペルソナ（ソフトウェアの作り手側の想像で作成した未検証のユーザー像）を活用する。
- ユーザーストーリーマッピング
- ユーザーの視点で作成する。「〜できる」という表現を意識するとユーザー視点になりやすい。
- プロダクトバックログアイテムを作る
- ユーザーストーリー詳細と1:nになるとは限らず、複数のユーザーストーリー詳細を各々少しずつ実現して簡素な状態からリリースした方が動作する物が提供できる場合もある。
- ユーザーに届けたい価値を整理する
- バックログアイテムの見積もりは、バックログアイテムをスプリントバックログに追加した時に初めて確定する。
- 後から見直す前提でスピード優先で見積もる。
- チーム全体で基準のバックログアイテムを決定しておく。
- フィードバックは、意図的なものと意図しないものを組み合わせることが有効。
感想
調査系の見積もりはかなり悩むので、タイムボックスを決めてその中でできるところまで実施する、という方針は非常に良さそうに思いました。さらに調査が必要そうであれば追加調査のアイテムを作成すれば良いですし、調査結果に対して意見やアドバイスなども早い段階でいただけそうです。早速直近の調査から活用してみようと思います！
プロダクトバックログの作り方に関しては、書籍で解説されているほど価値やユーザ像から考えていませんでした。プロダクトを開発する本来の目的を思い出して、ただ単にアイテムを追加するのではなく、作り方の流れに沿ってかつ簡潔にプロダクトバックログアイテムを作っていければと思いました。
Chapter6 アジャイルで求められる開発技術
キーワード
- 書籍内で重要視しているのは、オブジェクト指向・GoFのデザインパターン・テスト駆動開発・リファクタリング（やモブプログラミング）・ペアプログラミング・マイクロサービス。
- アジャイル開発に効果的なデザインパターンとしては、FactoryMethodパターン・Adapterパターン・CommnadパターンとTemplateMethodパターンの組み合わせ・Facadeパターン・Stateパターン・Strategyパターンなど。
- テスト駆動開発は「進化的設計」という考え方をベースにしている設計手法である。
- リファクタリングは、ソースコードの理解を容易にするという目的でも実施する。
- マイクロサービスの特徴と注意点
- 特徴
- ある役割をもった単独で動作可能である。
- 単独で個別にデプロイが可能である。
- 各サービス間はAPIで実行する。
- 注意点
- 共通ライブラリは非推奨。密結合を起こしやすいため。
- ネットワークの負荷が高くなることや、同期処理によるレスポンス遅延などの問題もある。
- チーム編成
- サービスごとにチームを編成し、DevOpsを実現できることが理想である。
- 特徴
感想
デザインパターンは過去に何度か勉強したことはあるものの、パッと言われても内容がすぐに思い浮かばないものもあります。もっと良い実装方法はないかと悩んだ時に、その都度適するデザインパターンがないかを見返して、自分の中に定着させたいですね。
ソースコードの理解を容易にするためのリファクタリングは、タスクとしてはなかなか切り出しづらいです。そのため、機能追加や不具合修正が発生した時に、周辺のソースコードもスケジュールに影響が出ない範囲で少しずつ綺麗にしていきたいです！頑張ってはいますが、そこまで余裕がない時が多いのも事実。。。
この書籍では簡潔に要点を説明しているので、各キーワードの細かい内容は必要に応じて各々の専門書で確認したいと思いました。
Chapter7 品質管理
キーワード
- テスト駆動開発に加え、性能やセキュリティについての検証とテストも必要である。
- アジャイル開発でいうユニットテストの対象は、単一の関数やクラスではなく、インターフェースである。コンポーネントテストは、これらの複数のユニットから形成された1つの機能に対するテストである。
- 探索的テストはテスターの知見に基づいて実施するテストであり、素人に操作させるだけ（に近い意味合いの）モンキーテストとは別物である。
- ストーリーテストはユーザーストーリーに対するテストであり、シナリオテストはユーザーストーリーを基にして作成したテストケースに対するテストである。
- ソフトウェアメトリクスの収集には静的解析ツールを利用すると良い。オープンソースではSonarQubeが良い。商用ツールも多数ある。
感想
テスト名に関しては、明確な定義を十分に理解していないものもあったなと感じました。プロジェクトや組織によって若干意味するものは異なることもあると思いますが、基本的な定義を改めて理解することができて勉強になりました。
ソフトウェアメトリクスは収集したことがないので、少し興味がありますね！最近、より良いソースコードを書くにはどうすれば良いかに結構悩むので、良い契機かもしれません。問題はそのための時間をいかにして確保するかですが、これが超難題です><
以上
