軟體工程M1/M2總結

標籤：

已經清楚的問題：1. 什麼是“沒有銀彈”論斷？

      通過閱讀Brooks最著名的這篇文章，我知道了在軟體開發過程裡是沒有萬能的終殺性武器的，只有各種方法綜合運用，才是解決之道。而各種聲稱如何如何神奇的理論或方法，都不是能殺死“軟體危機”這頭人狼的銀彈。在軟體工程中，雖然各種高階語言的使用有效地移除了次要複雜度的問題，但是軟體本身的必要複雜度卻無法被移除掉。就比如我們平常的作業，面向課程中的電梯調度，電梯的狀態變化和各種屬性都必須考慮和實現，如果參考現實生活中的一些實際例子，情況就變得更加複雜。總而言之，要得到一個理想的程式，必須考慮多方面的問題，多人合作開發一個複雜的軟體時，因為每個人的想法各有不同，團隊初期的磨合過程也很費勁。

 

2. 團隊模式和項目的開發模式有什麼關係，怎樣選取效率最高最適合的模式？

• 大教堂模式（The Cathedral model）：原始碼在軟體發行後公開，但在軟體的每個版本開發過程中是由一個專屬的團隊所控管的。作者以GNU Emacs及GCC這兩軟體為例。

• 市集模式（The Bazaar model）：原始碼在開發過程中即在互連網上公開，供人檢視及開發。作者以Linux核心的創始者林納斯·托瓦茲帶領Linux核心的開發為例，亦引用fetchmail的開發為例。

      此篇文章用“大教堂模式”來形容互連網世界裡封閉的、集中式的開發模式（例如最典型的蘋果公司的封閉模式），用“集市模式”形容互連網世界裡並行的、動態多人協同開發模式，從傳統公司角度來看“大教堂模式”顯然更能維護其自身的利益，但如果從軟體開發和IT發展角度來看“集市模式”則是必行之道。

      經過我們小組的討論，我認為，效率較高的做法是，將一個具有價值的集市轉化為大教堂。也就是說，先將一個半成品公開，最後逐步完善形成最終的項目。在轉化的過程中，需要許多因素的推動。初始項目可以是一個不完善的、具有許多缺陷的項目，但是它要有一個項目的雛形，也要具有能吸引投資和人才的價值。大教堂模式雖然品質一般來說較高，但是它所耗費的周期長，市集模式是人數的智慧的疊加，在這方面，市集模式具有更大的競爭潛力。

 

3. 結對程式設計的時候，夥伴的性格等因素對合作的影響。

      具體實踐的時候，我認為夥伴最重要的性格因素是責任感和積極的態度。這兩點對於我們的合作具有非常重要的作用。責任感證明他會按時提交所布置的任務，而積極的態度會影響整個團隊計程車氣。

 

4. 敏捷開發或其他進階方法對於團隊的要求，方式的選取的技巧。

      通過查閱資料，我對這個問題有了更加深入的瞭解。

主要的敏捷方法：極限編程（ XP ）

　　極限編程（ XP ）的主要目的是降低需求變化的成本。它引入一系列優秀的軟體開發方法，並將它們發揮到極致。比如，為了能及時得到使用者的反饋， XP 要求客戶代表每天都必須與Team Dev在一起。同時， XP 要求所有的編程都採用結對程式設計（ pair-programming ）的方式。這種方式是傳統的同行審查（ peer review ）的一種極端表現，或者可以說是它的替代方式。

過程：

　　 XP 定義了一套簡單的開發流程，包括：編寫使用者案例，架構規範，實施規劃，反覆項目計劃，代碼開發，單元測試，驗收測試等等。

思想：

　　像所有其他敏捷方法一樣， XP 預期並積極接受變化。

 

Scrum

　　 Scrum 是一個敏捷開發架構，它由一個開發過程，幾種角色以及一套規範的實施方法組成。它可以被運用於軟體開發，項目維護，也可以被用來作為一種管理敏捷項目的架構。

　　在 Scrum 中，產品需求被定義為產品需求積壓（ product backlogs ）。產品需求積壓可以是使用者案例，獨立的功能描述，技術要求等。所有的產品需求積壓都是從一個簡單的想法開始，並逐步被細化，直到可以被開發。

過程：

　　 Scrum 將開發過程分為多個 Sprint 周期， Sprint 代表一個 2-4 周的開發週期。每個 Sprint 有固定的時間長度。首先，產品需求被分成不同的產品需求積壓條目。然後，在 Sprint 計劃會議（ Sprint planning meeting ）上，最重要或者是最具價值的產品需求積壓被首先安排到下一個 Sprint 周期中。同時，在 Sprint 計劃會上，將會對所有已經分配到 Sprint 周期中的產品需求積壓進行估計，並對每個條目進行設計和任務分配。在 Sprint 周期過程中，這些計劃的產品需求積壓都會被實現並且被充分測試。每天，Team Dev都會進行一次簡短的 Scrum 會議（ Daily Scrum Meeting ）。會議上，每個團隊成員需要彙報各自的進展情況，同時提出目前遇到的各種障礙。每個 Sprint 周期結束後，都會有一個可以被使用的系統交付給客戶，同時進行 Sprint 審查會議（ Sprint review meeting ）。審查會上，Team Dev將會向客戶或終端使用者示範新的系統功能。同時，客戶會提出意見以及一些需求變化。這些可以以新的產品需求積壓的形式保留下來，並在隨後的 Sprint 周期中得以實現。 Sprint 回顧會隨後會總結上次 Sprint 周期中有哪些不足需要改進，以及有哪些值得肯定的方面。最後整個過程將從頭開始，開始一個新的 Sprint 計劃會議。

