ツイート
アジャイルソフトウェア要求
#今日の30分 -1分。「アジャイルソフトウェア要求」KindleでNo.1699まで。アジャイルチームにおける役割、反復、ユーザーストーリーとチームバックログ、プログラムレベル。基本的にはスクラムの話。ユーザーストーリー、チームバックログ、タスクの役割の違いがわかりやすい。そうなるよなー。
— ざっきー dev (@zakky_dev) 2021年6月21日
#今日の30分 -2分。「アジャイルソフトウェア要求」KindleでNo.1751まで。ビジョン、フィーチャー、プログラムバックログ、リリース計画、ロードマップ。プロダクト管理の主な責任はビジョンの維持だ。どの問題を解決し、何を誰に、どんな性能や信頼性で、どういった環境に提供するかなど。
— ざっきー dev (@zakky_dev) 2021年6月22日
#今日の30分 -4分。「アジャイルソフトウェア要求」KindleでNo.1814まで。プロダクト管理の責任重複と、ポートフォリオレベルの全体像について。企業の規模や扱うソフトウェアの規模が大きくなるにつれて、スクラムのPOの責任が広がっていく。プロダクト管理者から共有された役割が増える。
— ざっきー dev (@zakky_dev) 2021年6月23日
#今日の30分 +1分。「アジャイルソフトウェア要求」KindleでNo.1934まで。チームレベルでの要求について。エンドユーザーへの価値提供速度を向上させるにあたり、要求を中心として組織化する必要性があるため、チームの活動についても言及する必要がある。反復の中で要求をどう処理していくか。
— ざっきー dev (@zakky_dev) 2021年6月24日
#今日の30分 -2分。「アジャイルソフトウェア要求」KindleでNo.2081まで。ユーザーストーリーとチームバックログ、受け入れテストについて。組織の効率性のために、チームの効率性は重要だ。そのため、チームが要求を扱う際には、シンプルさを保ちつつも有用な要求モデルが必要になる。
— ざっきー dev (@zakky_dev) 2021年6月25日
#今日の30分 「アジャイルソフトウェア要求」KindleでNo.2212まで。単体テストの話と、プログラムレベルの導入とチームのタイプについて。単体テストはストーリーの完了条件の一つ。書かれ、かつ合格していること。これは受け入れテストと合わせ、品質を作り込むことの一環だ。継続すること。
— ざっきー dev (@zakky_dev) 2021年6月26日
#今日の30分 -1分。「アジャイルソフトウェア要求」KindleでNo.2322まで。コンポーネントチームとフィーチャーチームの混合と、システムチームについて。求められる専門性専門性が高すぎて、扱える人が少ないなら、フィーチャーチームにすることは難しい。コンポーネントチームを混ぜることが有用。
— ざっきー dev (@zakky_dev) 2021年6月27日
ふりかえり
前回の結果
- タイミングを決めて「今日の30分」とは別枠で本を読む
- -
今回の追加活動
前回の活動を継続