[討論] 台灣敏捷方法實務研討會

看板Programming作者ggg12345 (ggg)時間18年前 (2007/06/16 07:55)推噓0(1推 1噓 0→)

留言2則, 2人參與討論串1/1

: ※ 引述《yellowpeach (端)》之銘言： .... : : 中壢市中央大學工程五館 A207室 : : 台灣軟體業積弱不振，是大家心中的痛。其中固然有市場行銷面的困難，然而 : : 工程品質普遍低落，卻也是不爭的事實。 : : 如何提升品質？近年的敏捷方法(Agile Method)強調：開發團隊(含客戶)溝通 : : 要快而準。又，國內業界有工廠觀念，只重視產量增加、成本降低，卻不追求思考品 : : 質的提升；其實要重視：開發者個人思考要深且密。這整個觀念會形成：測試帶動的 : : 開發(Test-driven development)。 =========================================================================== =有去聽的請發表一下心得. =講得很不錯, 雖然慢了一個鐘頭才進去, 但到結束都沒睡著. = =首先, 覺得陳教授的演講跟底下拿來比對討論的這篇文章所講的方法流派很接近 ! = =http://www.ithome.com.tw/itadm/article.php?c=39401&s=1 = ========================================================================== XP訴求以最佳智慧做出客戶最想要的東西敏捷軟體開發聯盟宣言 ● 個人及互動勝於流程和工具 ● 可用的軟體勝於詳盡的文件 ● 與客戶合作勝於合約談判 ● 回應變更勝於墨守計畫導入XP（eXtreme Programming，極限製程）的第一步就是拿起扳手與螺絲起子，動手拆隔板，因為XP強調的溝通、簡單、回饋與決心這4個價值觀，以及12項實務，主要精神說穿了就是貫徹「溝通」兩字。 XP是以少數人力在短時間開發系統的方式，適合2～12人的開發團隊，特別適合應用在需求經常改變的領域，因為需求的不確定性，所以相當重視客戶在開發過程所扮演的角色。管理者、客戶及開發人員對XP而言，都是專案的成員，必須透過充分的溝通與回饋，讓每個成員了解目前的版本能否滿足需求。 12項實務貫穿XP的核心精神－溝通仔細研究XP，會發現以下12項實務多數只是為了達到充分溝通的手段： 1. 客戶駐廠：為方便隨時隨地的溝通，因此客戶必須駐廠，即時地回饋意見，並確認目前的版本能否符合需求。 2. 系統隱喻：XP並沒有系統分析師（SA）、系統設計師（SD）與程式開發人員等區別，每個人都扮演SA、SD和程式開發者的角色，直接跳過需求分析的階段，藉由客戶駐點面對面溝通的方式，取得第一手的需求，並直接做給客戶看，目的是為了做出符合客戶真正想要的東西。而隱喻是為了讓客戶與開發者以共通的語言，確保彼此的溝通沒有誤解。以實際的比喻或故事，取代冗長而難以理解的文件，比喻可以與IT無關。例如說明授權機制可以舉實際生活的例子說明：一棟房子有很多層樓，每一層又很多房間，而某人的鑰匙只能開啟9樓A室的房間。總之盡量以易於了解的方式，表達需要的功能。 ========================================================================== =聽了陳教授的演講, 提到了 on site user expert , 這位專家是 acceptance test =與 object interface 的關鍵人物. = =討論時, 有人問道: 少了 SA SD 甚至沒有 Architect , PM 對目前的台灣業界怎麼 =能接受導入 ? = =不曉得 customer(買方)可不可以另外獨立雇用某家(甚至是同一家)公司不寫程式的 =Architect/PM/SA/SD 之一當 on site customer expert 專門溝通買方使用人員替買 =方決定 GUI 界面. = =至於使用隱喻還是明示的需求目標, 純脆就是買方是否要透過 on site customer =expert 透露其使用機密(例如軍事用途)而已. 而需求不講是不可能透過溝通讓開發 =者做出期望中的功能. =========================================================================== 3. 通盤規畫：透過使用案例（User Story）發掘與評估需求，並在卡片（Story Card）寫上對需求的描述，讓開發者得以根據客戶的描述切割工作量，並確保在穩定的周期內，發布新的版本。 4. 小階段發行：依據Story Card切割工作，分階段發行新版本，而且必須是可執行的版本。 5. 簡單設計：今天的需求可能明天就改變，預留彈性反而是包袱，而且環境與技術都會改變，因此不去預想未來可能的功能，盡可能保持符合需求的最簡單版本。 ============================================================================ =基本上, 初期應該是只有全案的大體樣子與概略目標, 排程是且戰且走在依負荷與時間 =的緊迫性與代價上適當調整的. = =提前完工或讓買方逐期導入試用, 似乎是可以進一步發揮的地方. 讓 Architect 或 =PM 站在買方甚至當監工是一種合乎實務的創舉. = =開發者此時比較像工程的承包者, 開發者的賣方也可以形成有一個會寫程式的包工頭, =依某段工期的工作量動態加減人手, 新增人手的溝通與任務指派一定是由工頭負責. =========================================================================== 6. 測試先行：XP的創始者Kent Beck提出的測試哲學，包括單元測試與整合測試。單元測試由開發者在撰寫系統程式前先寫測試程式，所以專案應有25~50%的時間是開發測試程式；而整合測試才是由測試人員負責。 7. 編程標準化：包括命名原則、編碼風格、函數、類別設計、繼承、運算符號等，設定一致的表現方式，提高程式的可讀性，將有助於改善軟體品質、提高開發效率並簡化維護工作。 8. 重構：在每個小階段發行、每個往覆式（Iteration）的周期後，甚至是每天下班前都可以執行一次重構，以保持程式碼的乾淨、簡單且具表達性。 9. 搭檔編程：兩個人共同開發一隻程式，一個人寫程式，另一個人看程式，檢視是否有錯誤或可改進的地方。兩人經常互換角色，這麼做的目的，是藉由充分的溝通與交流提升團隊整體的能力。 10. 共同維護：搭檔編程的搭檔關係，也需要經常替換（Switch Pair），讓每個人都可以維護系統的每個部分。 11. 持續整合：在開發期間，每一組搭檔可以隨時在測試過後，將程式簽入整合至系統，並諮詢其他搭檔執行所有測試，所以XP一天可能建構系統好幾次。 12. 每周40工時：為避免精疲力盡，XP希望以持久穩定的步調，維持高品質的工作效率，不借用明天的精力，強求在今天多完成一些工作，因此XP不允許團隊超時工作。唯一可以超時工作的例外，是發行前的最後一周，做最後的衝刺。測試先行應該就是在逼迫開發者進行 SA SD 與文件記敘的工作, 甚至是透過 data test 樣例來展現可讀性的文件. 除了是為了應付各種變動的彈性外, 她可以讓開發方的 source program 的行數大量增加, 可以在程式的價值感上增加品質價值. 測試驅動的開發流程 XP之類的敏捷開發方法論，其輕巧特質，頗受開發者認同，然而大家著眼於其簡單設計與靈活因應需求改變的主張，卻往往忽略XP是測試驅動（Test Driven）的開發方法論，「測試」是必要的條件，若未撰寫測試程式，便不算是XP。需求恆變是許多專案團隊抱怨的問題，然而XP的建議是擁抱改變，測試案例的目的，就是為了因應改變。以XP的經驗來看，透過錄製使用者介面的操作劇情，所執行的測試太過脆弱，系統底層很多功能與使用者介面無關，可能導致測試的漏洞，而建置健全的測試案例將使專案無懼改變。未著手寫程式前，如何寫測試「程式」的程式？事實上，寫測試程式本身就是在進行系統的細部設計，寫測試程式前，必須決定Class（類別）的命名、參數為何、功能為何等。從測試的角度分析，叫用者（Caller）的觀點將多於開發者觀點，有助於設計更彈性、易用及簡潔的系統。而先寫程式再寫測試的問題，在於開發完成後，團隊往往會缺乏動力，而且可能因為遺漏，使得有些程式沒有測試到，或者也可能將測試寫得太複雜。強調不拘型式的文件 XP的「文件無用論」廣受IT界爭議：一個沒有文件的專案，後續的維護性令人質疑。其實XP有文件，而且是不拘型式的文件，以「Story Card」說故事打比方、畫UML圖、拍下白板上畫好架構的圖，甚至手繪的各種圖或文，都可以是文件的一種。更重要的是，軟體會變，文件會過時，所以最好的文件是程式碼。為了讓程式擁有像文件一樣的可讀性，所以必須落實編程標準化，以同樣的風格撰寫程式，才能降低對文件的依賴性。 ======================================================================== = =聽完講習再對照看此篇文章, 感覺上這個流派的做法是: =1.像人月神話提到的外科手術式團隊 =2.On site customer/GUI expert 是買方執行委外的關鍵人物. =3.測試先行是強迫先分析, 查看各種 case , 進行資料化的文件說明. =4.動態排程可以隨時考量是否可以加派 "無關人手(指不必太多溝通就能進行的 = 工作)" 縮短工期. =5.這是一種各自委外, 專業分工的做法 ! ======================================================================== BUT...12項實務必須面臨現實環境的考驗盲目套用XP可能導致專案的成本難以估算，反而增加團隊的痛苦指數。條件1：成員個個是高手人的素質是影響XP最關鍵的因素，團隊要有經驗，否則有很多實務將流於形式，例如搭檔編程實際執行起來，負責看程式碼的人很容易會發呆或做別的事情，就算認真看，既然已經編程標準化，理論上能發揮的創新作法將大幅減少，因此未必能夠提出更好的建議。唯有雙方都是高手，才有可能激盪出令人讚嘆的火花。此外，Stand Up會議的用意是希望簡短而有效率地達到溝通的目的，最好在10~15分鐘以內結束會議。若人員的素質參差不齊，對意念的表達沒有默契，只要有人提出不同的意見，將展開冗長的討論，致使會議無法於短時間內落幕。重構對程式做分析變動以提升程式的品質，但對於閱歷不深的工程師，可能輕忽事前設計的重要性。任何技術上的說法，都必須有基本假設，雖然重構的精神是「不妨先動手」，但若草率行事，代價很高。條件2：切割適當的版本 XP要求2～3周演化一個新的版本，若系統的複雜度高，或版本切割不當，加入新的需求後，影響的範圍可能很大，將使重構與演化的進度遙遙無期，始終看不到結果的情況，對成員的信心打擊很大。就企業的立場來看，開發周期拖長，成本將越墊越高，產品可能錯失市場先機，造成更大的損失。條件3：適合需求不明確，卻希望提早看到東西的創新產品小版本發行的概念，適合需求尚在發散的方案，專案的時程壓力較大，若需求不明確，便難以估算成本。因此無論企業或資訊廠商，都寧願在清楚分析與定義需求的情況下承接專案，因此XP較少應用於專案的開發。若是仍在演化中的創新產品，希望提前看到東西，並進一步評估未來的走向，以利盡早投入市場試水溫，便很適合採用XP。開放源碼就是以這種「永遠的Beta版」開發出使用者真正想要的產品。 =========================================================================== =這是強調專業精英的思惟, 對於人口大國, 先天上她有一定的比率的精英, 她可以很 =快形成包工/代工的聚落效應, 不過, 這會是技術個人主義與 System Architect 間 =的爭鬥矛盾. = =軟工一直就是未能達到建築設計, 監工, 工程施工三者分離的程度 . =========================================================================== -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 140.115.5.81 ※ 編輯: ggg12345 來自: 140.115.5.81 (06/16 08:01)