敏捷開發(fā)流程與方法(參考版)
2025-05-06 18:43本頁面
【正文】 當(dāng)對系統(tǒng)結(jié)構(gòu)進(jìn)行大的調(diào)整時(shí)，如果沒有測試驅(qū)動輔助的話，那么可控性就會很差，這不能叫做重構(gòu)。 誤區(qū)四 :為了敏捷而敏捷 ? 重做不等于重構(gòu)，很多場合這兩個(gè)概念是混淆的。忘了以前是在哪兒看的大師采訪錄： ? Q：“我們現(xiàn)有的過程很好，不知道怎么用敏捷改進(jìn) ?” ? A：“既然很好，那就不要用敏捷”。 ? 文檔不是目的，有效溝通才是目的。 ? 因此，在實(shí)施敏捷的時(shí)候，需要在團(tuán)隊(duì)內(nèi)明確哪些知識是必須顯性的，這些知識可以通過文檔交流。 ? 應(yīng)該清楚文檔的本質(zhì)是把知識顯性化。 ? 文檔只是為了達(dá)成目標(biāo)的一種手段，如果這種手段是低效的，那就換一種手段。讓開發(fā)人員理解并實(shí)施，體驗(yàn)到敏捷的好處，而不是盲目機(jī)械地實(shí)施規(guī)范。 ? 把人的能動性調(diào)動起來，給動力而不是給壓力。這也是敏捷在國內(nèi)實(shí)施的最大障礙： ? 把客戶當(dāng)作合作伙伴而不是對手，從客戶角度出發(fā)去想問題，充分的跟客戶溝通，而不是出了問題推諉責(zé)任。 誤區(qū)二 :敏捷僅是個(gè)軟件過程 ? 敏捷相對以前的軟件工程最大的革新之處在于把人的作用提高到了過程至上，正如敏捷宣言的第一條“個(gè)體和交互勝過過程和工具”所說的。 7. 每一次 Sprint之后要 review，團(tuán)隊(duì)按照既定的 Sprint Backlog目標(biāo)來演示完成的內(nèi)容。 Scrum會議不同于項(xiàng)目會議，對團(tuán)隊(duì)來說，它起到了快速簡報(bào)的作用。 在這個(gè) 15分鐘的會議上， Scrum Master會詢問每個(gè)成員三個(gè)問題 : a) 自上次 Scrum會議后的 1天里你做了什么？ b) 從現(xiàn)在到下次 Scrum會議的 1天時(shí)間里你準(zhǔn)備做什么？ c) 你在工作中遇到了哪些困難？ 每個(gè)成員在 Backlog條目上所花費(fèi)的時(shí)間會被記錄到 Spring backlog中。 4. Scrum會議 : 這是與傳統(tǒng)方式最大的區(qū)別，每天 1520分鐘的 Scrum會議，通常在每天的同一時(shí)間和同一個(gè)房間內(nèi)舉行。 3. Sprint(沖刺 ): 通常為 30天的迭代時(shí)間，把 Backlog中的每一項(xiàng)安排在 Sprint中，由團(tuán)隊(duì)估算出所需要的時(shí)間（按小時(shí)記）。 SCRUM的過程圖 SCRUM實(shí)踐 1. Scrum團(tuán)隊(duì)： 57個(gè)人的小項(xiàng)目團(tuán)隊(duì)， 團(tuán)隊(duì)的負(fù)責(zé)人可能擔(dān)負(fù)起 Scrum Master的角色。 Scrum于 1995年提出，并在 2022年同其他方法論一起組成“敏捷聯(lián)盟（ Agile Alliance）” 。這一過程是迅速，有適應(yīng)性，自組織的，它代表了從順序開發(fā)過程以來的重大變化。 ” ? Scrum提供了一種經(jīng)驗(yàn)方法，它使得團(tuán)隊(duì)成員能夠獨(dú)立地，集中地在創(chuàng)造性的環(huán)境下工作。 ? 結(jié)對的編程比單獨(dú)編程更有效。 ? 改變各對的組合在可以在團(tuán)隊(duì)范圍內(nèi)傳播知識。 ? 至少有兩個(gè)人熟悉系統(tǒng)的每一部分。它們只不過需要盡可能簡單，但是仍能工作。我們總是先嘗試使用能夠工作的最簡單的設(shè)計(jì)，然后隨著現(xiàn)實(shí)的不斷顯現(xiàn)來更改它。 ? 構(gòu)對設(shè)計(jì)進(jìn)行優(yōu)化。 ? 以后的迭代過程，是在反饋和編程的基礎(chǔ)上做交互式設(shè)計(jì)，減少了設(shè)計(jì)的投機(jī)性。 需求 分析 設(shè)計(jì) 編碼 測試 集成 使用和維護(hù) Planned Design XP Design 變化導(dǎo)致的成本增加 軟件研發(fā) 異動曲線 編程方法 3:簡單設(shè)計(jì) 標(biāo)準(zhǔn) (依重要性 )：通過所有測試，可讀性高的代碼，避免重復(fù)，最少數(shù)量的類別或方法。 編程方法 3:簡單設(shè)計(jì) ? 簡單設(shè)計(jì) Do the simplest thing that could possibly work； You aren’t going to need it ? 如果沒有它和眾多慣例規(guī)則之間的耦合， XP的演化設(shè)計(jì)就蛻化成 CODEFIX。 在 Metaphor指引下的重構(gòu)，是為商業(yè)模型服務(wù)的。 可以根據(jù)需要，將一個(gè)迭代的全部目標(biāo)定為重構(gòu)。 XP提倡毫不留情的重構(gòu) (Refactor mercilessly)。 ” Kent Beck 8:00 AM Standup Meeting Pair Up Tester 自我測試 編碼 重構(gòu) 集成并納入 CI 驗(yàn)證 5:30PM 結(jié)束 測試用例 編程方法 編程方法 1:測試驅(qū)動開發(fā) (TDD) 失敗 通過 時(shí)間 單元測試 100% 通過 設(shè)計(jì) 先 寫 單元測試 重構(gòu) 運(yùn)行 單元測試 編程 發(fā)現(xiàn) BUG 集成 先 寫 功能測試 User Story 運(yùn)行 功能測試 編程方法 2:重構(gòu) (Refactoring ) 減少重復(fù)設(shè)計(jì)，優(yōu)化設(shè)計(jì)
電大資料相關(guān)推薦
鄂ICP備17016276號-1