現代軟體工程 構建之法(第六,七章)

2021-08-02 10:23:08 字數 2367 閱讀 1898

這週我閱讀了《構建之法》第六第七章

敏捷開發的原則:

(1)盡早並持續地交付有價值的軟體以滿足顧客的需求;

(2)敏捷流程歡迎需求的變化,並利用這種變化來提高使用者的競爭優勢;

(3)經常發布可用的軟體,發布間隔可以從幾周到幾個月,能短則短;

(4)業務人員和開發人員在專案開發過程中應該每天共同工作;

(5)以有進取心的人為專案核心,充分支援信任他們;

(6)無論團隊內外,面對面的交流始終是最有效的溝通方式;

(7)可用的軟體是衡量專案進展的主要指標;

(8)敏捷流程應能保持可持續的發展。 領導, 團隊和使用者應該能按照目前步調持續合作下去;

(9)只有不斷關注技術和設計才能越來越敏捷;

(10)保持簡明 - 盡可能簡化工作量的技藝 - 極為重要;

(11)只有能自我管理的團隊才能創造優秀的架構, 需求和設計;

(12)時時總結如何提高團隊效率, 並付諸行動。

由scrum軟體開發方**得出的敏捷步驟:

1.找出完成產品需要做的事情。

2.決定當前的衝刺需要解決的事情。

3.衝刺(同時進行每日立會來進行面對面的交流)

4.得到軟體的乙個增量版本,發布給使用者。

敏捷流程的經驗教訓:

1.敏捷宣言表明的是一些優先順序,不必當作聖旨或者教條來爭論。

2.scrum master不是乙個官,而是乙個沒有行政權力的溝通者,就像微軟的pm那樣。他/她同時還要在團隊中做具體的工作。直接把原來的「經理」變成scrum master,大多行不通。

3.一些專案需要很多暗箱操作和政治角力才能搞定,scrum會把這些矛盾都擺到明處。這有好處,也有風險。

4.在複雜的專案裡,讓一線團隊成員做決定。

5.創業公司的團隊其實經常是執行在scrum的模式中(只不過大家太忙,沒工夫論證自己到底有多麼scrum)

6.在scrum計畫階段的估計不是乙個「合同」,領導們不要把它當成乙個合同。估計總是不准的。堅持短期的sprint,這樣即使不准的估計也不會有大的損害。

7.不要和管理層談「流程」,他們只關心「結果」。

8.在大型團隊、跨地區的團隊,或者複雜專案中,scrum並沒有非常完美的答案,scrum的創始人也承認這一點。

msf是微軟解決方案框架,msf的9條基本原則:

1.推動資訊共享與溝通,第乙個原則,就是所有資訊都保留並公開,討論要包括所有涉及的角色,決定要公開並告知所有人。當然,對牽涉到技術機密、安全性等資訊要採取必要的保護措施。

2.為共同的遠景而工作,「共同的遠景」是指產品的遠景。我們做乙個產品,不管是應用軟體、行業軟體,還是通用軟體,要明確專案的目標是什麼。

3.充分授權和信任,在乙個高效的團隊中,所有的成員都應該能得到充分的授權,他們有權在職權範圍內按照自己的承諾完成任務,同時,他們也充分信任其他同事能實現各自的承諾。

4.各司其職,對專案共同負責,在專案進展的過程中,對於每一項任務,每個人都要明確以下幾點。

who:誰負責

what:做什麼,具體的執行方案,什麼叫做「做好了」

when:什麼時候開始,什麼時候結束

why:為什麼是這樣安排(和專案的遠景是否吻合),在什麼情況下可以變更?

5.交付增量的價值,現在的軟體產業,特別是和網際網路相關的產業,變化非常快,使用者希望產品團隊經常提供更新,以適應新的需求。

6.保持敏捷,預期和適應變化,軟體工程,唯一不變的是變化。所以乾脆別幻想客戶的需求會在第一時刻很明確,然後保持不會變。要注意,我們是預期變化,不是期望變化。

7.投資質量,軟體開發過程大部分時間花在了解/設計/變更/再了解/再設計的過程中。我們要重視質量,但並不是要不惜一切代價達到最高的質量標準(有人倒吸了一口涼氣),因為提高人/過程/工具的質量是要花成本的!我們不是為提高質量而提高質量。我們要講投資的效率。比如,在做快速原型的過程中,有些部分可以做得粗糙一點。

8.學習所有的經驗,在學習過去的經驗的同時,也要避免讓過去的經驗妨礙解決現在的問題 。

9.與顧客合作,在專案開發過程中,要一直保持與客戶溝通交流,因為商業價值是由客戶說了算的。

msf的團隊模型:

在msf團隊模型中,任何技術專案都必須達到特定的關鍵質量目標,才能夠被認為是成功的專案。任何乙個角色無法實現其目標,都將危及整個專案。因此,每個角色都被認為是同等重要的,重要的決定都要共同作出。

我認為在乙個專案結束的時候,每個角色都應該問自己這樣的問題——我是否達到了我的質量目標?

msf過程模型:

msf過程模型是從傳統的軟體開發瀑布模型和螺旋模型發展而來的,它把瀑布模型中基於里程碑的規劃優勢與螺旋模型中增量迭代的長處結合了起來。

團隊用里程碑來檢查工作是否結束和同步各個角色的進度,以此來確定當前階段的目標是否已經實現。此外,里程碑標誌著每個階段的結束,此時團隊應該引導成員轉移工作的重心,並鼓勵隊員以新的視角來看待下一階段的目標。

構建之法 現代軟體工程

我理解的軟體工程 軟體工程就是把系統的,有序的,可量化的方法應用到軟體的開發,運營和維護上的過程。軟體工程包含的領域有很多,軟體需求分析,軟體設計,軟體構建,軟體測試和軟體維護。我理解的軟體工程是,這必須需要乙個團隊或者乙個小組合作才能做出優秀的產品,乙個人是不可能完成的。軟體工程並不是我以前理解的...

構建之法現代軟體工程

讀了鄒欣老師著作的 構建之法 以及參考其他眾位大神對於本書的書評後,我獲益匪淺,具體如下 首先我覺得鄒老師這本書看起來很輕鬆,當然不是指沒含量,實則恰恰相反,只是這裡我要更多的突出是另一方面,那就是這本書給讀者營造的氛圍很輕鬆,讓我不知不覺就看了好多頁,內容很豐富,其中有很多的假設,難得的是每乙個假...

初識軟體工程 《構建之法 現代軟體工程》

每次開學都是乙個新的開始。當看到 軟體工程 這四個字時,既熟悉又陌生,熟悉是因為我的專業就是軟體工程,陌生的是他作為一門課程,我不知如何下手。從老師的推薦中,我選擇了這本 構建之法 現代軟體工程 他向我展現了乙個新的世界,讓我有了新的認知,同時也帶來了新的探索。問題 1.對於剛接觸這方面知識的我們,...