UP與Agile process的比較

以個人經驗提出兩者的差異

• agile使用user story捕捉需求，UP使用use case(文件，不是diagram)
• agile工程師往往一人身兼多職，從design architecture、designer、programmer
• UP並沒有強調是否一人身兼多職，但是往往將腳色獨立出來
• agile很強調Test，不是只有Unit Test還包含ATDD、BTDD
• agile認為文件必須要很精簡，UP則是比較鉅細靡遺
• agile很重視客戶合作，強調客戶需要配合軟體開發
• agile將"關係"維護在人之間，UP則是將關係落實到文件內

現在process其實有些相同的方向是

• Iterative方式
• 重視User Feedback
• 重視需求文件
• Risk driven
• 重視Architecture
• 重視business goal

agile實施起來未必比UP容易，agile裡的programmer往往一人身兼多種腳色，因此agile的programmer往往能力需要比較強，這也是為何早期XP強調pair programming的方式，一方面可以有feedback，另外一方面可以帶起新手

如果今天團隊內有人離職，UP因為將所有內容都記錄在文件上，理論上只要詳讀文件就可以理解，但是agile則是將一些隱含的關係放在人之間，一個programmer離職，恐怕新手只有user story以及code/test code可以讀取，有沒有design...等等的文件，則是看當時狀況

agile將某些資訊放到人之間，有個好處，由於資訊是共享的所以可以減少誤解，同時人在資訊上的更新，某種程度是比文件來的有彈性以及快速

agile最核心的難度恐怕在於改變人，因為過去客戶往往不瞭解他們的需求，同時也不了解軟體開發的一些資訊，客戶認為軟體專案如同販賣機一樣，只要錢投下去，軟體就會跑出來，agile正嘗試改變這一點

最後補上一個軟體工程的V-mode，由於agile很重視test，同時如果理解的話，應該就知道CMMI的 V&V在要求啥了。也就是只要了解軟體工程，自然可以滿足CMMI的Level 2, 3(除了4個跟organization相關的GG之外)

Specification by Example 書摘 (1)

這是一本不錯的書籍，雖然作者整理了一套需求捕捉的方法，但是如果沒有agile process的背景，可能會有點難以理解

Chapter 1.
一個好的需求文件，應該具備底下的優點

• 眾人一致同意的功能
• 精確地描述
• 已完成此功能為目的
• 文件容易改變跟維護

為避免傳統工作上的繁雜，在寫需求文件的時候應該注意下列幾點

• 避免太過詳細且浪費的需求描述
• 文件必須易懂
• 文件必須可以驗證
• 文件要具備一致性以及低成本的特性
• 文件必須符合process的iterations

作者推崇一種稱為Living Documentation System的工具，也就是維護需求捕捉文件的系統概念，不管是word files或者web page...任何其他方式，這是一個要具備以上特色的系統

Chapter 2.
整本書的的需求捕捉架構大體上就被他的圖一言以蔽之，後面都是章節是一些實用技巧

Chapter 3.
作者注重Living Documentation System，他建議必須可以執行ATDD以及BTDD，因為一致性在文件系統很重要，作者使用Testing來維護系統的一致性，做這建議從一開始，需求就必須可以執行(executable)
書中也提到一個普遍性的誤會就是agile process不需要文件!其實這是根本上的錯誤。其實另外一個更廣泛的錯誤就是，開發人員認為環境一直改變，不需要維護需求，這才是更嚴重的問題，所以這樣的開發人員會把agile process當藉口

新的語言特色!!??

java從java 5(or 6)?開始引入一連串的特色，讓我覺得這個語言愈來愈難掌握，愈來愈像是C++翻版:P
從annotation開始，annotation是類似comment，卻可以指使compiler去做一些處理，如果使用過hibernate的人就知道，可以連hibernate原本用來對應DB與java物件之間的xml檔案，全部寫入annotation上
跟著為了溶入generic programming，也就是在C++的template以及STL like的函數，引入了<?>這個符號，generic programming本人可是對他又愛又恨阿，他是非常的powerfull，但是又非常的難以maintain以及extend(對了，有時候還非常難以debug，visual c++ 6.0，光compiler吐出來的message，就根本不能看，更遑論runtime了)，只敢使用STL或者Boost之類，其他人寫出的template lib，我可是十分警戒

