#presentation
Date : 2019/07/09
[https://www.youtube.com/watch?v=haejb5rzKsM](https://www.youtube.com/watch?v=haejb5rzKsM)
# なぜこの動画を見た
[[Team Topologies]] の作者の人たちで、しかも本がベータのときの発表だったので行間を読めるようになるために
# なんの動画か
概ね [[Team Topologies]] の内容の発表
行間などを理解するのに参考になった
# メモ
> Strat with monlith and extract microservices
> - Tammer Saleh
> Dont't start with a monolith when your goal is a microservices architecture
> - Stefan Tilkove
> If you can't build a monolith, what makes you think microservices are the answer
> - Simon Brown
みんないろんな立場でいろんな観点でマイクロサービスを語っている
どういうアプローチをしていけばいいかわからない
> Software that fits in your head
> - Daniel Terhorst-North
> Software that is too big for out heads` works against organizational agility
## Cognitive Load
The total amount of mental effort being used in the working memory - John Sweller
- Intrisic : Fundamental part でスキルなどによって当たり前になるもの (e.g. How are classed defined in Java)
- Skills
- Extraneous : タスクのやり方など (e.g. How do I deploy this app, again?)
- これは最小にしたい cogniitve load
- mechanism
- Germane : 重要なビジネスについての知識でこれはあるべき cognitive load (e.g. How do bank transfers work?)
- Domain focus
Germane を最大にしつつ、Extraneous を最小にすることが重要
Intrisic は避けれない cognitive load
つまり
> Limit the size of software services/products to the cogniitve load that the team can handle.
Sociotechinical に考える = 人の脳や人の働きを考慮する アプローチが必要
> Each service must be fully owned by a team with sufficient cognitive capacity to build and operate it.
これを実行するためのテクニック
- Mob Programming
- Domain Boundaries (DDD)
- Developer Experience
- Operator Experience
- Thinnest Viable Platform (TVP)
## 4 fundamental topologies
Stream Aligned Team
- ビジネスバリューに沿っているチーム
- end-to-end で責任を持つ
以下の3つのチームは、Stream Aligned Team から Extraneous Cognitive Load を取り除いたり、Intrisic をサポートしたりするためのチーム
Enabling Team
Complicated Subsystem Team
Platform Team
## Case Study1
- 2016 (earyly)
- 
- 少人数でMobile WebService をスピード感持ってリリースできた
- 2016 (late)
- 
- CMSが作られたり、別のクライアントが出たり
- 2017 (early)
- 
- Product が増えたりして Product を検索するサービス
- 全体を整理する Framework が導入されたり
- 人も増えて、変更のライフサイクルやワークフローがみんな異なっていることがわかってきた
- 2017 (later)
- 
- 2チームに分けて運用してみた
- CMS と Framework
- Products と ユーザーへのサービス
- うまく動くようになった
Listen to triggers for evolution
- Software grows too large
- Over specialization
- Increaded coordination needs
## Case Study2
- 関係のない活動をしている人がチーム内に増えてきている状態
- 複雑さでシステムとオーナーチームを分割
考慮すべきはサイズだけではなくそれぞれのソフトウェアの複雑性に目も向ける必要がある
Listen to triggers for evolution
- Awkard interactions
- People not invested, burn out
- Frequent context switching
## How to start
Explicit cognitive load
- アンケートやヒアリングなどを通して cognitive load を把握する
Team Interactions
- Collaboration, X-as-a-Service, Facillitating のコミュニケーションプロセスが導入されたらチームへの影響はどうなるか
Thinnest Viable Platform
- 多くのことをやりすぎてるシステムにはなっていないか？
# 感想
[[Team Topologies]] の行間を読むためには参考にするとよい発表だった。
Sociotechnical の定義が曖昧だったのだけれど、「人間の考え方や組織や人のあり方を考慮にいれた」という定義をしていてしっくりきた
[[Team Topologies]] の本と言ってること自体はそんなに大きく変化はない