敏捷開(kāi)發(fā)模式

1、2022/10/142022/10/14敏捷開(kāi)發(fā)模式 10/14/2022前言敏捷并不神秘、并不難，不要把他當(dāng)成負(fù)擔(dān)，不要為了做而做，敏捷其實(shí)很有趣，我們一起來(lái)體會(huì) be agile 我們不是大師，不是敏捷的發(fā)明人，有時(shí)也對(duì)敏捷爭(zhēng)論的面紅耳赤，我們僅僅比大家先接觸敏捷而已。本材料中所描述的做法，并不是唯一的、適合的做法，做之前先考慮可行性以及本地化。當(dāng)然，如果實(shí)在想不出，那不妨照貓畫(huà)虎，嘗試過(guò)后你就知道如何調(diào)整了，這就是敏捷的做法 10/14/2022目錄敏捷實(shí)踐敏捷流派、敏捷宣言軟件開(kāi)發(fā)本質(zhì)FAQ10/14/2022軟件工程發(fā)展示意圖20世紀(jì)60年代70年代80年代90年代2000年軟件作坊

2、軟件工程瀑布敏捷開(kāi)發(fā)模式迭代、原型、螺旋模型硬件飛速發(fā)展，計(jì)算機(jī)應(yīng)用范圍迅速擴(kuò)大；軟件規(guī)模激增，復(fù)雜度越來(lái)越高導(dǎo)致軟件危機(jī)爆發(fā)CMM、CMMI其實(shí)迭代的思想早就存在詳見(jiàn)本頁(yè)備注10/14/2022什么是敏捷每個(gè)地方、每個(gè)人對(duì)敏捷的認(rèn)識(shí)和理解都不一樣。 從理論定義上講，“敏捷是指在動(dòng)蕩的業(yè)務(wù)環(huán)境中，適應(yīng)變化并創(chuàng)造變化，從而獲得價(jià)值的一種能力“。Jim Highsmith在他的敏捷項(xiàng)目管理一書(shū)中如是說(shuō)?！巴瑫r(shí)敏捷是平衡靈活性和穩(wěn)定性的一種能力”。敏捷開(kāi)發(fā)(Agile Development)是一種以人為核心、迭代、循序漸進(jìn)的開(kāi)發(fā)方法。10/14/2022首先我們思考下：我們?yōu)楹我褂妹艚?？為什么?/p>

3、捷能解決這些問(wèn)題，或達(dá)成這些目標(biāo)？10/14/2022如何控制開(kāi)發(fā)復(fù)雜性備注：本圖摘自ThoughtWorks 敏捷介紹。軟件規(guī)模開(kāi)發(fā)復(fù)雜度10/14/2022為什么敏捷會(huì)流行？回歸軟件本質(zhì)軟件的本質(zhì)是什么？現(xiàn)代軟件系統(tǒng)中無(wú)法規(guī)避的內(nèi)在特性：復(fù)雜性、一致性、可變性和不可見(jiàn)性 軟件工程中的根本和次要問(wèn)題FREDERICK P. BROOKS, JR.其中復(fù)雜性（需求、技術(shù)方面）和可變性是根本問(wèn)題如何解決軟件的復(fù)雜性和可變性？傳統(tǒng)軟件開(kāi)發(fā)敏捷軟件開(kāi)發(fā)把軟件開(kāi)發(fā)類(lèi)比為傳統(tǒng)工業(yè)，規(guī)范后可重復(fù)“生產(chǎn)”計(jì)劃、預(yù)測(cè)預(yù)定義過(guò)程和分階段控制一次性交付，變更成本大嚴(yán)格過(guò)程監(jiān)控過(guò)程決定質(zhì)量典型：瀑布模型、CMM等認(rèn)

4、為軟件開(kāi)發(fā)是復(fù)雜的有機(jī)生態(tài)系統(tǒng)，不可重復(fù)探索、適應(yīng)、演進(jìn)在變化中基于經(jīng)驗(yàn)的過(guò)程小批量快速交付，擁抱變化嚴(yán)格交付驗(yàn)收高效的人和協(xié)作是核心典型：Scrum，XP，自適應(yīng)軟件開(kāi)發(fā)10/14/2022軟件本質(zhì)：軟件內(nèi)在特性之“復(fù)雜性”規(guī)模上，軟件實(shí)體可能比任何由人類(lèi)創(chuàng)造的其他實(shí)體更復(fù)雜，因?yàn)闆](méi)有任何兩個(gè)軟件部分是相同的（至少在語(yǔ)句級(jí)別上）。如果有相同的情況，我們會(huì)把他們合并成子函數(shù)。數(shù)字計(jì)算機(jī)本身就比人類(lèi)建造的大多數(shù)東西復(fù)雜，計(jì)算機(jī)擁有大量的狀態(tài)，這使得構(gòu)思、描述和測(cè)試都非常困難。復(fù)雜度不僅僅導(dǎo)致技術(shù)上的困難，還引發(fā)很多管理上的問(wèn)題，它使得全面理解問(wèn)題變得困難，從而妨礙了概念上的完整性。它引起大量的學(xué)

5、習(xí)和理解上的負(fù)擔(dān)，使開(kāi)發(fā)慢慢演變成災(zāi)難。 Brooks博士人月神話10/14/2022軟件本質(zhì)：軟件內(nèi)在特性之“一致性”軟件工程師必須掌握的很多復(fù)雜度是隨心所欲、毫無(wú)規(guī)則可言的，來(lái)自若干必須遵循的人為慣例和系統(tǒng)，這些變化不是必須的，僅僅因?yàn)樗麄兪遣煌娜硕巧系墼O(shè)計(jì)的。新開(kāi)發(fā)的軟件，必須遵循各種接口，軟件開(kāi)發(fā)的目標(biāo)就是兼容性，很多復(fù)雜性來(lái)自保持與其他接口的一致性Brooks博士人月神話例如：SE列出的規(guī)格是用戶想要的么？項(xiàng)目組的設(shè)計(jì)和SE的想法一致么？合版本為什么經(jīng)常編譯不過(guò)？10/14/2022軟件本質(zhì)：軟件內(nèi)在特性之“可變性”系統(tǒng)中的軟件包含了很多功能，而功能是最容易感受變更壓力的部分，另

