Scrum轉型(一) 爲何敏捷和Scrum

1.1 爲何敏捷

因爲傳統的瀑布模型管理方法沒法知足現代某些軟件產品開發過程的特色，咱們須要使用敏捷的方法（例如，Scrum是一個讓咱們關注於在短期裏交付高質量商業價值的敏捷框架）。

需求頻繁變更，技術不肯定，這正式傳統管理方法不知足如今軟件產品開發的兩個突出問題。由於傳統管理方法不知足須要，纔出現了敏捷的方法。

需求不明確是指：雖然對要作一個怎麼的產品有規劃，可是並不明確和肯定全部的功能細節；而且隨着產品的開發，極有可能對產品功能不斷地改變以適應最終用戶的需求。這種狀況常常發生對全新概念的產品的開發過程當中。

技術的不肯定性指的是：技術的發展突飛猛進，對於所定義功能的可實現性面臨着多重不肯定性的因素。

實施Scrum對組織和項目的好處：
1.更高的生產力和更低的成本
2.員工的參與度與工做滿意度增長
3.更快的產品上市時間
4.更高的質量
5.項目干係人滿意度提高

1.2 什麼是敏捷

敏捷方式的核心思想在於迅速把產品投放給用戶來爲公司帶來盈利，敏捷的特色是迭代和增量。

對於公司來講，敏捷開發的目的就是儘早開發出能夠工做的產品給用戶贏得市場帶來的利潤。在產品投放市場之後，經過客戶的反饋，公司能夠繼續改進產品功能。而實現這一目的的過程就是，項目被分紅若干個迭代，每段時間裏開發出一部分產品功能（增量），而且按照計劃將這些功能投放到市場成爲爲公司盈利的產品。與傳統管理方法提早作好計劃，儘可能規避變化的管理方式不一樣，敏捷擁抱需求和技術的變化，認爲需求和技術的不明確和變化是必然的。 

1.4 敏捷宣言

敏捷宣言是敏捷的根本，它由兩部分組成，分別是敏捷價值觀和敏捷原則。

敏捷宣言：
1.個體和互動高於流程和工具：敏捷強調‘人’，人最清楚如何完成工做，要尊重人的意見和想法。
2.工做的軟件高於詳盡的文檔：這裏強調的是要把重點放在工做的軟件上，讓文檔服務於軟件，而不是把工做聚焦放在文檔上。
3.客戶合做高於合同談判：和合做方建立良好的合做關係共同解決問題要比逐條談判合同細節更重要。
4.響應變化高於遵循計劃：咱們認爲變化是一件好事，項目是流動的，所以項目有變化是正常的，必須隨時調整。

敏捷宣言遵循的原則
1.咱們最重要的目標，是經過持續不斷地及早交付有價值的軟件使客戶滿意，
2.欣然面對需求變化，即便在開發的後期也同樣。爲了客戶的競爭優點，敏捷過程掌控變化。
3.常常的交付可工做的軟件，相隔幾個星期或一兩個月，傾向於採用較短的迭代。
4.業務人員和開發人員必須合做，項目中的每一天都不例外。
5.激發個體鬥志，以他們爲核心搭建項目。提供所需的環境和支援，輔以信任，從而達到目標。
6.不論團隊內外，傳遞信息效果最好效率也最高的方式是面對面的交談。
7.可工做的軟件是進度的首要度量標準。
8.敏捷過程倡導可持續開發。責任人，開發人員和用戶要可以共同維持其步調穩定延續。
9.堅持不懈地追求技術卓越和良好設計，敏捷能力由此加強。
10.以簡潔爲本，它是極力減小沒必要要工做量的藝術。
11.最好的架構，需求和設計出自組織團隊。
12.團隊按期地反思如何能提升成效，並依此調整自身的舉止表現。

1.5 敏捷之傘

按照敏捷之傘的劃分，能夠將敏捷的各類方法分爲兩個部分。一個部分是輕量級的方法（服務於單個團隊的方法），另外一部分是服務於多個敏捷團隊的方法。在輕量級方法中，又能夠從方法的問題這個角度將它們分爲兩類，其中，Scrum, Kanban都是生產產品的框架，用於產品開發或工做管理。而XP(極限編程)，FDD(特性驅動開發)則是工程實踐類的方法。敏捷之傘的另一部分是服務於多個團隊的方法，根據不一樣的項目規模和團隊之間的耦合度，有多個方法來協調敏捷團隊的協同工做（如SAFe,Scrum-of-Scrums,LeSS等）。