後來因為其他需要，我開始使用python之類的語言，好處是十分快速的可以開發出一些prototype，來驗證自己的演算法，即使python的速度大概只能達到C++的1/10，不過如果我用C++開發大概要一個月，python我只要一個星期就搞定了XD 在驗證想法上，python有很大的優勢，只要把速度的問題交給機器去克服:P
在使用python之後，突然我想到了一個問題，為何PHP/Python這類不純粹是OO的語言，可以發展得如此之好，甚至於好過原本Java，不是一直在說OO可以幫忙處理、分析複雜的問題嗎??為何感覺PHP/Python愈發興盛?這意味著有某些是我們沒考慮到的!?這個問題似乎還沒有個終極的答案，我只有把它留在心裡

最近看了一下，java 8的新特色，OMG，開始支援一些PHP/Python的特色，比方說lambda的特色，讓java感覺又為了相容一些functional programming的特色以及generic的特色，"走回頭路"，整個語法亂到了一個極致。在此同時，已也已經披露了OO的一些極限，比方說，在以前(java 6)，你想弄個類似function pointer(C/C++)，必須定義一個介面，走template method或者其他pattern的模式，光為了一個function pointer，必須多出一個interface再多出一個implementation，當然在OO上面有好處，但是在code上面可是多了不少阿

另外上面這些java的新特色，有個幾乎千篇一律的特色就是.....全部是在compiler的時候做手腳，也就是在.java轉換成.class的時候自動產生一些額外的code

回到核心的問題，是否一個語言在與時俱進的時候，必須要弄出一些"不倫不類"的特色，弄了一些code sugar，但是降低了原本的簡潔性?我倒是覺得java乾脆弄出個新的關鍵字，不要再把一些舊有的模式跟新的模式作一種奇怪的搭配，然後用compiler去處理這件事情。我只能說，我對這些新特色十分感冒orz

軟體設計與開發之野人獻曝(2)

我一直在想我有沒有資格寫一篇如何熟悉軟體開發過程的地圖，一直誠惶誠恐，覺得自已不夠資格，不過我換個角度來想，我把我自己的過程寫下來，或許對一些新踏入的人，可以有一些參考作用，就比較釋懷了

誠如會寫軟體未必需要懂得軟體工程，但是軟體工程可以幫助提綱挈領，統籌資料

個人認為的次序是 "軟體工程"=>"軟體流程"，需求捕捉以及分析的工具，還需要"設計工具"(UML/Design pattern/Architecture Design)，最後是"程式工具"(Refectoring)，但是這裡缺乏了專案管理的工具，畢竟市面上太多，懂得流程後，尋找工具或者手動應該會輕鬆得多

軟體工程(統合概念的書籍)

軟體開發流程的書籍 (UP, RUP, agile, scrum)

設計工具 (UML, design pattern, architecture design)

需求捕捉與管理

程式(Code)工具

其他(CMMI)

個人經驗，我是從RUP/UP入手，其實學習過程中，剛好另外一套稱為XP (eXtrem Programming)的學說興起，我個人在心理上比較認同XP(或許是自己是個programmer吧:-> )。使用RUP/UP的過程中，真的開始覺得他非常heavy，每件事情都快要鉅細靡遺，但是我也了解到了一個軟體開發過程中應該要有的大多數的成果(artifacts)

跟著也是一般人都會有的疑問，就是需求捕捉，之前寫得"從user case裡面直接分析出名詞跟動詞接著進入到設計階段"<=這絕對是簡化到誇張的講法，因為一般需要從需求裡面分析出domain model跟著才進化到desgin model