6、外的原因是軟件很容易修改，它是純粹思維活動(dòng)的產(chǎn)物，可以無(wú)限擴(kuò)展。成功軟件的生命周期一般比最初開(kāi)發(fā)他們的硬件的生命周期長(zhǎng)，因此，軟件必須與各種新生硬件保持一致。軟件估計(jì)的不準(zhǔn)確性：業(yè)界研究數(shù)據(jù)表明，在項(xiàng)目開(kāi)始時(shí)，估計(jì)值和實(shí)際值之間的差異可能會(huì)達(dá)到4倍，隨著時(shí)間的推移，估計(jì)與實(shí)際的差異會(huì)越來(lái)越小。蔓延的需求在普通項(xiàng)目中它大概占到了 25% ，而在大型項(xiàng)目中則占到 50% 。 Brooks博士人月神話10/14/2022軟件本質(zhì)：軟件內(nèi)在特性之“不可見(jiàn)性”軟件是不可見(jiàn)的和無(wú)法可視化的，幾何抽象是強(qiáng)大的工具，但建筑圖、機(jī)械制圖、分子模型、膜片圖，都有幾何表達(dá)方式，但軟件的客觀存在不具有空間形體特征。當(dāng)

7、我們?cè)噲D用圖形表達(dá)軟件結(jié)構(gòu)時(shí)，發(fā)現(xiàn)它不僅僅是一個(gè)，而是很多互相關(guān)聯(lián)，重疊在一起的圖形，這些圖形可能代表數(shù)據(jù)流圖、控制流程圖、依賴關(guān)系圖、時(shí)間序列圖等。軟件的不可見(jiàn)性不僅僅限制了個(gè)人的設(shè)計(jì)過(guò)程，而且嚴(yán)重阻礙了思路相互之間的交流。 Brooks博士人月神話10/14/2022Page 13Page 13軟件更像是一個(gè)有生命的植物，其開(kāi)發(fā)過(guò)程類(lèi)似于植物自然生長(zhǎng)過(guò)程，自底向上逐步有序增長(zhǎng)。敏捷開(kāi)發(fā)遵循軟件客觀規(guī)律，不斷的迭代增量開(kāi)發(fā)，最終交付符合客戶價(jià)值的產(chǎn)品軟件開(kāi)發(fā)本質(zhì)：軟件開(kāi)發(fā)過(guò)程自然規(guī)律10/14/2022敏捷迭代的優(yōu)勢(shì)：三個(gè)“均衡”風(fēng)險(xiǎn)控制均衡 14人力投入均衡質(zhì)量均衡10/14/2022目錄

8、敏捷實(shí)踐敏捷流派、敏捷宣言軟件開(kāi)發(fā)本質(zhì)FAQ10/14/2022敏捷流派之XPXP（eXtreme Programming 極限編程）1996年，由Kent Beck創(chuàng)立4項(xiàng)價(jià)值觀、12項(xiàng)實(shí)踐技術(shù)型流派，注重開(kāi)發(fā)實(shí)踐最著名的敏捷流派，對(duì)敏捷思想的傳播影響深遠(yuǎn)。整體價(jià)值驅(qū)動(dòng) 勇氣Courage交流Communication反饋Feedback XP簡(jiǎn)單Simplicity10/14/2022XP哲學(xué)觀（Philosophy）和12項(xiàng)實(shí)踐勇氣(Courage)交流(Communication)反饋(Feedback)簡(jiǎn)單(Simplicity)現(xiàn)場(chǎng)客戶（On-Site Customer）計(jì)劃項(xiàng)目（

9、Planning Game）頻繁地小規(guī)模發(fā)布軟件（Small Releases）簡(jiǎn)單設(shè)計(jì)（Simple Design）持續(xù)集成（Continuous Integration）集體擁有代碼（Collective Code Ownership）編程規(guī)范（Coding Standards）重構(gòu)（Refactoring）系統(tǒng)隱喻（System Metaphor）測(cè)試驅(qū)動(dòng)開(kāi)發(fā)（Test Driven Development）結(jié)對(duì)編程（Pair Programming）平穩(wěn)的工作效率（Sustainable Pace）徹底改變傳統(tǒng)開(kāi)發(fā)模式，同時(shí)也最具爭(zhēng)議10/14/2022四項(xiàng)價(jià)值觀溝通： 溝通對(duì)創(chuàng)造團(tuán)隊(duì)

10、的氣氛和有效的協(xié)作很重要。這樣做的目標(biāo)是讓所有開(kāi)發(fā)人員對(duì)系統(tǒng)有共同的理解，并且和用戶對(duì)系統(tǒng)的理解相對(duì)應(yīng)。簡(jiǎn)單： 簡(jiǎn)單是指讓系統(tǒng)簡(jiǎn)單到只是足夠解決好今天的問(wèn)題。其他的功能可以在以后加入。這樣做的好處是可以使至今為止的投資回報(bào)率最大化，而不是投資在可能會(huì)改變的將來(lái)的需求上。反饋： 沒(méi)有一個(gè)固定的方向會(huì)長(zhǎng)期有效。改變是避免不了的。有改變就需要反饋。XP試圖產(chǎn)生盡可能多的來(lái)自不同方向的反饋，越早知道，越容易調(diào)整：勇氣： 勇氣是面對(duì)恐懼的有效回應(yīng)。勇氣是指真實(shí)地說(shuō)出進(jìn)展和估計(jì)；不用文檔記錄失敗的借口，即使我們計(jì)劃著成功；不去害怕任何事情，因?yàn)闆](méi)有人是單獨(dú)工作的。10/14/2022extreme的由來(lái)將

11、優(yōu)秀實(shí)踐發(fā)揮到極致如果代碼Review重要，隨時(shí)進(jìn)行代碼Review（結(jié)對(duì)編程）如果測(cè)試重要，所有人員隨時(shí)進(jìn)行測(cè)試（單元測(cè)試），包括客戶（驗(yàn)收測(cè)試）如果設(shè)計(jì)重要，作為開(kāi)發(fā)人員每天的工作（重構(gòu)）如果簡(jiǎn)單重要，使用最簡(jiǎn)單的設(shè)計(jì)支持現(xiàn)有功能（簡(jiǎn)單設(shè)計(jì)）如果架構(gòu)重要，所有人員隨時(shí)參與分析和精化架構(gòu)（隱喻）如果集成測(cè)試重要，每天多次進(jìn)行集成和測(cè)試（持續(xù)集成）如果反饋重要，進(jìn)行快速反饋每天、小時(shí)、分鐘，而不是周、月（計(jì)劃游戲）10/14/2022敏捷流派之ScrumScrum一詞來(lái)自英式橄欖球：每個(gè)成員都明確自己角色，環(huán)繞同一目標(biāo)，集體行動(dòng)，奮力拼搏。他定義了一個(gè)項(xiàng)目管理框架、方式，包括需求搜集、團(tuán)隊(duì)協(xié)作