Scrum:做爲最受歡迎，使用最爲普遍的敏捷方法，Scrum是一種迭代的增量化過程，用於產品開發或工做管理。
它是一種可集合各類開發實踐的經驗化過程框架。

Kanban:是一種源於豐田精益化管理的方法，它是僅次於Scrum的另一種敏捷開發的框架方法。它有如下特色：流程可視化，
限制WIP(Work In Progress,在製品數量)，度量生產迭代（沒有固定時長的迭代）。相對於Scrum更適合於開發新產品，
Kanban則更加適合於運營團隊實施敏捷的使用。

XP: 極限編程，XP注重的核心是溝通，簡明，反饋和勇氣。由於知道計劃永遠趕不上變化，
XP無需開發人員在軟件開始之初期寫出不少的文檔。XP提倡測試先行，爲了將之後出現bug的機率將到最低。
在XP的12個團隊實踐中，TDD（測試驅動開發）是其中之一。它的原理是在開發功能代碼以前，
先編寫單元測試用例代碼，測試代碼肯定編寫什麼產品代碼，即經過測試驅動整個開發的進行。

FDD：特性驅動開發，FDD是一套針對中小型軟件開發項目的開發模式，是一個模型驅動的快速迭代開發過程，
它強調的是簡化，實用，易於被開發團隊接受，適用於需求常常變更的項目。

Scrum-of-Scrums: SoS是一種管理大型的Scrum團隊的技術（團隊多於12人，被劃分5～10人一組的Scrum小組）。
每一個小組都選出一名錶明成員去參加所在團隊的每日會議。根據不一樣團隊的需求，根據不一樣團隊的需求，
這些表明能夠是工程師或ScrumMaster。經過SoS會議達到小組之間的信息同步，解決問題的目的。

SAFe: The Scaled Agile Framework是一個企業及的敏捷管理框架，適用於管理大型的Scrum團隊。
SAFe框架提供了三層管理模型，分別由項目組合，項目集，實施團隊構成。 

1.6 敏捷怎麼工做

1.建立一我的物列表

項目組須要和產品負責人一塊兒討論，而且由產品負責人建立一個關於‘Scrum電子任務板’應包括的功能列表。在這裏咱們使用用戶故事來描述這些功能，咱們稱每個要完成的功能爲一個用戶故事。

2.給任務標記工做量大小

使用敏捷的估算技術，給這些故事彼此之間相對的任務大小而且估算完成這些故事須要的時間。 

3.給故事設置優先級

項目組須要和產品負責人確認每個故事的優先級，以便保證一直處理高優先級的任務。

4.開始執行

5.根據項目實際狀況更改計劃

在項目的進行中，團隊前後碰到如下兩種狀況。

（1）項目進行的比預期的要快。（2）有太多事情要作，時間不夠用

此時，項目組能夠有如下兩個選擇。

（1）少作一些，縮減一部分功能範圍（推薦作法）。

（2）加緊作，加班也要完成。

1.7 敏捷和瀑布模型的區別

瀑布模型是一個迭代模型，通常狀況下將其分爲計劃，需求分析，概要設計，詳細設計，編碼以及單元測試，測試，運行維護幾個階段。瀑布模型的迭代是環環相扣的，每一個迭代中交互點都是一個里程碑，上一個迭代的結束須要輸出結果做爲下一個迭代的輸入。這樣，當某一個階段出現了不可控的問題的時候，就會致使返工，返回到上一個階段，甚至會延遲下一個階段。

瀑布模型的弊端：

1.質量不高
當發現項目已經沒有錢和時間的時候，測試已經成爲惟一剩下的尚未作的事情。這就意味着項目必須剪掉測試的時間和預算，所以，產品質量就必須定出問題。

2.可見性不高
由於直到項目的最後才能看到產品，在瀑布模型的項目裏，你永遠不知道你真正在哪。項目的最後20%常常花費80%的時間。

3.太多風險
在項目一開始你就有風險：首先，你有時間安排上的風險，由於你永遠不知道項目會在何時完成；接下來，你有技術上的風險，
由於你只有在項目的最後測試階段纔會知道你的設計和架構問題；最後你還有產品上的風險，由於你根本不知道是否開發一個正確的產品，
直到項目的後期不管作什麼任何變化都已經太晚了。

4.沒法應對變化
瀑布模型是環環相扣的迭代模型，是沒法應對變化的。

敏捷有如下特色：

1，需求分析，設計，編碼和測試的工做是持續進行的。
2，產品開發過程是迭代的。
3，計劃更加靈活，能夠調整
4，項目成員爲了同一個目標努力，作出力所能及的奉獻；而不強調‘角色’的分工和明確的職責劃分。
5，擁抱變化，及時調整。
6，交付可工做的軟件是最重要的衡量項目是否成功的標誌。

