互聯(lián)網(wǎng)團(tuán)隊(duì)開發(fā)流程

精選優(yōu)質(zhì)文檔-----傾情為你奉上精選優(yōu)質(zhì)文檔-----傾情為你奉上專心---專注---專業(yè)專心---專注---專業(yè)精選優(yōu)質(zhì)文檔-----傾情為你奉上專心---專注---專業(yè)為什么需要敏捷開發(fā)。在幾萬年以前，軟件項(xiàng)目的開發(fā)都是以年來計(jì)算的，這代表什么意思呢？需求設(shè)計(jì)了半年多，方案設(shè)計(jì)做了半年多，開發(fā)了三年多，了半年多，修改Bug用了半年多。總計(jì)花了很長很長的時(shí)間，然后上線后發(fā)現(xiàn)有很多需求已經(jīng)不存在了，同時(shí)又出現(xiàn)了很多新的需求。怎么辦？繼續(xù)改。這一改又是半年多的時(shí)間過去了。馬丹用戶的需求還再改，怎么辦？這是困擾軟件開發(fā)項(xiàng)目的最大的問題，越大的項(xiàng)目，參與的人越多，風(fēng)險(xiǎn)越大。文檔越規(guī)范，維護(hù)起來的難度就越高，導(dǎo)致項(xiàng)目中遇到的問題越來越多。不僅僅在幾萬年前，就是在現(xiàn)在，也是經(jīng)常會(huì)有團(tuán)隊(duì)出現(xiàn)這種問題。不相信，你可以看看是否遇到了以下這些問題：1.需求總是在變動(dòng)，反復(fù)變動(dòng)，無限拖延。2.開發(fā)工程師做出來的項(xiàng)目，bug不但多，而且經(jīng)常改不好。常常是改了一個(gè)Bug，出現(xiàn)另一個(gè)Bug，好不容易把一個(gè)Bug改好了，過了沒多久又重現(xiàn)了。原本好好的功能，反而會(huì)因?yàn)楦腂ug導(dǎo)致出現(xiàn)的問題更多。3.做出來的東西完全不是產(chǎn)品經(jīng)理想要的樣子，溝通完之后才發(fā)現(xiàn)開發(fā)工程師的理解和產(chǎn)品經(jīng)理的理解是完全不一樣的。4.項(xiàng)目延期不是最壞的結(jié)果，最壞的結(jié)果是還從不知道項(xiàng)目倒底會(huì)延期多少，根本沒辦法去衡量工作量，團(tuán)隊(duì)的成員都在加班加點(diǎn)，然而完全看不出來問題出在什么地方。5.開發(fā)文檔，產(chǎn)品文檔，接口文檔，測試報(bào)告和真實(shí)的代碼從沒有完美契合過。產(chǎn)品經(jīng)理設(shè)計(jì)出來的原型和UI設(shè)計(jì)出來的頁面和程序員開發(fā)出來的代碼完全是一種不同的體系，三位一體的故事從沒有真正發(fā)生過。代碼的實(shí)現(xiàn)和接口文檔根本不一致，最后索性干脆不看接口文檔，完全口頭交流。出錯(cuò)的時(shí)候各種撕逼扯皮，誰也分不清倒底誰錯(cuò)了。6.Team的戰(zhàn)斗力和凝聚力不強(qiáng)，經(jīng)常是對(duì)著干，對(duì)分配的任務(wù)總是各種報(bào)怨，出現(xiàn)問題之后第一反應(yīng)是這個(gè)不關(guān)我的事，不是我的問題，是后端前端設(shè)計(jì)QAPM的問題。

如果你遇到了這種情況，或者說你不甘于這種現(xiàn)狀，那么恭喜你，你可以真的需要敏捷開發(fā)流程了。第二，敏捷開發(fā)包括了哪些內(nèi)容

