嵌入式項目開(kāi)發(fā)總是單打獨斗，該如何管理？

瀑布模式

瀑布模型是比較傳統一種開(kāi)發(fā)模式，特別是在2B的傳統企業(yè)，包括ERP，MES，WMS，CRM，OA，IBMS等系統當中可以經(jīng)常見(jiàn)到他們的影子。

現在這種模式仍然流行在一些大的項目或者是外包的一些項目當中。

如上圖所示，瀑布模型優(yōu)缺點(diǎn)都很突出。

• 階段清晰。從計劃到開(kāi)發(fā)最后到上線(xiàn)運行，三個(gè)階段非常清晰。
• 時(shí)間順序。每個(gè)階段順序必須是從上到下，嚴格按照時(shí)間先后進(jìn)行。
• 環(huán)環(huán)相扣。在每一個(gè)階段都必須有產(chǎn)出物然后才能進(jìn)入到下一個(gè)階段進(jìn)行。
• 黑盒模式。每個(gè)階段都有各自的角色和分工，各自只關(guān)心自己的任務(wù)。比如需求階段開(kāi)發(fā)人員無(wú)需關(guān)注。

• 需求隔離。由于各階段的人員只能接觸到自己工作范圍內的東西，所以對客戶(hù)需求的理解程度高低不等，開(kāi)發(fā)人員更像是定義為流水線(xiàn)上的工人。
• 變更代價(jià)大。既然叫做瀑布，就意味著(zhù)不應該走回頭路。否則如果出現返工，付出的代價(jià)會(huì )很大。需求變更，編碼人員會(huì )很強的抵觸情緒。
• 束縛創(chuàng )造性。由于強調文檔管理，所以管理人員會(huì )比較喜歡，但是他束縛了開(kāi)發(fā)人員的創(chuàng )造性。
• 周期漫長(cháng)。整個(gè)開(kāi)發(fā)持續的生命周期很長(cháng)，需求和設計的時(shí)間會(huì )耗費特別多，有時(shí)候會(huì )占用三分之一甚至更多時(shí)間，這樣整個(gè)周期就會(huì )變長(cháng)，大都在半年到一年左右的時(shí)間，所以更適合需求相對穩定的大項目。

根據以上分析，我們知道瀑布模式強調里程碑，重視文檔，強調分工，避免變化，凡事喜歡規劃和做計劃，但是代價(jià)就是拖沓笨重，反應遲鈍。

敏捷開(kāi)發(fā)借助互聯(lián)網(wǎng)浪潮開(kāi)始流行起來(lái)，這也是2C的業(yè)務(wù)特點(diǎn)決定的，看過(guò)QQ和微信長(cháng)大的人，這種體會(huì )特別深?；ヂ?lián)網(wǎng)產(chǎn)品不可能一步規劃到位，一般都是核心功能優(yōu)先，比如微信，先是實(shí)現聊天功能，然后才是漂流瓶，錢(qián)包，小程序……

互聯(lián)網(wǎng)業(yè)務(wù)有何特點(diǎn)呢？借用雷軍的七字訣：專(zhuān)注、極致、口碑、快。

• 唯有專(zhuān)注才能聚焦能量，引爆燃點(diǎn)。
• 唯有極致才能排除競爭，爭取用戶(hù)。
• 金杯銀杯不如口碑。
• 天下武功唯快不破。

敏捷無(wú)疑更加貼近互聯(lián)網(wǎng)的這種業(yè)務(wù)需求，如果純用瀑布模式，估計黃花菜都涼了。

敏捷還有一個(gè)更極致的做法，直接上PPT通過(guò)類(lèi)似眾籌的方式進(jìn)行開(kāi)發(fā)，這種從群眾中來(lái)到群眾中去的個(gè)性化定制功能非常的有創(chuàng )意，如果眾籌的結果是沒(méi)有人感興趣，就可以直接否定該產(chǎn)品開(kāi)發(fā)，可以避免無(wú)謂的“庫存”導致的開(kāi)發(fā)壓力，節省巨大的成本浪費。

Scrum的意思是橄欖球運動(dòng)的一個(gè)專(zhuān)業(yè)術(shù)語(yǔ)，表示“爭球”的動(dòng)作。把一個(gè)開(kāi)發(fā)流程的名字取名為一項體育運動(dòng)，你一定能感受到其中的碰撞，沖突，激情。如果是這樣，Scrum如何能提高開(kāi)發(fā)效率呢？