1.8 什麼是Scrum

Scrum是一個框架，在此框架中人們能夠解決複雜的自適應難題，同時也能高效並創造性地交付儘量高價值的產品。Scurm做爲一個框架，它的最大特色就是迭代和增量。項目以一個迭代接着一個迭代的方式運轉，麼哥迭代的產出就是產品增量。在迭代當中，項目組天天都進行檢查和調整。每一個迭代的工做內容就是實現產品列表上的功能。

Scrum的工做方式：在每個迭代開始的時候，Scrum團隊找出他們要作的產品列表條目。而後開始在這些條目上工做。而且在迭代結束的時候完成這些條目成爲潛在可發佈的產品增量。在平常開發中，咱們常常定義迭代名爲Sprint 1, Sprint 2,...Sprint N,這裏Sprint就是衝刺的意思。

Scrum大概會以下面過程：

衝刺工做前的工做
（1）組建Scrum團隊。
（2）首先肯定衝刺長度是兩週。
（3）準備好產品列表。

衝刺當中的工做
（1）計劃：團隊從產品列表中選擇優先級最高的一兩個（具體取決於團隊能力和故事的難度）用戶故事。
（2）工做於計劃的用戶故事（）召開每日站會以便隨時進行檢視和調整
（3）在衝刺結束前完成這些功能，提交潛在可發佈的增量（也許當即發佈，也許之後發佈，何時發佈取決於產品發佈策略）。
（4）召開評審和回顧會議。

1.9 Scrum框架

Scrum經過三個角色----產品負責人，ScrumMaster，開發團隊----來完成一系列的流程：計劃會議，每日站會，評審會議，回顧會議，工件，產品列表，衝刺列表，潛在可交付產品增量以實現迭代，增量開發。

 

產品負責人是有受權的產品領導力核心，一方面他擔任着產品經理的角色以確保能開發出正確的解決方案，另外一方面他還必須和開發團隊交流以保證
特性的接受標準有明確的說明（用戶故事）而且已經知足後續須要運行測試驗收的標準，以確保特性完成（業務分析師和測試人員的部分工做）。
這個角色責任重大，負責構建正確的產品。

ScrumMaster負責幫助每一個人理解並樂於接受Scrum的價值觀，原則和實踐。對於團隊和產品負責人來講，ScrumMaster履行的是教練，
過程領導的職責。他負責幫助團隊和組織其餘成員發展具備組織特點的高效的Scrum方法。

開發團隊是主任工程師，開發，測試工程師，數據庫管理員，界面設計工程師和其餘傳統軟件開發方法當中定義的不一樣工做類型的
全部類型的人的跨職能的集合。開發團隊負責用正確的方法構建產品。

衝刺（Sprint）是Scrum的核心，它的持續時間爲一個月或者更短（兩週時間最爲廣泛），在這段時間內構建產品增量。
在整個開發過程當中，Sprint的長度都應儘可能保持一致。前一個Sprint結束後，下一個Sprint緊接着當即開始。

潛在可發佈產品增量：在衝刺結束時，團隊應當獲得一個潛在可發佈的產品或者產品增量。若是業務上合適，就能夠發佈；
若是不合適在每次衝刺後發佈，能夠把多個衝刺的一組特性合併在一塊兒發佈。

產品列表：是一個優先級排序的，有粗略估算的，成功開發產品所需特性及其它功能的列表。在產品列表的指導下，
咱們老是優先作優先級最高的條目。換句話說就是，當一個衝刺完成時，已完成的條目都是優先級最高的。

衝刺計劃會： 通常狀況下，產品列表中的工做量遠遠不是一個短時間衝刺內可以完成的。因此衝刺開始的，
團隊須要定製計劃，說明一下衝刺中要建立產品列表中的哪幾個高優先級的特性（生產Spint列表）。

Sprint列表（也稱待辦列表）：是一組當前Sprint選出的產品待辦列表項，同時加上交付產品增量和實現
Scrum目標的計劃（包括每一個待辦列表項完成所需的估算等）。


