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

在目前的互聯(lián)網(wǎng)公司，敏捷（Agile）的概念已經(jīng)有相當(dāng)?shù)钠占?，人人都在談，似乎不談敏捷就不那么互?lián)網(wǎng)了。幾乎所有的互聯(lián)網(wǎng)公司都不同程度的實施了敏捷。

采用敏捷開發(fā)的方法也有很多，主要包括極限編程（XP）、Scrum、水晶方法（Crystal Methods）、自適應(yīng)軟件開發(fā)（ASD）、特性驅(qū)動開發(fā)（FDD）、動態(tài)系統(tǒng)開發(fā)（DSDM）、輕量級RUP、測試驅(qū)動開發(fā)（TDD）等等。而在眾多的敏捷開發(fā)方法中，尤以實施Scrum比較流行。

對于我本人來說，接觸Scrum有幾年的時間了。在軟件開發(fā)項目中做了一些Scrum的實踐，閑暇時間也經(jīng)常與業(yè)界Scrum同仁們溝通交流一些心得；同時，也始終在關(guān)注業(yè)界對于Scrum的一些新的認識和實踐的書籍材料。在這一過程中，也促使我對Scrum有了更深刻的理解。

結(jié)合我的Scrum實踐，本文主要從Scrum的認識，Scrum的實施過程以及實施Scrum帶來的變化幾個方面進行分享，解讀一個可運行的 Scrum是怎樣的。希望能給大家?guī)聿灰粯拥恼J識，并對Scrum實踐有所幫助。

首先來了解一下Scrum的定義。

Scrum 是一個用于開發(fā)和維護復(fù)雜產(chǎn)品的框架，是一個增量的、迭代的開發(fā)過程。在這個框架中，整個開發(fā)過程由若干個短的迭代周期組成，一個短的迭代周期稱為一個Sprint，每個Sprint的長度是2到4周。

在Scrum中，使用產(chǎn)品Backlog來管理產(chǎn)品的需求。產(chǎn)品backlog按照實現(xiàn)的優(yōu)先級進行排序，以商業(yè)價值作為排序的主要原則。在Sprint中，Scrum團隊從產(chǎn)品Backlog中挑選最高優(yōu)先級的需求進行開發(fā)。挑選的需求在Sprint計劃會議上經(jīng)過討論、分析和估算得到相應(yīng)的任務(wù)列表，稱它為Sprint backlog。當(dāng)Scrum團隊完成Sprint backlog列表中的所有任務(wù)時，本次Sprint結(jié)束，進入下一個Sprint迭代周期。

Scrum有很大的價值，然而在有些公司推行Scrum卻困難重重，有些人說Scrum沒有什么實質(zhì)性的作用，然并卵。為什么會有這樣的認識呢？深入分析，原因主要有：

• 項目團隊缺乏對敏捷的正確認識，單純的認為敏捷就是快，就是追趕進度,就可以不受任何制度約束。大家可能聽說過這樣的對聯(lián)，“這個功能很簡單，怎么實現(xiàn)我不管。”橫批：“明天上線”。也曾聽說有些公司要開發(fā)一個新功能，因為實施了scrum，于是要求項目團隊加班加點，將2周甚至3周以上的開發(fā)任務(wù)在一周內(nèi)就發(fā)布上線。實施Scrum意味著項目團隊“漫無天日”的加班，這導(dǎo)致了項目團隊對敏捷有一種“恐懼”感；
• PO不能勝任工作，無法拆分有效的用戶故事，或者用戶故事拆分的不合理，無法實現(xiàn)迭代增量開發(fā)；
• Scrum對于自組織的團隊要求很高，但許多同學(xué)認為自己達不到自組織的標(biāo)準；
• Scrum倡導(dǎo)工作透明化，項目實時完成情況和每個人的任務(wù)認領(lǐng)情況通過項目看板和項目燃盡圖一覽無余，許多人對此不太適應(yīng)；
• 在迭代的過程中無法及時發(fā)現(xiàn)問題，或者發(fā)現(xiàn)問題，無法有效解決問題，使項目團隊有一種挫敗感。等等。

如果對Scrum的認識僅僅停留在“上午有個點子，下午就要實現(xiàn)，晚上就能上線，是不恰當(dāng)?shù)摹Ｔ谖铱磥?，Scrum肯定是有價值的，Scrum的主要作用包括：

