阿里研发效能&敏捷实践交流群精华内容整理（持续更新中。。。）-CSDN博客

精华文章：

日站会——你的站会姿势正确吗？
如何使用云效看板，让需求持续快速地流动和交付
 何勉：从持续交付到业务创新（上）：互联网时代研发效能的核心
 何勉：《从持续交付到业务创新》（下）：有效的业务创新
 如何打造7*24h持续交付通道？阿里高级技术专家的5点思考
 如何在团队建设工程师文化？阿里资深技术专家这么做
 DevOps越来越流行，2019年这八大趋势值得关注
 企业研发效能月刊：告别996，走向“211”！

精华问答：

关于敏捷

@金涛：多个项目并行，并且有交付时间点压力是不是不适合敏捷看板方式？
@何勉：有点困难，我们需要的是更多的关注产品。阿里云的对外交付项目面临同样的压力，我们现在的做法是更多的关注产品，从不同的项目中抽象出场景，用老大的话是：“勤于规划，勤于抽象场景”。用产品的规划来满足多个项目

@上海-前端-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 的《单元测试的艺术》