12、、項(xiàng)目運(yùn)作、活力激發(fā)等。核心：自管理自組織的團(tuán)隊(duì)：公開(kāi)、獨(dú)立每日研討：更新任務(wù)、暴露并解決問(wèn)題；通過(guò)回顧不斷提高和學(xué)習(xí)。共同的語(yǔ)言、價(jià)值觀、實(shí)踐10/14/2022敏捷流派之Scrum三個(gè)角色：Product OwnerScrum MasterTeam三個(gè)工件：產(chǎn)品Backlog迭代Backlog可以工作的軟件四個(gè)會(huì)議：每日站立會(huì)議迭代計(jì)劃會(huì)議迭代驗(yàn)收會(huì)議迭代回顧會(huì)議10/14/2022敏捷流派之Crystal、DSDM、ASDCrystal將人和團(tuán)隊(duì)作為第一要義，過(guò)程和工具作為第二要義強(qiáng)調(diào)人、交互、團(tuán)隊(duì)、技能、才智、交流可以有條件的減少中間工作產(chǎn)品動(dòng)態(tài)系統(tǒng)開(kāi)發(fā)方法(Dynamic Solut

13、ion Delivery Model,DSDM)，也稱“業(yè)務(wù)中心框架開(kāi)發(fā)方法”，是一種過(guò)程控制框架倡導(dǎo)以業(yè)務(wù)為核心，快速而有效的進(jìn)行系統(tǒng)開(kāi)發(fā)，重點(diǎn)在于快速交付，應(yīng)該用20%的時(shí)間完成80%的有用功能。自適應(yīng)軟件開(kāi)發(fā)(Adaptive Software Development, ASD)要關(guān)注結(jié)果而非過(guò)程。 要提供工具和技巧來(lái)培養(yǎng)自組織能力其特征分別是以任務(wù)為中心、以特性為基礎(chǔ)、迭代、時(shí)間框限制、風(fēng)險(xiǎn)驅(qū)動(dòng)、容變等。ASDDSDM10/14/2022敏捷流派之FDD、Evo、UPFDD特性驅(qū)動(dòng)開(kāi)發(fā)(Feature-Driven Development, FDD)是一個(gè)開(kāi)發(fā)過(guò)程特性作為一個(gè)開(kāi)發(fā)單位，

14、是客戶眼中最小的有用功能，2周內(nèi)可以實(shí)現(xiàn)強(qiáng)調(diào)簡(jiǎn)化、實(shí)用、過(guò)程簡(jiǎn)單、建模、快速迭代、一次實(shí)現(xiàn)一組特性核心原則：強(qiáng)調(diào)可度量的過(guò)程，漸進(jìn)式交付對(duì)性能需求（質(zhì)量、負(fù)載能力、資源節(jié)?。┑牧炕攘啃枨竺枋鼍_和量化：鼓勵(lì)使用結(jié)構(gòu)化的P語(yǔ)言迭代的遞增的記錄需求統(tǒng)一過(guò)程(United Process, UP)一種迭代過(guò)程框架，把研發(fā)分成4個(gè)階段。相對(duì)重型、半教條的方法文檔到過(guò)程，有可選的模板和工作UPEvo10/14/2022XP、SCRUM區(qū)別：迭代長(zhǎng)度的不同XP的一個(gè)Sprint的迭代長(zhǎng)度大致為12周, 而Scrum的迭代長(zhǎng)度一般為 2 4周Scrum team在一個(gè)sprint中是不接受任何任務(wù)變更的

15、Scrum不對(duì)具體實(shí)施過(guò)程做規(guī)定，要求開(kāi)發(fā)者自覺(jué)保證。XP非常嚴(yán)格，規(guī)定需要采用TDD，自動(dòng)測(cè)試，結(jié)對(duì)編程等約束團(tuán)隊(duì)的行為。在管理模式上啟用Scrum， 而在實(shí)踐中，創(chuàng)造一個(gè)適合自己項(xiàng)目組的XP。10/14/2022敏捷思想的歸一在2001年2月以前，“敏捷”一詞意味著“標(biāo)記快速而優(yōu)雅的移動(dòng)的能力”，或者是“擁有快速機(jī)敏和適應(yīng)能力的角色”。從2001年2月開(kāi)始，這個(gè)詞對(duì)于軟件開(kāi)發(fā)人員來(lái)說(shuō)擁有了更多的意義。2001年2月，在美國(guó)猶他州的一個(gè)滑雪場(chǎng)，由17個(gè)人組成的一個(gè)自稱為無(wú)政府組織的團(tuán)體出現(xiàn)了。這是17位輕量級(jí)軟件開(kāi)發(fā)方法的創(chuàng)始人和專家，包括Kent Beck、Martin Fowler、Ro

16、bert C. Martin等等，共同發(fā)布了“The Manifesto for Agile Software Development”（敏捷軟件開(kāi)發(fā)宣言）。敏捷終于為軟件行業(yè)，以及這個(gè)行業(yè)中的一些人所認(rèn)識(shí)、理解和推崇。敏捷聯(lián)盟10/14/2022敏捷宣言敏捷宣言我們正在通過(guò)親身實(shí)踐以及幫助他人實(shí)踐，揭示更好的軟件開(kāi)發(fā)方法。通過(guò)這項(xiàng)工作，我們認(rèn)為：個(gè)體和交互 勝過(guò) 過(guò)程和工具可以工作的軟件 勝過(guò) 面面俱到的文檔客戶合作 勝過(guò) 合同談判響應(yīng)變化 勝過(guò) 遵循計(jì)劃 雖然右項(xiàng)也有價(jià)值，但是我們認(rèn)為左項(xiàng)具有更大的價(jià)值。10/14/2022敏捷軟件開(kāi)發(fā)的原則我們最優(yōu)先要做的是通過(guò)盡早的、持續(xù)的交付有價(jià)值的

17、軟件來(lái)使客戶滿意。即使到了開(kāi)發(fā)的后期，也歡迎改變需求。敏捷過(guò)程利用變化來(lái)為客戶創(chuàng)造競(jìng)爭(zhēng)優(yōu)勢(shì)。經(jīng)常性地交付可以工作的軟件，交付的間隔可以從幾個(gè)星期到幾個(gè)月，交付的時(shí)間間隔越短越好。在整個(gè)項(xiàng)目開(kāi)發(fā)期間，業(yè)務(wù)人員和開(kāi)發(fā)人員必須天天都在一起工作。圍繞被激勵(lì)起來(lái)的個(gè)體來(lái)構(gòu)建項(xiàng)目。給他們提供所需的環(huán)境和支持，并且信任他們能夠完成工作。在團(tuán)隊(duì)內(nèi)部，最具有效果并且富有效率的傳遞信息的方法，就是面對(duì)面的交談?？梢怨ぷ鞯能浖鞘滓倪M(jìn)度度量標(biāo)準(zhǔn)。敏捷過(guò)程提倡可持續(xù)的開(kāi)發(fā)速度。責(zé)任人、開(kāi)發(fā)者和用戶應(yīng)該能夠保持一個(gè)長(zhǎng)期的、恒定的開(kāi)發(fā)速度。不斷地關(guān)注優(yōu)秀的技能和好的設(shè)計(jì)會(huì)增強(qiáng)敏捷能力。簡(jiǎn)單 使未完成的工作最大化的藝術(shù)

