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

一個軟件產(chǎn)品的完整開發(fā)流程，分為需求確定、產(chǎn)品研發(fā)、產(chǎn)品驗收、全量測試發(fā)布這四個階段，而Scrum框架為每一個階段都設(shè)定了對應(yīng)的解決方案。本文作者對Scrum敏捷框架進行了分析，一起來看一下吧。

《Scrum敏捷開發(fā)實戰(zhàn)》系列：

1. 方法介紹
2. 團隊組建
3. 敏捷框架（本章節(jié)）
4. 看板工具
5. 每日站會
6. 常見問題

一、完整開發(fā)流程

一個軟件產(chǎn)品的完整開發(fā)流程分為4個部分，分別是：

1. 需求確定階段
2. 產(chǎn)品研發(fā)階段
3. 產(chǎn)品驗收階段
4. 全量測試發(fā)布階段

在實際的開發(fā)過程中，為了提高效率，②③是有可能重疊交替進行，Scrum框架為每一個階段都設(shè)定了對應(yīng)的解決方案。

二、Scrum框架-334

三、完整的Scrum流程

完整的Scrum流程包含了3個角色、3個物件，以及4個會議；

3個角色：

• Product Owner 產(chǎn)品負(fù)責(zé)人
• Scrum Master 敏捷教練
• Scrum Team 開發(fā)團隊

3個物件：

• Product Backlog 產(chǎn)品功能列表
• Sprint Backlog 迭代任務(wù)列表
• 燃盡圖

4個儀式：

• Sprint沖刺計劃會
• 每日站會
• Sprint沖刺評審會
• Sprint沖刺回顧會

3個角色我們在上一篇文章《組建敏捷團隊》已經(jīng)詳細(xì)介紹，本章就不做過多的闡述。

3個物件屬于敏捷工具，會使用即可，其中“產(chǎn)品功能列表”由產(chǎn)品負(fù)責(zé)人維護，然后進行優(yōu)先級排序，以用戶故事的形式展示，能夠讓團隊成員容易理解。

“迭代任務(wù)列表”是當(dāng)前沖刺迭代版本的任務(wù)集，由產(chǎn)品將用戶故事拆成任務(wù)，并讓團隊成員各自領(lǐng)取。

“燃盡圖”則是一個公開的圖表，是項目進度的一種看板表現(xiàn)形式，有助于項目成員能夠直觀的理解項目進展，直到所有任務(wù)開發(fā)完畢。

4個儀式貫穿整個敏捷流程，領(lǐng)悟每個會議的作用，將決定整個敏捷開發(fā)的質(zhì)量。

四、Sprint沖刺計劃會

每個沖刺版本都由一個Sprint沖刺計劃會開始，產(chǎn)品負(fù)責(zé)人PO或團隊成員選擇用戶故事，然后由產(chǎn)品負(fù)責(zé)人詳細(xì)講解用戶故事，產(chǎn)品經(jīng)理負(fù)責(zé)講解滿足用戶故事的產(chǎn)品功能解決方案，開發(fā)團隊進行任務(wù)估算。

沖刺會最終產(chǎn)出1張表和3個時間節(jié)點：

• Sprint里程碑任務(wù)計劃表
• 可測試介入的時間節(jié)點、整體開發(fā)完成的時間節(jié)點、上線時間節(jié)點

沖刺計劃會要注意幾個關(guān)鍵點：

• 一個Sprint的周期不宜過長，控制在4周內(nèi)，而且以2周為佳
• 每次會議全員必須參加，每個人都要清楚本次版本的目標(biāo)，我們能交付什么，明確各自的職責(zé)和責(zé)任
• 全員承諾，PO不死壓完不成的任務(wù)量
• 任務(wù)估算時可以討價還價，但一旦接受則所有人都要對里程碑no delay，做到當(dāng)日事當(dāng)日畢
• 盡量不要壓縮測試的時間
• 在任務(wù)進度表沒有出來之前，不要中斷會議

1. 任務(wù)估算

任務(wù)估算是沖刺計劃會中最重要的一個環(huán)節(jié)，只有理解了本次會議的需求內(nèi)容，才能估算出準(zhǔn)確的時間，確保里程碑的進度可控，SM要在這個環(huán)節(jié)把控全局，確認(rèn)好里程碑的時間節(jié)點。

