ツイート
アジャイルソフトウェア要求
#今日の30分 「アジャイルソフトウェア要求」KindleでNo.7879まで。要求分析ツールキット。大規模になるほどコミュニケーションは複雑になる。システムを構築する際には仕様を厳格に定義する必要が出てくるが、そのためのコミュニケーションが難しくなる。そこでツールにより厳格な定義をする。
— ざっきー dev (@zakky_dev) 2021年8月16日
#今日の30分 +1分。「アジャイルソフトウェア要求」KindleでNo.8033まで。ユースケースの話。ユースケース自体はアジャイル界隈で嫌われることも多かったが、大規模なシステムであるほど、ユーザーストーリーだけでは表現できないような文脈、完全性の提供、今後を展望する観点において有用。
— ざっきー dev (@zakky_dev) 2021年8月17日
#今日の30分 -2分。「アジャイルソフトウェア要求」KindleでNo.8127まで。ユースケースモデルの構築と適用について。ユースケースの構築は5つのステップに分けられる。アクターの識別と記述、ユースケースの識別、それらの関係性の識別、フローの概略の決定、ユースケースの洗練。
— ざっきー dev (@zakky_dev) 2021年8月18日
#今日の30分 -2分。「アジャイルソフトウェア要求」KindleでNo.8259まで。アーキテクチャの扱いについて。大規模になるほど、自然発生的なアーキテクチャだけでは経済的な効率が悪いことが増える。学びを反映しアーキテクチャを進化させるのは一定の規模まで。ラインを超えれば再作業が増える。
— ざっきー dev (@zakky_dev) 2021年8月19日
#今日の30分 -3分。「アジャイルソフトウェア要求」KindleでNo.8383まで。アーキテクチャとアーキテクトの話。アーキテクチャを取り扱うビジネス要因はいくつかある。新しいチャンスのため、技術の変化、既存部分の問題解決、ガバナンス、重複作業回避、イノベーションの推進、コスト削減。
— ざっきー dev (@zakky_dev) 2021年8月20日
#今日の30分 「アジャイルソフトウェア要求」KindleでNo.8463まで。疑わしいときはコードやモデルを作り確認する、構築したらテストする。アーキテクチャを考えても、実際にどうなるかはやってみないとわからないことはある。その場合、小さく作って試し、フィードバックを得て先に進むと良い。
— ざっきー dev (@zakky_dev) 2021年8月21日
#今日の30分 「アジャイルソフトウェア要求」KindleでNo.8463まで。大規模なシステムではアーキテクチャー滑走路を長くとる、アーキテクチャーは役割間の協調、イノベーションを仕組みとして組み込む、アーキテクチャーフローの実装。小さいシステムならここまで色々考える必要はない。
— ざっきー dev (@zakky_dev) 2021年8月22日
ふりかえり
前回の結果
- タイミングを決めて「今日の30分」とは別枠で本を読む
- -
- アンガーマネジメントについて調べる
- -
今回の追加活動
前回の活動を継続