18、是根本的。最好的構(gòu)架、需求和設(shè)計(jì)出自于“自組織”的團(tuán)隊(duì)。每隔一定時(shí)間，團(tuán)隊(duì)會(huì)在如何才能更有效地工作方面進(jìn)行反省，然后響應(yīng)地對(duì)自己的行為進(jìn)行調(diào)整。10/14/2022目錄敏捷實(shí)踐敏捷流派、敏捷宣言軟件開(kāi)發(fā)本質(zhì)FAQ10/14/2022瀑布、迭代和敏捷的外在區(qū)別瀑布：開(kāi)發(fā)模型重量級(jí)：所有需求統(tǒng)一步伐，全部分析完畢后再開(kāi)始設(shè)計(jì)，全部設(shè)計(jì)完畢后再啟動(dòng)編碼重過(guò)程：有明顯的過(guò)程，每個(gè)過(guò)程不重疊，界線清晰 SRS、HLD、LLD、Coding、UT、IT、ST，開(kāi)發(fā)完畢后集中轉(zhuǎn)測(cè)試。迭代：開(kāi)發(fā)模型中量級(jí)：需求分成多批，每批一輪迭代，每輪內(nèi)都是小瀑布；每輪迭代出一個(gè)版本交付測(cè)試。沒(méi)有明顯的過(guò)程。敏捷：開(kāi)發(fā)模式

19、輕量級(jí)：需求分解成更小粒度，每個(gè)小粒度需求13天實(shí)現(xiàn)，并立即轉(zhuǎn)測(cè)試。從瀑布、迭代到敏捷，是量變引起質(zhì)變。（每輪迭代結(jié)束時(shí)出版本并不是測(cè)試的開(kāi)始，更多的是開(kāi)發(fā)和測(cè)試共同結(jié)束點(diǎn)）過(guò)程：在一個(gè)過(guò)程框架下，嵌入了很多敏捷實(shí)踐，并由很強(qiáng)的原則進(jìn)行約束。開(kāi)發(fā)模式之外，更是一種思想、理念、文化！10/14/2022推薦的敏捷實(shí)踐發(fā)布計(jì)劃迭代迭代計(jì)劃會(huì)議迭代展示會(huì)議迭代回顧會(huì)議故事澄清會(huì)議故事級(jí)別簽收故事級(jí)別測(cè)試每日站會(huì)可視化管理開(kāi)放式辦公用戶故事系統(tǒng)解剖敏捷估計(jì)簡(jiǎn)單設(shè)計(jì)測(cè)試驅(qū)動(dòng)開(kāi)發(fā)重構(gòu)持續(xù)集成結(jié)對(duì)編程靈活檢視10/14/2022如何把敏捷實(shí)踐串起來(lái)？（Story級(jí)）TDD、重構(gòu)、PP、CI檢視測(cè)試測(cè)試用例

20、& 測(cè)試代碼Story澄清Story簽收Story開(kāi)始Story結(jié)束每日站會(huì)、可視化管理、Session、開(kāi)放式辦公CI要考慮真實(shí)環(huán)境10/14/2022如何把敏捷實(shí)踐串起來(lái)？（迭代級(jí)）Story1開(kāi)發(fā)系統(tǒng)測(cè)試迭代計(jì)劃迭代開(kāi)始Story1測(cè)試Story2開(kāi)發(fā)Story2測(cè)試迭代展示&迭代回顧也可以在系統(tǒng)測(cè)試之后需求分析、Story分解系統(tǒng)解剖、簡(jiǎn)單設(shè)計(jì)建立持續(xù)集成環(huán)境計(jì)劃、培訓(xùn)、研討等迭代啟動(dòng)前迭代結(jié)束10/14/2022如何把敏捷實(shí)踐串起來(lái)？（版本級(jí)）各個(gè)角色內(nèi)部工作串行；測(cè)試與開(kāi)發(fā)并行。完成若干輪迭代，就可以提交給用戶一個(gè)版本（Release）。10/14/2022做事方式：small s

21、tep：小粒度、快速反饋、迭代、Stop & Fix；simple：簡(jiǎn)單設(shè)計(jì)、 no more no less（just enough）、復(fù)雜問(wèn)題簡(jiǎn)單化；自動(dòng)化：持續(xù)集成、測(cè)試自動(dòng)化；隨機(jī)應(yīng)變：響應(yīng)變化、自適應(yīng)計(jì)劃；做事理念：以人為本、自我驅(qū)動(dòng)、自我組織、持續(xù)改進(jìn)（個(gè)人和組織）。實(shí)踐和流程背后是什么呢？敏捷是一種開(kāi)發(fā)模式，更是一種思想、理念、文化10/14/2022目錄敏捷實(shí)踐敏捷流派、敏捷宣言軟件開(kāi)發(fā)本質(zhì)FAQ10/14/2022敏捷項(xiàng)目成功的關(guān)鍵點(diǎn)是什么？RDPDT對(duì)敏捷的認(rèn)同 最關(guān)鍵！你是否有魄力給團(tuán)隊(duì)一段時(shí)間磨合，并深信磨合后能趕上進(jìn)度？甚至犧牲一點(diǎn)進(jìn)度也在所不惜？沒(méi)有進(jìn)度不緊的項(xiàng)目，

22、敏捷原則和基本活動(dòng)你能否堅(jiān)持？質(zhì)量和進(jìn)度沖突時(shí)，決策權(quán)應(yīng)該在主管手中教練敏捷項(xiàng)目的成敗，教練占了絕對(duì)性比重。啟動(dòng)前準(zhǔn)備工作通過(guò)mini項(xiàng)目和一系列研討，加深所有成員對(duì)敏捷的認(rèn)識(shí)，重要的是觀念的轉(zhuǎn)變。對(duì)操作方式、工具達(dá)成一致。建立持續(xù)集成環(huán)境（含測(cè)試）。調(diào)整座位：讓SE、測(cè)試、資料和開(kāi)發(fā)團(tuán)隊(duì)按功能劃分（而不是按部門(mén)劃分），坐在一起 非必須，但能極大的提升整體研發(fā)效率。運(yùn)作過(guò)程中：在原則上持續(xù)堅(jiān)持，在形式上持續(xù)改進(jìn)。10/14/2022敏捷項(xiàng)目的巨大車(chē)輪是如何被驅(qū)動(dòng)的？10/14/2022敏捷其實(shí)很簡(jiǎn)單與其花費(fèi)大量時(shí)間研究各種“流派”和飛吐沫星，還不如去實(shí)踐、去體會(huì)！敏捷是實(shí)踐科學(xué)。10/14/2