需求分析設計，一個講求what to do，一個講求how to do，但是在what to do之前呢?如何讓人們懂得溝通?一個是住在火星的programmer，一個是住在水星的客戶(business man)，一個只認得code，一個只會寫的一嘴好程式(最常見的需求，我要做的跟XXX網站一樣，XXX請自行帶入yahoo, amazon, 淘寶...)，在上面幾本書有很好的解析，writing effective use cases比較偏重UP/RUP的模式，Sepcification by Example, User Stories Applied則是Agile

至於設計工具GoF的design pattern就不用說了，真的是很多OOD的工具，另外一本Pattern Oriented Software Architecture(簡稱POSA)則是講究Architecture，如果懂得Architecture以及Pattern中間模糊的差異(其實有時候蠻難切開的，比方說broker有時是architecture有時又是pattern)，另外一本Patterns of Enterprise Application Architecture則包含了許多web based的pattern跟架構

其他常用的code工具refatoring則是如何改善code工具，除了改善，我覺得後面另外一個很重要的精神是，不要隨便拋棄code(約爾趣談軟體有提到類似的精神)，但是refactoring有個天生的缺點，很繁瑣，如果沒有自動化工具，我建議把一些類似rename等等太低接的動作捨棄，專注界面的改善比較好

最後是CMMI，CMMI這東西抽象化程度不輸給軟體工程，完全只有給出what to do(工程/流程面相)，沒有how to do(實際執行)，不妨將軟體流程的成果對應到CMMI上面去，因為軟體流程幾乎可以cover CMMI的Level 2跟Level 3，但是很不幸Level 3有四個SG (special goal)是屬於組織流程的，軟體工程無能為力，說實話Level 4跟Level 5我也很難領悟

軟體設計與開發之野人獻曝(1)

發現很多人對於軟體工程嗤之以鼻，或者覺得這是一個象牙塔發展出來的東西，現實專案很少依照這樣的學理發展，我個人倒是認為，軟體工程是提供一個對照，軟體也好、硬體也罷，一定有個生產流程，但是過程中應該產生出來的東西是否被"省略"了

比方說，規格書被省略是最常看到的，軟體好像就從空氣中跑出來了，事實上不是這樣，需求或許未被寫出來，可是他一定留在某些人的腦袋當中

另外一個就是，軟體工程有時太過高度抽象畫，很難落實，或許流程(process)會比較貼近實際，但是流程往往又需要很高的門檻，比方說要熟悉UML(UML只是描述語言，並不是完全依賴於某種流程，反過來倒是很多流程依賴UML)

流程(process)會開始解釋，如何從需求捕捉到系統分析，也就是從what to do到how to do，從抽象的描述到軟體設計開始，如果沒有實際經歷，往往也是落到跟軟體工程一樣的結論，這是一個高階的開發流程，並沒有辦法使用

流程(process)為何比軟體工程更貼近實際呢?因為流程往往綁定特定模式，比方OO，但是軟體工程則是更抽象，喜歡用lisp這種非OO開發也可以，要用OO流程開發也可以，換句話說，軟體工程工過程中省略了某些部分，使得讀者很難連貫跟理解

以RUP為例子，流程(process)會解釋如何從use case的描述之中抽出名詞跟動詞，如何組合名詞跟動詞成為class，在設計的時候會進一步將class抽象成其他class，常見的手法就是套用design pattern。但是如果是The object primer書的agile模式，則是從user story轉換為use case diagram然後慢慢地轉換為class，步驟、方法上跟精神上是有所不同的

因為時間的關係，先簡單寫到這裡，可以看到，要懂得一種process至少知道軟體開發過程，要懂得UML，要懂得design pattern，還要知道某些開發者的角色扮該執行怎樣的工作，所以不是一個簡單的過程，流程(process)也是一種方法論，懂得之後未必需要完全依照執行，但是可以加深取捨的決策。又如我最一開始說的，即使沒有任何需求、設計文獻就落實到了code，但是這些東西是保留在程式設計師或者客戶腦袋中，不落實將會一些效應的存在(比方引進新人員，要花很多工夫在訓練新人融入專案)

軟體工程、軟體開發流程是否需要懂??我說: Everything is about the trade-off.