l

2013年6月26日 星期三

軟體架構也可逐步成長(6):Piecemeal Growth的啟發

June 0 21:37~23:08

image

 

Teddy在《軟體架構也可逐步成長(5):Piecemeal Growth》這一篇未了留下了一個伏筆:

請鄉民們先思考一下,Piecemeal Growth的三個子規則,與軟體開發活動有沒有對應關係?如果有,這些對應關係是什麼?這三條子規則對於平常的軟體開發與架構發展有沒有幫助?

幾天過去了,不知道鄉民們針對以上問題有沒有什麼看法?今天來談討一下將Piecemeal Growth這三條規則應用在Scrum敏捷開發方法中,如何支持軟體架構逐步成長的作法。首先複習一下Alexander幫Piecemeal Growth列出的三條子規則:

  • 任何單一的建築增長計畫規模不可太大。
  • 混合合理大小的建築增長計畫。
  • 建築功能的分配要合理。

***

現在把節目場景轉到Scrum身上,曾經採用過Scrum的鄉民們幾乎都會遇到相同的問題,那就是「在Scrum或是其他敏捷方法中,何時設計軟體架構?」Teddy在《Iteration 0 要幹麼?》介紹過一種「偷吃步」的方法,在專案正式開始之前,先偷偷地安排一段不太長的時間來設計軟體架構。但這種作法許多「敏捷狂熱分子」是不屑採用的,他們不贊成事先安排一段時間來做所謂的專案啟動前的準備。但無論如何,當組織與團隊還「不夠超級敏捷」的時候,實務上iteration 0也不失為一種可行的方案。

另一種理想的狀況是,團隊並沒有事先花費額外的時間來設計或規劃軟體架構,而是靠著一個、一個story的完成,讓軟體架構逐漸慢慢成形。

從以上兩種做法,可以觀察到兩個相衝突的force(作用力)。

  • 只要需求不變,事前花越多的時間設計架構,事後重改的機會就越少。但只要需求改變,有可能導致架構改變,事前設計所花的時間可能就白費了。
  • 因為需求一直在變,所以不要花(太多)時間做事前架構設計。但是讓架構隨著需求實作而慢慢成長,長壞掉需要打掉重做的風險又很高。

問題的關鍵點是,要如何在這兩者之前取得平衡。

***

鄉民甲:看到這邊還是不知道敏捷專案的軟體架構設計和Piecemeal Growth的三條子規則有何關係?

Teddy:恭喜老爺,賀喜夫人,此為正常現象。

請再看一次這三條子規則:

  • 任何單一的建築增長計畫規模不可太大:如果真的需要事前花時間設計軟體架構,那麼「單一回合」所設計出的軟體架構涵蓋範圍不可太大。例如,一個6個月的專案,如果連續花2個月的時間在設計軟體架構上,感覺耗費的時間就太長了。如果每一個為期6個月的開發週期,安排1~2週來決定初始軟體架構的雛形,這樣的大小感覺比較合適。
  • 混合合理大小的建築增長計畫:一個系統設計是好是壞,不光只是由選擇軟體架構這種 「大尺度」的設計決定,還包含模組化與物件導向設計的程度、設計模式的套用這種「中尺度」的設計決定,以及類別設計、函數或方法(method)設計、命名等「小尺度」的設計決定。專案要合理分配花在這三種尺度的設計時間,把全部時間都花在大尺度的「架構設計」,而忽略了模組化或是變數名稱等中、小型設計議題,最終的軟體設計品質也不可能會好。只關注物件導向設計原則、單一類別設計、每個函數要寫幾行、變數怎麼取名等中、小型設計議題,忽略了大的軟體架構,當然整體的設計品質也不可能會好。
  • 建築功能的分配要合理:最後這個概念,有點像是「end-to-end story」的味道(請參考《End-to-end stories:鄉民要求篇》),或是RUP(Rational Unified Process)提到的「Use-Case Driven」的概念(使用案例驅動系統與架構的成長)。翻成白話文就是說,透過完成story的方式來讓軟體架構逐步成長的過程中,story要橫跨架構的每一個層面,不能只涵蓋某一個階層(layer)。換句話說,儘量不要用functional team或component team的方式來成長你的軟體架構(關於functional team的說明,請參考《Scrum框架下的跨界開發(4):分組方式》)。

***

以上,看起來像是天書,但只要經歷過「軟體架構逐步成長」過程的鄉民們,多多少少應該可以體會Teddy解釋的這三點精神。如果還是不行但是又想要學的話,只好等Teddy以後有空開「軟體架構逐步成長設計課程」的時候再來報名了挑眉質疑

***

友藏內心獨白:這種偏門的課,可能要排到民國XXX年。

2 則留言:

  1. 雖然上次在C.C.Agile分享的是逐步成長成功的例子,但也許應該要找些人來分享軟體架構逐步成長失敗的例子,找出問題在哪裡?不然我覺得不相信逐步成長的人依舊不相信。

    回覆刪除
    回覆
    1. 公開增求願意來C. C. Agile分享軟體架構逐步成長的失敗範例...XD

      刪除