23、022敏捷相關(guān)網(wǎng)站 英文網(wǎng)站內(nèi)容更豐富10/14/2022推薦書(shū)籍針對(duì)管理者： Scrum敏捷項(xiàng)目管理KEN SCHWABER清華大學(xué)出版社 PMPL必讀， Scrum理論與實(shí)踐的重要奠基之作，作者是Scrum的締造者。 敏捷迭代開(kāi)發(fā) 管理者指南Craig Larman 中國(guó)電力出版社 PMPL參考手冊(cè)，了解敏捷的多個(gè)流派，里面有很多的checklist可以參考。 敏捷估計(jì)與規(guī)劃MIKE COHN清華大學(xué)出版社 了解優(yōu)秀的計(jì)劃由哪些東西組成，如何才能使計(jì)劃也成為敏捷的。 人月神話 Frederick P. Brooks，Jr. 清華大學(xué)出版社 很多人都知道了。針對(duì)需求分析人員： User St

24、ories Applied MIKE COHN Addison-Wesley 敏捷項(xiàng)目需求分析人員必讀。 針對(duì)系統(tǒng)設(shè)計(jì)、開(kāi)發(fā)人員： 大規(guī)模C+程序設(shè)計(jì)John lacks 中國(guó)電力出版社 經(jīng)典之作，C程序員也應(yīng)閱讀。敏捷軟件開(kāi)發(fā)原則、模式與實(shí)踐Robert C. Martin清華大學(xué)出版社 OOD最經(jīng)典的一本書(shū)，使用過(guò)程化開(kāi)發(fā)語(yǔ)言也可借鑒其中思想。 修改代碼的藝術(shù)MICHAEL FEATHERS 人民郵電出版社 了解如何重構(gòu)大型的、無(wú)測(cè)試的遺留系統(tǒng)。產(chǎn)品歷史3年以上的開(kāi)發(fā)人員必備書(shū)籍。重構(gòu) - 改善既有代碼的設(shè)計(jì)Martin Fowler 中國(guó)電力出版社 了解重構(gòu)的基本技巧和思想，編碼過(guò)程中如

25、何進(jìn)行重構(gòu)。 持續(xù)集成:軟件質(zhì)量改進(jìn)和風(fēng)險(xiǎn)降低之道Paul M.Duvall等 了解持續(xù)集成的基本原則、工具和方法。 計(jì)算機(jī)程序的構(gòu)造和解釋 Harold Abelson,Gerald Jay Sussman,Julie Sussman 機(jī)械工業(yè)出版社 英文名：SICP: Structure and Interpretation of Computer Programs 麻省理工計(jì)算機(jī)系教材。不是所有努力都有收獲，但每一次收獲都必須努力！10/14/2022發(fā)布計(jì)劃（Release Planning）一個(gè)項(xiàng)目的開(kāi)發(fā)周期中，可分為若干個(gè)Release，每個(gè)Release都可完整對(duì)外交付功能、特性

26、。每個(gè)Release長(zhǎng)度一般是23個(gè)月，根據(jù)實(shí)際情況設(shè)置。20%的功能，能實(shí)現(xiàn)80%的客戶商業(yè)價(jià)值，每個(gè)Release都應(yīng)交付剩余優(yōu)先級(jí)最高、對(duì)客戶最有價(jià)值的功能、特性。每個(gè)Release可以被客戶直接上線，也可以內(nèi)部交付（TDT-PDT）、demo、參展、比拼、向MKT演示等等，應(yīng)根據(jù)實(shí)際情況，制定每個(gè)Release的策略。相對(duì)于瀑布長(zhǎng)時(shí)間開(kāi)發(fā)后的一次性交付，敏捷能提前實(shí)現(xiàn)客戶價(jià)值（客戶提前盈利），更符合客戶的心理期望。InitiationDevelop and Deploy Release nRelease n+1Release n+2Project Closure10/14/2022發(fā)布

27、計(jì)劃（Release Planning）每個(gè)Release，都包含若干輪迭代（Iteration）。Release對(duì)外（客戶等），Iteration對(duì)內(nèi)（研發(fā)）。一個(gè)是市場(chǎng)策略，一個(gè)是研發(fā)策略，兩者并不相等（但有聯(lián)系）.Project Release PlanRelease nRelease n+1DevTestDevTestDevTestDevTestDevTestDevTestDevTestDevTestDevTestDevTestDevTestRelease n+2DevTestScheduled releaseAnalyseAnalyseAnalyseAnalyseAnalyseAna

28、lyseAnalyseAnalyseAnalyseAnalyseAnalyseAnalyseIterationScheduled releaseScheduled releaseIterationScheduled milestoneScheduled milestone10/14/2022發(fā)布計(jì)劃（Release Planning）所有未實(shí)現(xiàn)的需求（包括新增、修改、刪除），統(tǒng)一排序，統(tǒng)一計(jì)劃在哪輪迭代實(shí)現(xiàn)。一般針對(duì)下輪迭代詳細(xì)計(jì)劃，越往后的迭代，計(jì)劃越粗略。自適應(yīng)計(jì)劃（Adaptive Planning）：基于當(dāng)前掌握的信息做滿足要求的簡(jiǎn)單計(jì)劃，隨著掌握信息的變化和形勢(shì)的發(fā)展，及時(shí)做適應(yīng)性的

29、計(jì)劃調(diào)整。對(duì)剩余需求排優(yōu)先級(jí)、調(diào)整計(jì)劃，每輪迭代中都應(yīng)進(jìn)行。IterationSSSSSSSSSSDoneNextFutureSSSSSSSSSSSSSRelease nInProgressRelease n -1SSSSSS新增Story刪除StoryS修改StorySS10/14/2022迭代（Iteration）推薦24周一輪迭代，應(yīng)不大于6周。迭代周期應(yīng)固定（Time box）。每輪迭代并不是一個(gè)小瀑布（不是幾天分析、幾天實(shí)現(xiàn)、幾天測(cè)試）。和瀑布的最顯著差異，也最容易實(shí)施。有時(shí)可以安排一個(gè)特殊迭代（可以和普通迭代周期不一樣），比如：經(jīng)過(guò)幾輪迭代，有很多Story堆積在聯(lián)調(diào)和測(cè)試驗(yàn)證上，

