07 | 大厂都在用哪些敏捷方法？（下）
该思维导图由 AI 生成，仅供参考
一个应用敏捷开发的小组日常
荧光笔
直线
曲线- 深入了解
- 翻译
- 解释
- 总结
本文介绍了一个小组在敏捷开发框架下的日常工作。该小组基于Scrum方法进行过程管理，采用极限编程做工程实践，以及看板可视化。团队每周一个Sprint的工作节奏下，通过Ticket来分配任务，每周一部署生产环境，每周二开迭代回顾会议，每周四进行迭代规划会，每周五进行分支切割。团队成员通过集体表决的方式决策，避免独裁式决策。他们还采用估算扑克的方式评估工作量，促进成员的交流和经验分享。另外，他们实行每周轮值的方式，让每个人都有机会去体验团队中的各种工作，增加集体荣誉感和责任感。这些敏捷方法的应用，有助于团队高效协作，提高工作质量和效率。文章还解答了一些关于敏捷开发的常见问题，如加班情况、质量保障、计划制定和沟通协作等。作者强调敏捷开发的核心在于遵循敏捷的价值观和原则，而不是固守某种具体的方法。文章鼓励读者对比自身项目开发模式，借鉴优点并思考改进之处。
《软件工程之美》，新⼈⾸单¥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，但是可能会有不少代码冲突 各有优缺点，具体怎么做还是看项目组的决策。
2019-03-09314
探索无止境这真是极客专栏的典范，有问必答，购买专栏的目的更多是为了跟大师有交流的机会，而有些专栏仅仅只是发布了文章或视频。说回我的问题，老师在文中说到的主分支切割"测试验收通过后，预部署分支的代码会部署到生产环境。"，我的理解是部署的分支的代码，上线测试没问题之后，再把这个代码合并回主分支，不知道这样理解对不对？作者回复: 谢谢支持！ 这里有两种策略： 1. 每次线上bug，修复后只合并到预部署分支，最后统一把预部署分支合并会主分支。优点是简单，缺点是合并时可能会有很多冲突； 2. 每次线上Bug，修复后同时合并预部署分支和主分支。优点是以后就不用再合并回去，还有可以及时同步bug修复，缺点是麻烦，每次要cherry pick。 我们项目中选的是后一种策略，因为能及时同步Bug修复到主干对我们很重要。
2019-05-0611
舒偌一看了上下两篇文章，自己当前紧急的问题是成员的责任心和能力问题，就是怎样培养团队成员？老师有没有好办法作者回复: 这个呀，有一些建议参考： 1. 招人和开人都很重要，招优秀的，开掉没有责任心，没能力的。这两点都不容易做到，不过得坚持做； 2. 设置合理的流程，配合一定的奖惩制度；你奖励什么，团队就会往哪方面发展； 3. 团队要有梯队，不能都是资历浅的也不能都是资深的，保持一个合适的比例是比较健康的； 4. 实战中锻炼，实战中磨合；给他们有挑战的任务，给予合适的指导（这就是有梯队的原因，需要高一级别的待低一级别的） 仅供参考
2019-03-0910
十斗簸箕请问老师对于C++开发有什么好用的单元测试、继承测试框架推荐？作者回复: 这个问题我真帮不上你，因为我C++不懂，你得自己去网上问问别人。 帮你发了条微博问问，希望有用：https://weibo.com/1727858283/Hko9VyVbI 更新：微博上大家都推荐gtest，应该不错。
2019-03-118- Felix读了老师这篇文章，给我最大的启发就是扑克估算；我之前的做法是让具体开发自己先估算，我再基于他的估算结果根据自己的认识进行微调，虽然这估算经过两个人，但这种形式还是有估算不准的情况 下周周会我就要确定新的流程；后续我会让小组内成员加上我一起针对Ticket进行估算，充分讨论后达成一致 还有一个问题问一下宝玉老师，我对于结对编程的概念不是很明晰；一个冲刺，分派给两位同学开发，他们相对来讲都很资深，分工明确，互相配合，但是分别在自己的电脑上开发……这种是否是结对编程呢
作者回复: 赞，可以先实验，看看扑克估算是不是适合，如果好的话就可以进一步固定下来。 你说的那种不算结对编程。 结对编程（英语：Pair programming）是一种敏捷软件开发的方法，两个程序员在一个计算机上共同工作。 一个人输入代码，而另一个人审查他输入的每一行代码。 输入代码的人称作驾驶员，审查代码的人称作观察员（或导航员）。 两个程序员经常互换角色。
2019-03-098 
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的另一个任务就要延期了！
2020-03-257
一路向北这篇学习完后，对敏捷的实际操作有了更深的理解。 对于小公司小团队的项目，因为项目经理，产品经理都是身兼数职，是否有更好的实施方式呢？ 目前认为的难处：1. 作为项目成员的程序员可能还需要去做项目经理或者产品经理的工作，2. 项目交织在一起，有新的项目在做，也有原先项目的维护工作或者新的需求。这样的情况在实施敏捷开发的时候应该如何最大化的发挥敏捷的优势？作者回复: 项目经理、产品经理兼多个项目是正常的，也没大问题。 但是让程序员同时兼做开发和项目经理工作就很不好，因为项目经理需要更多全局掌控，而一旦要花精力在开发上，很难跳出具体的开发工作，会极大影响项目管理工作；项目管理工作也会频繁打断开发，造成进度延迟。 所以我建议应该有专职的项目经理，不应该让程序员兼职项目管理。 新旧项目交织并不是问题，可以放在一个项目一个Sprint里面一起管理，也就是同一个Sprint里面有维护的Ticket，也有新需求的Ticket，只要保证开发人员同一时间只是做一件事，而不要几件事并行，就可以最大化发挥敏捷优势。
2019-03-116
alan老师好！关于人工测试，我想向您请教一个困惑。 我所在的团队正在尝试敏捷开发，遇到的问题是“人工测试”不知该摆在什么位置。 我们当前在Jira上设置的工作流是这样：todo→进行中→已完成→测试中→已测试。这种工作流是可行的吗？还是说把当前sprint的测试工作，都放到下个sprint会比较好？ 由于我们有专职测试的同事，但是很多issue是测试同事很难进行测试的，导致工作流走不顺畅。 但如果不设置“测试中”这列，又觉得质量没有足够的保障（我们的自动化测试还很不完善）。 谢谢老师！不知您后续是否会就敏捷开发中测试的话题单独讲述。作者回复: 我觉得当前Sprint的测试，还是应该和当前Sprint一起走比较好，因为这个Sprint的内容是不是上线，还是要看测试是不是已经通过。另外两个Sprint或多个Sprint是可以同时存在的。 针对文章中的流程，以下工作流可以参考： ToDo->开发中->代码审查中->合并master->部署测试环境->测试通过->已部署 设置“测试中”取决于测试人员是不是很多，任务可能有冲突，要不要知道测试人员当前正在干嘛，不需要的话其实不需要，只需要知道测试结果就好了：测试通过移动到“测试通过”栏，测试没通过，回到“To Do”栏。 有些测试只有开发能测试的，这种应该在Ticket中标明，例如在标题上加上“[开发]”标签，然后由组内其他开发人员辅助测试，或者根本不需要测试。 自动化测试要放作为日常开发任务的一部分，比如一个任务，你可以创建两条Ticket，一条是开发的ticket，一条是自动化测试代码的Ticket，分别进行打分。 后面还会有测试章节。
2019-03-0926
J.M.Liu关于Ticket工期估算那里有个疑问。团队中一般都是一两个人负责一个小模块，之所以这样做是为了提高工作效率，避免同一段代码每次迭代都由不同的人去修改，因为大家对自己的小模块很熟悉，所以工作效率很高。但这样带来的问题是，团队成员对其他人负责的模块不熟，所以工期估算只能由模块负责人自己完成，别人很难帮上忙。这种情况怎么解决啊作者回复: 这是个好问题。 我的建议是模块要换着做，宁可慢一点，不然的话不仅仅是其他人不能帮忙不能估算，万一有人离开团队了，麻烦更多的。 如果团队不大，甚至于做的时候，分工都不要太细，都不要太局限前端后端，这样其实对整个团队来讲是最好的，互相能替换。 当然，也不要着急，慢慢来，不要一下子改变很大。
2019-03-214
哈拿老师，你不是说当前的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里。 希望我这么补充说明能说清楚，而不是更混乱了。 如果不清楚请继续留言。
2019-03-124
