李子驊--石墨文件技術總監。
一個產品有需求的提出、評審、確定，以及實際的開發測試和交付這幾個階段。從2001年敏捷被提出開始到現在已經有越來越多的專案在使用敏捷。現在的敏捷已經變成一種常態，這個時候討論敏捷實踐中被大家的忽略點就變得非常有意義。
今天我們會圍繞兩個關鍵的點來討論：一個是關注非功能需求，另一個是DevOps相關的策略。
關注非功能需求
這是一個網站的截圖，上面有兩個文字塊，第一個是標題，第二個是答案。
看到這個圖，首先大家會想它是什麼東西，其次是為什麼會有人問這個問題。
這是現在最流行的前端開發框架 React 的新一代的核心演算法，Fiber的提出有兩個背景原因。
第一個原因 是現在越來越多的產品和網站非常複雜，尤其體現在互動和功能方面。就比如石墨文件可以讓很多人同時線上編寫 Word 文件，這和之前傳統的類似部落格和新聞的Web 應用不一樣，現在我們會有更復雜的互動，所以複雜互動帶來什麼呢？越來越多的使用者發現雖然網站功能越來越多，但是好像網站也隨之變得更卡了。滾動的時候會有一些延遲，開啟一個網頁會越來越慢。Fiber專門是為了解決這個問題，也就是說當你的網站很複雜的時候它可以讓你的網站速度響應更快一些。
第二個原因是什麼呢？ 經過長期的發展，React是現在最流行框架之一，全世界使用者都在向它提各種需求：我想加這個功能，要那個功能，但是長期發展過程中也積累了很多技術債，也有很多沒有完成的重構的東西，所以他們也希望能夠通過Fiber的開發可以把這些技術債還上，把它變成更容易維護一些。
到現在，Fiber開發了滿打滿算兩年時間，它已經推出了。推出之後大家驚喜的發現我的網站好像變快了，我們也可以看到React市場佔有率在逐漸升高，迭代頻率也在逐漸加快。所以其實Fiber的開發就是一個很明顯的非功能需求，大家收到很多需求反饋，但是最終團隊還是選擇開發這樣一個Fiber的工具。
所以，我們當提到非功能性需求的時候，會有幾個常見類別，包括響應的速度、負載能力和測試覆蓋。每個團隊根據不同的情況會有不同的處理方式，把非功能的需求放到Acceptance Criteria裡面，也可以放到Definition of Done裡面作為這個使用者故事是否完成的標準。
不同的方式其實各有利弊，如我們在開發石墨文件過程中支援多個人在一篇文件實時編寫內容，同時每一個人看到編輯的東西，這是很明確的功能需求。
怎麼去約定它背後的非功能需求呢？大部分情況下應該把它放到我們的驗收準則裡面，就是說我們可以約定一些通用效能需求。就多個人實時編寫這個例子來講，可能會約定一個人數，比如希望能夠十個人都能夠去實時編寫，然後每個人的儲存時間可以控制在一秒鐘之內。這樣當我們去完成這個使用者故事的時候，我們會看驗收準則，如果它支援了在一秒鐘之內儲存，那我們就確定它是完成的，所以這是一個對於事情有沒有完成的很清晰的量化標準，不會讓人忽略掉非功能的方式。
但其實也有另一種做法。有些團隊會把這種非功能需求當成一個獨立的專案，然後放在Backlog裡面，這會造成什麼問題呢，在時間寬鬆的情況下沒有什麼問題，但是當開發遇到一些阻礙的時候會發生什麼事呢？就是我們常常會傾向於優先解決客戶能看到的東西。因為當我去交付這個專案的時候，客戶看到有這個功能覺得還挺不錯，你們工作很快，然後你們也很賣力，這些功能對我也很有用處。
可實際上隱含的非功能性需求非常重要：能夠承載多少人、能不能在公司範圍內使用我們的產品以及安全性怎麼樣等等，還有一個很容易被忽略的點就是專案的可維護性是如何的。
長期迭代中，敏捷強調越來越頻繁的跟客戶溝通，去了解客戶需求，響應使用者的需求，所以開發速度會非常快，互動週期非常短。
在這個時候，很容易發現就是我們會忽略掉我們產品的可維護性，就比如我們會引入很多技術債，會有很多投機取巧方法把這個東西快速上線。到下一個迭代的時候，卻繼續關心客戶反饋的其他需求了，沒有再去解決之前的技術債。這就會導致一個產品開發的時候，初始階段速度很快，但是越到末尾越會發現速度越來越慢了，直到不能不得不停下來大家坐在一起討論解決這個問題。
兩個“負責人”
這個負責人是打引號的。為什麼打引號呢?
最近很火的一部電影 《綠皮書》 ，看過這部電影的同學應該都知道《綠皮書》有兩個男主角。
坐在後排的這個人獲得了最佳男配角獎。其實大家很難想象他是配角，因為如果這部電影少了他，我們很難想象這部電影怎麼能拍得下去，怎麼能把這個故事講完。所以，雖然我們會有主角，會有配角，但實際上很有可能這兩個人缺一不可，我們應該做到不能忽略其中任何一個人。
在一個敏捷團隊專案裡面，我們很關注PO的決策，很關注PO的傾向，他會去把我們做的事情按照優先順序排列。其實，我們還需要另一個負責人，就是說他需要能夠很清晰地瞭解我們現在的狀態，我們現在團隊的情況，我們的開發的速度，我們對一些非功能需求的深刻理解。
就比如可維護性到底是如何，需不需要停下來做一些重構，還是繼續前進。
對石墨來講這個「負責人」不是一個角色，因為我們不會設定一個職位做這個事情，如果專門設定一個職位這個事情的時候，整個團隊其他人很容易說：「好像這個職位的人他只要做這個事情就可以了，我們其他人不需要關心。」這反而會造成對整個非功能性需求理解的一個倒退，會起一些反作用，對於我來講更重要的是從文化角度把非功能性需求的灌輸給整個團隊可以使得團隊透明的理解和推動NFR，非功能需求。
什麼叫透明的？ 簡單留有一定比例的NFR時間不能幫助透明化。很多團隊會有另一種做法，就是我可以有很多功能性需求，可能有很多使用者的反饋，但是我也要做一些可維護性的東西，我要做一些重構，我要去還一些技術債，我要去做團隊的提升，我要做一些方便部署的事情。為此我需要在每個迭代週期預留固定的10%或20%的時間來做這些事情。
這樣會有什麼問題呢？ 一個敏捷團隊，或者正常一個團隊，我們最關注它是能不能自我成長，自我提高，自我進步，自我反饋。所以當討論非功能性需求的時候，其實是一個很好的契機，整個團隊，包括我們的PO、包括我們的整個的開發團隊，可以坐在一起一起討論為什麼我們要花這些時間去做這個重構；為什麼現在去做，而不是下一個迭代去做；這些會對我們的使用者、商業產生什麼樣的價值。我們會發現這些討論可以讓整個團隊能夠更快地去得到一些反饋，更快地知道我們的產能到底是什麼，而不是說我們儘快地去完成客戶所有的的事情，直到因為技術債的各種包袱導致我們不得不停下來。
所以透明地和整個團隊討論這件事情，使得團隊可以自我提升，這是一個很重要的事情。
DevOps 的左移
提到非功能性需求，我們很自然就會聯想到DevOps，這是一個很自然的關聯。
DevOps左移，看這個圖就知道了：
我們知道大部分的敏捷框架或者敏捷方法都會很關注軟體迭代開發的部分，就是左邊這個部分，我們要有敏捷團隊、我們讓開發團隊和業務團隊坐在一起、我們能夠實時去了解客戶的需求、儘早根據不同的環境做不同的改變，我們希望能夠儘早地頻繁地去交付可以工作的軟體給客戶。
但是，右面是什麼？ 右面是我們傳統的IT實施運維，他們最關心的是穩定，這個東西如果沒有問題，就儘量不要搞，上線的次數不要太頻繁。我們每次上線可能都會有風險，我們要盯著這個上線的過程，然後運維同學也要去，所以對於運維來說，上線是一個很痛苦的事。
於是，你能發現，這個綠色的和黃色的好像是有一種衝突在裡面，左邊是希望能夠更加頻繁一點，儘快交付，右邊是冷靜一點，不要這麼快。所以，大家會發現當採用了敏捷的時候，如果我們在運維層面不做任何改變的話，整個交付給客戶的時間有可能並沒有縮短。
我要怎麼做呢？就是標題所說的，我們要將運維向左移，這個就回到我演講這個話題，敏捷思想在產品週期的延伸，我們什麼時候延伸，當我們敏捷的時候關注的是溝通，就是我們會和環境溝通，我們會和客戶溝通。
那其實也一樣的，開發團隊要做什麼？運維團隊要做什麼？這個其實也需要儘早溝通，就像這個圖一樣，我們可以在更早的時間，比如說開發的第一天，或者是我們在開發之前，就讓大家坐在一起溝通。
DevOps最重要是什麼，其實很難有一個確切的定義。
我們可以說它是一種方式，一種工具，也是一種文化，所以最根本的就是溝通。就是說我們在敏捷時已經證明了溝通的重要，我們可以快速的把軟體交付給客戶，更快速地去確保我們這個東西滿足使用者的需求。而不是以前那樣埋頭苦幹一兩年，丟給使用者，使用者卻說這不是我想要的。所以專案部署也是一樣，像過去如果我們做埋頭開發，最後丟給運維團隊，運維團隊說這可能不是我們想要的，我們可能部署不了。其實之前石墨經常會遇到這樣的問題，就是我們其實迭代會非常的頻繁，客戶需求也會非常多。所以對當時的我們來講最痛苦的時候就是當一個迭代結束，要部署的時候，發現部署是一件很可怕的事情，我們經常在部署時發現部署指令碼有問題、程式碼好像有點問題、部署上線了但各種錯誤撲面而來，運維電話響個不停。
實踐：石墨服務開發流程
現在去看之前，我覺得石墨開發的最重要的一個基礎的產品，就是我們內部使用的交付平臺。通過它，我們的迭代週期可以更短，交付頻率可以更快，部署上線的整個流程也會更穩定。
因為石墨是面向企業線上協作的軟體，所以我們自己也會用石墨寫一些文件。這個截圖可以看到及我們會用石墨寫一些案例、寫一些值班計劃、寫一些工作日誌、技術分享和假期安排。
石墨每個員工都是自己產品的重度使用者。剛才提到的敏捷，我們最關心的是怎麼能夠接受反饋。其實內部員工的反饋往往比使用者甚至種子使用者來得更快，這是因為大家都坐在一個辦公室裡，天天見，也會更瞭解產品。
所以，我們就在想兩個事情:
第一個事情是我們怎麼能夠儘早地收到我們內部員工的反饋；
第二個事情就是怎麼能夠把我們最害怕的問題，部署的問題解決掉。
所以，我們做了一個這樣的功能。
“隨時測試和部署每個功能” 這個功能是怎麼用的呢？石墨在開發每個專案的時候，每個小組開發每個專案的時候都會建立一個特性分支，然後我們所有的功能都會在這個特性分支裡去開發。每個石墨的員工，訪問石墨的時候都會有一個特殊的頁面，如截圖所示，通過這個頁面，每個人都可以去配置每個微服務使用哪個特性分支來相應自己的請求。
舉個具體例子
就是回到剛才這個圖，前幾個月我們是沒有左側的樹型目錄的，但是很多內部員工會反饋，如果左側有樹型目錄，就能更容易地找到和管理自己的文件。所以我們決定加上這個功能。當開發進入第五天的時候，我們已經可以通過這個平臺把正在開發的樹形目錄可以給內部員工用了，我們會發各種邀請連結，告訴大家可以到這裡選擇我們特性的分支，然後重新整理就可以看到這個樹形結構來實際體驗了。
在我們開發之前，其實大家都應該知道我們會把設計圖會給利益相關者，會給老闆看，但這個圖給客戶看的時候，客戶說還不錯,，但是我們把軟體交給客戶的時候，經常發現他們說這個跟當初好像不太一樣，不太能滿足自己的需求。其實每個人都一樣，大家看設計圖和在實際工作場景中使用這個東西的時候，感觸是完全不一樣的。
看圖可能會忽略很多東西，但當你每天使用的產品出現這樣變化的時候才能切實的感受到這個東西到底好不好用，到底有沒有改進的地方，第五天的時候可以把左邊有樹形目錄的產品發給我們的員工看，他們可以把資料放在石墨上，他們會日常體驗，因為他們每天用這些文件，所以能很快發現這些東西到底合不合適，到底能不能滿足他們的需求，所以也是通過這樣我們可以能夠非常早地去收集到我們使用者的反饋。
相比於之前我們會花很高的成本做AB測試的策略、做各種實驗來分析我們的使用者使用場景。然後要過兩三週的時間才能把這些資料彙總起來。
通過這樣的功能，我們就能夠非常以一個最低的成本，最快的速度收集到客戶最真實的需求。
第二個問題就是剛才說到了，我們每次迭代最怕的就是部署的那一天。因為之前經歷到一些部署的問題。現在我們通過這個平臺可以做成什麼樣呢？部署就像切換標籤一樣方便！剛才講內部員工可以通過這個平臺去選擇每個模組所要使用的分支，對於釋出來講是一樣的。
我們可以設定一個比例，比如2%或者10%的使用者可以訪到某個分支，然後剩下百分之幾的使用者可以放到另一個分支，其他的使用者再訪問到線上分支。它是一個非常快速、靈活的一種上線的方式。
文章來源：Worktile敏捷部落格
歡迎訪問交流更多關於技術及協作的問題。
文章轉載請註明出處。