敏捷開(kāi)發(fā)是一種指導思想，Scrum和XP則是敏捷開(kāi)發(fā)的具體開(kāi)發(fā)流程，這里只選擇Scrum進(jìn)行探討。

我們先來(lái)看下Scrum的三個(gè)角色：

• 產(chǎn)品負責人：提供整體產(chǎn)品需求清單，確定產(chǎn)品邊界，功能組合圖譜，交付內容和日期。另外產(chǎn)品負責人有權拒絕開(kāi)發(fā)團隊的開(kāi)發(fā)成果。
• 開(kāi)發(fā)團隊：因為追求快，開(kāi)發(fā)人員需要很強的自我管理能力，需要主動(dòng)反饋，主動(dòng)溝通。
• 流程管理員：主要任務(wù)是疏通開(kāi)發(fā)和業(yè)務(wù)的障礙，起到一個(gè)膠水的粘合作用，所以一旦開(kāi)發(fā)進(jìn)行，流程管理員有權拒絕需求的變更或修改。

Scrum是一個(gè)理想化的開(kāi)發(fā)流程，前提條件是角色完整，分工明確，配合默契，溝通融洽。如果出現其中任何一個(gè)環(huán)節的故障，可能都會(huì )破壞流程的效率，比如，開(kāi)發(fā)經(jīng)理和流程管理員脾氣一樣倔強，脾氣互斥，那么整個(gè)效率就打折扣。我感覺(jué)在招聘人員，團結組建的過(guò)程中，我們務(wù)必要尋找氣味相投的人，這可以減少開(kāi)發(fā)過(guò)程中的沖突。

Scrum和瀑布的本質(zhì)區別是，一個(gè)以文檔為本，一個(gè)以人為本。在以人為本的團隊里，領(lǐng)導者的文化就是團隊的文化。

如果領(lǐng)導者不透明，喜歡玩虛假，自大，官僚氣十足，這個(gè)團隊基本上就沒(méi)什么希望了。人必須是主人，有能動(dòng)性，這個(gè)高度困難。因為如何讓團隊覺(jué)得公司的事是我家里的事是高度困難的，因為有些開(kāi)發(fā)人員自己家的事都沒(méi)怎么認真過(guò)。想要做到這點(diǎn)，需要老板重視，否則中層領(lǐng)導我感覺(jué)一般都心有余力不足。

• 首先需要確定一個(gè)產(chǎn)品需求列表，由產(chǎn)品負責人負責；

• 開(kāi)發(fā)團隊根據列表，做工作量的預估和安排；
• 有了產(chǎn)品需求列表，我們需要通過(guò)計劃會(huì )來(lái)從中挑選出一個(gè)故事作為本次迭代完成的最小目標，這個(gè)目標的時(shí)間周期是1~4個(gè)星期，然后把這個(gè)故事進(jìn)行細化，形成一個(gè)最小產(chǎn)品需求。比如該故事是登陸的功能故事，那么登陸的需求就要進(jìn)行完整的細化工作；
• 開(kāi)發(fā)成員根據故事再細化成更小的任務(wù)（細到每個(gè)任務(wù)的工作量在2天內能完成）；

計劃紙牌怎么怎么用的呢？比如A程序員開(kāi)發(fā)一個(gè)功能，需要5個(gè)小時(shí)，B程序員認為只需要半小時(shí)，那他們各自取相應的牌，藏在手中，最后攤牌，如果時(shí)間差距很大，那么A和B就可以討論A為什么要5個(gè)小時(shí)...

• 開(kāi)發(fā)過(guò)程需要設置每日站會(huì )，每次會(huì )議控制在15分鐘左右，每個(gè)人都必須發(fā)言，并且要向所有成員當面匯報三個(gè)問(wèn)題：A.你昨天完成了什么；B今天要完成什么；C.什么問(wèn)題不能解決。

每個(gè)人回答完成后，要走到黑板前更新自己的sprint燃盡圖；

• 每日集成，也就是每天都要有一個(gè)可以成功編譯、并且可以演示的版本，可以機制CI,CD工具進(jìn)行輔助開(kāi)發(fā)；
• 當一個(gè)故事完成，也就是最小目標被完成，這時(shí)，我們要進(jìn)行演示會(huì )議，也稱(chēng)為評審會(huì )議，產(chǎn)品負責人和客戶(hù)都要參加（最好本公司老板也參加），每一個(gè)開(kāi)發(fā)成員都要向他們演示自己完成的軟件產(chǎn)品（這個(gè)會(huì )議非常重要，一定不能取消）；

