阿里研发效能&敏捷实践交流群精华内容整理(持续更新中。。。)-阿里云开发者社区

开发者社区> 开发与运维> 正文

阿里研发效能&敏捷实践交流群精华内容整理(持续更新中。。。)

简介: 精华问答: 关于敏捷 @上海-前端-alery :敏捷开发的核心是什么呢@舍卫 :顺畅和高质量地持续交付有用的价值,从而促进业务目标的达成。 @小飞_PHP开发_深圳 :前几天看DevOps,有一句话有我觉得可以分享一下,敏捷开发是一套方法和实践,但 又不是固定的套路,能得到或者实现目标的都可以来用。

精华问答:

关于敏捷

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

@上海-前端-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.html

Maven公共仓库: 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-testing

2、云效支持私有云部署吗?怎么收费的?

答:支持。收费请参考:https://help.aliyun.com/document_detail/92574.html?spm=a2c4g.11174283.6.673.22013c6awXqH1N

3、云效看板有示例文档吗?

答:帮助文档将会上线,敬请期待

阿里研发效能&敏捷实践交流群

良好的群分享氛围需要大家共同打造,有疑问或希望听到哪些分享内容,欢迎大家在群内抛出来。
_

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享:
开发与运维
使用钉钉扫一扫加入圈子
+ 订阅

集结各类场景实战经验,助你开发运维畅行无忧

其他文章