• Scrum能夠保證優(yōu)先開發(fā)對客戶具有較高價值的需求，更好的滿足用戶的需求；
• 與瀑布流程下的開發(fā)方式相比較，通過實施Scrum，能夠提升團隊一倍的開發(fā)效率，最大限度的發(fā)揮團隊的作用；
• Scrum能夠縮短開發(fā)周期，提高項目的交付效率。

但是，實施Scrum并不意味著不受項目約束，任性而為。那么實施Scrum的正確姿勢是什么呢？

PO即Product owner，是一個角色，PO是管理產(chǎn)品待辦列表的唯一責(zé)任人。當(dāng)然，在有些公司PO也可能作為一個組織而存在——比如我們公司在實施Scrum中就將PO作為了一個組織。如果將PO作為一個組織運行，在這一個組織中必須選出一個Owner。

作為owner，必須具有大局觀；深刻了解行業(yè)信息與走向；能夠把握產(chǎn)品的方向，擔(dān)負起產(chǎn)品短期以及中長期的規(guī)劃與管理；能夠根據(jù)公司戰(zhàn)略要求，進行用戶研究和產(chǎn)品功能規(guī)劃，深度跟蹤、分析、挖掘不斷變化的需求，不斷進行產(chǎn)品創(chuàng)新。

另外，如果將PO作為一個組織，在軟件開發(fā)項目中，PO小組可能包括的成員有產(chǎn)品經(jīng)理、業(yè)務(wù)方、視覺設(shè)計師、交互設(shè)計師以及架構(gòu)師等。

在多數(shù)情況下，由產(chǎn)品經(jīng)理或交互設(shè)計師擔(dān)任Owner。

team是產(chǎn)品藍圖的真正實施者，負責(zé)在每個Sprint結(jié)束時交付潛在可發(fā)布并且“完成”的產(chǎn)品增量。

team主要包括開發(fā)及測試人員，team必須能夠落實PO對產(chǎn)品的設(shè)想。

team的規(guī)模宜小不宜大，一般5~9人較為合適。

在敏捷開發(fā)中倡導(dǎo)的是團隊人員的“全棧”能力，但目前在大多數(shù)互聯(lián)網(wǎng)公司可能難于落實，比如多數(shù)互聯(lián)網(wǎng)公司前后端開發(fā)是分離的，所以在組建team團隊時需要特別關(guān)注前后端開發(fā)人員投入的比例。

以我?guī)У?017年開發(fā)的小程序為例，前端和后端人員投入的比例為2:3時，能夠最大限度的提升項目的開發(fā)效率——當(dāng)然，這個比例必須基于項目中前后端所承擔(dān)的具體開發(fā)任務(wù)情況而定，而不是隨性給出。

Scrum Master為過程負責(zé)，服務(wù)于PO和開發(fā)團隊。Scrum Master要有儀式感，能夠有效地、高效的組織迭代計劃會、每日站立會、功能演示會、迭代回顧會等；Scrum Master必須具有高度的執(zhí)行力，并保持公信力，能夠幫助團隊聚焦交付目標(biāo)和質(zhì)量目標(biāo)，確保團隊高效交付高質(zhì)量的產(chǎn)品；推動團隊建立高效的流程，指導(dǎo)團隊了解敏捷價值觀、原則和敏捷實踐；負責(zé)培訓(xùn)團隊其他成員，確保Scrum得到正確運用；促進團隊有效的交流協(xié)作、問題管理、沖突解決，幫助團隊消除一切障礙。

產(chǎn)品需求池是所有用戶故事的集合，由PO依據(jù)公司的戰(zhàn)略和產(chǎn)品愿景進行的思考。PO按照產(chǎn)品實現(xiàn)的優(yōu)先級順序?qū)Ξa(chǎn)品需求池的所有用戶故事進行排序，并形成產(chǎn)品待辦事項列表，產(chǎn)品待辦事項列表相當(dāng)于產(chǎn)品研發(fā)的“路線圖”，要想了解產(chǎn)品的脈絡(luò)，產(chǎn)品待辦事項是最好的參考依據(jù)。

我們每一天都面對著新的競爭者和用戶新的訴求，這意味著PO必須不斷地優(yōu)化自己的產(chǎn)品設(shè)計，并對產(chǎn)品待辦事項列表實現(xiàn)的優(yōu)先順序進行調(diào)整。

在這一過程中，PO應(yīng)該與所有利益相關(guān)者和團隊進行協(xié)商，以確保產(chǎn)品待辦事項能夠反映用戶的真實訴求。