敏捷開發(fā)總的流程如下：1.需求規(guī)劃和分期2.需求評(píng)審3.需求講解4.方案評(píng)審5.每日晨會(huì)6.性能測試7.CodeReview8.Demo9.測試階段10.線上Bug修改流程表跟我說哪些東西不應(yīng)該包含在敏捷開發(fā)流程里，如果你不喜歡，跟你的觀念有沖突，你可以把敏捷開發(fā)這四個(gè)字換成任意四個(gè)字?？傊绻鉀Q這些問題，這是我目前看到的最佳實(shí)踐，每一個(gè)節(jié)點(diǎn)都非紙上談兵，而是經(jīng)過無數(shù)個(gè)嘗試和失敗總結(jié)出來的。如果你是一個(gè)IT公司的管理者，如果你不知道該怎么去管理自己的團(tuán)隊(duì)，我強(qiáng)烈安列你按著我說的這種標(biāo)準(zhǔn)化方式去做，放心，出了問題我保證不會(huì)負(fù)一點(diǎn)責(zé)任。確切的說，我說的敏捷開發(fā)流程，并不僅僅是開發(fā)團(tuán)隊(duì)的事情，它背后隱藏著更多的理念。我可能整理的不夠清楚，畢竟這是第一版。1.產(chǎn)品和開發(fā)必須是一個(gè)Team，大家只是分工不同，角色不同，并不是兩個(gè)對(duì)立的團(tuán)隊(duì)。如果你的公司是把產(chǎn)品和開發(fā)分成兩個(gè)部門，那么恭喜你，產(chǎn)品和開發(fā)之間的糾紛一定無限多。在所有我?guī)У腡eam中，自始至終強(qiáng)調(diào)的理念就是：出了問題，別跟我說這是產(chǎn)品設(shè)計(jì)出來，這是開發(fā)團(tuán)隊(duì)實(shí)現(xiàn)不了的。我只知道這是你們一個(gè)開發(fā)小組所有人的責(zé)任，這個(gè)后果是所有的人都需要承擔(dān)的。如果我們認(rèn)真的區(qū)分這是什么問題，那么也只是為了避免下次出現(xiàn)同樣的情況，用戶只會(huì)知道是一個(gè)公司出了一款垃圾產(chǎn)品，沒有人關(guān)心到底是產(chǎn)品還是開發(fā)的鍋。這是做敏捷開發(fā)的大前提?；蛘卟粌H僅是產(chǎn)品和開發(fā)，責(zé)任共擔(dān)，OneTeam這個(gè)理念是貫穿始終的。這并不是說，大鍋飯，而是說，面對(duì)不好的結(jié)果，所有Team的人都必須共同承擔(dān)。出現(xiàn)問題的原因僅僅是為了追溯和重現(xiàn)當(dāng)時(shí)的場景，以避免后續(xù)會(huì)出現(xiàn)同樣的情況。

產(chǎn)品和開發(fā)必須是一個(gè)Team還體現(xiàn)在需求分期上。這一點(diǎn)在講到需求分期的流程的時(shí)候，會(huì)提高的。實(shí)際上，需求分期如果沒做好，敏捷開發(fā)只能流于形式。需求分期怎么做，這是MVP的事情，另一個(gè)話題。簡單來說，每一期都要有一個(gè)提前的預(yù)測，這一期里要做的所有的功能都只為了檢測自己的預(yù)測是否正確。并根據(jù)結(jié)果去不斷的調(diào)整開發(fā)規(guī)劃。2.職責(zé)明確，每個(gè)人要負(fù)責(zé)的事情必須清晰無誤，誰該做哪些事情，必須要提前講清楚。開發(fā)團(tuán)隊(duì)的推薦角色應(yīng)該是這樣的。PM1個(gè)UI1個(gè)CSS/

1~2個(gè)

2~4個(gè)

1~2個(gè)

1~2個(gè)QA1個(gè)這是一個(gè)相對(duì)平衡的模板，這樣的一個(gè)8~10人的小Team，是可以復(fù)制的。敏捷開發(fā)支持多個(gè)Team并行開發(fā)。理論上來講。這種方式，可以支持五到六個(gè)小Team同時(shí)啟動(dòng)。在講到最后多Team并發(fā)協(xié)作的時(shí)候，我也會(huì)提到的。除了這些項(xiàng)目小組的角色，還有各個(gè)Team的Leader。我比較推薦小組分成如下幾種：1.產(chǎn)品Team產(chǎn)品團(tuán)隊(duì)2.用戶體驗(yàn)Team傳統(tǒng)的UI團(tuán)隊(duì)升級(jí)為UE，升級(jí)為整個(gè)系統(tǒng)甚至是公司的用戶體驗(yàn)師。3.后端Team苦逼的后端4.前端Team

//JS表問我為什么把這三個(gè)放到一起，我就是認(rèn)為一個(gè)前端工程師應(yīng)該三者通吃?？梢栽谀骋粋€(gè)客戶端上了解的更深入，但是普通的項(xiàng)目上手還是應(yīng)該沒有問題的。5.QATeamQA只需要做功能測試，回歸測試，邊界測試，并不需要做性能測試。這里也會(huì)在后面提到。

