中文字幕理论片,69视频免费在线观看,亚洲成人app,国产1级毛片,刘涛最大尺度戏视频,欧美亚洲美女视频,2021韩国美女仙女屋vip视频

敏捷開發(fā)是一種以人為核心、迭代、循序漸進的開發(fā)方法，通過快速、高效的反應(yīng)速度，積極、高頻的溝通為客戶提供一條暢通的指揮通道。而作者經(jīng)歷了九天的封閉式開發(fā)，在文中跟大家分享這次敏捷開發(fā)的實踐經(jīng)歷。

這是一次一個面向老板出產(chǎn)品的經(jīng)歷，一個傳統(tǒng)互聯(lián)網(wǎng)公司想要轉(zhuǎn)型成移動互聯(lián)網(wǎng)公司的關(guān)鍵節(jié)點上，當時經(jīng)過很長一段時間的產(chǎn)品調(diào)研和業(yè)務(wù)流程的梳理，每次會上都會有近十個總監(jiān)級別的各個部門老大。

由于每次意見不統(tǒng)一，僵持不下，導致產(chǎn)品一拖再拖。最后老板迫于壓力，在4月1日給出了一個命令，必須在4月20號做出來一個能看的產(chǎn)品。

迫于無奈，在4月10日進行封閉式開發(fā)，9天的時間完成了一個電商類型的小程序，已經(jīng)面向酒店和公司的兩個后臺系統(tǒng)。

正是在這樣的情況下，才能夠體會到敏捷開發(fā)小而快思想的精髓。

第一點，我們遇到的問題

盡管，前期我們有進行一個相對比較長的研究，但是并沒有梳理形成一個完整體系。在整個研討會上，也沒有形成一個明確的產(chǎn)品目標以及產(chǎn)品的形態(tài)。以至于一直停留在梳理業(yè)務(wù)流程上，沒有一個比較實質(zhì)的進展，即產(chǎn)品原型、產(chǎn)品架構(gòu)幾乎空白。

面向老總出產(chǎn)品最尷尬的是他們不在意后臺系統(tǒng)，也就是他們往往會忽略后臺系統(tǒng)的工作量。公司又面臨了資金緊張裁員、UI團隊需要多方共用，一些系列問題。

總結(jié)一下我們遇到的問題：

1. 產(chǎn)品設(shè)計幾乎需要從0開始；
2. 大量的后臺系統(tǒng)開發(fā)工作量沒有被正確評估；
3. 研發(fā)團隊人數(shù)不過；
4. UI團隊無法All In。

以上的問題，當我們一起討論分析，如果想要快速滿足老板的需求，必須進行封閉式開發(fā)，而且整個團隊需要嚴格的控制和監(jiān)管，降低風險，那么就必須要有一個更高效的協(xié)作方式來完成目標。

所以，我們選擇使用敏捷開發(fā)的團隊協(xié)作方式。

第二點，什么是敏捷開發(fā)

敏捷開發(fā)（Agile Development）是一種以人為核心、迭代、循序漸進的開發(fā)方法，通過快速、高效的反應(yīng)速度，積極、高頻的溝通為客戶提供一條暢通的指揮通道。

開發(fā)方式一般分為：Scrum 和 XP。

Scrum： 團隊最佳人數(shù)控制在5～9人，一個迭代為四周時間，不允許需求的變更。

XP：更側(cè)重于測試驅(qū)動開發(fā)，一般迭代為1到2個星期，允許等量工作量的需求替換。

在整個開發(fā)過程中，因為技術(shù)團隊、產(chǎn)品團隊的成熟度還不高，無法提供完整的XP模式開發(fā)方式，而項目有偏向于使用XP模式。

綜合考慮，我們在Scrum和XP模式下吸取各自的優(yōu)點：

1. 允許中途變更等量的需求，因為在整個過程中，很有可能面臨老板的新需求，必須做到快速響應(yīng)；
2. 嚴格按照優(yōu)先級進行開發(fā)，因為時間短，User Story之間很有可能存在依賴關(guān)系，如果沒有按照優(yōu)先級進行開發(fā)很容易導致團隊有些成員很忙，有些成員符合無法達到飽和；
3. 采用產(chǎn)品經(jīng)理驅(qū)動項目進度，而不是使用TDD模式，主要原因是因為整個技術(shù)團隊在TDD模式上未實踐過無法做到自我管理的程度，只能通過產(chǎn)品經(jīng)理人肉測試和項目跟進；

第三點，我們怎么選定工具

敏捷開發(fā)是一種快速響應(yīng)需求的開發(fā)方式，不同于傳統(tǒng)的瀑布式開發(fā)，在管理流程上也就不同。產(chǎn)品經(jīng)理通過采集需求，整理出產(chǎn)品需求池（Product Backlog），然后輸出到研發(fā)團隊進行工作量評估、實現(xiàn)可行性，最后根據(jù)優(yōu)先級進入到迭代需求池（Sprint Backlog）進行一輪迭代。

再通過每天的站立會進行對需求完成情況的審核，控制風險。

