ツイート
アジャイルソフトウェア要求
#今日の30分 -3分。「アジャイルソフトウェア要求」KindleでNo.2425まで。リリース管理チーム、ビジョン、フィーチャー。大規模になるほど、チームにあらゆることを委任することは現実的に難しい。それを補完する機能として、システムチームなどが組織される。リリース管理チームも同様だ。
— ざっきー dev (@zakky_dev) 2021年6月28日
#今日の30分 -3分。「アジャイルソフトウェア要求」KindleでNo.2510まで。非機能要求の特性とテスト、アジャイルリリース列車、ロードマップ。非機能要求は機能要求やシステム全体の開発のブロッカーになる特性がある。機能要求とはこのあたりが異なる。ただし、テストが必要なのは同じこと。
— ざっきー dev (@zakky_dev) 2021年6月29日
#今日の30分 「アジャイルソフトウェア要求」KindleでNo.2624まで。ポートフォリオレベルの導入、投資テーマ、ポートフォリオ管理チーム、エピック、ポートフォリオバックログ、アーキテクチャーについて。より大規模な企業になると、プログラムレベルでは不足するため、このレベルを導入する。
— ざっきー dev (@zakky_dev) 2021年6月30日
#今日の30分 -1分。「アジャイルソフトウェア要求」KindleでNo.2749まで。アーキテクチャーの話。アーキテクチャーに関する作業は大規模になりがちだが、かといってビッグバンリリースを許容していいわけではない。これもまた原則に則り実現する。すなわち、インクリメンタルに進めていく。
— ざっきー dev (@zakky_dev) 2021年7月1日
#今日の30分 7/2分。-2分。「アジャイルソフトウェア要求」KindleでNo.2884まで。ユーザーストーリーの概要と形式について。ユーザーストーリーは価値の納品を駆動する仕組みだ。ユーザー価値を短く理解できる形で定義し、それを短い反復で作りテストし、ユーザーにデモ、納品するサイクルを繰り返す。
— ざっきー dev (@zakky_dev) 2021年7月7日
#今日の30分 -1分。「アジャイルソフトウェア要求」KindleでNo.3036まで。ユーザーストーリーの詳細と、INVESTの話。ユーザーストーリー自体は、システムに求められるものの意図を端的に説明した文章だ。これの詳細はステークホルダーなどとの会話の中で見出される。チームは最初から関わる。
— ざっきー dev (@zakky_dev) 2021年7月3日
#今日の30分 -1分。「アジャイルソフトウェア要求」KindleでNo.3112まで。INVESTの続き、ユーザーストーリーの分割、スパイク。ユーザーストーリーのサイズを小さくすることで、複雑さの低減に繋がり、ひいては見積もり精度が上がる。逆に独立性は下がるため、PBLの上ほど小さくすると良い。
— ざっきー dev (@zakky_dev) 2021年7月4日
ふりかえり
前回の結果
- タイミングを決めて「今日の30分」とは別枠で本を読む
- -
今回の追加活動
前回の活動を継続