ツイート
チームトポロジー
#今日の30分 -3分。「チームトポロジー」KindleでNo.1167まで。認知負荷について。コードベースの複雑化、肥大化に伴い、認知しなければならない要素が増えている。ツールの多様化、複雑化もそれに拍車をかけ、チームへの負担が大きくなり続けている。責任範囲を調整し、これを軽減すること。
— ざっきー dev (@zakky_dev) 2022年6月20日
#今日の30分 -3分。「チームトポロジー」KindleでNo.1197まで。ドメインの種類を制限し、チームの認知負荷を軽減する。まず業務のドメインをシンプル、煩雑、複雑なものに分類する。チームが担当しているドメインがどのようになっているか分析し、偏りやよくない組み合わせを排除する。
— ざっきー dev (@zakky_dev) 2022年6月21日
#今日の30分 -3分。「チームトポロジー」KindleでNo.1243まで。ソフトウェアの境界について。チームがオーナーシップを持ちつつ、システムを効果的に進化させていくために、チームの認知負荷に合わせたアーキテクチャを採用する。システムの改善に集中できる環境を整える。
— ざっきー dev (@zakky_dev) 2022年6月22日
#今日の30分 -3分。「チームトポロジー」KindleでNo.1303まで。チームAPIとインタラクションについて。チーム間のコミュニケーションネットワークは、動的で明確なものであると良い。チームは自分たちとの連携、参加、状況理解を容易にするためのチームAPIを提供することが望ましい。
— ざっきー dev (@zakky_dev) 2022年6月23日
#今日の30分 「チームトポロジー」KindleでNo.1437まで。働く環境の設計について。チーム内外のコラボレーションを助けるため、オフィススペースのような物理的な作業環境や、チャットツールなどの仮想的な作業環境は、どのようなコラボレーションを促進するかを踏まえて明示的に設計すること。 pic.twitter.com/DHRgwkaRmO
— ざっきー dev (@zakky_dev) 2022年6月24日
#今日の30分 -5分。「チームトポロジー」KindleでNo.1529まで。チームファーストの前提となるエンジニアリングプラクティス、効果的なチーム設計の前のアンチパターン紹介。継続的デリバリーや自動化などのプラクティスはサイクルコストの低減のために有効であり、日々の投資が必要になる。
— ざっきー dev (@zakky_dev) 2022年6月25日
#今日の30分 「チームトポロジー」KindleでNo.1616まで。変更フローを考慮し、フィードバックを最大限活用するためのチーム設計についてと、DevOpsトポロジーの話。現代では本番からのフィードバックが重要視されるため、開発と運用が分離した構造は適していない。
— ざっきー dev (@zakky_dev) 2022年6月26日
ふりかえり
前回の結果
- タイミングを決めて「今日の30分」とは別枠で本を読む
- -
今回の追加活動
前回の活動を継続