软件工程之美
宝玉
Groupon 资深工程师,微软最有价值专家
43658 人已学习
新⼈⾸单¥59
登录后,你可以任选4讲全文学习
课程目录
已完结/共 55 讲
软件工程之美
15
15
1.0x
00:00/00:00
登录|注册

07 | 大厂都在用哪些敏捷方法?(下)

你好,我是宝玉,我今天继续与你分享大厂的敏捷方法应用。
在上一篇文章中,我们一起看了一下大厂和敏捷相关的一些流程规范,同时也为你留了一道思考题:
如果每周一个 Sprint,怎么保证每周都有交付,还能保证产品质量?
所以在这一篇中,我们就以每周一个 Sprint 的小项目组为例,看看它的日常是怎么应用敏捷开发的。

一个应用敏捷开发的小组日常

这个小组是做网站开发的,基于微服务负责网站的某一个小模块。标准配置 7 人左右,4 个程序员(至少有一个资深程序员,有架构能力),1 个产品经理(Scrum 里面叫 Product Owner),1 个测试,1 个项目经理(Scrum 里面叫 Scrum Master)。主要负责网站某模块的日常维护。
在分工上:
产品经理:写需求设计文档,将需求整理成 Ticket,随时和项目成员沟通确认需求;
开发人员:每天从看板上按照优先级从高到低领取 Ticket,完成日常开发任务;
测试人员:测试已经部署到测试环境的程序,如果发现 Bug,提交 Ticket;
项目经理:保障日常工作流程正常执行,让团队成员可以专注工作,提供必要的帮助,解决问题。
在敏捷开发框架下,已经形成了一些很好的敏捷实践,这个小组也是基于 Scrum 方法做过程管理,基于极限编程做工程实践,看板可视化。每周一个 Sprint。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结
仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《软件工程之美》
新⼈⾸单¥59
立即购买
登录 后留言

