李子驊--石墨文檔技術總監。前端
一個產品有需求的提出、評審、肯定，以及實際的開發測試和交付這幾個階段。從2001年敏捷被提出開始到如今已經有愈來愈多的項目在使用敏捷。如今的敏捷已經變成一種常態，這個時候討論敏捷實踐中被你們的忽略點就變得很是有意義。算法
今天咱們會圍繞兩個關鍵的點來討論：一個是關注非功能需求，另外一個是DevOps相關的策略。安全
關注非功能需求
這是一個網站的截圖，上面有兩個文本塊，第一個是標題，第二個是答案。微信
看到這個圖，首先你們會想它是什麼東西，其次是爲何會有人問這個問題。markdown
這是如今最流行的前端開發框架 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敏捷博客