如果團隊內(nèi)崗位都不相同，團隊成員分別編寫自己的任務(wù)卡，而如果有相同的崗位，應(yīng)當(dāng)以小組的形式來估時，比如一個團隊中有2個后端，那他們就要對本次里程碑的所有任務(wù)都進行估時（可參考撲克牌估算法），雙結(jié)果不同需要討論并重新出牌，結(jié)果比較接近即結(jié)束。

2. 任務(wù)卡

一張完整的任務(wù)卡要包含三個內(nèi)容：

1. 明確的交付內(nèi)容
2. 責(zé)任人（可以使用代號，只要不重復(fù)即可）
3. 任務(wù)完成時間（可以用小時H或天D作單位）

五、任務(wù)卡

敏捷教練SM在和每個人確認(rèn)任務(wù)卡片時，需要注意以下幾點：

1）目標(biāo)一致

做最后確認(rèn)，確保所有人都清楚本次里程碑的目的和邏輯細(xì)節(jié)，只有理解了業(yè)務(wù)細(xì)節(jié)才能很好的拆解任務(wù)卡片，確保不丟失業(yè)務(wù)邏輯。

2）任務(wù)拆解

單個任務(wù)1天為最佳，最多不能超過2天，絕大多數(shù)的任務(wù)都是可以拆解的，很多人無法拆解是沒有掌握正確的拆解方法，我們可以按照頁面數(shù)量、接口數(shù)量、制作步驟等方法進行拆解。

例：我們要畫一張原畫，正常需要7天，我們可以按照步驟拆解： 找參考（可省略）→ 畫草稿 → 畫線稿（將草稿清晰化）→ 上色（上底色、上陰影色、上第二層陰影色）→ 加特效（畫背景、光影）→ 優(yōu)化細(xì)節(jié) → 完稿。

拆解到人天的好處就是讓每個人都知道每天要完成什么內(nèi)容，工作目標(biāo)清晰透明，驗收時只有兩個結(jié)果是和否，不存在模糊不清的進度（比如完成30%這種），既讓成員有一定壓力，也能夠有效的減少工作不飽和的情況。

第二個好處是SM每天都知道誰交付了什么，如果沒有完成第二天也能及時風(fēng)控，而不是等幾天之后才發(fā)現(xiàn)某人完成不了。

3）明確信息

任務(wù)卡片里的內(nèi)容要清晰準(zhǔn)確，要有量化的內(nèi)容，不能用模糊不清的概念，SM要能夠理解每個卡片上交付的內(nèi)容，如果不理解需要讓成員修改，并檢查每個人卡片上三要素是否齊全。

例如：

• 錯誤：完成接口的開發(fā)（不具體）
• 正確：完成用戶注冊5個接口開發(fā)

4）消除瓶頸

檢查卡片時需要關(guān)注是否包含了所有的需求，是否有估算時長與預(yù)期、或和以往類似功能時間嚴(yán)重不符的任務(wù)卡片，單人的任務(wù)時間是否過長，評估整體里程碑時長是否過長。

如何評估任務(wù)估算過長？

• 里程碑的總時長是否和你預(yù)期的相差過長，如果是，和團隊表達你的想法，一起尋找瓶頸點
• 培養(yǎng)自己的直覺，和歷史同類任務(wù)進行對比進行判斷
• 把握不準(zhǔn)的，可以使用同崗位使用撲克牌估時法，找出差異大的估時邏輯
• 在前幾次的里程碑中，觀察和評估每個人的工作效率，用于后期對每個人的估時進行判斷是否有很大的不飽和情況

那如果有人任務(wù)估算過長，應(yīng)該如何處理呢？我們可以從以下幾個角度進行分析解決：