全部留言(52)

  • 最新
  • 精选
  • williamcai
    有个疑问v1.1 v1.2 开发分支是不是从master同一个版本拉下来的吗,因为到1.2的时候,v1.1处于待测,不可能合到了master

    作者回复: 好问题,这个通常有两种方案: 方案一:v1.1可以不合并回master,如果有bug修复,现在v1.1上修复,然后把修复的代码同时cherry-pick到master,就是要提交两个PR,内容一样。 方案二:v1.1在部署后合并到master,这样就可以把v1.1上的修改合并到master,但是可能会有不少代码冲突 各有优缺点,具体怎么做还是看项目组的决策。

    3
    14
  • 探索无止境
    这真是极客专栏的典范,有问必答,购买专栏的目的更多是为了跟大师有交流的机会,而有些专栏仅仅只是发布了文章或视频。说回我的问题,老师在文中说到的主分支切割"测试验收通过后,预部署分支的代码会部署到生产环境。",我的理解是部署的分支的代码,上线测试没问题之后,再把这个代码合并回主分支,不知道这样理解对不对?

    作者回复: 谢谢支持! 这里有两种策略: 1. 每次线上bug,修复后只合并到预部署分支,最后统一把预部署分支合并会主分支。优点是简单,缺点是合并时可能会有很多冲突; 2. 每次线上Bug,修复后同时合并预部署分支和主分支。优点是以后就不用再合并回去,还有可以及时同步bug修复,缺点是麻烦,每次要cherry pick。 我们项目中选的是后一种策略,因为能及时同步Bug修复到主干对我们很重要。

    11
  • 舒偌一
    看了上下两篇文章,自己当前紧急的问题是成员的责任心和能力问题,就是怎样培养团队成员?老师有没有好办法

    作者回复: 这个呀,有一些建议参考: 1. 招人和开人都很重要,招优秀的,开掉没有责任心,没能力的。这两点都不容易做到,不过得坚持做; 2. 设置合理的流程,配合一定的奖惩制度;你奖励什么,团队就会往哪方面发展; 3. 团队要有梯队,不能都是资历浅的也不能都是资深的,保持一个合适的比例是比较健康的; 4. 实战中锻炼,实战中磨合;给他们有挑战的任务,给予合适的指导(这就是有梯队的原因,需要高一级别的待低一级别的) 仅供参考

    10
  • 十斗簸箕
    请问老师对于C++开发有什么好用的单元测试、继承测试框架推荐?

    作者回复: 这个问题我真帮不上你,因为我C++不懂,你得自己去网上问问别人。 帮你发了条微博问问,希望有用:https://weibo.com/1727858283/Hko9VyVbI 更新:微博上大家都推荐gtest,应该不错。

    8
  • Felix
    读了老师这篇文章,给我最大的启发就是扑克估算;我之前的做法是让具体开发自己先估算,我再基于他的估算结果根据自己的认识进行微调,虽然这估算经过两个人,但这种形式还是有估算不准的情况 下周周会我就要确定新的流程;后续我会让小组内成员加上我一起针对Ticket进行估算,充分讨论后达成一致 还有一个问题问一下宝玉老师,我对于结对编程的概念不是很明晰;一个冲刺,分派给两位同学开发,他们相对来讲都很资深,分工明确,互相配合,但是分别在自己的电脑上开发……这种是否是结对编程呢

    作者回复: 赞,可以先实验,看看扑克估算是不是适合,如果好的话就可以进一步固定下来。 你说的那种不算结对编程。 结对编程(英语:Pair programming)是一种敏捷软件开发的方法,两个程序员在一个计算机上共同工作。 一个人输入代码,而另一个人审查他输入的每一行代码。 输入代码的人称作驾驶员,审查代码的人称作观察员(或导航员)。 两个程序员经常互换角色。

    8
  • stg609
    绝对是模范老师,有问必答。 我也有个疑问想请教老师,如果在一个 sprint 过程中,客户(老板)提了2种新需求(第一种,属于新增的需求,但是客户希望立刻实现。第二种,是对老需求的修改,有可能是完全颠覆了sprint计划会议中所定义的需求),此时作为 SM 该如何进行控制? 如果sprint过程中经常出现这种情况,怎么办?

    作者回复: 在敏捷开发的Sprint中,有几个基本原则要把握好: 1. 一个Sprint的时间周期是固定的。 比如说2周一个Sprint,那么到2周后,就必须要发布新的版本。 很多人把敏捷生生搞成了瀑布,一个主要原因就是无法做到固定时间发布版本,总是在延期。 守住固定时间发布这条线,你才能真正敏捷起来,很多问题才能真正解决。 2. 一个Sprint开始后,不接受需求变更,有需求变更,放到下一个Sprint。 为什么瀑布模型让人诟病良多呢?一个重要原因就是瀑布模型周期太长,在这么长的周期中,很难做到需求不变化,也很难响应需求的变化。 敏捷开发通过迭代的方式,把大的开发周期变成一个个的Sprint,让开发周期大幅缩短,这样就可以及时响应需求的变化,但这不意味着可以随时对需求变化,每个Sprint开始之前要对这个Sprint做的事情有计划,确定好一个Sprint的任务后,这个Sprint内不要接受新的需求和需求的变更,有需求变更统一放到后续Sprint。 3. 如果不得不在当前Sprint做需求变更,那么需要重新调整整个Sprint的计划。 原则上Sprint开始后,不接受需求变更,但总有例外情况,比如临时的紧急事件。在当前Sprint有变化时,比如说增加了新的需求,那么相应的就要移掉优先级不那么高的任务,而不是一味添加新任务。根本目的还是回到原则1,保证版本能按时发布。 并且这样的变更不宜多,否则就失去了Sprint的意义,失去了前面两个原则的意义。 所以再回到之前的问题: 有新需求?可以,但是要等到下个Sprint加进去,同时会导致其他优先级不那么高的任务延期。 有需求变更?可以,我们下个Sprint会正式把这个变更加进去。 想要加到这个Sprint?对不起,我们马上就要发布新版本了,已经来不及了! 非加不可?可以,但是这个Sprint的另一个任务就要延期了!

    7
  • 一路向北
    这篇学习完后,对敏捷的实际操作有了更深的理解。 对于小公司小团队的项目,因为项目经理,产品经理都是身兼数职,是否有更好的实施方式呢? 目前认为的难处:1. 作为项目成员的程序员可能还需要去做项目经理或者产品经理的工作,2. 项目交织在一起,有新的项目在做,也有原先项目的维护工作或者新的需求。这样的情况在实施敏捷开发的时候应该如何最大化的发挥敏捷的优势?

    作者回复: 项目经理、产品经理兼多个项目是正常的,也没大问题。 但是让程序员同时兼做开发和项目经理工作就很不好,因为项目经理需要更多全局掌控,而一旦要花精力在开发上,很难跳出具体的开发工作,会极大影响项目管理工作;项目管理工作也会频繁打断开发,造成进度延迟。 所以我建议应该有专职的项目经理,不应该让程序员兼职项目管理。 新旧项目交织并不是问题,可以放在一个项目一个Sprint里面一起管理,也就是同一个Sprint里面有维护的Ticket,也有新需求的Ticket,只要保证开发人员同一时间只是做一件事,而不要几件事并行,就可以最大化发挥敏捷优势。

    6
  • alan
    老师好!关于人工测试,我想向您请教一个困惑。 我所在的团队正在尝试敏捷开发,遇到的问题是“人工测试”不知该摆在什么位置。 我们当前在Jira上设置的工作流是这样:todo→进行中→已完成→测试中→已测试。这种工作流是可行的吗?还是说把当前sprint的测试工作,都放到下个sprint会比较好? 由于我们有专职测试的同事,但是很多issue是测试同事很难进行测试的,导致工作流走不顺畅。 但如果不设置“测试中”这列,又觉得质量没有足够的保障(我们的自动化测试还很不完善)。 谢谢老师!不知您后续是否会就敏捷开发中测试的话题单独讲述。

    作者回复: 我觉得当前Sprint的测试,还是应该和当前Sprint一起走比较好,因为这个Sprint的内容是不是上线,还是要看测试是不是已经通过。另外两个Sprint或多个Sprint是可以同时存在的。 针对文章中的流程,以下工作流可以参考: ToDo->开发中->代码审查中->合并master->部署测试环境->测试通过->已部署 设置“测试中”取决于测试人员是不是很多,任务可能有冲突,要不要知道测试人员当前正在干嘛,不需要的话其实不需要,只需要知道测试结果就好了:测试通过移动到“测试通过”栏,测试没通过,回到“To Do”栏。 有些测试只有开发能测试的,这种应该在Ticket中标明,例如在标题上加上“[开发]”标签,然后由组内其他开发人员辅助测试,或者根本不需要测试。 自动化测试要放作为日常开发任务的一部分,比如一个任务,你可以创建两条Ticket,一条是开发的ticket,一条是自动化测试代码的Ticket,分别进行打分。 后面还会有测试章节。

    2
    6
  • J.M.Liu
    关于Ticket工期估算那里有个疑问。团队中一般都是一两个人负责一个小模块,之所以这样做是为了提高工作效率,避免同一段代码每次迭代都由不同的人去修改,因为大家对自己的小模块很熟悉,所以工作效率很高。但这样带来的问题是,团队成员对其他人负责的模块不熟,所以工期估算只能由模块负责人自己完成,别人很难帮上忙。这种情况怎么解决啊

    作者回复: 这是个好问题。 我的建议是模块要换着做,宁可慢一点,不然的话不仅仅是其他人不能帮忙不能估算,万一有人离开团队了,麻烦更多的。 如果团队不大,甚至于做的时候,分工都不要太细,都不要太局限前端后端,这样其实对整个团队来讲是最好的,互相能替换。 当然,也不要着急,慢慢来,不要一下子改变很大。

    4
  • 哈拿
    老师,你不是说当前的sprint可以放到下一个进行测试吗?为什么在回答alan的问题时又建议他放到当前的sprint里呢?

    作者回复: 抱歉这是我没表达清楚。 我把时间上的Sprint和看板的Sprint混在一起说了。 我们以文中的Sprint1.1为例,Sprint1.1在第一周,某个功能(例如:Ticket-123)属于Sprint 1.1。 然后到了第二周,Sprint1.2开始开发了,这时候,Sprint1.1开始测试了。发现了Ticket-123的Bug,测试提了一个Bug(例如:Ticket-234),这个Bug的Ticket属于Sprint 1.1,而不是Sprint 1.2。 像Jira这种软件,可以多个Sprint共存,也就是你看Sprint 1.1,可以看到Sprint 1.1的所有的Ticket状态;切换到Sprint 1.2,可以看到Sprint 1.1的所有的Ticket状态。 这就是为什么我建议alan把Bug放到当前的sprint里。 希望我这么补充说明能说清楚,而不是更混乱了。 如果不清楚请继续留言。

    4
收起评论
显示
设置
留言
52
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部