国外亚洲成av人片在线观看,热99re久久精品这里都是精品,天堂网在线最新版www,国产成人av区一区二区三,51久久成人国产精品麻豆

在產(chǎn)品開發(fā)過程中，敏捷開發(fā)和瀑布模型都是常用的流程和開發(fā)方法，這兩種方法是什么？細節(jié)是什么？這篇文章，為我們進行了解答。

成本、時間和質(zhì)量是項目管理的鐵三角，項目管理的核心目標是平衡好這三者之間的關系，盡量確保軟件項目能夠在可控的成本范圍之內(nèi)，符合質(zhì)量要求地按期交付。

這里的質(zhì)量我覺得包含了兩方面：

1. 功能的完成度與穩(wěn)定性；
2. 用戶需求的滿足程度。

在一些大型項目的交付過程中，面對交付過程中頻繁變化的需求，按照既定合同內(nèi)的需求以瀑布模式開發(fā)，雖然能發(fā)揮瀑布開發(fā)的優(yōu)勢，但在用戶需求滿意度方面肯定會有所損失，更嚴重的會導致返工改造、驗收不通過。

相對“瀑布”模式的重，“敏捷開發(fā)”是一種應對頻繁需求變化、快速響應的輕量開發(fā)模式，在以“瀑布模式”開發(fā)的項目中，將“敏捷”的理念引入，發(fā)揮各自優(yōu)勢，會對整個項目順利的交付起到積極的作用。

本篇先講下“敏捷開發(fā)”與“瀑布開發(fā)”的工作流程、適用場景、各自優(yōu)缺點，然后將二者融合，談一下在實際項目交付過程中的應用思考。

一、瀑布模式

瀑布模式是一種經(jīng)典的線性開發(fā)模式，在傳統(tǒng)的軟件項目交付過程中被大量使用。

瀑布模式的整個項目周期是確定的，按照項目開發(fā)的時間可以分為規(guī)劃階段、需求分析階段、軟件設計階段、編碼階段、測試驗收階段、上線階段運維階段等若干里程碑。

下面這張圖生動地描述了瀑布開發(fā)的模式：

客戶需要一輛代步工具，需要按照事先規(guī)劃的方案，經(jīng)過漫長的研發(fā)，最終給客戶交付一輛汽車。

前期的方案是足夠好，但在此過程中客戶無法盡早體驗產(chǎn)品，最終交付后產(chǎn)品可能不是客戶實際想要的，從這個角度看風險很高。

一個典型的瀑布模式的產(chǎn)品研發(fā)流程

適用場景：

瀑布模式比較適合需求比較清晰的項目開發(fā)，比如簽訂合同的項目制交付，一般情況下合同內(nèi)的需求都是確定的，乙方按照合同內(nèi)的需求，按時交付即可。

理論上需求和設計方案確定后，在開發(fā)過程中需要嚴格執(zhí)行，需求變動需要執(zhí)行變更流程，或者另簽一個補充協(xié)議。

優(yōu)點

1. 由于需求相對比較明確，在前期可以對系統(tǒng)整體架構、擴展性進行整體、全面的設計；
2. 團隊的目標相對明確，按照里程碑節(jié)點順序推進，向目標前進的效率會比較高，易于管理和監(jiān)督；
3. 每個階段投入的人力不同，不同崗位的人員可以分批投入項目。

缺點

• 對業(yè)務需求的快速變化，靈活性不足，尤其是對于處于摸索階段的新業(yè)務，這種變化是不可避免。
• 比如系統(tǒng)試運行、業(yè)務推進過程中會產(chǎn)生很多新的需求，我們之前按照合同內(nèi)需求規(guī)劃的設計可能要推翻或者有較大的修改，尤其在項目中后期，很可能將會導致項目延期，超出合同成本預算。
• 由于產(chǎn)品從研發(fā)到上線是一個線性的推進過程，在此期間客戶沒有真正看到過、體驗過產(chǎn)品，最后上線，客戶很可能對最終的產(chǎn)品不滿意，重新改造的成本較高。

二、敏捷模式

敏捷模式是針對瀑布模式太重提出的一種小步迭代、快速反饋的開發(fā)模式，能有效的提高軟件的開發(fā)效率，應對市場的快速變化。