30、那就可以專門(mén)安排一輪迭代用于聯(lián)調(diào)和測(cè)試驗(yàn)證，沒(méi)有新的Story開(kāi)發(fā)，開(kāi)發(fā)、SE、測(cè)試全都重點(diǎn)投入測(cè)試，用以穩(wěn)定版本質(zhì)量。還可以安排一輪迭代專門(mén)用于Bug Fix，來(lái)解決前期積壓的大量問(wèn)題單。也給團(tuán)隊(duì)成員一個(gè)調(diào)整的機(jī)會(huì)。10/14/2022迭代（Iteration）Try：Time Box。Avoid：臨時(shí)延長(zhǎng)迭代周期。按小瀑布方式運(yùn)作迭代。臨時(shí)變更本輪迭代正在開(kāi)發(fā)的需求。迭代開(kāi)發(fā)中，臨時(shí)抽走團(tuán)隊(duì)成員。10/14/2022迭代計(jì)劃會(huì)議（Iteration Planning Meeting）迭代計(jì)劃會(huì)議分成2部分：第一部分：由PO向團(tuán)隊(duì)(所有角色)澄清最高優(yōu)先級(jí)的產(chǎn)品需求。團(tuán)隊(duì)和PO協(xié)商哪些需求納

31、入下輪迭代開(kāi)發(fā)計(jì)劃中，確定下輪迭代目標(biāo)（包括“完成標(biāo)準(zhǔn)”）。第二部分：由團(tuán)隊(duì)分解迭代需求到Story（甚至Task），工作量估計(jì)。PO也參加，以了解團(tuán)隊(duì)達(dá)成目標(biāo)的風(fēng)險(xiǎn)，也現(xiàn)場(chǎng)解答團(tuán)隊(duì)關(guān)于需求的問(wèn)題。對(duì)于多團(tuán)隊(duì)產(chǎn)品，迭代計(jì)劃會(huì)議可以分層召開(kāi)：產(chǎn)品PO和團(tuán)隊(duì)的PL、BA先召開(kāi)。再由PL、BA和團(tuán)隊(duì)成員召開(kāi)。10/14/2022迭代計(jì)劃會(huì)議（Iteration Planning Meeting）Try：PO全程參與。由團(tuán)隊(duì)評(píng)估工作量，根據(jù)自己能力承諾迭代可完成的需求 這點(diǎn)很難 Avoid：PO不參與。團(tuán)隊(duì)過(guò)度承諾（基于期望 VS. 基于能力承諾）10/14/2022迭代展示會(huì)議（Iteration

32、Showcase Meeting）每輪迭代結(jié)束前，團(tuán)隊(duì)向用戶、PO、利益相關(guān)人演示工作成果，通過(guò)充分的交流溝通，判斷是否滿足要求。會(huì)議可以持續(xù)10分鐘，也可以是2小時(shí)。通過(guò)客戶操作和現(xiàn)場(chǎng)交流，團(tuán)隊(duì)獲得各方面反饋（包括需求范圍、易用性等），明確的內(nèi)容可以當(dāng)場(chǎng)給出承諾，不明確的作為遺留問(wèn)題跟蹤。團(tuán)隊(duì)根據(jù)反饋，在下輪迭代立即調(diào)整。提前進(jìn)行：如果開(kāi)發(fā)過(guò)程中，通過(guò)口頭交流還是難以把握需求（比如界面類(lèi)需求），可以在功能基本跑通時(shí)，就進(jìn)行showcase，以盡早獲得反饋，盡早調(diào)整。團(tuán)隊(duì)以一個(gè)整體對(duì)外展示工作成果，有助于形成一致的工作目標(biāo)，有助于團(tuán)隊(duì)成員配合更加默契，有助于團(tuán)隊(duì)自信的建立 10/14/2022

33、迭代展示會(huì)議（Iteration Showcase Meeting）Try:用戶、PO、利益相關(guān)人盡量全部到場(chǎng)。盡量使用真實(shí)環(huán)境。Avoid:某些重要角色不參加會(huì)議，之后團(tuán)隊(duì)也未尋找機(jī)會(huì)向他showcase 走過(guò)場(chǎng)10/14/2022迭代回顧會(huì)議（Iteration Retrospection Meeting）每輪迭代末，或進(jìn)展不暢時(shí)，都應(yīng)召開(kāi)回顧會(huì)議。迭代回顧會(huì)議是促進(jìn)團(tuán)隊(duì)持續(xù)改進(jìn)的最有效手段。建議議程：開(kāi)場(chǎng)：致歡迎詞；每個(gè)人用一兩個(gè)形容詞描述對(duì)本次回顧會(huì)議的期望；分析：回顧本輪迭代所有度量數(shù)據(jù)、圖表、完成的特性、重要問(wèn)題、周邊評(píng)價(jià)等信息；信息收集：發(fā)給每人貼紙，10分鐘寫(xiě)出白板上要求的內(nèi)容

34、，并自行貼到白板上（白板上的信息見(jiàn)后2頁(yè)）快速歸類(lèi)：主持人發(fā)動(dòng)大家一起歸類(lèi)；快速分享：主持人念出貼紙上的內(nèi)容，讓大家知道；探討TOP問(wèn)題根因&解決方法：針對(duì)TOP35問(wèn)題，使用頭腦風(fēng)暴進(jìn)行討論，并得出措施（可以分組也可以一起討論）；會(huì)后跟蹤：解決措施在下輪迭代就應(yīng)立即實(shí)施，努力讓本輪TOP問(wèn)題不再是下輪TOP問(wèn)題。準(zhǔn)備開(kāi)會(huì)跟蹤關(guān)鍵道具10/14/2022回顧會(huì)議最高原則我們堅(jiān)信，以當(dāng)時(shí)團(tuán)隊(duì)成員的能力和技術(shù)，以當(dāng)時(shí)資源的可用率，當(dāng)時(shí)的狀況，所有人都盡了最大的努力。10/14/2022為什么每輪都要回顧有形原因：幫助團(tuán)隊(duì)發(fā)現(xiàn)成績(jī)，發(fā)揚(yáng)光大！幫助團(tuán)隊(duì)挖掘問(wèn)題，找到解決方案，立即在下一輪迭代中改正！無(wú)

35、形原因：把決定和精力放在最需要的地方！軟件開(kāi)發(fā)中，總有進(jìn)一步提升的空間和必要性！理解團(tuán)隊(duì)中不同的觀點(diǎn)，增進(jìn)團(tuán)隊(duì)成員互相理解和信任！相對(duì)于回溯，我們更愿意用回顧這個(gè)詞。10/14/2022回顧會(huì)議形式 4象限4個(gè)方框分別表示：做的好的、做的不好的、點(diǎn)子、遇到的障礙；10/14/2022迭代回顧會(huì)議Try：想盡辦法調(diào)動(dòng)大家發(fā)言、探討的積極性。有個(gè)好的引導(dǎo)者。Avoid：一言堂 主角是團(tuán)隊(duì)成員，而不是管理者或者某些角色。走過(guò)場(chǎng)。10/14/2022故事澄清會(huì)議（Story Clarification Meeting）在開(kāi)發(fā)某個(gè)故事前，需要BA、開(kāi)發(fā)、測(cè)試、資料進(jìn)行一個(gè)簡(jiǎn)短的澄清會(huì)議，以明確需求要做成

