軟件工程發(fā)展歷史上, 當(dāng)軟件變得越來越復(fù)雜時, 規(guī)模變得越來越大時, 失敗的機率由此遞增, 許多項目一再延期, 軟件工程應(yīng)運而生, 人們希望向建筑工程, 機械工程那樣來定義和規(guī)范軟件工程.
很難說在軟件行業(yè)的過去流行一些做法不好, 軟件工程中大部分理論都是對的, 但是由于軟件本身所具有的復(fù)雜性和多變性, 僵化的流程, 硬性的規(guī)定難以適用所有的場景.
所以既然唯一不變的是變化本身. 我們的流程和方法也應(yīng)該是著重于應(yīng)對變化.
這里簡單回顧一下我所經(jīng)歷的軟件工程向敏捷過渡的過程.
軟件開發(fā)一般有如下方法
- 1.編碼修復(fù)方法Code-fix: 邊寫邊改
- 2.瀑布式方法Waterfall: 概念-需求-設(shè)計-編碼-測試
- 3.進(jìn)化式原型化方法Evolutionary Prototypeing:迭代開發(fā)
- 4.分布交付方法Staged Delivery:
- 5.RUP方法: www.rational.com
- 6.MSF方法(Microsoft Solutions Framework): www.microsoft.com/business/services/mcsmsf.asp
- 7.敏捷方法: XP, FD, Scrum, ASD,DSDM,etc. 里程碑: FC,CC,CF,ER XP:http://www.extremeprogramming.org/
瀑布方法
我所在的公司中曾經(jīng)長期施行一套軟件工程周期方法 ERCM - Engineering Release Cycle Methodology
將軟件開發(fā)過程分為需求分析, 設(shè)計,編碼,測試等過程, 并以里程碑 milestone 來管理
共用如下里程碑
- RC - Requirements Complete: 需求完成, 各方簽署同意需求文檔 (PRD/UI sign-off)
- DC - Design Complete: 設(shè)計完成, 各方簽署同意設(shè)計文檔 (Design Spec sign-off)
- FC - Feature Complete: 功能完成, 單元測試完成
- CC - Code Complete: 代碼完成, 集成測試完成
- CF - Code Freeze: 代碼凍結(jié), 沒有遺留嚴(yán)重的 bug
- ER - Engineering Release: 工程項目正式發(fā)布
這套方法執(zhí)行了若干年, 行之有效, 但是隨著市場的變化, 競爭的激烈, 需求變化變更頻繁, 它的問題暴露得愈加明顯, 往往前松后緊, 不能及時的應(yīng)對變化, 一旦在設(shè)計完成之后發(fā)生變化, 就會打亂原來井井有條的流程. 更要命的是, 在項目后期發(fā)現(xiàn)設(shè)計有重大缺陷, 或者與需求大相徑庭, 需要推倒重來, 卻發(fā)現(xiàn)時間已經(jīng)遠(yuǎn)遠(yuǎn)不夠了, 只能加班.
所以, 軟件從業(yè)者逐漸認(rèn)識到, 一次就全部想好,想周全, 并在項目開發(fā)過程中不再修改需求和設(shè)計, 幾乎是一個不可能完成的美好夢想, 迭代式開發(fā), 逐漸更新完善軟件才是正道
IBM 公司為此提出了一套堪為完整的開發(fā)流程 RUP - Rational Unify Process
在
簡單來說, 有四個階段:
- 初始階段 Inception
- 細(xì)化階段 Elaboration
- 構(gòu)建階段 Construction
- 發(fā)布階段 Transition
六個最佳實踐:
- 1 迭代式開發(fā)
事先了解所有需求當(dāng)然最好, 但是通常辦不到, 分階段增量式迭代開發(fā)的方案可降低返工成本
- 2 管理需求
永遠(yuǎn)銘記是用戶設(shè)定需求, 可以引領(lǐng)和分析, 不可臆測, 需求應(yīng)該有優(yōu)先級, 有清晰的驗收標(biāo)準(zhǔn)
- 3 使用組件
將整個系統(tǒng)拆分成組件, 在集成之前進(jìn)行組件測試, 模塊化的面向?qū)ο缶幊桃灿欣诖a重用
- 4 可視化建模
用圖表來表示所有主要的組件,用戶, 和它們之間的交互, 比如UML 和簡單的框圖
- 5 驗證質(zhì)量
用單元測試, 集成測試, 端到端的測試, 以及度量分析來充分驗證質(zhì)量
- 6 控制變化
唯一不變的是變化, 變化對于項目應(yīng)該是漸進(jìn)的,可控的
敏捷方法
敏捷是一種方法, 代表一種精神, 讓事情變得簡單高效, 就象 XP 創(chuàng)始人 Kent Back 所說的快速地?fù)肀ё兓?/p>
所以敏捷的精神在于快速的應(yīng)對變化, 告別冗長的流程, 專注于提供對于用戶有價值的軟件.
先回顧一下敏捷宣言及其提倡的原則
Agile Manifesto 敏捷開發(fā)宣言
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
- Individuals and interactions over Processes and tools
- Working software over Comprehensive documentation
- Customer collaboration over Contract negotiation
- Responding to change over Following a plan
That is, while there is value in the items on the right, we value the items on the left more.
我們一直在實踐中探尋更好的軟件開發(fā)方法，
身體力行的同時也幫助他人。由此我們建立了如下價值觀：
個體和互動 高于 流程和工具
工作的軟件 高于 詳盡的文檔
客戶合作 高于 合同談判
響應(yīng)變化 高于 遵循計劃
也就是說，盡管右項有其價值，
我們更重視左項的價值。
Agile principles 敏捷開發(fā)原則
The Agile Manifesto is based on twelve principles
- Customer satisfaction by rapid delivery of useful software
- Welcome changing requirements, even late in development
- Working software is delivered frequently (weeks rather than months)
- Close, daily cooperation between business people and developers
Projects are built around motivated individuals, who should be trusted- Face-to-face conversation is the best form of communication (co-location)
- Working software is the principal measure of progress
- Sustainable development, able to maintain a constant pace
- Continuous attention to technical excellence and good design
- Simplicity—the art of maximizing the amount of work not done—is essential
- Self-organizing teams
- Regular adaptation to changing circumstances
- 通過快速交付有用的軟件來滿足客戶需求
- 歡迎不斷變化的需求，即使是在開發(fā)后期
- 工作軟件頻繁交付（幾周而不是幾個月）
- 業(yè)務(wù)人員和開發(fā)人員之間密切的日常合作
- 項目是圍繞有積極性的個人建立的，這些人應(yīng)該值得信任
- 面對面交談是最好的溝通方式（同地辦公）
- 可以工作的軟件是衡量進(jìn)度的主要標(biāo)準(zhǔn)
- 可持續(xù)發(fā)展，能夠保持恒定的步伐
- 持續(xù)關(guān)注卓越技術(shù)和良好設(shè)計
- 簡單性 — 最大化未完成工作量的藝術(shù)—至關(guān)重要
- 自組織團(tuán)隊
- 定期適應(yīng)不斷變化的情況
- 工具和流程很重要，但更重要的是讓有能力的人有效地合作。
- 好的文檔有助于幫助人們理解軟件是如何構(gòu)建以及如何使用它，但開發(fā)的重點是創(chuàng)建軟件，而不是文檔。
- 合同很重要，但不能替代與客戶密切合作以發(fā)現(xiàn)他們的需求。
- 項目計劃很重要，但不能太死板，無法適應(yīng)技術(shù)或環(huán)境、利益相關(guān)者的優(yōu)先事項以及人們對問題及其解決方案的理解的變化。
-- Scott Ambler
- 敏捷運動并不是反方法論，事實上我們許多人都希望恢復(fù)方法論這個詞的可信度。
- 我們想要恢復(fù)平衡。 我們擁抱建模，但并不是為了在塵土飛揚的公司存儲庫中歸檔一些圖表。
- 我們歡迎文檔，但不喜歡數(shù)百頁從未維護(hù)和很少使用的大部頭。
- 我們計劃，但認(rèn)識到在動蕩的環(huán)境中計劃的局限性。
—?Jim Highsmith
XP
在眾多敏捷方法中, 最負(fù)盛名的當(dāng)數(shù)極限編程 eXtreme Programming, 它所倡導(dǎo)的用戶反饋, 持續(xù)集成, 測試驅(qū)動, 結(jié)對編程等最佳實踐影響深遠(yuǎn)
這是我當(dāng)年作筆記時畫的一張腦圖
Kanban
看板據(jù)說最早來自豐田工作法, 有一個產(chǎn)品需求任務(wù)的優(yōu)先級隊列, PO(Product Owner 產(chǎn)品負(fù)責(zé)人) 負(fù)責(zé)需求分析并制定任務(wù)的優(yōu)先級, 團(tuán)隊成員從中按優(yōu)先級從高到低選取任務(wù)進(jìn)行開發(fā), 所有的任務(wù)都放在一個大的看板上
Scrum
現(xiàn)在眾多軟件及互聯(lián)網(wǎng)公司應(yīng)用較多就是 Scrum 敏捷開發(fā)流程, 強調(diào)以相對固定的幾周一個迭代周期(Sprint), 以跨職能,自組織的 Scrum team 持續(xù)交付對用戶有價值的軟件.
它比較強調(diào)節(jié)奏感, 儀式感, 可操作性強, 在多數(shù)互聯(lián)網(wǎng)公司中廣泛應(yīng)用
Scrum 是一個輕量的框架，它通過提供針對復(fù)雜問題的自適應(yīng)解決方案來幫助人們、團(tuán)隊和組織
創(chuàng)造價值。
簡而言之，Scrum 需要 Scrum Master 營造一個環(huán)境，從而：
- 一名 Product Owner 將解決復(fù)雜問題所需的工作整理成一份 Product Backlog。
- Scrum Team 在 一個 Sprint 期間將選擇的工作 Sprint Backlog 轉(zhuǎn)化為有價值的 Increment。
- Scrum Team 和利益攸關(guān)者檢查結(jié)果并為下一個 Sprint 進(jìn)行調(diào)整。
- 重復(fù)以上步驟
詳細(xì)說明參見 https://scrumguides.org/scrum-guide.html
Scrum 的三大支柱
透明
涌現(xiàn)的過程和工作必須對執(zhí)行工作的人員和接受工作的人員都是可見的。在 Scrum 中，重要的決
策是基于其 3 個正式工件的感知狀態(tài)。透明度較低的工件可能導(dǎo)致做出降低價值并增加風(fēng)險的決
策。透明使檢查成為可能。沒有透明的檢查會產(chǎn)生誤導(dǎo)和浪費。檢查
Scrum 工件和實現(xiàn)商定目標(biāo)的進(jìn)展必須經(jīng)常地和勤勉地進(jìn)行檢查，以便發(fā)現(xiàn)潛在的不良的差異或問
題。為了幫助檢查，Scrum 以 5 個事件的形式提供了穩(wěn)定的節(jié)奏。
檢查使適應(yīng)成為可能。沒有適應(yīng)的檢查是毫無意義的。Scrum 事件旨在激發(fā)改變。
- 適應(yīng)
如果過程的任何方面超出可接受的范圍或所得的產(chǎn)品不可接受，就必須對當(dāng)下的過程或過程處理
的內(nèi)容加以調(diào)整。 調(diào)整工作必須盡快執(zhí)行以最小化進(jìn)一步的偏差。
當(dāng)所涉人員沒有得到授權(quán)或不能自管理（self-managing）時，則適應(yīng)將變得更加困難。 在通過檢
查學(xué)到任何新東西時，Scrum Team 會做出相應(yīng)調(diào)整
Scrum 價值觀
Scrum 的成功應(yīng)用取決于人們變得更加精通踐行并內(nèi)化 5 項價值觀：
- 承諾：Scrum Team 致力于達(dá)成其目標(biāo)并且相互支持。
- 專注：Scrum Team 的主要關(guān)注點是 Sprint 的工作，以便盡可能地向著這些目標(biāo)獲取最好的進(jìn)展。
- 開放：Scrum Team 及其利益攸關(guān)者對工作和挑戰(zhàn)持開放態(tài)度。
- 尊重：Scrum Team 成員相互尊重，彼此是有能力和獨立的人，并因此受到與他們一起工作的人的尊重。
- 勇氣：Scrum Team 成員有勇氣做正確的事并處理那些棘手的問題
Scrum的過程
- 將整個產(chǎn)品的 Product Backlog 分解成 Sprint Backlog, 這個Sprint Backlog是按照目前的人力物力條件可以完成的。
- 召開 Sprint Planning Meeting，安排選定這個Sprint內(nèi)需要完成的 User Story，標(biāo)注 User Story 的優(yōu)先級并由團(tuán)隊成員認(rèn)領(lǐng)。
- 進(jìn)入sprint開發(fā)周期，在這個周期內(nèi)，每天需要召開 Daily Scrum meeting。
- 整個sprint周期結(jié)束，召開Sprint review meeting，將成果演示給Product Owner.
- 團(tuán)隊成員最后召開 Sprint retrospective meeting，總結(jié)問題和經(jīng)驗。
- 這樣周而復(fù)始，按照同樣的步驟進(jìn)行下一次Sprint.
3 種角色：
- 產(chǎn)品負(fù)責(zé)人（Product Owner）
- Scrum Master
- Scrum團(tuán)隊
5 種事件:
- Sprint 沖刺過程
- Sprint計劃會議（Sprint Planning Meeting）
- 每日站會（Daily Scrum Meeting）
- Sprint評審會議（Sprint Review Meeting）
- Sprint回顧會議（Sprint Retrospective Meeting）
3 種工件:
- 產(chǎn)品Backlog（Product Backlog）
- SprintBacklog（Sprint backlog）
- Increment（產(chǎn)品增量）
Scrum 的工件代表工作或價值。 它們旨在最大限度地提高關(guān)鍵信息的透明度。 因此，為適應(yīng)而檢
視它們的每個人對工件都有相同的基礎(chǔ)。每個工件都包含一個承諾，以確保它提供可增強透明度并聚焦于可度量進(jìn)展的信息：
- 對于 Product Backlog 而言，它是 Product Goal。
- 對于 Sprint Backlog 而言，它是 Sprint Goal 。
- 對于 Increment 而言，它是 Definition of Done
中文版的 scrum guide 參見 https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Chinese-Simplified.pdf
GASP
Scrum 有一些被廣泛接受的實踐 Generally Accepted Scrum Practice (GASP)， 比如 User story 的制訂的Role-Action-Benefit 格式, 例如:
- "As a Role, I want to Action, so that benefit"
- 作為一個招聘者，我想在各大招聘平臺發(fā)布新的職位信息，從而讓應(yīng)聘者方便快捷地發(fā)現(xiàn)我們的職位并來求職
以及 User Story 的 INVEST 原則
- "I" ndependent (of all others) 獨立的: 每個用戶故事應(yīng)該代表一組獨特且獨立的業(yè)務(wù)價值，這樣，如果它單獨發(fā)布，它將比之前的狀態(tài)提供增量價值。
- "N" egotiable (not a specific contract for features) 可協(xié)商的: 雖然最終目標(biāo)可能被清楚地描述，但實現(xiàn)該目標(biāo)的方法應(yīng)該是可協(xié)商的——在產(chǎn)品負(fù)責(zé)人和開發(fā)團(tuán)隊、產(chǎn)品負(fù)責(zé)人和客戶或任何其他相關(guān)利益相關(guān)者之間—以防止對特性或功能的不切實際的要求
- "V" aluable (or vertical) 有價值的： 任何用戶故事的商業(yè)價值都應(yīng)該通過閱讀故事而容易被識別，并且每個故事都應(yīng)該代表特定用戶類型的某種價值
- "E" stimable (to a good approximation) 可估量的： 我們必須有足夠的信息來正確確定故事的大小，以便我們可以正確地計劃和致力于我們的工作
- "S" mall (so as to fit within an iteration) 足夠小的， 用戶故事應(yīng)該足夠小，以便能夠在一個 sprint 沖刺內(nèi)完成
- "T" estable (in principle, even if there isn't a test for it yet) 可測試的: 團(tuán)隊的所有成員都需要一種清晰、準(zhǔn)確的方法來驗證用戶故事是否已完成
以及常用的 Burndown Chart 燃盡圖， Burnup Chart 燃起圖等等，不再一一贅述
