敏捷方法- 軟體業新思維
台灣軟體業積弱不振, 可能因思維較舊所致:
含程式)，構成龐大負擔，常導致很多溝通不準或思考不週之處 (即 Bugs)。有些公司製作不少文件卻乏人閱讀，全無溝通之效；甚 或冀望多年後維修程式時，將會閱讀文件，殊不知程式是不斷變動的，文件更新常趕不上變動的。
敏捷方法視開發為合作活動(如攀岩)，力求以面對面直接溝通，來取代目前文件製作及閱讀的間接溝通，使開發變得快而準(即 agile)。 又，敏捷方法以測試來帶動開發 (Test-driven development)，軟體品質極佳。
最後，除國外重視的溝通訓練外，吾人亦加強國人不足的思考訓練，溝通及思考乃深層基本功；–練功後人人紮實、軟體優質，再用逆向工程工具動態產生class diagram, sequence diagram等，有可能敏捷達 成CMMI 一些process areas 的 goals。 此敏捷方法係陳振炎教授擴充極限開發法 (extreme programming)而得，方法細節請見下面網站的上課教材：敏捷方法苗圃 (www.agilemethod.csie.ncu.edu.tw )
- 工廠思維: 軟體工程在 1968 NATO 大會出現時, 仿效其他工程領域, 把軟體視為工廠生產, 講求精細分工 嚴格控管 注意產量成本等. 但新趨勢是, 軟體講求創意及合作, 像 工藝家聯合工作室, 而不像工廠.
- 電機思維: 軟體本由電機電子而來, 從The Institute of Electrical and Electronic Engineers, Inc, IEEE 這代表性機構的名稱, 即可看出此沿革, 但演進至今, 軟體已與電機無關.
敏捷方法視開發為合作活動(如攀岩)，力求以面對面直接溝通，
最後，除國外重視的溝通訓練外，吾人亦加強國人不足的思考訓練，
陳振炎教授
國立中央大學資訊工程系
拜讀宏文，感覺提倡敏捷方法對發展台灣的軟體工業或有相當助益，不過要了解敏捷方法，不論是XP，TDD及其他方法，須先深入了解「敏捷宣言」(Agile Manifesto)的精神與哲學，否則無法了解敏捷方法的精髄，這一點文中似未著墨。敏捷方法的重點在於程式撰寫與測試上，這一點我認為須予延伸論述，撰寫程式在軟體工程發展軌跡上其抽象層次較低，因此有人提出結合agility與MDA，即所謂Agile MDA，Agile MDA主要是將模式視同程式，可用來執行，這個觀念解決不少(但非全部)軟工的問題，Agility可帶來effectiveness，而MDA可帶來efficiency，兩者結合可「活化」需求，這是最大的好處，我在「漫談模式驅動架構」三篇輕鬆談中曾有論及，另外agility對於軟體管理也有相當助益，這一點將來應有所討論，不知振炎兄可認同否？
回覆刪除我們會聽到這樣的話："Agile development is a philosophy, not a methodology, but a set of values and principles."
回覆刪除除非我們能夠瞭解並認同Agile方法的『精神』，否則 "just following a methodology" 可能對開發者而言沒有太大的幫助。如果不知道 agile methodologies中的程序背後的理由，那麼走極端可能又回到"code-and-fix"的『方法』了。
敏捷宣言確實揭開了軟工新時代 其背後的精髓就是: 溝通 這觀念用在 model driven architecture (MDA) 就叫 agile MDA
回覆刪除依這觀念工作 人的思考方式與古早時 code and fix 是截然不同的
當你/妳要使用XP，TDD，Srum等敏捷方法時，腦袋必須常常想到敏捷宣言的精神，其中『溝通』只是其中第三項："Customer collaboration ‧‧‧"，由敏捷宣言引伸出12項「施行細則」更明白宣言的精神。Agility基本的『座右銘』(motto)就是"embrace change"(Kent Beck之言)，也就是迅速而且彈性反應變更，再說如何迅速且彈性反應，據我所知，MDA是最有效而且安全的方法，因此我說Agile MDA可活化需求(live requirements)。我不太同意『溝通』用在MDA就是Agile MDA，因為MDA並非敏捷方法，它只不過能幫助敏捷方法容易達到『敏捷』的有效率的良方，之所以如此，請參考「漫談模式驅動架構(一)，(二)，(三)」。
回覆刪除由於陳教授認為軟體業績不振，乃因思維陳舊所致，本人十分認同這種說法，其原因可能許多人以「過程為中心」(process-centric)的發展思維所致，如果發展者，尤其管理者堅持這種思維，則可能產生所謂「隧道觀點」(tunnel-view)，人們會忽略追縱建造系統的目標，無法有效率地符合客戶需求，因此敏捷方法的構想應該在於如何協助「人」而非「流程」，這是敏捷宣言最重要的一點，因此只要秉持"people over process"的精神，任何敏捷方法只要符合專案之需都是良方。在這個「意見」中我兩處使用可能語氣，一來我不十分確定我的觀點是否正確，二來希望能拋磚引玉，大家來輕鬆談陳教授所謂「軟體業新思維」這個嚴肅的議題。
回覆刪除