ツイート
アジャイルソフトウェア要求
#今日の30分 +1分。「アジャイルソフトウェア要求」KindleでNo.6453まで。従来手法におけるプロダクト管理者の幻滅のフェーズ、そこから抜け出して新しいモデルになるためのプロダクト管理者の進化について。「あとよろしく!」といって放置した結果、現実を見せられて幻滅する、という話だな。
— ざっきー dev (@zakky_dev) 2021年8月2日
#今日の30分 昨日分。-2分。「アジャイルソフトウェア要求」KindleでNo.6515まで。アジャイルなプロダクト管理者の責務について。ビジョンとリリースバックログに責任を持つことが主たる責務。ビジョンはギャップと機会への対応をどのような形でも伝えるもの。非機能要求もビジョンに含む。
— ざっきー dev (@zakky_dev) 2021年8月4日
#今日の30分 今日分。-1分。「アジャイルソフトウェア要求」KindleでNo.6577まで。リリースバックログの更新責任と、ロードマップの維持責任。リリース計画イベントを通してビジョンを伝え、チームと一緒に計画、得た情報からスコープを調整、ビジネス目標を設定する。その後は追跡して管理する。
— ざっきー dev (@zakky_dev) 2021年8月4日
#今日の30分 「アジャイルソフトウェア要求」KindleでNo.6711まで。効果的なチームを築く責務と、アジャイルリリース列車の概要について。プロダクト管理チームは横軸的な組織だ。全体的なプロダクトの方向性を提供する役割を担う。開発チームの容量とビジネス都合のバランスを取る必要がある。
— ざっきー dev (@zakky_dev) 2021年8月5日
#今日の30分 「アジャイルソフトウェア要求」KindleでNo.6770まで。アジャイルリリース列車のルールと効果。リリース日固定、品質固定、スコープ可変、共通の反復期間、マイルストーン、システムレベルのCI、定期的なリリース、硬化反復、共通基盤の先行開発。これらによりリリースを定期化する。
— ざっきー dev (@zakky_dev) 2021年8月6日
#今日の30分 -2分。「アジャイルソフトウェア要求」KindleでNo.6824まで。アジャイルリリース列車によるプロダクト開発フローの制度化の効果について。待ち行列管理の促進、不確実性の扱いやすさ向上、バッチサイズ低下、WIP制約、オーバーヘッド減少、高速なフィードバック、制御の分散。
— ざっきー dev (@zakky_dev) 2021年8月7日
#今日の30分 -1分。「アジャイルソフトウェア要求」KindleでNo.6890まで。アジャイルリリース列車の設計、リリースの計画、追跡、管理、振り返り、予見性について。数チーム程度ならともかく、チーム数が多くなるほど、列車にどのチームを乗せるか考える必要がある。誰が、何を作るのか。
— ざっきー dev (@zakky_dev) 2021年8月8日
ふりかえり
前回の結果
- タイミングを決めて「今日の30分」とは別枠で本を読む
- -
- アンガーマネジメントについて調べる
- -
今回の追加活動
前回の活動を継続