2012年8月14日 星期二

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

Source:網路

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

延續"Scrum大師講座 (Emerson Mills)" 那篇所提到的,趁著那次的講座,我問了關於architecture design 的時間點以及必要性,得到的回答是"Do not pre-architecture too mush".....well~至少我知道Scrum派的說法了,不過我心中還是存著疑惑。在討論這個問題前要先解釋,因為其實敏捷式開發還是有分很多支派或方法論,如:
上面所有的方法論共同特色就是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,有興趣的人可以去看軟體架構也可逐步成長

張貼留言