ツイート
チームトポロジー
#今日の30分 -2分。「チームトポロジー」KindleでNo.2402まで。チームサイロを避けることと、プラットフォームについて。引き継ぎの無駄を避ける。コンセプトから運用まですべてストリームアラインドチームが担当できるようにする。そのために他のチームタイプがノンブロッキングに支援する。
— ざっきー dev (@zakky_dev) 2022年7月4日
#今日の30分 +3分。「チームトポロジー」KindleでNo.2504まで。既存チームから各チームタイプへの変換について。ほとんどのチームはストリームアラインドチームに変換される。機能のスライス、もしくは特定のユーザーアウトカムにオーナーシップを持ち、長続きする柔軟なチーム。
— ざっきー dev (@zakky_dev) 2022年7月5日
#今日の30分 -1分。「チームトポロジー」KindleでNo.2583まで。アーキテクチャーチームの変換と、責任の境界について。アーキテクチャーチームはパートタイムのイネイブリングチームへ変換すると良い。重要なのはサポートチームであること。指針を示したりアドバイスはすれど、強制しない。
— ざっきー dev (@zakky_dev) 2022年7月6日
#今日の30分 +4分。「チームトポロジー」KindleでNo.2688まで。よくあるモノリスの形と、ソフトウェアの境界、節理面について。単一で巨大なアプリケーションだけがモノリスではない。DB結合、ビルド、リリース、モデル、思考、ワークスペースなどでも結合し、悪影響を及ぼす可能性はある。
— ざっきー dev (@zakky_dev) 2022年7月7日
#今日の30分 -1分。「チームトポロジー」KindleでNo.2740まで。ソフトウェアの境界、節理面の種類。規制遵守、変更のケイデンス、チームの地理的配置。規制による変化、監査を受け入れやすくするために、そこだけを切り離したサブシステムを構築する。変更頻度の多い部分を切り離す。
— ざっきー dev (@zakky_dev) 2022年7月8日
#今日の30分 +1分。「チームトポロジー」KindleでNo.2804まで。ソフトウェアの境界、節理面の種類。リスク、パフォーマンス、技術、ユーザーペルソナ。ビジネスを取り巻く環境の変化や、変更したときのユーザー影響の大きさなどのリスクがわかっているなら、それを隔離したサブシステムも有効。
— ざっきー dev (@zakky_dev) 2022年7月9日
#今日の30分 -2分。「チームトポロジー」KindleでNo.2920まで。ソフトウェアの境界を明確にし、チームに単一のドメインを割り当てるのは、フローの最適化が目的だ。チームサイズに合わせてシステムを分割することで、担当チームにオーナーシップを持たせ、持続可能な進化を可能にする。
— ざっきー dev (@zakky_dev) 2022年7月10日
ふりかえり
前回の結果
- タイミングを決めて「今日の30分」とは別枠で本を読む
- -
今回の追加活動
前回の活動を継続