精華問答：
關于靈活
@金濤：多個項目并行，并且有傳遞時間點壓力是不是不适合靈活看闆方式？
@何勉： 有點困難，我們需要的是更多的關注産品。 阿裡雲的對外傳遞項目面臨同樣的壓力，我們現在的做法是更多的關注産品，從不同的項目中抽象出場景，用老大的話是：“勤于規劃，勤于抽象場景”。用産品的規劃來滿足多個項目
@上海-前端-alery ：靈活開發的核心是什麼呢
@舍衛 ：順暢和高品質地持續傳遞有用的價值，進而促進業務目标的達成。
@小飛_PHP開發_深圳 ：前幾天看DevOps,有一句話有我覺得可以分享一下，靈活開發是一套方法和實踐，但 又不是固定的套路，能得到或者實作目标的都可以來用。大意如此。
@姚高林-淺涵 ：想問問 關于靈活開發 對團隊成員，包括 UED、PD、後端、前端、測試 會有哪些不一樣的能力要求？開發流程、工作内容、職責範圍、溝通協作有什麼不一樣？該如何提升相關的能力？
@小飛_PHP開發_深圳 ：沒什麼不同吧…… 盡量更細的拆分需求，更頻繁的跟進進度，有問題及時回報，讓每一個環節 更細小、輕快，友善調整 排程 安排。 靈活開發都是為結果負責的，根本目的還是要更快更好的傳遞軟體。不用想的高大上。降低溝通成本、提高軟體開發品質，降低軟體傳遞周期，都是為了提高軟體價值。
@姚明偉 ：請教個問題，面向B端市場的硬體裝置開發，實際開發過程中，會發現硬體疊代一版的周期都會很長，如何在這種情況下使用scrum？換句話說，scrum是否适用于硬體産品的開發？
@劉昶：這個看硬體開發的功能是否能分解細化，如果可以應該是可以适用靈活的。也就是說疊代版本太長是不是功能獨立性不夠或者功能太大太多
@姚明偉 ：使用者故事不夠細？不夠小？或者是說功能子產品的拆分不夠獨立？大多情況都是，前幾個sprint完成卡片數都是0，硬體開發出來的那一個sprint，可驗證的故事一下子好幾個
@雲層：看拆分吧，sprint可長可短
關于站會
@小臣：每天的站會，怎麼來驗收效果
@小飛—PHP開發—深圳：可以談談站會的作用嗎
@黎昊 ：問下各位 如果遇到 測試工作還沒開展 此時他們是不是不用參加站會？除了将要到測試工作的前兩天才讓其參與？
@上海-前端-alery ：我覺得測試還是要參加的，測試要根據産品需求提前寫測試用例和文檔，每天也要彙報自己的工作進度
@GBASE 黃軍雷 天津 ：站會兩個目的：建立團隊共識，資訊及時回報
前往站會課程關于DevOps
@楊波：持續內建和自動化測試架構用啥好呢
@Youngee ：持續內建一般都是 Jenkins。自動化測試一般需要按分層來，不同層技術不太一樣：單元測試 junit + easymock 等 mock架構，UI 層可以用大阿裡的 macaca （
https://macacajs.github.io/zh/introduction）。
（小編說：當然也可以使用
雲效——一站式DevOps工具平台喔）
@李文輝 ：如何在傳統企業中比較傳統的研發模式下，逐漸推進DevOps，實作持續內建和傳遞？
@雲層：首先是文化，梳理價值，持續內建和傳遞可以先行，devops還比較後面。
@李文輝 ：持續內建、傳遞比較依賴自動化水準，目前傳統企業的研發模式下，自動化水準都比較偏低。
@雲層：持續內建在開發端是比較好做的
@Youngee ：自頂向下，還是自下而上，然後再讨論。
@雲層：先把打包釋出的自動化做起來，再做上線自動化，接着在這個流水線上逐漸引入品質監控和分支管理
@李文輝：打包、釋出相對好做。
@Youngee ：有時候一個高層可以給你省掉很多事
@李文輝：上線自動化，品質監控，需要推動從研發、測試整體流程的改進。持續內建，肯定是要自頂向下去推進。
@雲層：規範了建構腳本和環境，很多事情就可以慢慢對接了
@李文輝：在推進研發往持續內建方向過程中，遇到的最大問題是什麼？自動化測試工作量？品質和效率的平衡？請問剛提到的文化、價值，如何了解？
@雲層：做靈活,devops一定是所有人都意識到配合才行。推薦先拿曆史項目做維護拆分練靈活
關于代碼分支管理
@慕白：靈活中并行開發是常态，在小團隊裡（開發測試共25人），代碼分支合并有什麼好的建議嗎？
@懷虎：因人而異，人員能力比較強的，就直接主幹開發。用持續內建和自動化測試保證代碼品質，再加上功能開關，将部署和功能釋出解耦。
@慕白：請教一下 關于代碼分支和主幹的問題，隻有一個開發主幹dev分支，每次測試都在dev上，當驗收通過後，拉取一個分支，打上tag，作為代碼的release版本，釋出到準生産環境。這樣有個問題，就是在驗收之前，總有不守規矩的開發，送出代碼到dev上，怎麼能避免或者降低這種情況呢？
@金戟 ：主幹開發也是需要配合Code Review的實踐的，可以是使用Merge request和小的代碼送出分支的方式來Review，也可以是先送出主幹，每天固定時間所有開發一起過一遍當天所有的送出，然後及時發現問題。第二種方式對開發團隊的成熟度要求會更高，适合整體能力比較好的團隊。前一種更帶有一定管控性，總之單主幹并不是說随便什麼代碼可以都直接往主幹上送出，也是需要規矩的。業務發展初期的時候，多快好省還行，到業務積累了一定使用者以後，必要的品質管控一定要跟上了哈。穩定和速度的平衡
@大連-Rookie-web前端 ：一個團隊不僅要有持續傳遞能力還得有好的代碼習慣和規範啊！最近在重構整理一個項目代碼，以前疊代的備援太多啦，代碼規範更差，前期傳遞能力很快，到了後期，服務越來越複雜，問題顯現出來了。整個服務擴充性變差，往往一個bug修複，會引起新的問題。但是重構和整理，比他媽的寫個新服務都惡心
關于單元測試
@張路：請教下單元測試作為內建的一環，除了mockito，dbunit還有沒有更加智能或者高效的元件推薦一下
@陳小偉：單元測試元件 我以為可以分為 4類: 測試架構，模拟架構，覆寫率報告，自動化用例生成。覆寫率報告 顯得比較智能的可以關注一下 mutation test，比如 pitest。Java生态裡 自動化用例生成 好用的基本上都 收費，.net 的話 vs2017自帶，生成的用例規模巨大，要用好成本也不低。
@張路：java裡面自動化用例生成有推薦的嗎？之前知道有個EvoSuite，但沒看到好用的idea插件
@陳小偉：AgitarOne EvoSuite。我也隻是試用了一下。
覺得對于我們産品，內建在開發過程中成本并不低，效率提升幫助不大，就沒有推了。單元測試，其實 寫好的用例，比用進階的架構更重要。
推薦Roy Osherove 的《單元測試的藝術》
關于雲效：
1、阿裡雲效哪裡下載下傳：
答：雲效官網：
https://www.aliyun.com/product/yunxiao子産品如下：
項目協作:
https://www.aliyun.com/product/yunxiao-project代碼托管:
https://promotion.aliyun.com/ntms/act/code.htmlMaven公共倉庫:
https://m.aliyun.com/markets/aliyun/ali-repo制品倉庫:
https://m.aliyun.com/markets/aliyun/repo-manage持續傳遞:
https://www.aliyun.com/product/yunxiao-cd測試平台:
https://www.aliyun.com/product/yunxiao-testing2、雲效支援私有雲部署嗎？怎麼收費的？
答：支援。收費請參考：
https://help.aliyun.com/document_detail/92574.html?spm=a2c4g.11174283.6.673.22013c6awXqH1N3、雲效看闆有示例文檔嗎？
答：幫助文檔将會上線，敬請期待
阿裡研發效能&靈活實踐交流群
良好的群分享氛圍需要大家共同打造，有疑問或希望聽到哪些分享内容，歡迎大家在群内抛出來。
