難得的機(jī)會(huì)本文主要涵蓋的內(nèi)容如下： 敏捷Scrum模式概貌 Scrum Team的組成與角色分工 團(tuán)隊(duì)的日?；顒?dòng)
敏捷Scrum模式概貌開發(fā)管理的痛點(diǎn)開發(fā)過(guò)程的各個(gè)環(huán)節(jié)的明確邊際，造成信息傳遞鏈條過(guò)長(zhǎng),，溝通成本以及問(wèn)題反饋效率低?，F(xiàn)行的多數(shù)團(tuán)隊(duì)，其溝通方式多數(shù)是鏈?zhǔn)絺鬟f的,，從產(chǎn)品->架構(gòu)->開發(fā)->測(cè)試這樣一個(gè)過(guò)程,。然后就是每個(gè)人都希望做完自己規(guī)定的職責(zé)后可以當(dāng)甩手掌柜，最后結(jié)果是下游環(huán)節(jié)在出現(xiàn)問(wèn)題的時(shí)候把責(zé)任習(xí)慣性推給上游環(huán)節(jié),。測(cè)試不管大局,，拼命找開發(fā)的所謂的“漏洞”，而開發(fā)則去說(shuō)架構(gòu)沒有設(shè)計(jì)好,，架構(gòu)則找產(chǎn)品茬說(shuō)產(chǎn)品啥YY需求,。這樣最明顯的特征就是測(cè)試似乎績(jī)效很好，但是產(chǎn)品質(zhì)量依然一塌糊涂,。這里引出一個(gè)公司管理的一個(gè)很現(xiàn)實(shí)的問(wèn)題,，在小團(tuán)隊(duì)規(guī)模開發(fā)模式下，以個(gè)人還是以團(tuán)隊(duì)的方式考核KPI和事,？ 新技術(shù)的引入（微服務(wù),、容器化），不再適應(yīng)大軍團(tuán)作戰(zhàn),，而是需要匹配的靈活的端到端團(tuán)隊(duì)。在一個(gè)分層比較多的組織里面,，最難做到的是管理水平化,，往往在團(tuán)隊(duì)外增加“保姆式”的組織或監(jiān)控流程。這樣團(tuán)隊(duì)除了日常的工作,，還要疲于應(yīng)付那些水平管理所帶來(lái)的溝通,、會(huì)議等。這樣整個(gè)團(tuán)隊(duì)都在疲于加班,，但是事情依然無(wú)法按時(shí)完成,。 客戶的需求變化已經(jīng)不再局限于整體產(chǎn)品購(gòu)買，而是傾向于業(yè)務(wù)快速迭代,，大軍團(tuán)作戰(zhàn)已經(jīng)難以快速交付,、快速變更,。如何配合客戶的業(yè)務(wù)變更成為傳統(tǒng)大型產(chǎn)品銷售型企業(yè)最大的挑戰(zhàn)。因?yàn)橐粋€(gè)客戶的產(chǎn)品已經(jīng)難以復(fù)制性再交付給下一個(gè)客戶了,。在這樣的市場(chǎng)條件下,，如何將系統(tǒng)更大程度的拆解與靈活組裝考驗(yàn)架構(gòu)設(shè)計(jì)能力，也同樣考驗(yàn)開發(fā)組織形式的變更能力,。
敏捷開發(fā)不是個(gè)新鮮事物,，但是隨著微服務(wù)、容器化等新技術(shù)理念的推出,，敏捷開發(fā)找到了更合適的切合點(diǎn)而已,。 什么是Scrum敏捷開發(fā)
幾個(gè)值得思考的問(wèn)題： 團(tuán)隊(duì)對(duì)于需求范圍是否有自主性？ 開發(fā)范圍是否是根據(jù)時(shí)間倒排,？ 是流程管控開發(fā)人員,，還是人主導(dǎo)流程？
在有市場(chǎng)交付壓力的團(tuán)隊(duì)中,，最容易遇到的問(wèn)題就是倒排時(shí)間,。因?yàn)榻桓秲?nèi)容與交付日期已經(jīng)先確定了，然后當(dāng)遇到開發(fā)瓶頸的時(shí)候,，第一個(gè)想到的就是給團(tuán)隊(duì)增加人手,。但是別忘了一個(gè)經(jīng)典的說(shuō)法，一個(gè)女人生一個(gè)孩子需要9個(gè)月,，那么9個(gè)女人是否可以一個(gè)就生出一個(gè)孩子呢,？答案是顯而易見的。另外一個(gè)說(shuō)法就是,，如果所有的需求都是高優(yōu)先級(jí)的,，那么所有的需求都是低優(yōu)先級(jí)的。 具體什么是Scrum敏捷開發(fā),，大家可以參考一下這本書：<<Successding with Agile Software Development with Scrum>> 不過(guò)還是跟大家強(qiáng)調(diào)一點(diǎn),，流程是死的，人是活動(dòng),，需要根據(jù)團(tuán)隊(duì)情況進(jìn)行變通,。 區(qū)別
現(xiàn)在已經(jīng)不流行敏捷開發(fā)，而是流程DevOps了,。其實(shí)可以這樣說(shuō),，不以敏捷開發(fā)為基礎(chǔ)的DevOps都是耍流氓。 Scrum不是等同DevOps,，也不等同與現(xiàn)在更流行的SRE的概念,。（具體SRE是什么，大家可以搜索一下）。DevOps和SRE將運(yùn)維管理引入到開發(fā)團(tuán)隊(duì)中,，將運(yùn)維情況與開發(fā)形成一個(gè)閉環(huán),，是開發(fā)更能有效的考慮實(shí)際使用情況。個(gè)人理解,，其三者的關(guān)系如下圖：
'scrum vs devops vs sre'
困境
雖然很多時(shí)候,，大家都覺得敏捷開發(fā)， DevOps等理念都很好,，但是就是很難去實(shí)行,，最大的借口就是原來(lái)需要做的事情太多。但是這個(gè)時(shí)候,，無(wú)論是團(tuán)隊(duì)還是管理者,，需要停下腳步，做下思考,，因?yàn)槟阌龅降那闆r很可能與下面這個(gè)圖類似(來(lái)自互聯(lián)網(wǎng))：
'hard work'
公司形態(tài)與Scrum模式
不同的公司業(yè)務(wù)形態(tài)是否Scrum的方式都一樣呢,？我的理解是核心是相通的，方式是靈活適配的,。主要分為兩種主要形態(tài)： 自運(yùn)營(yíng)/服務(wù)模式Scrum流程概貌
參考下圖：
'operation mode'
在自運(yùn)營(yíng)的場(chǎng)景下,，市場(chǎng)人員和產(chǎn)品的策略管理者(SPM)來(lái)探討大的產(chǎn)品方向，然后業(yè)務(wù)分析師(BSA)做相應(yīng)的規(guī)劃,，然后各個(gè)子產(chǎn)品Owner,，俗稱Product Owner(PO)根據(jù)這些輸入制定各自產(chǎn)品的Backlog，然后規(guī)劃各自產(chǎn)品的迭代,。這里引出一個(gè)問(wèn)題,，怎么將抽象的需求或者業(yè)務(wù)需求拆解到各個(gè)子產(chǎn)品中呢？一般的做法是頂層有對(duì)應(yīng)的架構(gòu)師（俗稱首席架構(gòu)師）,，他來(lái)規(guī)劃產(chǎn)品的邊界,，與大的需求的拆分。但是這樣的人比較難找,，因?yàn)樗纫脴I(yè)務(wù),，還要設(shè)計(jì)整體體系的架構(gòu)，還要能分解需求邊界等等,。如果你遇到這樣的人,，千萬(wàn)不錯(cuò)過(guò)。 在自運(yùn)營(yíng)或者以服務(wù)的形式向客戶提供支持的場(chǎng)景下,，每個(gè)子產(chǎn)品的PO自行規(guī)劃迭代范圍，自行規(guī)劃上線時(shí)間,。不是所有的特性都要完成才能上線,。對(duì)于跑的快的團(tuán)隊(duì)，其實(shí)可以將某個(gè)需要?jiǎng)e的子產(chǎn)品配合的特性的提前上線的，盡管這個(gè)特性還沒有真正能使用,。對(duì)于產(chǎn)品關(guān)聯(lián)依賴的特性,，則可以通過(guò)PO間的Scrum2Scrum協(xié)調(diào)解決。(后面講) B2B的Scrum流程概貌
參考下圖：
'b2b mode'
在B2B的產(chǎn)品銷售模式下,，很難做到各自獨(dú)立的子產(chǎn)品對(duì)客戶發(fā)布,，因?yàn)榭蛻粜枰氖且粋€(gè)Turn Key的交鑰匙模式。在這種模式下是否就不可以做到敏捷開發(fā)呢,？其實(shí)也不然,。 和前面的自運(yùn)營(yíng)模式不同的是，各個(gè)子產(chǎn)品不會(huì)發(fā)布到生產(chǎn)環(huán)境中,，但是各個(gè)子產(chǎn)品依然可以根據(jù)自己的節(jié)奏做發(fā)布,。只是需要在特定的時(shí)間，將各個(gè)子產(chǎn)品的組合起來(lái)做一次基線測(cè)試和聯(lián)調(diào),，出一個(gè)整個(gè)產(chǎn)品的基線版本就好,。這里需要主要的是，不用拉齊各個(gè)產(chǎn)品的版本節(jié)奏,，而是根據(jù)時(shí)間點(diǎn)對(duì)不同的子產(chǎn)品做版本選擇就好,。另外集成測(cè)試團(tuán)隊(duì)只是在需要的時(shí)候臨時(shí)組建，而不是固定的團(tuán)隊(duì),。切記,，平時(shí)這些集成測(cè)試的人員應(yīng)該在各個(gè)子產(chǎn)品的團(tuán)隊(duì)中。各個(gè)子產(chǎn)品間的集成測(cè)試應(yīng)該在功能特性完成時(shí)就獨(dú)立去做了,。這個(gè)基線測(cè)試更像是集成的回歸測(cè)試,。 Scrum 2 Scrum
對(duì)于產(chǎn)品比較龐大的系統(tǒng)而言，一個(gè)業(yè)務(wù)流程很可能涉及多個(gè)子產(chǎn)品,，這樣就需要不同的團(tuán)隊(duì)的PO/SA一起做協(xié)調(diào)與溝通了,。
'scrum 2 scrum'
通常是Chieft SA召集（平臺(tái)類產(chǎn)品）或者Businss System Analyst(業(yè)務(wù)類分析師)召集。Strategy Product Manager和Release Project Manager也會(huì)參與進(jìn)來(lái),。這個(gè)需要注意的是,，要避免團(tuán)隊(duì)與團(tuán)隊(duì)間的人員交叉協(xié)調(diào)與溝通，因?yàn)檫@樣會(huì)導(dǎo)致團(tuán)隊(duì)效率極其低下,。團(tuán)隊(duì)間的溝通最好由PO/SA統(tǒng)一在這個(gè)會(huì)議上協(xié)調(diào),。 另外就是，對(duì)于阻礙別的團(tuán)隊(duì)進(jìn)展的需求,，應(yīng)該優(yōu)先解決（不一定是完成整個(gè)特性,，如提供對(duì)應(yīng)的接口也是一種形式），避免團(tuán)隊(duì)間等待的情況發(fā)生,。 這個(gè)會(huì)議更多的是對(duì)于需求范圍的確定,，以及團(tuán)隊(duì)間的協(xié)調(diào),，不討論具體的方案細(xì)節(jié)。原理上不同的團(tuán)隊(duì)都是接口間的依賴,，方案可以由各自團(tuán)隊(duì)的SA負(fù)責(zé),。 對(duì)于是否需要對(duì)每個(gè)團(tuán)隊(duì)的方案進(jìn)行評(píng)審和把控，取決與團(tuán)隊(duì)情況,。因?yàn)楸容^難有幾個(gè)都對(duì)整體系統(tǒng)的每個(gè)模塊的方案細(xì)節(jié)都清楚的,。當(dāng)然如果有，則可以成立Change Control Board(CCB)來(lái)做專門的架構(gòu)評(píng)審,。 Scrum Team的組成與角色分工
對(duì)于Scrum團(tuán)隊(duì)的組成,，一直沒有一個(gè)很好的定義，人數(shù)的多少總是爭(zhēng)議的焦點(diǎn),。另外就是當(dāng)遇到變化的時(shí)候,，到底是給團(tuán)隊(duì)增加人手還是有別的好的方式呢？從實(shí)踐看,，對(duì)于一個(gè)團(tuán)隊(duì)的事情變化,，負(fù)荷變重后，最好的方式重新成立一個(gè)Scrum團(tuán)隊(duì)接管新的任務(wù)遠(yuǎn)遠(yuǎn)比給團(tuán)隊(duì)增加人手的方式容易的多,。畢竟新人的加入在一段時(shí)間并不能給團(tuán)隊(duì)產(chǎn)生正向的價(jià)值,，因?yàn)樾枰獪贤ㄈ诤稀１３諷crum團(tuán)隊(duì)的穩(wěn)定性是首要原則,。那么什么樣的規(guī)模的團(tuán)隊(duì)比較合適呢,？或許和7這個(gè)數(shù)字比較有緣吧（我家的車牌就有777 -:)），團(tuán)隊(duì)的規(guī)模在7個(gè)人左右的規(guī)模比較容易操作,，一來(lái)溝通的成本比較低,，二來(lái)無(wú)需安排特定的人員做管理類的工作。這樣整個(gè)團(tuán)隊(duì)都會(huì)聚焦在具體的事情上,。 團(tuán)隊(duì)的組成方式：1-1-3-2,，如下圖：
'scrum team'
這里需要注意的是，在這樣的規(guī)模團(tuán)隊(duì)溝通不再是鏈?zhǔn)降臏贤ǚ绞?，而是有PO和整個(gè)團(tuán)隊(duì)傳遞需求,，SA和整個(gè)團(tuán)隊(duì)傳遞技術(shù)。這里沒有真正意義的管理者,，團(tuán)隊(duì)是自管理,，高度自治。 PO的職責(zé)根據(jù)MRD(平臺(tái)類產(chǎn)品可選)來(lái)分析和定義PRD并設(shè)計(jì)解決方案 競(jìng)品分析,、外部數(shù)據(jù)收集,，自我提出制定產(chǎn)品提升需求 并規(guī)劃產(chǎn)品的Roadmap，制定版本計(jì)劃 選定每個(gè)迭代的Scope,，對(duì)團(tuán)隊(duì)內(nèi)澄清需求 組織planning game, 組織產(chǎn)品開發(fā)中特性的Demo,，組織驗(yàn)收每個(gè)版本的交付,。組織回顧會(huì)議，總結(jié)和提升團(tuán)隊(duì)能力,。 （平臺(tái)類）收集業(yè)務(wù)產(chǎn)品反饋，推動(dòng)業(yè)務(wù)對(duì)于新特新的使用 （平臺(tái)類）運(yùn)營(yíng)產(chǎn)品,，收集產(chǎn)品運(yùn)行數(shù)據(jù),，支撐業(yè)務(wù)日常使用的方案支持等 與架構(gòu)師配合，規(guī)劃產(chǎn)品的技術(shù)改進(jìn)
這里需要再此強(qiáng)調(diào)的是,，PO需要能夠控制團(tuán)隊(duì)的開發(fā)節(jié)奏,，屏蔽外界對(duì)于團(tuán)隊(duì)的干擾，同時(shí)還要展現(xiàn)團(tuán)隊(duì)的核心價(jià)值,。千萬(wàn)不要做成傳聲筒的角色,。 SA的職責(zé)產(chǎn)品的技術(shù)實(shí)現(xiàn)架構(gòu)的設(shè)計(jì) 指導(dǎo)開發(fā)成員的開發(fā) 指導(dǎo)測(cè)試成員的測(cè)試設(shè)計(jì) 驅(qū)動(dòng)測(cè)試自動(dòng)化 組織Design Review、Code Review,、Test Design Review等 與PO配合,，規(guī)劃產(chǎn)品的技術(shù)改進(jìn) （平臺(tái)類）指導(dǎo)業(yè)務(wù)團(tuán)隊(duì)架構(gòu)師對(duì)于產(chǎn)品使用的技術(shù)支持
SA是這個(gè)團(tuán)隊(duì)的技術(shù)的代表，需要能代表團(tuán)隊(duì)對(duì)外做技術(shù)的PK的功底,。所以和PO的配合很重要,，一個(gè)代表需求放，一個(gè)代表實(shí)現(xiàn)方,。沒有哪方比哪方重要,，關(guān)鍵是如何用技術(shù)的方式體現(xiàn)業(yè)務(wù)的更高價(jià)值。SA對(duì)于開發(fā)的技術(shù)能力的提升富有不可代替的責(zé)任,。 Develper的職責(zé)產(chǎn)品的技術(shù)實(shí)現(xiàn) 負(fù)責(zé)子模塊的詳細(xì)設(shè)計(jì) 負(fù)責(zé)自動(dòng)化單元測(cè)試以及集成測(cè)試的開發(fā) 對(duì)產(chǎn)品的技術(shù)持續(xù)提升提供建議 對(duì)測(cè)試澄清技術(shù)細(xì)節(jié),、協(xié)助測(cè)試完善測(cè)試設(shè)計(jì) 確保代碼即時(shí)“可見”：Portal展示/Test Case Pass
最為開發(fā)，除了完成開發(fā)任務(wù)外,，還需要對(duì)于業(yè)界的技術(shù)特別是開源的技術(shù)的敏感度,。加入某些開源的項(xiàng)目，提供一些自己的代碼將是十分有意義的,。如果能有自己的想法,，自己創(chuàng)建出自己的開源例子那更加完美。不過(guò)國(guó)內(nèi)的開源情況,，開源還是背靠公司表容易推進(jìn),。 Tester的職責(zé)產(chǎn)品的測(cè)試設(shè)計(jì) 完善測(cè)試自動(dòng)化工具與流程 驅(qū)動(dòng)開發(fā)的完善與補(bǔ)充開發(fā)思考上遺漏 負(fù)責(zé)端到端的系統(tǒng)級(jí)測(cè)試、性能測(cè)試,、穩(wěn)定性測(cè)試 為開發(fā)定位問(wèn)題提供便利 產(chǎn)品的發(fā)布執(zhí)行
對(duì)于測(cè)試,，這里需要多說(shuō)一些。因?yàn)橛行┗ヂ?lián)網(wǎng)公司開始推行無(wú)測(cè)試的團(tuán)隊(duì),。其實(shí)并不代表測(cè)試已經(jīng)不重要了,，而是互聯(lián)網(wǎng)的快速變化使得對(duì)于測(cè)試人員的要求與開發(fā)一樣高了,，而且團(tuán)隊(duì)的運(yùn)作已經(jīng)沒有辦法再預(yù)留出測(cè)試的空檔期了。不過(guò)這個(gè)還是要看團(tuán)隊(duì)的情況,，如果測(cè)試能夠從每個(gè)迭代就能開始做測(cè)試設(shè)計(jì),，那么測(cè)試獨(dú)立性還是有必要性的。如果團(tuán)隊(duì)總是以開發(fā)主導(dǎo),，變化總是比較隨意（或者叫無(wú)法拒絕變化）,，或許還是開發(fā)自己測(cè)試比較合適。 另外就是測(cè)試最重要的職責(zé)是測(cè)試設(shè)計(jì),，而不是開發(fā)的幫手,，更不是給開發(fā)打雜。測(cè)試最重要的價(jià)值體現(xiàn)是找到架構(gòu),、開發(fā)上的思維漏洞而不是bug的數(shù)量,。如果還是用KPI的方式考核測(cè)試對(duì)于開發(fā)的bug的數(shù)量，除了助長(zhǎng)開發(fā)與測(cè)試的矛盾,，別無(wú)益處,。 開發(fā)與測(cè)試的磨合溝通、溝通還是溝通,。 開發(fā)和測(cè)試的信息來(lái)源將都來(lái)自于產(chǎn)品需求,，而不是開發(fā)是測(cè)試的上游 測(cè)試的定位的轉(zhuǎn)化。 在Scrum模式下,，開發(fā)與測(cè)試的工作邊界將更加模糊,。 測(cè)試有個(gè)最主要的功能是測(cè)試點(diǎn)的設(shè)計(jì)而不是通過(guò)復(fù)雜的重復(fù)性工作來(lái)體現(xiàn)測(cè)試的價(jià)值。 測(cè)試應(yīng)該更好的思考如何提供便利的工具,。讓定位問(wèn)題和更加方便 開發(fā)則應(yīng)該配合測(cè)試一起詳細(xì)review測(cè)試點(diǎn)的設(shè)計(jì),，并從而思考開發(fā)中潛在的問(wèn)題。
團(tuán)隊(duì)的日?；顒?dòng)
Planning Game
Planning Game的目的是向團(tuán)隊(duì)傳遞這個(gè)迭代的范圍，確保團(tuán)隊(duì)每個(gè)人都有一致的目標(biāo),。在一個(gè)或者兩個(gè)迭代后要以發(fā)布一個(gè)版本為結(jié)果,。那么每個(gè)版本都可以用一句話的方式總結(jié)出來(lái)。如果每個(gè)迭代沒有一個(gè)核心的思想,，則迭代范圍將比較混亂,，團(tuán)隊(duì)的工作也容易無(wú)序。定出來(lái)的范圍,，需要預(yù)先拆解成每個(gè)任務(wù)項(xiàng),，并且把任務(wù)放到gitlab issue中管理，讓每次代碼提交都能關(guān)聯(lián)起來(lái),，便于后續(xù)的代碼的審核,。同時(shí)將任務(wù)寫到字條上貼在自己團(tuán)隊(duì)的看板中,。看板現(xiàn)在有很多電子版的管理工具,，但是不用糾結(jié)這個(gè),，其實(shí)一個(gè)真實(shí)的看板更管用。（后面會(huì)講我們和電子類的看板的不同）
'planning game'
Planning Game的經(jīng)驗(yàn)： 不要一次性選擇多個(gè)大的feature在一個(gè)版本中 選擇一些小功能或改進(jìn)性功能作為風(fēng)險(xiǎn)控制的緩沖 預(yù)留技術(shù)改進(jìn)的工作項(xiàng) 以版本維度作為計(jì)劃 一個(gè)版本中以2個(gè)開發(fā)迭代（4周）為好 需要做發(fā)布到生產(chǎn)的,，預(yù)留一周做發(fā)布緩存
看板與站會(huì)
目前已經(jīng)有不少電子類的工具提供看板的功能,，但是實(shí)踐中，使用一個(gè)真實(shí)的看板反而比較容易操作,。看板雖然并不復(fù)雜,，但是也有相應(yīng)的書,，可以參考<<Kanban in Action >>，如下圖：
'kanban'
和電子類的看板的區(qū)別主要在于： 聚焦事與人,，而非進(jìn)度,。一般的看板總是將不同的task按照進(jìn)度進(jìn)行粘貼，處理人寫在字條上,。這樣容易讓人忽略誰(shuí)正在處理的事情,，容易忽略誰(shuí)的情況是最后交付的風(fēng)險(xiǎn) 將事情歸類整理，如某個(gè)特性相關(guān)的事情都粘貼在一起,，這樣日常容易掌控某個(gè)特性是否能夠端到端的完成,，而不至于同時(shí)并行過(guò)多的特性開發(fā)，導(dǎo)致最后無(wú)法端到端完成,。這樣也容易處理在迭代末尾需要砍任務(wù)的時(shí)候比較容易
有了看板,，那么日常的站會(huì)進(jìn)行將比較容易，不過(guò)有些注意點(diǎn)如下： 盡可能簡(jiǎn)短(15min內(nèi)),，每個(gè)人只講完成情況和遇到的問(wèn)題,，不具體討論方案 需要特意申明需要配合的內(nèi)容 額外增加的內(nèi)容，需要立即貼出來(lái)并由PO判斷是否需要做 自主領(lǐng)取新的內(nèi)容,，如果有工作依賴或難度的內(nèi)容,，需要TL協(xié)調(diào) 風(fēng)險(xiǎn)需要立即提出 盡可能做完一個(gè)任務(wù)在領(lǐng)下一個(gè)任務(wù) 如果發(fā)現(xiàn)任務(wù)時(shí)間過(guò)長(zhǎng)，需要做分析和拆解 如果覺得任務(wù)有難度,，開發(fā)應(yīng)該提出要求SA給出設(shè)計(jì)
Review Meeting
在團(tuán)隊(duì)的日?；顒?dòng)中，有各類的Review Meeting,，主要目的是團(tuán)隊(duì)內(nèi)信息的有效傳遞以及貢獻(xiàn)團(tuán)隊(duì)的智慧,。具體操作經(jīng)驗(yàn)如下： 由各個(gè)主題的Owner自主組織，包括：Design Review, Code Review, Test Design Review, Retrospect Review 對(duì)于比較大或比較復(fù)雜的設(shè)計(jì)可以分階段Review: 1/3->1/2->final Review一定要有最后的完整輸出 時(shí)間長(zhǎng)度一定要控制,，1個(gè)小時(shí)為宜,，時(shí)間過(guò)長(zhǎng)應(yīng)該分多次
End to End Demo
團(tuán)隊(duì)PO的要確保對(duì)于迭代中交付物的驗(yàn)收,，最好的方式就是組織端到端的功能特性的Demo。培養(yǎng)團(tuán)隊(duì)有意識(shí)的在每次提交代碼的時(shí)候,，都能快速將結(jié)果展示出來(lái),。 Demo會(huì)的一些經(jīng)驗(yàn)： 目前團(tuán)隊(duì)對(duì)于輸出的理解是否一致，是否滿足PO的想法 不要局限在一定完整測(cè)試完,，只要能端到端跑完場(chǎng)景即可 不要局限一定在版本交付前,，而是每個(gè)feature為維度，時(shí)間可長(zhǎng)可短,，越早越好 不要局限一定要有界面,，跑測(cè)試代碼也是一種Demo 不是去挑刺，也不是去測(cè)試
同時(shí)Demo會(huì)也可以邀請(qǐng)一些關(guān)鍵任務(wù)參與,，如市場(chǎng)人員,，樹立大家對(duì)于產(chǎn)品的信息，以及傳達(dá)團(tuán)隊(duì)對(duì)于產(chǎn)品更深刻的理解,。 DoD Meeting
DoD: Definition of one,。DoD會(huì)議主要目的是團(tuán)隊(duì)對(duì)于一個(gè)迭代的輸出的總結(jié)。團(tuán)隊(duì)這個(gè)時(shí)候可以找個(gè)輕松的環(huán)境如咖啡廳進(jìn)行,。
'dod'
DoD的一些經(jīng)驗(yàn)：
－ 以迭代為維度作為DoD
－ 版本中的第一個(gè)迭代的DoD要為下一個(gè)迭代做好風(fēng)險(xiǎn)控制,，及時(shí)調(diào)整版本范圍
－ 不要只關(guān)注代碼是否已經(jīng)完成，要同時(shí)關(guān)注自動(dòng)化程度,、代碼質(zhì)量程度（Jenkins狀態(tài),， Sonar狀態(tài)），文檔情況(Doc, Wiki),，測(cè)試結(jié)果,，是否已經(jīng)CodeReview，是否已經(jīng)做了代碼清理工作(如掃描ToDo)等 Retrospect Meeting
回歸會(huì)主要團(tuán)隊(duì)的自我反省以及自我提供,，主要是提供機(jī)會(huì)給團(tuán)隊(duì)成員思考有哪些地方做的好的,，哪些需要提高的，哪些地方有遺漏等,。
'retrospect'
Retrospect meeting的經(jīng)驗(yàn)： 需要先回顧上一次回顧會(huì)的執(zhí)行情況 每項(xiàng)內(nèi)容每個(gè)成員各寫3個(gè)認(rèn)為是重點(diǎn)的內(nèi)容,，寫在便利貼上 不是批斗會(huì)也不是拍馬屁會(huì) 需要總結(jié)后制定Action Plan 盡可能把氛圍調(diào)整在一個(gè)輕松的環(huán)境如咖啡屋 頻率可以是兩個(gè)版本一次（8-10周）
總結(jié)
'summary'
人是活的，流程是死的,；沒有明文禁止的,，都是應(yīng)該可以改變的 大家不要過(guò)于拘束學(xué)術(shù)上的定義，而是真實(shí)根據(jù)自己團(tuán)隊(duì)的情況進(jìn)行調(diào)整,，適應(yīng)以及高效就是好的流程,。也不是說(shuō)Scrum一定能保證高效，也不是說(shuō)沒有Scrum就不高效，一切取決于人,。就像有些大的互聯(lián)網(wǎng)公司的核心平臺(tái)團(tuán)隊(duì),，每個(gè)人的能力和自主性都很強(qiáng)，沒有比散養(yǎng)更好的管理方式了,。 另外,，如果管理者愿意看到團(tuán)隊(duì)的自治與效率提升，則切實(shí)應(yīng)該考慮如何更好的去信任團(tuán)隊(duì),，去輔助團(tuán)隊(duì)自治,，而不是在去做“保姆式”管理。
|