相對精確的評估工作一般都是在沖刺計劃會上進行，并由負責(zé)實際開發(fā)及測試工作的團隊對產(chǎn)品待辦事項做出評估。

在實踐過程中為了讓沖刺計劃會更高效，在沖刺計劃會之前PO與Scrum Master會作出一個粗略的評估?？纯礇_刺計劃是否切實可行？要完成這些事項，現(xiàn)有的信息是否足夠？用戶故事拆分是否合理？在開發(fā)團隊進行評估時，建議摒棄傳統(tǒng)的“人天”評估法，采用故事點的方式，用斐波那契數(shù)列的數(shù)字（1，2，3，5，8，13，21……）的形式去評估。

評估時team需要首先確定一個用戶故事為作為評估的參照。另外，特別注意的是當(dāng)評估的單個故事點大于21的時候，用戶故事需要進行再次拆分，單個用戶故事點數(shù)不超過8是最理性的狀態(tài)。

這是第一場真正意義上的Scrum會議。Team、Scrum Master、PO坐到一起，規(guī)劃沖刺的內(nèi)容。作為軟件開發(fā)項目，進入規(guī)劃沖刺的用戶故事，用戶故事應(yīng)該已拆分完成，并且完成了視覺設(shè)計。

沖刺周期一般是固定的，大部分是2至4周。團隊要從產(chǎn)品待辦事項列表優(yōu)先級最高的用戶故事著手，看看一個沖刺迭代中能完成多少。

如果團隊已經(jīng)開展過多個沖刺迭代，通過參考前幾次迭代中完成的“故事點數(shù)”，團隊可能預(yù)估到本次迭代完成的大概故事點數(shù)。“故事點數(shù)”相當(dāng)于團隊的速度。Scrum Master與Team應(yīng)努力在每一個沖刺迭代中提高這個數(shù)字。

對于沖刺目標(biāo)，即在一個沖刺迭代需要完成的事項，team所有成員都應(yīng)該形成共識。在沖刺計劃會上，PO需要告訴team用戶故事實現(xiàn)的優(yōu)先級順序。team承諾在下一次沖刺迭代中他們能夠完成多少用戶故事。在沖刺的過程中，任何人不能單方面擅自變更沖刺內(nèi)容。

這是Scrum的活力源泉。站立會參加人員一般包括PO、Scrum Master、team。團隊每天在固定地點、固定時間進行內(nèi)部溝通，時間一般為早晨，時長不超過15分鐘，且站立進行，Scrum Master向team成員提出下列問題：

• 你昨天完成了哪些工作？
• 你今天計劃做哪些工作？
• 目前的困難及障礙？

這樣做的意義在于：讓整個團隊清楚地知道在這一個沖刺周期內(nèi)各項任務(wù)的進展，所有任務(wù)是否能夠按時完成。

Team的任務(wù)都不是自上而下分派的，而是自主決定、自愿申領(lǐng)的。如果前一個任務(wù)沒有完成時，不能申領(lǐng)下一個任務(wù)，不能同時申領(lǐng)2個在當(dāng)天不能完成的任務(wù)。

Scrum Master負責(zé)消除團隊面臨的障礙。

在Scrum中，必須做到工作透明化，最常見的做法是實施項目看板制度。

有的團隊善于借助第三方工具使用電子看板，比如Redmine看板，Leangoo看板；有的團隊樂于使用線下物理看板。

無論使用電子看板，還是物理看板，看板的欄目大致包括待辦事項、進行中事項以及已完成事項三個部分。隨著迭代進度的推進，由Team每天及時將事項轉(zhuǎn)移到對應(yīng)看板欄目下。

讓工作透明化的另一個工具是燃盡圖。在這張圖中，一個軸代表工作量，另一個軸代表時間。每天Scrum Master都會記錄待完成的剩余點數(shù)，而后畫在燃盡圖上。理想情況下，該圖是一條向下的曲線，隨著剩余工作的完成，“燃盡”至零。

在《Scrum指南》中將此環(huán)節(jié)稱為Sprint評審會議，書中認為Sprint評審會議應(yīng)該包括開發(fā)團隊演示完成的工作并解答關(guān)于所交付增量的問題、評審市場或者潛在的產(chǎn)品使用方式所帶來的接下來要做的最有價值的東西的改變、為下個產(chǎn)品版本功能或能力的發(fā)布評審時間表、預(yù)算、潛在功能和市場等多個會議主題。

