Modeling in the Agile Age: What to Keep Next to Code to Scale Agile Teams
Scaling Challenges: Productivity, Cost Efficiency, and Microservice Management The main objective of this article is to delve into the technical complexities and strategic adjustments undertaken by Trainline. By examining challenges such as managing peak transaction volumes and orchestrating microservice architectures, we aim to uncover the valuable lessons learned and insights gained from Trainli
アジャイル時代のモデリング: アジャイルチーム拡大のためにはコードの次に何を保つべきなのか
図１．シンプルなスクラム構成 この最小限のフレームワークの中で、チームのインプットとなるのが”ユーザ要求”としての”プロダクトバックログ”です。そして、アウ トプットは”動くソフト ウェア”としてのコード（”製品コード”と”テストコード”）です。 そこには他の設計要素が明示的に現れてはいません。スプリントの中で作られたすべての意図的な設計はチームの財産として実行コートの中に組み込まれるのが 望ましいですが、そこには直接コード化されない情報もあります。スクラムは開発プロセスであり、設計に関しては敢えて何も言及していませんが、設計と設 計活動はチーム内部であいかわらず行われています。 Grady Booch氏は”コー ドは真実ではあるが、すべての事実ではない” と語っています。だから、もしそこにコードで表現又は伝われない情報が残されるとしたら、私達はその情報をどこに格納できるでしょうか？その質
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
