敏捷迭代五步曲，人人都是開發(fā)主力

工序、流水線和軟件研發(fā)

在農(nóng)業(yè)時代，有民間作坊式的工序，例如：釀酒、制陶、染布。

在工業(yè)上，為了提高普工的生產(chǎn)力、工作效率和產(chǎn)量，引入并廣泛使用了流水線，從而使得每個工位只專注某一極小部分、簡單而重復的基本工作。1769年，韋奇伍德開辦陶瓷廠時進行了勞動分工，把制陶流程拆分成了十幾道工序，由不同的專人分工完成。福特汽車也通過流水線生產(chǎn)了人人都可以買得起的汽車?？梢?，流水線這一概念以及應用在工業(yè)制造所發(fā)揮的價值和帶來的作用。

例如，我們熟悉的不銹鋼中板生產(chǎn)流程。

圖片來自網(wǎng)絡

那么，在信息行業(yè)有什么？流水線和工序，對于我們進行軟件項目研發(fā)又有哪些啟發(fā)呢？

說句實在話，用戶不會太關心我們使用的是什么編程語言，需求方也不會太關心我們用的是敏捷開發(fā)、Scrum還是XP編程，他們更為關注的是：“這個需求很簡單，今晚就要上線?！?nbsp;時間就是金錢，當下的時間窗口就是百年一遇的最好時機。縱使行業(yè)不同，但本質(zhì)是相似的，不管是工業(yè)時代，還是信息時代，都是為了提升生產(chǎn)力、交付能力、交付速度和交付質(zhì)量，降低成本，提高市場競爭力。

然而，在軟件開發(fā)行業(yè)，和工業(yè)制造有著相似但又頗為不同的之處。相似地，兩都會有會專業(yè)分工，也需要既定的流程進行配合和流轉(zhuǎn)。明顯差距在于，軟件開發(fā)需要腦力集中型的工作而非體力密集型的勞動；軟件團隊所面臨的問題和待實現(xiàn)的功能都是之前從出現(xiàn)過的，而非可量產(chǎn)、千篇一律的產(chǎn)品；除此之外，軟件開發(fā)很有可能是一邊在會議室改需求、一邊在加班加點改代碼。

敏捷迭代五步曲

現(xiàn)在，在互聯(lián)網(wǎng)企業(yè)的技術團隊，可能接觸最多、討論最多和應用最為廣泛當數(shù)敏捷開發(fā)。但我們是否真的非常了解敏捷開發(fā)，以及是否得到了正確的應用和期望的收獲？

為了方便大家更好地在實際項目研發(fā)中，提升協(xié)作效率和團隊產(chǎn)出的速度和質(zhì)量，這里分享一下我總結(jié)的協(xié)作五步曲。分別是：提需求、建項目、做任務、改Bug、推發(fā)布。

雖然只有不到15個字，但請注意每個步驟的關鍵動詞，主導角色，以及在軟件研發(fā)流程中所承擔的作用。

提需求

需求是最初的起點。

提需求，關鍵在一個字：提。

看似很簡單，不就是提個需求嗎？但是正是看似最為簡單的動作和環(huán)節(jié)，控制不好就會發(fā)生全盤失控的場面。

需求的成分很復雜，并且脾氣古怪。如果梳理得當，有明確的商業(yè)目標和產(chǎn)品路線圖，并且通過產(chǎn)品經(jīng)理的梳理可以形成技術人員容易理解的PRD，將有助于整個項目周期的迭代、協(xié)作和產(chǎn)出。相反，如果只是一句話需求，或者需求未確定、未清晰，或頻繁變更需求，就會在源頭上造成非常嚴重和惡劣的影響。

在提需求前，應當根據(jù)公司的核心業(yè)務劃分產(chǎn)品線。

在接收到需求時，產(chǎn)品經(jīng)理應當梳理成書面的需求文檔、PRD。

用戶、需求方，包括產(chǎn)品經(jīng)理提出的需求，都應該先進入需求池。需求池里都是可能需要做的需求。產(chǎn)品經(jīng)理梳理好需求后，需要和負責這個需求的技術人員、測試人員、需求提出方和相關TL組織需求評審會議，對需求的背景、流程、邏輯和UI交互、注意事項等進行介紹和說明，并接受大家的提問，僅當需求評審無異議時，才能進行下一個環(huán)節(jié)。同時，如果需求評審時間過長，或者大家的提問源源不斷，也要適時中止并打回需求，等需求重新梳理并完整后重新評審。