角色：

Scrum 定義了 4 種主要的角色：

Ø       產品擁有者（ Product Owner ）：該角色負責產品的遠景規劃，平衡所有利益相關者（ stakeholder ）的利益，同時確定產品需求積壓的優先順序等。它是Team Dev和客戶或終端使用者之間的聯絡點。

Ø       利益相關者（ Stakeholder ）：該角色與產品之間有直接的利益關係，通常也是由客戶或終端使用者代表組成。他們負責收集編寫產品需求，審查項目成果等。

Ø       Scrum 專家（ Scrum Master ）： Scrum 專家負責指導Team Dev進行 Scrum 開發與實踐。它是Team Dev與產品擁有者之間交流的聯絡點。

Ø       團隊成員（ Team Member ）：即為項目做實際開發工作的開發人員。

　　 Scrum 提供一個敏捷開發架構，其他許多敏捷方法都可以被整合到 Scrum 中。比如測試驅動開發（ test-driven development ）和結對程式設計（ pair programming ）等都可以被整合到 Scrum 中。

 

精益開發（ Lean Development ）

　　精益軟體開發模式是從豐田公司的產品系統開發方法中演化而來。它主要包括兩個部分：一部分是核心思想及原則，另外一部分由一些在相應的工具構成。

　　精益開發的核心思想是查明和消除浪費。在軟體開發過程中，錯誤（ bugs ），沒用的功能，等待以及其他任何對實現結果沒有益處的東西都是浪費。浪費及其源頭必須被分析查明，然後設法制止。

　　精益軟體更重要的是不斷完善開發過程的一種思維方式。因此，將精益模式與其他敏捷開發模式一起使用將會取得很好的效果。

 

如何選擇一種敏捷方法：

　　選擇一種合適的方法取決於多種因素。在做出決定之前，我們需要充分考慮以下這些方面：

Ø       方法的複雜度。確保團隊或組織能夠應付這種複雜度。

Ø       社區支援。流行的方法可能並不是你最理想的選擇，但流行的方法至少有較多的社區及行業支援，可以使你受益匪淺。

Ø       工具 + 生產力。選擇一種可以為你提供許多支援工具的方法。一個良好的自動化工具可以協助團隊有效處理日常工作，促進團隊協作，並減少管理成本。

Ø       你目前的開發方式和你目前團隊關于敏捷方法的認識程度。選擇一些與你當前開發方式比較接近的敏捷方法將有助於推動該方法的實施。

Ø       你的團隊規模。較小規模的團隊最好從簡單的方式入手。當然，這並不意味著你必須選擇那些本身就比較簡單的方法如 Crystal Clear 。你可以選擇一些相對比較全面的方法，但從簡單入手。當你的團隊規模逐漸擴大，再增加相應的細節。

Ø       你不需要只遵從一種方法。你可以為團隊選擇一個主要的方法（如 Scrum ），然後從其他方法中借鑒對你的團隊或組織有所協助的其他方式加以整合。

敏捷總是在不斷髮展演變，因此，沒有一個人能保證目前的敏捷方法都是正確的。每個採用敏捷開發的團隊都可以通過發現並形成自己的想法和最佳實務，對敏捷開發做出自己的貢獻。

 

仍有疑問的問題

      我們對於Scurm meeting的示範流程，比較流於形式化，我今天做了什嗎？明天準備做什嗎？有什麼問題……所以仍然希望能夠知道有沒有更加高效、科學的開會方式。

 

新的問題

      1、關於代碼風格，每個人有不同的風格，如何能夠更好地將它們整合到一起？是否要在項目初期要求一個統一的代碼規範？

      2、在團隊協作的過程中，通過一個什麼樣的機制才能調動大家的積極性？

      3、怎樣才能讓項目組的每一名成員都找到適合自己的工作崗位，使他能發揮他的最大價值？項目分工按照什麼依據才能更加科學？

 

關於8篇軟體工程相關的論文或部落格的新體會

      軟體工程包括三個要素：方法、工具和過程。

      關於軟體工程，關於團隊合作，在以上許多種疑問的解答中，永遠逃不開方法的選取和規則的定義。如同Linux和蘋果系統，它們的開發模式完全不同，然而最終結果卻殊途同 歸，不是所有的“好”方法都適合自己，也就是說，選擇一個“適合”的方法才會對項目有很大助力。同時，管理也是非常重要的一個環節，好的管理團隊的方式在某種意義上來說也是統籌全域的一個表現。

 

在項目的 需求/設計/實現/測試/發布/維護 階段中都學到了什麼 “知識點”

Ø       需求：NABCD模型需求分析方法 

Ø       設計：從功能需求抽象成圖形建模，循序漸進

Ø       實現：敏捷編程、大教堂與市集開發模式

Ø       測試：黑箱和白箱

Ø       發布：盡量在更多的平台上發布軟體，收取更多的使用者反饋

Ø       維護：結構化維護，從設計文檔開始著手修改與複審

 

部落格連結：

http://www.cnblogs.com/yuccalan/p/4826577.html

軟體工程M1/M2總結