36、啥樣子、驗(yàn)收條件是啥。建議在澄清會(huì)之前，開(kāi)發(fā)和測(cè)試先行閱讀需求，寫(xiě)出主要的測(cè)試用例，然后再召開(kāi)會(huì)議：有思考后再與會(huì)，效果往往會(huì)更好。直接澄清需求是正向理解需求，討論測(cè)試用例是逆向理解需求，“正向+逆向”能確保澄清的更充分。會(huì)議簡(jiǎn)短高效，在座位上召開(kāi)即可，一般1030分鐘。10/14/2022故事澄清會(huì)議（Story Clarification Meeting）Try：會(huì)前準(zhǔn)備測(cè)試用例。Avoid：BA不參加。討論實(shí)現(xiàn)方案。會(huì)議冗長(zhǎng)。10/14/2022故事級(jí)別簽收（Story level Signoff）Story開(kāi)發(fā)、review，并經(jīng)過(guò)開(kāi)發(fā)人員測(cè)試、check in后，需要和資料、測(cè)試人員

37、一同召開(kāi)簽收會(huì)議。建議由測(cè)試人員操作，運(yùn)行開(kāi)發(fā)人員的用例，也進(jìn)行初步的現(xiàn)場(chǎng)測(cè)試，目的是通過(guò)簡(jiǎn)短的操作，判斷沒(méi)有大的問(wèn)題阻礙之后的測(cè)試（包括開(kāi)發(fā)和測(cè)試?yán)斫獠灰恢聠?wèn)題）。如果資料也開(kāi)發(fā)完，一同驗(yàn)收。會(huì)議簡(jiǎn)短高效，在座位上進(jìn)行即可，一般520分鐘。10/14/2022故事級(jí)別簽收（Story level Signoff）Try：堅(jiān)持召開(kāi)。和測(cè)試充分交流。測(cè)試人員操作。Avoid：草草了事。長(zhǎng)時(shí)間討論。（或許意味著應(yīng)該和BA確認(rèn)需求了）10/14/2022故事級(jí)別測(cè)試（Story level Test）盡量做到每開(kāi)發(fā)完一個(gè)Story，就測(cè)試一個(gè)Story。盡量避免只能到迭代末才能提供版本給測(cè)試。這是一

38、個(gè)過(guò)程，如果當(dāng)前無(wú)法做到，就先從迭代級(jí)別測(cè)試做起，即每輪迭代末交付一個(gè)版本給測(cè)試。開(kāi)發(fā)下輪迭代時(shí)，測(cè)試部針對(duì)上輪迭代需求進(jìn)行測(cè)試。10/14/2022每日站會(huì)（Daily Standup Meeting）我有個(gè)信息要知會(huì)2位同事，你工作進(jìn)展和另3位同事相關(guān) 如果去交流，整個(gè)團(tuán)隊(duì)將會(huì)消耗多少時(shí)間？是否有更好的辦法？敏捷按小粒度需求開(kāi)發(fā)，進(jìn)展日新月異，團(tuán)隊(duì)成員間很有必要每日分享信息。我們發(fā)覺(jué)每日站會(huì)能解決這個(gè)問(wèn)題，他是個(gè)很好的信息分享平臺(tái)。10/14/2022每日站會(huì)（Daily Standup Meeting）每個(gè)團(tuán)隊(duì)每日早上515分鐘，所有人參加（開(kāi)發(fā)、測(cè)試、資料、SE、PL等），一般在狀態(tài)墻

39、旁進(jìn)行。團(tuán)隊(duì)成員依次自發(fā)的分享各類(lèi)信息：昨日我做了什么；今日打算做什么；有什么困難、問(wèn)題、好的點(diǎn)子；如果進(jìn)展有更新，那就更新下?tīng)顟B(tài)墻；如果有新任務(wù)，立即寫(xiě)張任務(wù)卡貼在狀態(tài)墻上。10/14/2022每日站會(huì)（Daily Standup Meeting）如果一個(gè)版本中有多個(gè)團(tuán)隊(duì)，每日站會(huì)可以分層進(jìn)行（如下），在30分鐘內(nèi)，就可把各類(lèi)信息傳遞到每個(gè)人、每個(gè)角色：8:459:00：各項(xiàng)目組站會(huì)。9:009:15：PM、PL站會(huì)；PO、BA站會(huì)；測(cè)試人員站會(huì)；資料人員站會(huì)等。10/14/2022全體站會(huì)（Global Standup Meeting）如果認(rèn)為必要，每周還可召開(kāi)12次全體站會(huì)，還是15分鐘

40、，版本所有人員站在Anatomy圖、作戰(zhàn)圖前，每個(gè)PL講述：距上次全體站會(huì)我們組完成了什么（尤其是影響其他組的信息）、下次全體站會(huì)前計(jì)劃完成什么、有什么問(wèn)題困難和經(jīng)驗(yàn)。好處：通過(guò)簡(jiǎn)短的全員會(huì)議，不僅能使每位成員及時(shí)知曉其他組的進(jìn)展和各類(lèi)信息，同時(shí)也使得開(kāi)發(fā)人員了解整個(gè)版本的開(kāi)發(fā)狀態(tài)（每個(gè)人都是項(xiàng)目一員）。 10/14/2022每日站會(huì)（Daily Standup Meeting）Try：放松（早例會(huì)是件很有趣的事）發(fā)言簡(jiǎn)短；會(huì)議簡(jiǎn)短。PL盡量少發(fā)言，少布置任務(wù)。每人盡量挖掘和其他人相關(guān)的信息。Avoid：遲到。每個(gè)人講述時(shí)，眼睛里只有PL心不在焉：看報(bào)紙、開(kāi)小會(huì)、接電話 長(zhǎng)時(shí)間討論問(wèn)題（如有問(wèn)