當需求正式進入開發(fā)階段后，項目干系人可以通過需求排期實時看到自己的需求計劃上線時間、當前是什么狀態(tài)，以及負責人是哪位同事。

建項目

建項目如同蓋房子，容不得半點馬虎，需要敬畏的態(tài)度、嚴謹?shù)倪壿嬎季S和追求極致的工匠精神。

在創(chuàng)建項目時，YesDev之所以只提供了一個把需求關聯(lián)項目的入口，是出于這樣“用心良苦”的設計：我們希望在進行迭代需求規(guī)劃時，項目負責人應該在了解當前的需求環(huán)境后再進行決策和合理的安排，避免信息不全，或者安排明顯超出工作負荷的需求，或者忽略了一些優(yōu)先級極高或重要的需求。更為重要的是，我們希望大家有這樣的共識：需求變更都是有成本的，特別是中途加需求。

當項目創(chuàng)建好后，我們就可以得到項目計劃、項目排期、項目的工時。在項目進行過程中，我們可以看到項目燃盡圖、實時項目進度。

一個項目，就是一次迭代。要追求100%的進度和100%的質(zhì)量。

做任務

有了需要做的需求，也有了規(guī)劃好的項目。接下來，就是具體的“搬磚”過程。

一個項目，需要團隊里的多個成員共同參與。做任務，關鍵字是做，就是執(zhí)行能力和搞定力。

優(yōu)秀的開發(fā)程師，他會對所負責的需求進行任務評估，預計需要多少時間、什么時候完成、排期怎樣，這樣可以方便團隊內(nèi)部協(xié)作和項目經(jīng)理進行整體的項目統(tǒng)籌。因此，在做任務前，需要拆任務。

拆完任務，協(xié)調(diào)排期，接下來重點在于執(zhí)行。再完美的計劃，沒有執(zhí)行，最終也是0分。在執(zhí)行過程中，還要注重進度同步、快速反饋，和風險預警播報。通過每日站會、任務看板等會議和工具，可以在團隊內(nèi)部進行更好的溝通、協(xié)作和反饋。

改Bug

當功能開發(fā)完成，就可以進入測試階段。

這時，測試人員，如有必要，可以提前準備好測試用例和測試計劃，并關聯(lián)到項目。

在測試過程中，可以把發(fā)現(xiàn)的Bug記錄下來，進行流轉(zhuǎn)、跟蹤和回歸測試。還可以通過自動生成的測試報告，進行向上匯報。

最后，把全部的Bug跟進到底，關閉全部有效的Bug，為項目貢獻那100%的質(zhì)量。

推發(fā)布

當項目的全部任務都完成了，當全部的Bug也關閉了，需求功能也實現(xiàn)了，項目就算是已完成了嗎？

非也。

只有當全部的新功能都發(fā)布上線或成功交付后，這個項目，也就是這次迭代，才算完成。

項目，是以需求為起點，以發(fā)布為終點，構成一次項目迭代。

千萬不要以為發(fā)布上線是一件很容易的事情。發(fā)布上線會消耗團隊很多寶貴的時間、精力。例如：代碼合并、數(shù)據(jù)庫變更、環(huán)境變更、歷史數(shù)據(jù)處理、打包、構建、進行回歸測試、進行發(fā)布。更為可怕的是，每一個操作都蘊含著風險，稍有不慎，就有可能刪錯了數(shù)據(jù)庫、配置改錯了、因為代碼的Bug而造成嚴重的線上故障。

推發(fā)布，其中的推字，既意味著項目在最后時刻加班加點拼盡全力交付的集體努力，也暗含了上線發(fā)布所需要的勇氣。

人人都是開發(fā)主力

回顧本次分享的五步曲：提需求、建項目、做任務、改Bug、推發(fā)布。

明確的分工，有助于團隊每個成員更好的發(fā)揮自己的專業(yè)能力和聰明才智。人人都是開發(fā)主力，更扁平的協(xié)作，更多參與感，更多承擔，更多成就。

關于作者