以下是一個完整的產(chǎn)品迭代的過程：

通過什么會議進行管理？

通常情況下，一個敏捷開發(fā)需要以下的會議來把控研發(fā)的進度：

1. Sprint 需求規(guī)劃會議
2. 項目立項需求同步會
3. Sprint 功能規(guī)劃會議
4. 估算會議——根據(jù)項目情況合并到 Sprint功能規(guī)劃會議
5. 每日立會
6. Sprint 評審會議（Review Meeting）——根據(jù)項目需要舉行
7. 項目復(fù)盤會議

當然，我們根據(jù)當時時間緊迫，在盡可能表達清楚需求的情況下，降低溝通的時間，這也導致了后續(xù)出現(xiàn)了一些問題。比如：整個團隊對項目的理解不夠深入，在開發(fā)過程中會存在一些偏差，導致需求返工的情況出現(xiàn)。

敏捷開發(fā)需要依靠什么工具進行管理？

在高強度的開發(fā)中，如果沒有一系列工具進行管理，將會讓整個項目失去控制。

敏捷開發(fā)的工具主要有：

• Excel 需求池，用于管理需求，一般分為產(chǎn)品需求（Product Backlog）和迭代需求（Sprint Backlog）；
• 任務(wù)看板，主要用于管理需求狀態(tài)，跟蹤延誤的需求，查找成員是否成為絆腳石；
• 燃盡圖，查看用戶用例（User Story）是否按照計劃如期完成；
• 計劃撲克牌，防止研發(fā)因為考慮不全導致預(yù)估工期不準確。

第四點，敏捷開發(fā)實踐過程及結(jié)果

成員組成：一個產(chǎn)品經(jīng)理、一個交互設(shè)計師、一個后勤、3個后端工程師、3個前端工程師、機動UI設(shè)計團隊。

成果：完成一個小程序、兩個系統(tǒng)后臺。

實踐過程：

整個TAPD工作流設(shè)計：

產(chǎn)品規(guī)劃 => 交互設(shè)計 => UI設(shè)計 => 實現(xiàn)中 => 產(chǎn)品體驗 => 缺陷

缺陷的處理流程：

新 => 已接受 => 處理中 => 待驗收 => 已驗收 => 已關(guān)閉

我們在整個過程中，嚴格遵循以下幾個原則：

1. 產(chǎn)品設(shè)計需要拆分高內(nèi)聚低耦合的模塊，設(shè)計并且及時輸出最小可用單元，保證項目不會產(chǎn)生類似瀑布流開發(fā)的模式。
2. 每日完成手頭上的需求才算完成當天的工作，確保每個人的需求能夠完成保證進度。
3. 每日晚上十點進行審核，事實上，為了讓大家能夠繼續(xù)加班到凌晨的小技巧，也確保缺陷不過日。
4. 每個模塊需要完整的走過工作流，也就包括缺陷，出現(xiàn)問題及時調(diào)整。

實踐遇到的問題：

• 剛開始團隊磨合工具，沒有及時變更工作狀態(tài)。
• 預(yù)留給產(chǎn)品設(shè)計的時間太少，導致產(chǎn)品設(shè)計并沒有太全面，邊界條件未充分考慮。
• 需求排優(yōu)先級出現(xiàn)錯誤。
• 需求會沒有被重視，導致開發(fā)過程中需求重新開發(fā)。
• 測試環(huán)節(jié)節(jié)奏比較混亂，沒有從頭到尾測試聯(lián)調(diào)。
• 產(chǎn)品更新原型，缺少比較好的同步工具，讓所有人一直都是使用最新的文檔。

通過9天時間封閉式開發(fā)產(chǎn)生的數(shù)據(jù)：

由于離開上家公司的時候沒有整理出來這些資料，大致上，我們通過9天的時間完成了：

• 需求點大致上有300+個，采用前后端分開提需求點；
• 測試并且修復(fù)400條bug，基本上做到日清。

最后，注意事項

并不是所有的項目都適合用敏捷開發(fā)，在項目沒有特別明確的目標，團隊技術(shù)水平太弱、需要工期本身比較長無法細化顆粒度的情況下，使用敏捷開發(fā)會存在很多問題。

比如：

• 響應(yīng)無法做到及時；
• 對工具的使用無法快速適應(yīng)；
• 沒有明確目標，缺乏緊迫感。

等等一系列問題，都會讓整個敏捷開發(fā)變得不敏捷。

導致整個項目的燃盡圖呈現(xiàn)下圖這樣：

而正常的燃盡圖應(yīng)該未關(guān)閉的線段貼合基線：

不過，嘗試使用敏捷開發(fā)小而快的開發(fā)思想在自己的項目管理過程中也是不錯的。

參考資料

1. 敏捷開發(fā)之Scrum掃盲篇
2. 敏捷開發(fā)（agile）中story
3. 讀書筆記Scrum 總結(jié)
4. 瀑布式開發(fā)、迭代開發(fā)、敏捷開發(fā)、XP與SCRUM的區(qū)別