下面這張圖生動地描述了瀑布開發(fā)的模式。

客戶想要一輛代步工具，為了快速滿足可以出行的需求，按照敏捷的理念會先提供滑板、然后通過快速迭代逐步提供自行車、摩托車、小汽車。

在此過程中將產(chǎn)品快速投入市場，根據(jù)市場反饋，調(diào)整方向，雖然一開始提供的不是最優(yōu)解決方案，但是一直在正確的方向上前進，不至于跑偏。

敏捷的核心關鍵詞包括快速響應、迭代、增量交付、漸進式、面對面溝通、快速反饋與調(diào)整等。

敏捷項目管理通常采用Scrum敏捷框架進行實施，以固定時間盒的方式快速迭代，在實踐中比較常用的是雙周迭代的模式，在一個沖刺內(nèi)完成增量開發(fā)的交付。

“增量開發(fā)主要是一塊接著一塊地構建一個系統(tǒng)。一部分功能先被開發(fā)出來，然后另一部分功能被加入前一部分功能，以此類推。”

《敏捷宣言》中的價值觀：

個體和互動高于流程和工具；

工作的軟件高于詳盡的文檔；

客戶合作高于合同談判；

響應變化高于遵循計劃。

Scrum作為一個輕量級的團隊協(xié)同工作方式，一個沖刺從開始準備到完成主要由以下幾個關鍵活動組成：

1. 需求梳理，挑選需求并編寫需求說明

一般由產(chǎn)品經(jīng)理在沖刺開始之前從Product Backlog(類似需求池，Scrum中叫Product Backlog）中按照優(yōu)先級挑選在本次沖刺（Sprint）內(nèi)需求（這些需求可能為特性、用戶故事、缺陷等，在Scrum中被稱為PBI）。

產(chǎn)品負責人和開發(fā)團隊要對當前沖刺準備實現(xiàn)的需求及沖刺目標達成一致意見，在此期間產(chǎn)品負責人需要完成產(chǎn)品方案、編寫需求說明，并與需求方確認。

2. 需求澄清會（沖刺計劃）

產(chǎn)品經(jīng)理將當前Sprint中的需求向研發(fā)團隊澄清，在澄清的過程中可以根據(jù)實際情況對需求的范圍、方案進行調(diào)整。

每個需求澄清完畢，具體模塊的研發(fā)人員可對需求的進行工作量的估算（故事點、規(guī)劃撲克牌具體的估算方法這里不再具體說明）。

如估算的工作量過高，研發(fā)人員需要說明原因，最終會議結束確定本沖刺內(nèi)交付范圍，正式開啟沖刺。

3. 任務分解

一般需求澄清回后，開發(fā)人員會將每個需要完成的需求（特性）分解成一組任務，這組任務及相關的PBI組成了“沖刺列表”，開發(fā)團隊給出完成每項任務所需工作量的估算值（通常以小時計）。

4. 沖刺執(zhí)行（開發(fā)實施與測試）

在團隊沖刺的內(nèi)容達成一致意見后，研發(fā)團隊需要根據(jù)產(chǎn)品方案進行技術方案的設計，執(zhí)行為了完成特性而所需的所有任務開發(fā)的工作。

5. 每日例會

在沖刺開始的每一天，研發(fā)團隊會每天早上進行站會（通常不會超過15分鐘）。

團隊成員每天輪流回答下面三個問題，昨天我完成了什么？今天計劃做什么工作？有什么障礙讓我無法取得進展？

通過每日站會，每個人都能了解全局，知道發(fā)生了什么，沖刺目標的進展如何，是否需要幫助團隊解決一些問題，實現(xiàn)一個沖刺內(nèi)快速、流動的工作流。

6. 沖刺評審

沖刺周期的后期，團隊給產(chǎn)品負責人和其他業(yè)務需求干系人、客戶演示完成的成果，讓各方了解已經(jīng)交付的增量，檢視和調(diào)整產(chǎn)品，同時業(yè)務互相交流，收集反饋并及時調(diào)整。

7. 沖刺回顧會

沖刺回顧會是檢視并調(diào)整過程的時機，開發(fā)團隊、產(chǎn)品負責人、ScrumMaste一起討論，在上個沖刺中哪些過程是需要改進的。

需要注意的是沖刺回顧會不是吐槽、追責的會議，目的是幫助Scrum團隊成長、下一個沖刺能夠持續(xù)的改進。

適用場景

敏捷項目管理適用于業(yè)務需求變化頻繁、比較適合創(chuàng)新型項目、市場需求變化快速的項目，主打一個“快速迭代”，在一些互聯(lián)網(wǎng)公司、自研產(chǎn)品的公司比較常用。

優(yōu)點

能夠快速響應變化、提高客戶滿意度、減少項目風險，同時還能提高團隊協(xié)作能力、加快產(chǎn)品上市時間。

缺點

對于一些成熟業(yè)務，由于追求快速響應，前期在系統(tǒng)架構設計上并不一定那么完美，另外對團隊協(xié)作能力、敏捷理念的認可度要求比較高。

三、在項目交付過程中的思考

在實際的項目交付過程中甲乙雙方立場的不一樣，甲方期望乙方能在合同周期內(nèi)盡可能多的滿足需求，解決更多問題，而乙方期望能控制成本，如期交付，迫于甲方交付驗收的壓力，又不得不接受頻繁的需求變更。

從實際經(jīng)驗來看，有如下原因?qū)е鲁杀?、質(zhì)量、時間陷入三難的境地。

