人とコードのためのパターン言語
https://gyazo.com/e8d2bcf077690852e96fc660841917d9
5.2.3 : アーキテクトがプロダクトをコントロールする (プロダクトの一貫性を保つために、アーキテクトロールを作って、アーキテクチャスタイルを定義する原則や、それを正当化するような幅広いドメイン知識を体現させる) 開発者がプロセスをコントロールすることを忘れてはならない
開発者の、自分がコードの所有者であるという感覚を脅かしてはならない
5.2.4 : アーキテクチャチーム (大きくて複雑なシステムを 1 人のアーキテクトが見るのは難しいし、複数の視点を取り込む方が良い。 一方で関係者が多いと合意が難しい → 共感しあう少人数のチームでアーキテクチャを定義する。 アーキテクチャチームの仕事は、抽象的な仕切りを行うこと) 5.2.5 : 缶詰 (多様な人々で構成されたチームで一貫したアーキテクチャを考案するために、ドメインエキスパートを同じ部屋に集めてアーキテクチャを考え出してもらう) ドメインエキスパートと言っているけど、アーキテクチャチームではない？？
5.2.6 : 極秘の商談部屋 (組織の戦略的方向付けについて判断するにあたって、多くの人を巻き込むと意思決定プロセスがうまくいかないと思われる場合に、権力者たちの間で意思決定を行い、それを公開する。 ただし、この方法は控えめに使うべき) 5.2.7 : スタンドアップミーティング (プロジェクトでアーキテクチャ等の変更が多い状況では、全員が高頻度に同じ情報を受け取る必要がある。 チーム全員が参加する短い時間のミーティングを毎日行って情報共有や割り当てを行うと良い) TBD