• 最后就是回顧會(huì )議，也稱(chēng)為總結會(huì )議，以輪流發(fā)言方式進(jìn)行，每個(gè)人都要發(fā)言，總結并討論改進(jìn)的地方，放入下一輪sprint的產(chǎn)品需求中；

大家如果認真的看完整個(gè)Scrum的開(kāi)發(fā)流程，會(huì )發(fā)現這個(gè)過(guò)程還真的是很完美，不妨可以用在你的團隊開(kāi)發(fā)過(guò)程中。

瀑布敏捷是有邊界的，我覺(jué)得團隊在整體學(xué)習開(kāi)發(fā)模式優(yōu)劣后，需要對二者的邊界有一個(gè)清晰的認識，并在整個(gè)團隊上下都要達成一致的共識，否則后果可能會(huì )很?chē)乐?。雙方的邊界如下圖所示

為什么說(shuō)共識很重要呢？就我踩過(guò)的坑進(jìn)行盤(pán)點(diǎn)，有如下幾個(gè)問(wèn)題：

• 領(lǐng)導指揮不當：老板重文檔，覺(jué)得必須有文檔往下開(kāi)發(fā)才是規范的，否則后面的工作都是一種浪費，因為你的頂頭上司不一定懂技術(shù)，這樣導致的結果是文檔沒(méi)出來(lái)前，底下人只能泡茶聊天了。
• 團隊效率極低：因為瀑布強調分工，各自為戰，所以有可能架構設計人員在等產(chǎn)品經(jīng)理給需求文檔，開(kāi)發(fā)人員在等待架構設計文檔，測試人員在等待開(kāi)發(fā)成果，老板在等待產(chǎn)品交付。這里環(huán)環(huán)相扣，類(lèi)似電流串聯(lián)工作，一個(gè)環(huán)節出錯，造成斷電，導致交付延期，后果可能就是互相推諉和扯皮，嚴重的話(huà)可能會(huì )引發(fā)爭吵，團隊分崩離析。

就個(gè)人的經(jīng)驗來(lái)看，瀑布和敏捷不是天然分割的，只是針對業(yè)務(wù)各有側重，應該是你中有我，我中有你的混合體。比如微信第一版的時(shí)候，聊天核心功能的迭代一定也有內部的小瀑布，如果沒(méi)有計劃-開(kāi)發(fā)-測試-運維根本就無(wú)法進(jìn)行下去。

再比如瀑布，特別對創(chuàng )業(yè)團隊，剛開(kāi)始人手不多，分工不明，架構師有可能要去畫(huà)原型圖，做需求調研；產(chǎn)品經(jīng)理業(yè)務(wù)模糊，還在探索，各種短板和不足就像黑洞一樣存在你的周邊，你渾然無(wú)知。如果你一定要等整個(gè)調研完成，PRD文檔周全再做開(kāi)發(fā)，估計也要歇菜。

既然各有利弊，那么中間的這個(gè)平衡點(diǎn)如何拿捏就非常重要，如何在前期設計的時(shí)候既能不過(guò)渡導致交付延遲，又能兼顧后續的演進(jìn)和變化導致的修改可控，這需要開(kāi)發(fā)經(jīng)理豐富的實(shí)戰歷練和審時(shí)度勢的判斷力。

另外叨叨一下，開(kāi)發(fā)模式貫穿做整個(gè)開(kāi)發(fā)的生命周期，但是團隊各個(gè)成員包括產(chǎn)品經(jīng)理，技術(shù)經(jīng)理，架構師，開(kāi)發(fā)人員對項目管理的流程理解各不相同，深淺不一，很難想象如果大家沒(méi)有達成共識，整個(gè)開(kāi)發(fā)團隊的效率會(huì )有多高？但是現實(shí)當中，大部分團隊成員沒(méi)有開(kāi)發(fā)模式的培訓和上下達成一致依然在進(jìn)行著(zhù)開(kāi)發(fā)的工作……

• 敏捷開(kāi)發(fā)之Scrum掃盲篇(以上部分圖片摘錄自該地址)
• 敏捷開(kāi)發(fā)之Scrum掃盲篇
• 敏捷開(kāi)發(fā) 模型講解
• 軟件開(kāi)發(fā)模式之敏捷開(kāi)發(fā)

轉自: https://www.cnblogs.com/jackyfei/p/10078988.html