• 信息缺失：有可能是對所負(fù)責(zé)的任務(wù)還不是很了解，或把解決方案想復(fù)雜了，或?qū)椖坎皇煜ぃ恢烙行┓椒ㄒ汛嬖冢梢灾苯邮褂玫鹊?，這些都可以通過深度溝通來解決；
• 任務(wù)拆解：盡可能的拆細(xì)，查看每一天的任務(wù)的工作量是否飽和，直到無法再拆為止，拆到一個點就很容易評估時間；
• 能力不足：一些新人剛開始可能不知道如何拆解任何和評估，這個時候需要更資深的開發(fā)來進行輔導(dǎo)，梳理業(yè)務(wù)邏輯，輸出合理的卡片，輔導(dǎo)2~3次之后即可解決該問題（如果沒有資深開發(fā)可以考慮招聘一個，一個經(jīng)驗豐富的開發(fā)，對于消除瓶頸有極大的幫助）
• 態(tài)度問題：極個別的情況可能是員工的工作態(tài)度問題，態(tài)度問題很難在會議上進行解決，短期內(nèi)也不太好解決，這時需要PO使用權(quán)威來推進，適當(dāng)給予壓力，日常工作中要進行引導(dǎo)，若發(fā)現(xiàn)還是沒有改變的跡象，需要考慮替換；

5）打通關(guān)聯(lián)

SM需要全局觀察每個人的任務(wù)排序和時間，觀察上下游任務(wù)銜接情況，合理調(diào)整順序，確保任務(wù)的連貫性，盡早的交付可供測試的軟件。

6）交付承諾

任務(wù)卡片確認(rèn)完畢，明確三個時間節(jié)點，所有人達成共識，將任務(wù)按照優(yōu)先級展示在看板上，輸出里程碑計劃表，全體成員承諾交付結(jié)果。

六、每日站會

里程碑確定之后，通過每日站會來推進項目進度，由SM發(fā)起，全體成員參加，PO和其他需求方選擇性參加（但只參與、不說話），每日站會是快速專注的會議，用來分享進度和迭代看板進展，每個團隊成員就他們將要完成的任務(wù)對其他人口頭承諾。

所有人圍繞在看板周圍，每個人輪流上前回答一下三個問題：

1. 昨天我為團隊做了什么？
2. 今天我將要做什么？
3. 我需要哪些幫助？

回答完畢之后將已完成的任務(wù)移入Test泳道，將今天的任務(wù)移入Doing泳道。

一個有效的站會需要做到以下原則：

1. 固定時間、固定地點，養(yǎng)成習(xí)慣，遲到的人要有懲罰
2. 全員參與、站立開會，保持專注，時長控制在10~15分鐘
3. 三個問題、更新進度，不要討論技術(shù)問題，不要轉(zhuǎn)移會議話題
4. 注意聆聽、回應(yīng)問題，別人在講時其他人要注意聽，需要幫助時相關(guān)人員要及時回應(yīng)

七、Sprint沖刺評審會

在開發(fā)完畢后，即將交付上線之前，由SM發(fā)起，全體成員參加，開發(fā)團隊將可交付物演示給需求方，需要方進行功能評審，收集反饋意見。

評審會并不是必須的，但Scrum團隊要經(jīng)常和需求方保持信息互通，確保接受到最新的市場動態(tài)和用戶反饋，交付的產(chǎn)品滿足利益相關(guān)者的期望，讓團隊的產(chǎn)出有價值。

八、Sprint沖刺回顧會

每一個沖刺會完成后，都會舉行一次沖刺回顧會議，在會議上所有團隊成員對本次沖刺進行反思，包括：什么進展順利？缺少什么？需要改變什么等等。

沖刺回顧會是針對迭代末期進行的時間盒會議，目的是幫助團隊如何提高他們的工作效率和改進工作方式，就未來的迭代改進計劃達成一致；同時梳理以往的項目缺陷和債務(wù)，對用戶故事進行審視，是否需要新增、刪除、修改用戶故事，對用戶故事進行優(yōu)先級排序。

需要注意的是，讓團隊自己反思，PO盡量不參加，或者參加也盡量少說話，反思時要找出明確的問題和意見，不要情緒化，切勿開成批斗會。

Scrum敏捷流程讓在早期發(fā)現(xiàn)可能的問題，可以用更快更小損失應(yīng)對問題，“沒有問題被掃入地毯下”，Scrum鼓勵每個團隊成員清楚的描述自己所遇到的困難，其他成員積極的響應(yīng)解決，降低項目風(fēng)險，SM必須有預(yù)警風(fēng)控能力，能判斷出可能的延遲或者偏差。

敏捷之路，不可能一帆風(fēng)順，團隊只有在不斷遇到問題解決問題才能快速成長。