會議一般在在本次迭代沖刺發(fā)布前召開。不過，從實踐來看，我更傾向于此次會議最重要的工作是功能和成果演示，驗證用戶故事的實現(xiàn)場景，并接受評價。

這是一場公開的會議，任何人都可以是參與者，不僅僅包括PO、Scrum Master及team，還包括利益相關(guān)者、業(yè)務(wù)方與管理者，乃至客戶。

團隊?wèi)?yīng)該只展示那些符合“完成定義”的事項，也就是全部完成，不需要再做工作就能交付的成果。這個成果或許不是完整的產(chǎn)品，但至少是一項完整的、可以使用的功能。

沖刺回顧會一般在本次迭代發(fā)布之后的第二天召開，會議時間最好不做具體的限制。

沖刺回顧會要認真分析以下幾個問題：

• 發(fā)生了哪些有待改進的事；
• 為什么會發(fā)生那件事；
• 為什么我們當(dāng)時忽略了；
• 怎樣才能加快工作進度。

作為一個團隊，要讓這個沖刺回顧過程有效，團隊需要相互信任。必須記住基于項目和技術(shù)問題的討論和爭論；對事不對人，不當(dāng)和事佬，鼓勵技術(shù)碰撞；不能把技術(shù)和業(yè)務(wù)討論牽扯到人身攻擊上去；抵制帶著有色眼睛看人，引導(dǎo)大家理性討論；勇敢接受別人的挑戰(zhàn)，接受自己的不完美大家要對自己的流程和結(jié)果負責(zé)，要集思廣益，共同尋求問題解決之道。這一點是至關(guān)重要的。

最后，團隊確定一個最值得改善的地方，將其設(shè)定為下一個沖刺迭代的首要任務(wù)，當(dāng)然，改善的結(jié)果必須通過“驗收測試”。你如何證明自己成功地完成了改善？你需要用具體的、可操作的方式界定什么是“成功”，這樣，在下一個沖刺回顧會議中才能很快判斷出是否已完成改善。

上一個沖刺迭代結(jié)束之后，開始進入新的沖刺迭代。

通過在Scrum項目中的實踐，給我們的團隊和項目組帶來的變化主要有：

在瀑布流程下，通常會設(shè)置包括業(yè)務(wù)方、產(chǎn)品經(jīng)理、項目經(jīng)理、開發(fā)人員、測試人員、交互設(shè)計師、視覺設(shè)計師等多個角色，由于強化了不同角色的定位，而且不同角色又隸屬于不同的職能部門，無形中增加了項目協(xié)同的難度。

在Scrum項目實施中，僅設(shè)置了PO小組、master和team團隊這樣的角色和組織，而且大家在一起集中辦公，很大程度上淡化了角色隸屬關(guān)系，形成了團隊合力和向心力。

團隊合作的要旨是提高團隊的內(nèi)聚性，內(nèi)聚也體現(xiàn)在個人工作焦點上，避免了一個人同一時段身兼多責(zé)。每個人都需要長時間的深度思考和環(huán)境浸染，如果天天在會上趕會，必定是失敗的。

用用戶故事和站立會、沖刺會的形式，重構(gòu)項目過程，細致而又綿密，靈活而又緊湊，減少時間死角，讓需求等人而非人等需求。

實施Scrum，極大的縮短了發(fā)布周期，讓我們的用戶及早的感知產(chǎn)品，這對保持正確的產(chǎn)品航道有極大的幫助，也能更好的幫助公司做好戰(zhàn)略上的決策。

作為敏捷實踐，項目看板制度是必不可少的，通過項目看板制度，項目成員每天完成的任務(wù)情況一目了然，團隊目標(biāo)感明確，顯著增強了工作的主動性和能動性。

深刻剖析和本地化執(zhí)行scrum敏捷方法論，持續(xù)自省，自我革命，破除僵化流程，解除自我保護，項目團隊能夠“就事論事”的討論問題，解決了管理“人”的難題。

2018年，我們將繼續(xù)在用戶故事點數(shù)預(yù)評估，項目燃盡圖使用，代碼質(zhì)量，持續(xù)集成、自動化等方面進行深入的探索。

如同《敏捷革命》所說的那樣：Scrum需要實踐和專注，只有持續(xù)不斷地付出努力，才能達到新的狀態(tài)。我們在前進的路上，我相信，我們會越來越好！