41、題，相關(guān)人員留下繼續(xù)討論）走過(guò)場(chǎng)，除了讓員工反感，沒(méi)有任何其他效果10/14/2022可視化管理（Visual Management）管理并不是我們想象的那么復(fù)雜，有時(shí)很簡(jiǎn)單的方式，就有很好的效果?？梢暬莻€(gè)簡(jiǎn)單高效的方式：將項(xiàng)目的各類(lèi)信息（進(jìn)度、質(zhì)量數(shù)據(jù)等），用各種恰當(dāng)?shù)男问剑埌濉装?、墻壁、液晶電視、甚至喇叭、光線），在辦公環(huán)境周?chē)鷮?shí)時(shí)展示出來(lái)。好處：簡(jiǎn)單有效、一目了然、管理成本低廉。及時(shí)知會(huì)所有人進(jìn)展、問(wèn)題、成績(jī)。信息同源，理解一致，提升透明度。提升團(tuán)隊(duì)凝聚力、激勵(lì)團(tuán)隊(duì)進(jìn)取心。打造一種精益式的、Just in time方式的軟件開(kāi)發(fā)環(huán)境、習(xí)慣和系統(tǒng)。10/14/2022可視化管理形

42、式 進(jìn)度墻團(tuán)隊(duì)自定義每列名稱，比如：To Do、TCM、TDD、Signoff、SDV、Done，可以簡(jiǎn)單到只寫(xiě)3個(gè)階段：To Do、Doing、DoneTo Do列，Story卡從高優(yōu)先級(jí)到低優(yōu)先級(jí)，依次從上向下排列。結(jié)對(duì)的員工自行領(lǐng)取Story時(shí)，默認(rèn)領(lǐng)取最上一張Story卡，如果感覺(jué)無(wú)法開(kāi)發(fā)，則再看下一張卡；領(lǐng)取后，貼上寫(xiě)有自己姓名的小便簽紙（也可貼上粘有自己頭像的磁性貼）10/14/2022可視化管理形式 燃盡圖（Burn down Chart）X軸：日期或天數(shù)；Y軸：故事點(diǎn)；由PL每天畫(huà)一點(diǎn)，表示當(dāng)時(shí)剩余的故事點(diǎn)總數(shù)，并和昨日的點(diǎn)連成線。需要注意的是：只有當(dāng)一個(gè)Story完全被開(kāi)發(fā)完

43、，這個(gè)Story的點(diǎn)數(shù)才可算作已開(kāi)發(fā)完。從線的趨勢(shì)，就能很容易的判斷到預(yù)定日期，計(jì)劃的Story是否可以被開(kāi)發(fā)完，當(dāng)然，是個(gè)粗略的判斷。10/14/2022可視化管理形式 進(jìn)度和燃盡圖結(jié)合10/14/2022可視化管理形式 其他缺陷走勢(shì)圖Anatomy表情日歷生產(chǎn)線10/14/2022可視化管理（Visual Management）Try：簡(jiǎn)單、明了。放在團(tuán)隊(duì)成員抬頭、打水都能看到的地方。盡量實(shí)時(shí)更新。Avoid：復(fù)雜，細(xì)細(xì)思考才能看懂。被扔在角落里。沒(méi)人更新、沒(méi)人閱讀、沒(méi)人理會(huì)、沒(méi)效果，為可視化而可視化。10/14/2022開(kāi)放式辦公（Co-location）軟件開(kāi)發(fā)是一種團(tuán)隊(duì)活動(dòng)，團(tuán)隊(duì)活動(dòng)

44、就會(huì)面臨溝通的難題。如何讓團(tuán)隊(duì)成員樂(lè)于溝通？開(kāi)放式辦公，容易讓團(tuán)隊(duì)形成“滲透式溝通”，也是一種心理暗示。通過(guò)開(kāi)放式辦公（在同一個(gè)視覺(jué)與聽(tīng)覺(jué)空間中工作），滿足軟件開(kāi)發(fā)所需要的快速反饋、信息和知識(shí)迅速傳播的需求，從而提升團(tuán)隊(duì)的工作效率和質(zhì)量。開(kāi)放式辦公也能提升團(tuán)隊(duì)工作的可視化度；增強(qiáng)團(tuán)隊(duì)成員間的相互信任，更利于團(tuán)隊(duì)協(xié)作。10/14/2022開(kāi)放式辦公（Co-location）10/14/2022開(kāi)放式辦公（Co-location）Try：多交頭接耳辦公桌周?chē)卸鄠€(gè)小會(huì)議室，供專題集中討論。在辦公區(qū)，要逐步養(yǎng)成安靜討論的習(xí)慣提醒周邊同事小聲交談。Avoid：團(tuán)隊(duì)成員間還是老死不相往來(lái)。辦公桌旁大聲喧

45、嘩。長(zhǎng)時(shí)間打電話。10/14/2022簡(jiǎn)單設(shè)計(jì)（Simple Design）簡(jiǎn)單設(shè)計(jì)包含3個(gè)概念：Try設(shè)計(jì)簡(jiǎn)單，Avoid避免過(guò)度設(shè)計(jì)：設(shè)計(jì)方案要保持簡(jiǎn)潔，不要使用很復(fù)雜的設(shè)計(jì)方案。僅為目前已經(jīng)看到的需求進(jìn)行設(shè)計(jì)，不要為日后可能會(huì)有的需求進(jìn)行設(shè)計(jì)，經(jīng)驗(yàn)表明這常常是杞人憂天 過(guò)度設(shè)計(jì)（over-engineering）?；谑聦?shí)，而不是基于猜測(cè)作設(shè)計(jì)。design for simple，而不是design simply；簡(jiǎn)單的設(shè)計(jì)，而不是簡(jiǎn)單地設(shè)計(jì)。Try架構(gòu)先行，Avoid避免沒(méi)有設(shè)計(jì)：現(xiàn)在的軟件很復(fù)雜，如果沒(méi)有架構(gòu)，僅靠小粒度代碼毫無(wú)策略的堆疊，將會(huì)導(dǎo)致代碼“腐敗”，提高重構(gòu)成本，因此需要開(kāi)發(fā)之初就進(jìn)行系統(tǒng)設(shè)計(jì)。簡(jiǎn)單設(shè)計(jì)常常被誤解成“沒(méi)有設(shè)計(jì)”Try演進(jìn)式設(shè)計(jì)，Avoid避免過(guò)大的前端設(shè)計(jì)：設(shè)計(jì)不可能一步到位：現(xiàn)在的軟件很復(fù)雜，總有些地方考慮不完全，開(kāi)發(fā)之初設(shè)計(jì)一個(gè)簡(jiǎn)單可用的架構(gòu)，夠用即可，避免過(guò)大的前端設(shè)計(jì)（BUFD：Big Up Front Design）。迭代開(kāi)發(fā)過(guò)程中，不斷的優(yōu)化設(shè)計(jì)，開(kāi)發(fā)中如遇到以前的設(shè)計(jì)不合適，要及時(shí)調(diào)整設(shè)計(jì)，也就是設(shè)計(jì)也需要small step。即使設(shè)計(jì)一部到位了：也會(huì)由于后期需求變更，常