那么來描述一下每個(gè)角色的不同職責(zé)。這些不同的角色牽涉到團(tuán)隊(duì)并行開發(fā)，所以并不是簡單的隨便扒拉到一堆就好了的。PM

：PM的職責(zé)并不是畫原型，而是去分產(chǎn)品的分期，確定產(chǎn)品要做的功能和優(yōu)先級(jí)。對(duì)于產(chǎn)品來說，最大的職責(zé)并不是將原型畫出來，而是要證明自己要做的功能是合理的。如果你證明不了自己要做的功能是合理的，是值的嘗試的，就是產(chǎn)品經(jīng)理的失職?？梢詤⒖糓VP，有無數(shù)的辦法可以提前驗(yàn)證，如果不能夠提前驗(yàn)證，那么就證明這是有風(fēng)險(xiǎn)。做為PM，一定要有這種風(fēng)險(xiǎn)的意識(shí)，要知道自己身上擔(dān)負(fù)的責(zé)任，PM花了兩周時(shí)間設(shè)計(jì)的原型，8人的開發(fā)團(tuán)隊(duì)要折騰近三周左右的時(shí)間。原型和產(chǎn)品文檔都是輔助的東西，我甚至不推薦產(chǎn)品經(jīng)理去做原型設(shè)計(jì)，只拆分Story。原型設(shè)計(jì)交給傳統(tǒng)的UI更合適。然而在真實(shí)實(shí)施的過程中，因?yàn)楹苌儆蠻I具備原型的設(shè)計(jì)能力，所以實(shí)施起來會(huì)有一些難度。這個(gè)不算特別重要，慢慢培養(yǎng)。PM不需要為開發(fā)進(jìn)度負(fù)任何的責(zé)任，這很重要，不要把PM當(dāng)成項(xiàng)目管理來使用，如果你讓PM去做了項(xiàng)目管理，恭喜你，Game近乎Over，產(chǎn)品經(jīng)理沒有時(shí)間再去思考如何做功能了。PM的職責(zé)就是把功能設(shè)計(jì)好，優(yōu)先級(jí)排好，給開發(fā)團(tuán)隊(duì)講清楚需求，結(jié)合Story優(yōu)先級(jí)和功能實(shí)現(xiàn)的大概時(shí)間點(diǎn)去做排期。開發(fā)工期交給開發(fā)團(tuán)隊(duì)去做，Bug會(huì)和QA，開發(fā)團(tuán)隊(duì)一起來定。記著要在開發(fā)團(tuán)隊(duì)開發(fā)項(xiàng)目的時(shí)間里，去做好下一個(gè)產(chǎn)品迭代的設(shè)計(jì)。

小組Leader：需求評(píng)審會(huì)的成員應(yīng)該包括PM組的Leader，前端組的leader,后端組的leader,測試組的Leader，或者是其他公司的中層骨干。這應(yīng)該是一個(gè)公司所有應(yīng)該為這個(gè)項(xiàng)目負(fù)責(zé)的人的評(píng)審會(huì)，在評(píng)審會(huì)上的結(jié)論，就應(yīng)該被堅(jiān)定的執(zhí)行下去了。不參與評(píng)審會(huì)的人，不應(yīng)該再對(duì)需求指手畫腳。需求評(píng)審會(huì)的目標(biāo)就是確定原封不動(dòng)的需求，所以在這里要格外的注意，PM拿出來的方案設(shè)計(jì)，一定是完整的，而且必須評(píng)細(xì)節(jié)。如果說，一個(gè)公司的中層骨干經(jīng)過需求評(píng)審會(huì)議，仍然需求亂成一比，那就沒什么可說的了，繼續(xù)努力提升自己的水準(zhǔn)，或者是補(bǔ)充真正的中層。而PM的目標(biāo)就是吸引需求評(píng)審會(huì)的意見，盡量讓自己的需求和設(shè)計(jì)通過評(píng)審。各個(gè)小組的Leader還應(yīng)該承擔(dān)的角色就是各個(gè)組的方案評(píng)審。這是中層骨干必須要起到的作用。小組的Leader還應(yīng)該負(fù)責(zé)項(xiàng)目中風(fēng)險(xiǎn)的調(diào)控，考慮是增加人手，安排加班，項(xiàng)目延期，還是調(diào)整功能。與些同時(shí)，應(yīng)該去審核最后的性能報(bào)告，看看是否達(dá)到系統(tǒng)的期望值，遇到了疑難問題如何解決。

