06 | 大厂都在用哪些敏捷方法？（上）
该思维导图由 AI 生成，仅供参考
荧光笔
直线
曲线- 深入了解
- 翻译
- 解释
- 总结
大厂采用敏捷方法和自动化流程优化提高了工作效率和协作效果。敏捷开发中的每日站立会议是非常重要的环节，通过高效沟通反馈和检查最新的Ticket来保障敏捷实施。敏捷开发中的流程规范，如自动化测试、项目管理软件、每日站会和代码审查，都是为了保障敏捷的实施。读者可以通过观察工作中的流程规范和结合敏捷开发的知识点来更好地理解敏捷开发。如果项目中采用敏捷开发，可以思考哪些做得好、不够好以及疑惑的地方，并分享讨论。另外，对于一个每周一个Sprint的敏捷项目，如何保证每周都有交付并保证产品质量也是一个需要思考的问题。
《软件工程之美》，新⼈⾸单¥59
全部留言(36)
- 最新
- 精选
纯洁的憎恶分治策略是应对庞大复杂系统的惯用思路，但它的难点或精髓在于如何确保形散神聚。 详细计划（甘特图）VS任务状态（Ticket） 代码不稳定&环境部署麻烦 VS 代码审查&自动测试&自动部署（GIT、CI、DevOps） 上传下达VS频繁沟通、提醒、分享 大厂的敏捷开发实践，把枯燥的编码变得跟玩游戏一样。借助有效的流程与工具，能够有效节约团队成员的精力，聚焦于任务或角色，不会因频繁“统一思想”导致“技术动作变形”。而另一面，在大厂里每个人通常都是螺丝钉，长此以往也许会养成不谋全局的习惯。如果能从自己的角色中跳出来，俯瞰整个组织协作的全过程，并站在这个视角上思考问题，一定会有更喜人的收获。作者回复: 感谢你帮我把螺丝钉这段写出来了，我有想写这么一段类似的，后来觉得篇幅太长另外和软工关系不那么大就没扯淡了😄 大厂优势就是资源多，项目大，如果如你所说，能跳出所在岗位，站在全局多观察多思考，能学到很多东西👍 如果只局限于自己岗位做一个螺丝钉，只会大厂的一套很窄领域的技能，时间一长很可怕，将来出去后难以找到合适的工作！
2019-03-0741
J.M.Liu老师，敏捷开发这么强调扁平化，这么重视人，这么强调开放而弱化约束，那和最初没有软件工程时期的开发主要区别是啥呀😂作者回复: 好问题，你难倒我了😂 前面介绍过，没有软件工程的时候呢，开发就是边写边改模式，没有需求分析，没有架构设计，没有测试，导致很多问题。 敏捷开发的话，需求分析还有，只是简化了，架构设计也有，只是说仅仅做当前Sprint的架构，测试也没省，只是很多自动化测试辅助，所以让测试人员从繁重的体力劳动中解放出来很多。
2019-03-07418- Felix“一切以Jia为准”一直我长挂在嘴边的一句话，以此也教育了用户(开发、产品、测试)养成习惯，之后大家也乐于通过Jira来沟通、对齐信息
作者回复: 👍是的，一切以Ticket为准！不用担心问题被遗忘，会被跟踪，直到被解决或决定不解决！
2019-03-0712 
Charles创业公司，目前只做到了 1. 所有需求、bug、任务等都放issue里 2. 项目经理发起，大家讨论，结合市场或阶段性目标整理这个版本包含哪些issue，评估时间，再进入开发阶段 2. git管理代码，有master、develop以及bug或特性分支 3.master对应生产环境、develop对应测试环境，修复bug或特性，本地自测完配合一点点的单元测试，推送到develop自动部署到测试服务器，测试开始测试，测试通过再把对应的bug或特性分支合并到master自动部署生产环境 看了老师的专栏，感觉可以超几个方向努力更敏捷 1. 提高单元测试覆盖率，尝试自动化测试，目前人工测试效率低，压力大 2.测试环境和生产环境容器化，目前各种特性并行开发测试环境容易冲突 3.master分支尝试pr的方式，互相阅读代码学习还能发现一些单个人考虑不全测试又测不到的潜在隐患 就是这些做完不知道是否又会引入新问题，感谢老师专栏，学到很多作者回复: 你说的这几个方向都很好的。第二个要慎重一点，如果没有特别懂的人不要着急马上去做，会有不少坑要填。一三可以尝试做起来。 自动化测试的话，最重要一点，就是要让开发同时写一些自动化测试，传统测试人员短期内恐怕难一下子写出来高质量自动化测试代码。还有就是要项目管理上要支持，例如说写测试的时间要放到计划里面，必须要留出来写测试的时间，不能不给又想马儿跑得快不让马儿吃草。 PR是个很好的代码审查以及结合CI看测试状态的方式。但是需要花点时间去搭平台。如果创业公司，没有必要自己去基于Jenkins这种搭建，去买成熟的第三方服务就足够了。 最后一点，要改变，不要着急一蹴而就，一点点去试点，然后再推广，不建议贸然改变太多。
2019-03-0729
KK_TTN如何培养自己维护ticket的习惯呢？感觉写代码是一件愉快的事情，倒是经常会忘记(或者内心去回避)更新ticket的状态作者回复: 这倒是小事了，可以养成习惯，每天下班前检查一下，一次性更新。 我有写过一个小脚本，在CI里面运行，PR merge或者部署测试环境都自动更新，PR里面标题加上Ticket编号就可以。又酷又省心✌️
2019-03-077
敏捷教练夏勇杰之前也在团队里实施过Code Review的机制，但是，大家对于Review别人的代码都不是很积极，最后就变成了Team Leader一个Review所有人的代码，Team Leader没有时间做这个事情的时候，大家就敷衍了事，直接通过，让Code Review流于形式。对于这种情况，宝玉老师遇到过么，是如何解决的？作者回复: 我有写过一篇《Code Review最佳实践》发在了博客园： https://www.cnblogs.com/dotey/p/11216430.html 供参考
2019-08-215
卡皮敏捷开发中有什么好用的工具推荐呢？作者回复: 具体看哪一类的工具，比如CI的话你可以看看开源的Jenkins（https://zhuanlan.zhihu.com/p/54050436），比如项目管理工具你可以看看Jira或者类似的，自动化测试具体要看你的语言，源代码管理GitHub
2019-03-144
javaadu思考题：一周一个sprint ，要保证每周交付的话，一要看ticket 的粒度（任务拆分）是否合理，二要提前一周做计划，三要每周结束做总结。作者回复: 任务拆分力度可以解决好分工协作问题；敏捷里面每个Sprint开会前会有迭代计划会，团队成员一起安排计划下一个Sprint的ticket；Sprint结束还有迭代回顾会做总结。 交付的问题解决了，质量上再思考思考？
2019-03-074- alva_xu在一个以Scrum 为方法的敏捷团队里， 首先，Scrum master是呵护develop team的保护神，他的其中一个职责是保护每一次迭代的工作量是dev team能按时完成的，而且保护dev team 能专注于现有sprint back log的实现，不会被其他干系人的新需求所打断。 其次,Dev team是一个T型团队，技术比较全面，许多事情多能自助搞定，比如，开发人员同时又有测试技能，同时如果结合结对开发，测试驱动开发，那么，交付物的质量就更有保障。 再者，在一个敏捷团队里，人数比较少，dev team的沟通能力都比较强，沟通可以比较充分，所以解决问题的能力就比较强，工作效率比较高 最后，敏捷模式的开展，也依赖于工具的使用，目前常用的CICD工具，与jira/confluence 需求沟通管理工具的打通，部署次数的提高，无疑大大提高了开发发布效率，同时也提高了发布质量。 综上所述，只要在人员组织架构、工具产品、流程这三个方面都达到了敏捷的要求，那么发布质量就有了保证。
作者回复: 对敏捷了解已经很熟悉很深入了👍 你还可以继续考虑考虑还有没有其他手段可以加强质量的？尤其是可以从瀑布模型那边学习借鉴一些。
2019-03-074 
小老鼠1、小厂如何使用敏捷？好些小厂朋友抱怨敏捷玩不起来或不好用。 2、像嵌入式软件等非BS架构产品可使用容器+微服务吗？ 3、以前我测试过一款网络管理产品，走的是SNMP协议，但由于各个客户所用产品的厂商不同，比如A用户用华三交换机、B用户用华为交换机、C用户用华中兴交换机、D用户用阿朗交换机⋯，各厂商交换机除了支持标准SNMP协议外，还支持自定义协议，所以该产品测试非常难。现在在DevOps 下可以解决吗？作者回复: 小厂使用敏捷开发，几件事需要做起来： 1. 固定迭代周期，每2-4周一个迭代，迭代结束能交付可用的产品，为了定期发布舍得砍掉功能需求 2. 增加自动化测试的比例，把源代码管理、CI（持续集成）用起来，借助开发流程、自动化测试保证基本产品质量 3. 用好任务管理系统，把所有要做的任务都跟踪起来，按照优先级都排到相应的迭代版本，在一个迭代中，有紧急任务插队加塞，相应的就应该把其他任务移出去。 嵌入式软件能不能用微服务这问题超纲了，我也不懂 DevOps也不是银弹，主要有三点你可以借鉴： 1. 高度自动化 2. 透明可量化 3. 紧密协作 你这个问题可以从上面几个角度考虑，尤其是自动化的角度考虑是不是可行。
2019-08-213
