<pre id="ff7yo"></pre>

      <form id="ff7yo"><legend id="ff7yo"></legend></form>
        <nav id="ff7yo"><listing id="ff7yo"></listing></nav><nav id="ff7yo"></nav>

        <nav id="ff7yo"><listing id="ff7yo"></listing></nav>
        <small id="ff7yo"></small><nav id="ff7yo"><dd id="ff7yo"></dd></nav>
      1. <nav id="ff7yo"></nav>
          <form id="ff7yo"></form><nav id="ff7yo"></nav>
          <nav id="ff7yo"></nav>
          <sub id="ff7yo"></sub>
          更多課程 選擇中心

          軟件測試培訓
          達內IT學院

          400-111-8989

          你一定要了解的團隊敏捷轉型的三個階段

          • 發布:軟件測試培訓
          • 來源:軟件測試教程
          • 時間:2017-07-20 14:29

          我們假設,敏捷轉型的開始是瀑布式開發,我把這個階段定義為Agile 0,根據我們的敏捷成熟度模型(AMM)里提及的最終形態定義為Agile 5,期間會經歷三個階段。

          階段一(Agile 0 – 1):建立敏捷流程,縮短交付周期

          這個階段,引入迭代或者建立看板是重點,類似于下圖:

          (Scrum運作全景圖)

          這個階段的主要目標,就是將需求的反饋、開發質量的反饋、以及改進周期縮短在一個迭代內(通常2-4周)。 為達到目的,Coach主要會做以下一些事(Actions):

          培訓 – 給團隊培訓敏捷流程、各角色的職責,以及各種工具的使用(比如Jira)。

          現場指導 – 先帶領團隊走完整的敏捷流程,通常會有幾個迭代;然后觀察團隊自己執行流程,并幫助團隊改進;最后不再參與這類活動。

          需求梳理 – 指導PO和BA建立需求全景圖(比如Story Map)、拆分Story、排優先級、和團隊其他成員協作等;制定Story編寫規范,Story價值流和建立Story看板。

          這個階段主要培養的目標,是Scrum Master或者類似的角色,讓他們能了解敏捷流程的運作方式,并能帶領團隊在Coach不在場的情況下,依然按敏捷流程運作。

          要走過這個階段,有一些關鍵指標:

          交付周期 <= 3周:如果是迭代開發,則應該每個迭代小于3周,并且每個迭代都Release;如果是用Kanban,則Story的Lead Time應該小于3周。

          上線的已知缺陷數 = 0:有些企業會給缺陷分級,只要求把高優先級的修復,但是我們推動敏捷,要求質量不可妥協,因此需要轉變客戶的想法,讓客戶把缺陷修復放到高優先級。

          Finish Rate / WIP:如果是迭代開發,為了改變瀑布式開發硬塞需求的習慣,一定要控制Finish Rate大于80%。如果是看板,那就要控制到WIP,讓每個人專注于一件事的完成。

          有些人說為什么不從技術實踐開始?設想一下在瀑布式開發中,開發團隊幾周甚至一個月才交一次版本給測試團隊,在這種情況下,開發怎么會有動力寫自動化測試?運維怎么會有動力做自動部署?需求沒有妥協的空間,設計沒有妥協的空間,導致團隊的痛點永遠是按時交付,質量一定會被犧牲掉的。因此只有先強制縮短交付周期,讓團隊痛點轉移,才能改變開發人員對質量的觀念。至于這個過程中導致的交付速率降低,我們會說:

          在敏捷轉型前期一定是有所付出的,然而你投入越多,進展就會越快,收益就會來的越早。

          沒有質量的交付不能稱為完成,只能叫半成品或者次品。

          由此我們來討論第二階段

          階段二(Agile 1 – 3):引入技術實踐,質量內建,減少返工

          這個階段的主要目標,是提升開發人員的質量意識,從而提升開發階段產出的質量水平,減少后續環節的返工。用質量內建的話來說,在缺陷時就立刻修復。這樣做的好處就是同時提高了質量和團隊整體效率。 其實在軟件開發中,生產過程隨著開發結束而結束,隨之而來的都是檢查和傳遞,因此產品的質量實際是由開發階段就確定的,如下圖:

          (Story的生命周期)

          只有提升生產過程的質量,才能減少返工,提高效率,因此我們在這個階段會引入技術實踐,縮短質量驗證的反饋周期,主要包括:

          單元測試:單元測試的反饋周期最快,也在測試金字塔的最底層。要求開發人員編寫單元測試,一方面可以提升開發人員的代碼設計能力,提升代碼質量,另一方面可以提升開發人員的質量主人翁意識,讓開發階段的交付物質量有所提高。

          集成測試:包括API測試和組建測試、契約測試等。這依然是要求開發人員來編寫,提高開發人員的能力和意識。

          UI自動化測試:如果是帶頁面的項目,這個階段通常都會引入UI測試,一般會要求測試人員編寫,這個階段的主要作用是幫助團隊提高回歸測試的效率。

          CI:通過CI服務器,將以上測試定期運行,并可視化報告,讓所有團隊看到。同時要求團隊第一時間修復CI。

          CD Pipeline:建立自動部署流水線到生產環境,并集成冒煙測試,E2E測試等自動化測試,同時實現回滾。

          Git:建立使用Git的規范,建立分支策略或者指導客戶做純主干開發,培訓客戶使用GIT高級功能,同時解決一些疑難雜癥。

          Operation相關技術:指導客戶實踐藍綠部署、云和容器、金絲雀發布等。幫助客戶設計更好的部署架構和技術架構,同時幫助客戶架構師做更好的決策。

          這個階段培養的主要目標就是開發,建立開發的質量意識,幫助開發寫出更好的開發,培養開發處理復雜問題的能力。同時開闊團隊視野,讓團隊成員了解更多的技術,學習如何利用新技術提升自己效率。

          除了第一階段的指標繼續改進外,這個階段我們會重點關注的一些指標:

          CI相關指標:做CI的背后其實是為了培養團隊能力

          CI觸發頻率 > 開發人員個數:確保開發人員每天每人有提交。

          CI通過率 > 80%:確保開發人員在提交代碼前做了本地自檢。

          最近一周內的CI修復時長 < 8h:確定團隊對CI有足夠的關注,沒有CI紅過夜。

          質量相關指標:

          一次通過率 > 80%(或者迭代手動Test的缺陷數接近于0):Story開發完成后,會對完成的功能做一輪手動測試。這時得到的缺陷數,代表了開發階段的質量,缺陷數越少,說明開發人員的自動化測試和CI做的越好。一次通過率可以作為更高的要求,因為包括了后續的測試環境和生產環境中,產生問題的返工。

          單元測試覆蓋率 > 80%(大家不要糾結為啥是80%,你也可以改成79%,或者100%):首先要確保單元測試的數量在持續增加,同時要有Code Review的機制來保證單元測試的質量。另外,如果覆蓋率造假,那一次通過率一定不會得到改善。

          測試金字塔:收集各層測試的數據,并關注是否是一個良好的金字塔,給個參考比例1:2:7。這里需要特別關注的一點,如果發現頂層測試數量太多,通常說明開發人員對自動化測試的關注不足,需要加大對單元測試和集成測試的推廣力度。

          交付相關指標:

          CD Pipeline的Cycle time < 1h:這個一定要嚴格控制,假設一個團隊有8個開發,每人每天提交一次,那一天至少提交8次,如果Pipeline跑的太慢,就會影響到大家的代碼提交。當然,你也可以把這個時間要求減少,只是我的經驗里,有些部署環境復雜、UI測試寫的有點多的團隊中,1h完成已經是一件非常難的事了。

          一個月內 Product Incident <= 1:差不多就是1年小于10個的標準,這個數字可以根據不同行業有不同要求,銀行業通常會更嚴格,而創新互聯網企業對線上事故的容忍度會更高。

          其他SLA指標:比如服務可用率、響應速度、負載等,這些指標關系到的是部署架構和技術架構的設計和實現。

          這個階段會耗時比較長,因此會有兩階的跨度,第一階是起步,往往會有教練帶著團隊做重構,寫自動化測試Demo,定規范和總結最佳實踐。到第二階后,這些能力就由團隊自己去傳播了,教練只會偶爾參加一下Code Review來看看團隊是否走在正確的路上。

          小結:

          總的來看,以上兩階段就是幫助客戶建立流程,定義參與角色并找到適合的工具,然后通過度量追蹤整個轉型過程,并逐步引入敏捷實踐來提升相關指標。

          (敏捷轉型內容示意圖)

          階段三(Agile 3 – 5):提升價值交付效率和響應力

          到Agile 3為止,我們一直在告訴客戶你要做什么,通過改變客戶團隊成員的行為,來改變他們的思想,特別是開發人員的質量意識和團隊成員的能力。基于已有的成果,這個階段的目標,就是培養成員的自我提升意識,團隊的自我改善能力,并幫助團隊建立自我改進的習慣。

          因為團隊專注于自我改進,因此大家會有自己的改進線路,不過無論如何,都會專注于以下幾個方面:

          更高級的能力建設:能進入這個階段的團隊說明已經具備了支撐快速變化業務的基本能力,因此可以推動更高級的能力建設,比如引入微服務、代碼共享、特性團隊等(這些能力也能在階段三之前引入,但是只有在有了階段二的基礎后,才能真正做好)。

          以Coaching為主:我們Teaching的內容會變少,Coaching的內容會變多,會讓客戶自己組織更多的分享,鼓勵客戶自學,并建立學習型文化。我們會和一些關鍵人物定期的做交流溝通,來幫助他們解決他們所面臨的問題。

          與業務走的更近:團隊可以更好的理解業務,同時能給業務提供更有價值的建議,因此很多業務在決策早期就會引入技術團隊的成員。另外團隊也能更好的做出業務想要的東西。 在這個過程中,文化貫穿始末。因為團隊能力變強,所以更容易建立業務和技術團隊的信任,形成信任文化;因為團隊養成了自我改善的習慣,所以更容易形成學習型文化;因為大家有信任、有能力,所以會打破原來的控制型文化,培育出創新型文化。這些文化的建立,能更好的幫助企業在未來保持良好增長。

          這個階段度量的內容會關注在響應力、創新上,這里給些參考:

          交付周期 < 5d:這是響應力的象征。

          假設驗證率:這個指標可以用來考核PO,理論上學到的知識越多,這個數字就會越高。

          其他業務指標:這時團隊關注的是如何幫業務走向勝利,因此在軟件開發時就會大量埋點用于業務分析。

          總結

          整個轉型的過程,其實是行為改變思想,再通過思想影響行為的過程,當團隊中的人員能力慢慢提升,思想也在隨之改變,所有人都能對什么是正確的事作出更好的判斷,繼而走向持續改進的道路。所以如果定義團隊轉型成功,我認為就是幫助團隊建立起了一群能自己做持續改進的自組織特性團隊。 團隊要經歷這三個階段必然是一個漫長的過程,很多錢多氣粗的企業一定想知道有沒有什么捷徑,我的答案是有:敏捷轉型的過程就是培養大家能力的過程,既然終點是所有人都擁有很強的能力,那為什么不在一開始就找這樣的人來工作呢?

          預約申請免費試聽課

          填寫下面表單即可預約申請免費試聽!怕錢不夠?可就業掙錢后再付學費! 怕學不會?助教全程陪讀,隨時解惑!擔心就業?一地學習,可全國推薦就業!

          上一篇:網易測試團隊轉型實踐整理(精華)
          下一篇:產品需求怎么做?產品需求怎么做好?
          • 掃碼領取資料

            回復關鍵字:視頻資料

            免費領取 達內課程視頻學習資料

          • 視頻學習QQ群

            添加QQ群:1143617948

            免費領取達內課程視頻學習資料

          Copyright ? 2021 Tedu.cn All Rights Reserved 京ICP備08000853號-56 京公網安備 11010802029508號 達內時代科技集團有限公司 版權所有

          選擇城市和中心
          黑龍江省

          吉林省

          河北省

          陜西省

          湖南省

          貴州省

          云南省

          廣西省

          海南省

          神马影院-战旗影院-首播影院-新视觉影院-在线观看中文字幕dvd播放 百度 好搜 搜狗
          <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <文本链> <文本链> <文本链> <文本链> <文本链> <文本链>