Scrum與Architecture是否有矛盾或衝突 (1)

Source:網路

(內心戲小劇場：成長總是會伴隨著破壞，必須先打破舊的價值觀與預設立場，然後透過一連串痛苦的過程，把新舊知識融合、消化、吸收，最後產生屬於自己的東西。)

延續"Scrum大師講座 (Emerson Mills)" 那篇所提到的，趁著那次的講座，我問了關於architecture design 的時間點以及必要性，得到的回答是"Do not pre-architecture too mush".....well~至少我知道Scrum派的說法了，不過我心中還是存著疑惑。在討論這個問題前要先解釋，因為其實敏捷式開發還是有分很多支派或方法論，如：

• Agile Modeling
• Agile Unified Process (AUP)
• Dynamic Systems Development Method (DSDM)
• Essential Unified Process (EssUP)
• Extreme Programming (XP)
• Feature Driven Development (FDD)
• Open Unified Process (OpenUP)
• Scrum
• Velocity tracking
• ICONIX Process (Use Case Driven Object Modeling with UMLTheory and Practice)
  

上面所有的方法論共同特色就是iteration，快速且短期程的交付，然後不斷的重複與持續改善，所以Scrum只是其中一個方法，話 說在學習Scrum之前，我第一次接觸到Agile的方法論是ICONIX Process，主要是結合UML & Use Case driven 的方法論。

不過說實在，自從學了Scrum以後，關於Architecture Design 與 SA&SD 的角色定位，與Design的發動時機點，這些問題以困擾我很久，在公司會議上也常常因為這個議題產生很多的激烈辯論，以我們公司為例，我們比較常見的作法就是開案前，或是開案初期，先由architector和 SD (or senior development)來討論系統架構(包含，定義溝通介面，溝通方式，與溝通流程..等)。而我們最常使用的architecture pattern就是SOA的pattern，所以我們會把每一個service or component 的功能與負責的角色定義出來，每個service 視為一個黑箱子，只先定義黑箱子對外的介面，至於黑箱子裡面要怎麼做，那就交由每個develpoer 自由發揮(之後再分別code review 和重構)。

看起來就像教科書一樣簡單的流程與工作分配方式，但是卻處處充滿了危機，以上面的例子來看 Architecture Design看起來就很重要，但到底Architecture Design 是不是在前期就該規劃好？但是在需求還不明確的狀況下所設計的Architecture是否太薄弱，整個砍掉重練的機會還是很大？

此外很多公司為了讓人員不要閒置，發揮最大產能，Design 允許耗時多久？還是就像Agile一樣，大家領了user story就開始各幹各的，之後再想辦法整起來？(這應該算是另一個極端)所以問題應該是，實行敏捷式開發到底需不需要在前期就預先規劃 Architecture?還是它只是不斷的重構下的最終產物。

為了更加了解Agile(Scrum)對於 Architecture的想法，我上網找了更多的資料，結果發現了更多的歧見~XD

且待我花時間把這些文章消化整理~~

Scrum與Architecture是否有矛盾或衝突 (2)
Scrum與Architecture是否有矛盾或衝突 (3)


Ps. 原來我還在醞釀這篇文章的時候，Teddy大師已經有先幫我解惑了~XD，有興趣的人可以去看軟體架構也可逐步成長。