以下の内容はhttps://daiksy.hatenablog.jp/entry/2020/06/21/113348より取得しました。
- 大規模: 2つ以上のアジャイルチームが必要なプロジェクト
- 大規模プロジェクトにおけるアジャイルの変更点
- 創発的な設計 -> ウォーターフォールのように全ての作業を事前に完了させる必要はないが、標準的なアジャイル開発よりも事前に完了させなければならない作業が増える
- テスト -> 依然として小さなテストの恩恵は受けるが、統合テストやシステムテストの重要度が高まる
- 大規模プロジェクトで複数のアジャイルチームを構成するには、その分割点がコンウェイの法則にしたがっているべきである
- アーキテクチャが不充分だと、結局は大規模なシステム全体に精通しないといけなくなり意味がない。
- アジャイルの隆盛と、マイクロサービス化の潮流のタイミングが似ているのは偶然ではない
- チームを分割したためにコミュニケーションコストがオーバーヘッドになるくらいなら、諦めてチームを統合したほうがよい。設計に関する技術的な判断と、チーム組織に対するマネジメントな判断とのトレードオフ
コミュニケーション
- 小さなチームと異なり、全ての情報が口頭伝達でもうまく行く、という期待を捨てなければならない。より多くの作業を文書化しなければならない
- スクラム・オブ・スクラムミーティングにはスクラムマスターよりもプロダクトオーナーを出席させる方が良いだろう
以上の内容はhttps://daiksy.hatenablog.jp/entry/2020/06/21/113348より取得しました。
このページはhttp://font.textar.tv/のウェブフォントを使用してます
不具合報告/要望等はこちらへお願いします。
モバイルやる夫Viewer Ver0.14