本文主要介紹scrum的好處(如何使用scrum)，下面一起看看scrum的好處(如何使用scrum)相關(guān)資訊。
摘要:你有沒有一種感覺，團隊使用scrum后，任務(wù)越來越多，加班越來越嚴(yán)重？什么事？好兄弟，這篇文章正好可以幫到你~你有沒有一種感覺，團隊使用scrum后，工作任務(wù)越來越多，加班越來越嚴(yán)重？什么事？好兄弟，這篇文章正好可以幫到你~
使用scrum后，團隊越來越累。scrum應(yīng)該被指責(zé)嗎？其實這個鍋scrum真的不是背出來的?！?020-scrum-guide（簡體中文）》是這樣描述的:scrum基于經(jīng)驗主義和精益思想。經(jīng)驗主義主張知識來源于實踐經(jīng)驗，是根據(jù)目前觀察到的情況做出判斷而獲得的。精益思維減少浪費，關(guān)注根本。 也就是說，scrum可以幫助團隊減少浪費，開發(fā)出最具核心價值的產(chǎn)品，但并不意味著工作量會隨著scrum而增加或減少。有什么問題？讓 讓我們分析一下。
問題分析本文列舉了三個有代表性的原因。
1.需求沒有得到很好的闡明。自規(guī)劃會議以來，團隊一直處于混亂狀態(tài):一些業(yè)務(wù)場景相對復(fù)雜，po can 不要僅僅通過計劃會議向團隊闡明所有重要的業(yè)務(wù)需求；在規(guī)劃會議結(jié)束時，許多需求細(xì)節(jié)甚至主要功能都沒有被開發(fā)人員理解，他們帶著滿滿的疑問進入了編碼階段。結(jié)果，可想而知，——的開發(fā)人員在迭代中一直與po保持一致，并不斷修正完成的代碼。測試的人員也忙著測試的職能，忙著回測試——，整個團隊忙著飛，但是做出來的產(chǎn)品沒有起飛。
2.估計不準(zhǔn)確。這里有兩方面的估算誤差，一是團隊速度的估算誤差，二是所需工作量的估算誤差。
例如，團隊的一次迭代很難滿足40個故事點的需求。結(jié)果團隊高估了自己的能力，認(rèn)為可以輕松滿足50個故事點的需求，最終導(dǎo)致團隊疲于交付。需求工作負(fù)荷估計誤差與速率誤差相同。
3.團隊卷起it行業(yè)已經(jīng)成為常態(tài)。在使用scrum之前，每個人都寫一份周報，發(fā)給領(lǐng)導(dǎo)匯報工作。沒有人知道對方做了什么?，F(xiàn)在每天都有晨會，晨會的時候聽說的，嗯？這位兄弟昨天做了這么多嗎？然后我 我會比你做得更多(更好)。當(dāng)——的內(nèi)卷化氣氛在團隊中蔓延時，整個團隊都會很疲憊。
解決方案1。增加需求梳理會，提前了解需求。scrum框架中預(yù)設(shè)的五個活動不包括需求梳理會議，所以許多團隊對這個詞感到很不舒服需求梳理會議及(以下簡稱梳理會)。陌生人，那什么是梳理期？
梳理會議是po向團隊成員闡明未來迭代需求的活動。在梳理會議之后，團隊成員將對需求有更好的理解。雖然梳理會議不是scrum的標(biāo)準(zhǔn)活動，但是在實際生產(chǎn)中，很多scrum團隊都會在迭代中插入梳理會議，幫助團隊對需求達成共識，保證下一次沖刺的順利進行。
梳理會什么時候開，開多久？梳理會一般在迭代中后期進行。和scrum標(biāo)準(zhǔn)事件一樣，梳理會議的時間應(yīng)該是固定的，適合時間盒。梳理會議的持續(xù)時間通常不超過總迭代時間的5%。例如，對于兩周的迭代，團隊可以選擇第二周的周三下午召開需求梳理會議。
怎么開梳理會？首先聲明，需求梳理會不是計劃會的提前演練，而是與計劃會相比的輔助關(guān)系。梳理會議的目的是對產(chǎn)品積壓進行整理、提煉和分類。規(guī)劃會議更多的是關(guān)于拆分和聲明sprint backlog中的需求。
梳理會議首先需要po說明哪些需求需要迭發(fā)，同時po負(fù)責(zé)向團隊闡明這些需求。如果需求太大，po和團隊將一起分割需求。在梳理會上進行需求拆分的目的是為了找出下一次迭代結(jié)束時要做什么。這個過程不涉及團隊分工，所以需求拆分可以在故事層面完成，將故事拆分成任務(wù)的操作可以在規(guī)劃會上完成。
需求分解完成后，團隊和po一起確定新產(chǎn)品待定項(pbi)的優(yōu)先級，并估計在不久的將來要開發(fā)的需求的工作量。因此，梳理將為規(guī)劃會議打下良好的基礎(chǔ)，同時，團隊將有更多的時間深入了解需求，以避免需求沒有得到很好的闡明。
2.合理估計團隊速度和工作量。如果團隊成員對需求理解到位，但是每次迭代仍然被大量的工作壓得喘不過氣來，可能是規(guī)劃會議的工作很多，需要團隊對團隊速度和每個需求的工作量有很好的估計。
單個需求的工作量可以用小時來衡量，高端的話可以用故事點來衡量。在工作量估算的過程中，最好是全團隊參與?！丝诟?，實力更強。一方面可以更全面地考慮需求，另一方面可以縮小估算偏差。更多估算知識，請參考《【devcloud · 敏捷智庫】估算四篇合集》。
團隊速度通常不等于迭代時間的100%，因為團隊仍然需要會議、研討會等。
團隊速度是基于故事點的，也就是正常情況下，團隊在一次迭代中能交付多少故事點。如果團隊沒有嘗試過用故事點來估算團隊速度，用工作時間來估算也是可以的。建議將迭代時間的80%作為工作時間。限制，也就是說團隊索賠的總工作量不能超過迭代時間*團隊人數(shù)的80%。比如團隊7人，迭代時間兩周(每天工作八小時，每周工作五天)，8*5*2*7*80% = 448h，也就是說這個團隊每次迭代所宣稱的總工作量應(yīng)該在448h左右(故事點也是如此)。
如果團隊覺得448h時間還短(不考慮團隊混日子的情況)或者有很多空閑時間，那么后續(xù)迭代可以根據(jù)實際情況重新估算團隊速度。
3.scrum master遵循敏捷原則，讓團隊遠(yuǎn)離內(nèi)卷團隊成員一點點可能會有一定的積極影響；但是如果體量嚴(yán)重，比如996甚至007，整個團隊都會很累，對團隊的發(fā)展是不利的。
scrum本身提倡精益思維。既然團隊迭代初期宣稱的需求工作量是符合團隊速度的，那么團隊加班到底是為了什么？是不是過度開采，后期會不會造成浪費？scrum master和整個團隊都要反思。
此外，敏捷的十二條原則中有一條是:敏捷過程提倡可持續(xù)發(fā)展，負(fù)責(zé)人、開發(fā)人員和用戶應(yīng)該能夠共同保持其步伐的穩(wěn)定延續(xù)。 如果團隊能夠按照內(nèi)卷的節(jié)奏持續(xù)高效的發(fā)展，是可以接受的，但是團隊往往很難堅持下去，這就違背了敏捷的原則。作為一個scrum高手，我們應(yīng)該注意這一點，引導(dǎo)團隊做出調(diào)整。
整個環(huán)境都參與其中。如果scrum mast《頸椎護理指南》《21天弄明白腰間盤》等健康書籍。
總結(jié)以上三點，從不同角度講述使用scrum后團隊越來越累的原因和解決方法，希望對你有所幫助。
本文由devsecops專家服務(wù)團隊制作，前往專家服務(wù)獲取更多devsecops工程方法、工具平臺、最佳實踐等干貨。
點擊關(guān)注了解華為云；;s新鮮科技第一次~
標(biāo)簽:
團隊需求
了解更多scrum的好處(如何使用scrum)相關(guān)內(nèi)容請關(guān)注本站點。