外部原因：

• 甲方業(yè)務比較新，存在邊用邊發(fā)現(xiàn)新問題的情況，合同外的、變更需求時有發(fā)生；
• 甲方不配合，如不配合調(diào)研、系統(tǒng)使用不積極、不提供數(shù)據(jù)等等；
• 實施過程中非研發(fā)類工作耗費太多時間，如數(shù)據(jù)處理、甲方匯報文件、配合業(yè)務開展等臨時性工作安排、業(yè)務代運營等。

內(nèi)部原因：

1. 合同簽訂前銷售的對需求的過渡承諾，初設方案的不完善；
2. 系統(tǒng)規(guī)劃設計階段對整體應用架構、技術架構設計的不合理；
3. 需求分析不合格，設計出來的系統(tǒng)未能徹底解決甲方的問題，導致重復返工、打補??；
4. 缺乏有效的項目管理流程，多人協(xié)作變得混亂失控，缺少風險跟蹤，研發(fā)過程變得脆弱，導致研發(fā)效率和質(zhì)量不高。

原因很多，本篇僅從項目管理的角度探討，如何平衡成本、質(zhì)量、時間的矛盾，達到甲乙雙方共贏的目的。

有一種方式我叫做“大瀑布下的小敏捷”，將“敏捷開發(fā)”與“瀑布開發(fā)”相結合，發(fā)揮各自的優(yōu)勢，是一個實際可用的手段。

“大瀑布下的小敏捷”既能夠按照“瀑布模式”的里程碑節(jié)點，交付目標相對明確，又能發(fā)揮“敏捷開發(fā)”快速響應需求的變化、持續(xù)交付的優(yōu)勢，提升客戶滿意度。

在大的項目周期內(nèi)有明確的啟動、需求調(diào)研、系統(tǒng)設計、編碼開發(fā)、上線交付的里程碑節(jié)點，整體上看是瀑布模式的開發(fā)。

對于實際交付過程中頻繁變更的新需求和合同內(nèi)的老需求統(tǒng)一放進“產(chǎn)品代辦清單”（Product Backlog），按照敏捷開發(fā)的模式拆分成一個個固定時間盒的沖刺，當下的沖刺內(nèi)為優(yōu)先級最高的需求，通過一個個沖刺完成增量產(chǎn)品的交付，直至項目交付。

敏捷開發(fā)是為了讓團隊達成一種在固定時間內(nèi)持續(xù)交付的共識，一般一個沖刺開始時，該沖刺內(nèi)的需求一般不允許變更。

但有些特殊情況，為了配合甲方匯報（一些G端項目常見），這些臨時需求優(yōu)先級會變得非常高。

此時研發(fā)團隊可能正處在當前沖刺的開發(fā)中，不得不將主要精力投入配合匯報。

無論“敏捷開發(fā)”還是“瀑布開發(fā)”，流程是死的，人是活的，不同的公司、不同的業(yè)務可以根據(jù)實際情況靈活調(diào)整，切不可生搬硬套。

參考資料：《Scrum精髓》