我們真的在敏捷嗎？
“敏捷”這個詞在互聯網行業並不陌生，早在我剛入行的第二年，我就有幸加入一家以敏捷開發著稱的公司，並且在那裏得到了較早的一些敏捷的薰陶，比如每天開站會，腦暴，迭代計劃會，項目回顧會等等；那時候並沒有系統的去學習如何敏捷以及什麼是敏捷，只是針對如雷貫耳的敏捷，每天，每週，每個季度在執行一些相關的活動。
來到xx以後，我以一個QA人員的身份投入到項目測試裏面，隨着時間和經驗的增長，也越發的明白，項目質量和時間的控制需要一些項目管理的方法從源頭去把控，從團隊成員各個角度去思考，以結果導向去隨時調整我們的步伐。
在過去的三個月裏面，我經歷過2次比較失敗的迭代，以項目結果來說，非常讓人沮喪，項目延期現象不說，而且項目上線以後出現過一些較爲嚴重的Bug。
不如意的迭代結果給團隊的自信心帶來很大的打擊，痛定思痛，項目成員針對在迭代過程中的問題也進行了相關的列舉和總結：
QA同學總結如下：
1. 項目延期提測，導致上線延遲的風險
2. 需求蔓延，導致測試用例覆蓋不到位
3. 開發提測質量較差，不斷返工
開發同學總結如下：
1. 需求蔓延，導致開發時間緊張
2. 對老系統不熟悉，工作超出預期判斷
3. 對於業務流程沒有很好的理解和把握
4. 前後端聯調經常阻塞
產品同學總結如下：
1. 整個開發和測試階段，對她來說都是盲點，並不能真正的去了解風險和進度
2. 沒有從任何一方提早預知到風險
在那之後的很長一段時間內，其實我都非常的困惑，我們是在敏捷，一樣的開着着Sprint的迭代計劃，一樣每天早上站在一起開站會，討論着昨天干了什麼，今天要幹什麼；一樣的組織着Sprint的評審會；開發測試也都非常努力在做自己的事情，但是面對項目中的各種暴露出來的問題，面對項目中最基礎的鐵三角的結果展示，我一直反問自己我們真的在敏捷嗎？
初識互聯網敏捷的三大支柱
帶着我所經歷的項目痛點，我報了雲課堂的項目管理微專業，帶着困惑和疑問，希望從項目管理專業的角度去發現團隊到底哪裏出現問題；
在敏捷的課程中，我得到了非常大的啓發，結合我們項目的特點，我發現其實我們團隊只是copy了敏捷的身形而沒有領會他的神；當講到互聯網敏捷的三大支柱的時候，我如獲至寶，感覺找到了我想要的答案。
敏捷中Scrum 的三大支柱支撐起每個經驗性過程控制的實現:透明性、檢驗和適應，如下：
第一：透明性（Transparency）
透明度是指，在軟件開發過程的各個環節保持高度的可見性，影響交付成果的各個方面對於參與交付的所有人、管理生產結果的人保持透明。管理生產成果的人不僅要能夠看到過程的這些方面，而且必須理解他們看到的內容。也就是說，當某個人在檢驗一個過程，並確信某一個任務已經完成時，這個完成必須等同於他們對完成的定義。
第二：檢驗（Inspection）
開發過程中的各方面必須做到足夠頻繁地檢驗，確保能夠及時發現過程中的重大偏差。在確定檢驗頻率時，需要考慮到檢驗會引起所有過程發生變化。當規定的檢驗頻率超出了過程檢驗所能容許的程度，那麼就會出現問題。幸運的是，軟件開發並不會出現這種情況。另一個因素就是檢驗工作成果人員的技能水平和積極性。
第三：適應（Adaptation）
如果檢驗人員檢驗的時候發現過程中的一個或多個方面不滿足驗收標準，並且最終產品是不合格的，那麼便需要對過程或是材料進行調整。調整工作必須儘快實施，以減少進一步的偏差。
敏捷的調整
在系統的學習和理解了自適應敏捷以後，領悟到了敏捷所傳達的一些持續改進的精神，於是重振旗鼓，圍繞着敏捷的三個核心的思想，以優化項目時間和質量爲前提，針對項目做了一些流程和制度上的調整：
1.過程透明化
我們首要面臨的問題是如何讓開發過程透明化，這樣做的好處是能夠提早預知到開發過程中的風險，把控項目範圍和時間的風險；
在以往的過程中，我們團隊每天早會的時候，只是站在一起，講講今天干了什麼，明天幹什麼，但是我們沒有針對開發過程進行相關的任務記錄；以及在項目結束的時候，其實並不知道各個開發的預估和實際時間的排期是否有偏差；
基於透明性這個原則，我們利用Jira白板，進行開發任務和新功能需求的跟蹤，每天早會進行跟蹤，並且讓開發自己去記錄相關的預估和實際開發時間，這樣對於開發自身而說是可以提高自己對任務的評估能力和對自己承諾時間的一個自覺性的提高。
其次，針對測試的同學，需要將測試計劃以及測試過程透明化。在用例評審的時候，需要着重的將測試策略和測試用例過一遍；其次項目提測後至上線前，針對每日的測試進度和風險，進行郵件全員抄送，這樣做的目的是便於讓大家一起了解整個產品的進度和質量。
2.交付可檢驗
我們面臨的第二個問題是如何提高開發的交付質量。在以往的過程中，主要突出的核心矛盾有2個：
1.在前後端聯調的時候，後端同學交付出去的聯調接口質量較差，聯調時交付的接口50%以上仍然處於500的狀態，所以聯調時間較耽誤大家的時間。
2.開發提測的質量版本較差，導致Bug較多，不斷返工。
針對這兩點，我們做了一些改進，希望在每一次提測之前，都可以有一個檢驗的標準，可以確保任務及時的完成：
1.聯調前：利用接口測試平臺，要求在後端用統一用平臺自測成功後纔可開始聯調。
2.提測前：細化冒煙用例，統計每個版本的冒煙通過率進行版本迭代的跟蹤，制定冒煙通過率的標準。
總結
隨着不斷的調整和改進，團隊在質量和時間把控上有了各種改善和提高。
同時也讓我明白，一個項目裏面，我們遇到的問題大多是我們所看到的問題，可能問題的呈現方式會是各種各樣的，在這個過程中，我們很容易被問題的表相所迷惑而是採取出現一個窟窿填一個窟窿的方式去解決問題;尤其在互聯網企業中，敏捷開發的一些模式和方法能幫助我們很好的把控項目的進度和質量，但是團隊如果僅僅走了敏捷的形式而沒有領悟到敏捷的靈魂，仍然會暴露出非常多的問題。深刻理解敏捷背後的一些核心的支柱，核心的思想理念，敏捷的目的和價值以及團隊所執行活動的背後的原則給我們提供了一些解決問題的思路，可以幫助我們從源頭去找到問題和方法，給予團隊不斷去挑戰困難和變化的信心！