開發(fā)組成員：項(xiàng)目進(jìn)入真正的開發(fā)階段后，開發(fā)組的成員就應(yīng)該是主動(dòng)去控制項(xiàng)目的進(jìn)度，和風(fēng)險(xiǎn)，以及主動(dòng)去測試項(xiàng)目中存在的問題，在這個(gè)階段，除了一些需求不明，或者是發(fā)生變動(dòng)的情況出現(xiàn)，不應(yīng)該去打擾產(chǎn)品經(jīng)理。不要讓產(chǎn)品經(jīng)理做開發(fā)團(tuán)隊(duì)的保姆。開發(fā)組的成員的目標(biāo)就是做好項(xiàng)目的進(jìn)度控制，有風(fēng)險(xiǎn)就及時(shí)反饋給Leader，確保自己理解的需求是明確無誤的，確保自己的測試是完整和嚴(yán)謹(jǐn)?shù)?，確認(rèn)自己寫出來的代碼是可以維護(hù)的。一定要理解清楚，一旦PM通過Story講解，將需求交付給開發(fā)組成員，那么開發(fā)組成員就應(yīng)該主動(dòng)而獨(dú)立的為這件事情負(fù)責(zé)。當(dāng)項(xiàng)目完工以后，開發(fā)組成員應(yīng)該交叉去做CodeReview，并且出性能測試報(bào)告，以及組織Demo。

測試組成員：測試級(jí)成員的職責(zé)不是做功能性的測試，也不是做性能測試。而是應(yīng)該做邊界測試和回歸測試。功能性的測試主要應(yīng)該由開發(fā)組成員完成，除了一些特別麻煩的，需要各種極端條件才能復(fù)現(xiàn)的，正常的操作過程中出現(xiàn)的問題，都應(yīng)該是有開發(fā)組承擔(dān)。性能測試同樣是開發(fā)組人員自行完成，各小組Leader只需要知道一件事情，測試報(bào)告是否能夠通過。所以測試組的主要做的就是準(zhǔn)確的記錄，以及bug的統(tǒng)計(jì)。也不應(yīng)該去天催促開發(fā)組的成員去改Bug。只需要去反饋給開發(fā)組的Leader就好了。整個(gè)CTO或者是技術(shù)總監(jiān)應(yīng)該以此為標(biāo)準(zhǔn)去衡量每個(gè)小組Leader的績效?；貧w測試是需要做的，但是也不是完全必須要做。如果能夠積累足夠多的自動(dòng)化測試用例，就去正常使用它，如果不能，就盡可能少的減少回歸測試。這需要跟開發(fā)人員溝通的比較清楚，他們往往更清楚，什么地方容易出問題。接受線上的反饋并且記錄也應(yīng)該是QA的職責(zé)，如果Team足夠細(xì)，可能會(huì)有運(yùn)營或者是客服統(tǒng)一對(duì)外收集，然后交給QA，QA再負(fù)責(zé)錄入Bug系統(tǒng)中?；镜拿艚蓍_發(fā)流程中的角色的職責(zé)大致就是這樣的了。這不是一件容易的事情，其中的很多小細(xì)節(jié)，都照顧到了每個(gè)角色的職責(zé)和義務(wù)。理論上來說，如果有一張圖的話，可以更清楚的畫出來不同角色的功能。這種職責(zé)的劃分，和傳統(tǒng)的職責(zé)會(huì)有一些不同，反正，在我?guī)н^的Team中，這是最高效的，也是最能發(fā)揮出團(tuán)隊(duì)的能力的方式。你可以信，也可以不信，這中間的每一個(gè)細(xì)小的調(diào)整，都是經(jīng)過無數(shù)個(gè)日日夜夜的驗(yàn)證而得來的，我還未曾看到過比這種職責(zé)劃分方式更高效，更合理的做法，雖然我接觸的Team也不夠多，愛信不信~3.每個(gè)人必須學(xué)會(huì)主動(dòng)去為自己的事情負(fù)責(zé)當(dāng)有了第二條，你很快就能發(fā)現(xiàn)團(tuán)隊(duì)中，誰是能夠盡守職責(zé)，更主動(dòng)的人。第3條很難做到，特別在很多公司，并不注重對(duì)于團(tuán)隊(duì)凝聚力的培養(yǎng)，也不會(huì)注重和他們之間的交流，不知道他們想要什么。所以這也是我一再強(qiáng)調(diào)的，敏捷開發(fā)并不僅僅是一個(gè)開發(fā)流程，更是一種管理的方式，他牽涉到績效考核，公司福利，上下班制度等等你看不到的東西。如果說你的團(tuán)隊(duì)成員并不能做到為自己的事情負(fù)責(zé)，那