衝刺評審會和回顧會：在衝刺結束時，團隊與利益干係人一塊兒評審已經完成的特性，得到它們的反饋產品負責人和
團隊既能夠對下一步工做內容進行修改（在評審會上），也能夠修改之前的工做方式（在回顧會議上）。評審會議，
若是利益干係人在看到一個完成特性時，意識到本身沒有考慮到另外一個必須包含在產品中的特性。此時，
產品負責人只要創建一個表明該特性的新條目，並把它以適當的順序插入到產品列表，留到後面的衝刺中完成。
回顧會上，若是開發團隊在回顧衝刺過程當中，意識到本身沒有考慮到依賴風險致使開發過程沒必要要的等待時，
開發團隊能夠提出下一個衝刺計劃會上考慮依賴風險並作好相應的控制。

每日站會是整個Scrum裏面很是有特點的一個會議。開發團隊一個限制在15分鐘內的會議。名副其實，
每日站會須要天天都舉行。這個會議的目的是實現開發團隊天天對完成Sprint目標的進度和
Sprint待辦列表的工做進度趨勢的檢視，而且做出相應的調整和適應。

ScrumMaster在正式開始Sprint 1以前和團隊一塊兒確認了Sprint的長度，開始和結束時間，各個會議的具體時間和與會人員，產品列表和Sprint列表中所應該包括的內容等。在Sprint 1 開始的第一天，SM按照與你們約定組織召開項目組的第一個會議。在會議上，產品負責人向開發團隊解釋了產品列表當中優先級最高的幾個用戶故事，而且表示這些用戶故事是他但願能夠儘快完成的功能。在會議上，開發團隊的工程師們向產品負責人提出用戶故事對應的一些功能性的問題。在對功能清晰之後，SM指導開發團隊開始對每個用戶故事的工做量進行估算。SM幫助你們澄清如何才能進行正確的估算，估算後的結果如何記錄，估算和實際工做量之間的關係等問題。

下面是一份團隊轉型的評估要素：

1 表示徹底不不符合 6 表示徹底符合

分數< 27: 項目不適合轉型

27<分數<40:項目適合轉型

分數>40:項目很是適合轉型

 

 對於第7點的解釋：若是之前的項目作的很糟糕，感受已經無藥可救，那麼轉型帶來的變化再在糟糕也不會比之前糟糕了，因此說在這種團隊很是適合轉型。

 對於第8點的解釋：由於試點團隊的轉型對公司將來總體轉型具備重要意義，因此咱們建議必定要在重點項目上進行試點，這樣才能暴露問題。在非重要項目中進行轉型，沒法積累足夠的經驗，也就沒法引發足夠的重視。

1.10 實踐類問題

1.10.1 我能夠同時實踐Scrum和PRINCE2嗎 

PRINCE2是一個過程驅動的項目管理方法論。它是基於7個基本原則的：持續的業務驗證，經驗學習，角色與責任，按階段管理，例外管理，關注產品，根據項目環境剪裁。PRINCE2關注於項目的計劃和控制。推薦《敏控創變》講解柔實踐Scrum和PRINCE2。

1.10.2 Scrum是否能夠部分應用

Scrum就像下國際象棋要麼遵照遊戲規則，要麼不遵照。若是隻使用部分Scrum管理項目，那就不叫Scrum項目。不建議公司對Scrum團隊定製太多的「流程」，「規定」，「標準」，只要Scrum團隊按照《Scrum指南》裏的各部分去作就好，應該儘可能給各個團隊留下足夠的管理空間。

1.10.3 我何時不能用Scrum

1.當你的項目不用Scurm也能運行的很好的時候
2.當團隊跨國或者有外包參與的時候，Scrum就很難管理了
3.一些對需求很清晰的項目，也沒必要非要使用Scrum

1.10.4 Scrum能夠在大型組織中實踐嗎

一般在大型組織中最大的阻礙就是人們拒絕任何改變。不少人都不相信Scrum真的對組織有用。大多數的組織都認爲本身很特別，Scrum的規則不適用於他們。另一些你可能聽到爭議是：質量控制對咱們執行Scrum過重要了，咱們的項目太複雜了以致於不能Scrum，高管不支持Scrum。。。在種時候，最好的辦法是嘗試從很小的變更開始，證實變化有效，而後慢慢推廣。因此，在大型組織中推廣Scrum容易嗎？固然不，可是能夠在大型組織能夠推廣Scrum嗎？固然能夠～

1.10.5 Scrum是一個框架不是一個方法

框架和方法之間的差異就在於，方式是一個防止四海皆准的，格式化的途徑，就比如PRINCE2，PMP都是方法；可是框架相比之下就更靈活，它是一個平臺，根據環境的不一樣，它能夠提供一系列不一樣的途徑。對於Scrum框架來講，遵照它的規則是最重要的。而它的全部規則都在《Scrum指南》當中。

到此敏捷Scrum入門相關的知識介紹完了～～