2019-03-07分治策略是应对庞大复杂系统的惯用思路，但它的难点或精髓在于如何确保形散神聚。
详细计划（甘特图）VS任务状态（Ticket）
代码不稳定&环境部署麻烦
VS
代码审查&自动测试&自动部署（GIT、CI、DevOps）
上传下达VS频繁沟通、提醒、分享
大厂的敏捷开发实践，把枯燥的编码变得跟玩游戏一样。借助有效的流程与工具，能够有效节约团队成员的精力，聚焦于任务或角色，不会因频繁“统一思想”导致“技术动作变形”。而另一面，在大厂里每个人通常都是螺丝钉，长此以往也许会养成不谋全局的习惯。如果能从自己的角色中跳出来，俯瞰整个组织协作的全过程，并站在这个视角上思考问题，一定会有更喜人的收获。展开作者回复: 感谢你帮我把螺丝钉这段写出来了，我有想写这么一段类似的，后来觉得篇幅太长另外和软工关系不那么大就没扯淡了😄
大厂优势就是资源多，项目大，如果如你所说，能跳出所在岗位，站在全局多观察多思考，能学到很多东西👍
如果只局限于自己岗位做一个螺丝钉，只会大厂的一套很窄领域的技能，时间一长很可怕，将来出去后难以找到合适的工作！ 16- 2019-03-07“一切以Jia为准”一直我长挂在嘴边的一句话，以此也教育了用户(开发、产品、测试)养成习惯，之后大家也乐于通过Jira来沟通、对齐信息
作者回复: 👍是的，一切以Ticket为准！不用担心问题被遗忘，会被跟踪，直到被解决或决定不解决！
9 
2019-03-07老师，敏捷开发这么强调扁平化，这么重视人，这么强调开放而弱化约束，那和最初没有软件工程时期的开发主要区别是啥呀😂作者回复: 好问题，你难倒我了😂
前面介绍过，没有软件工程的时候呢，开发就是边写边改模式，没有需求分析，没有架构设计，没有测试，导致很多问题。
敏捷开发的话，需求分析还有，只是简化了，架构设计也有，只是说仅仅做当前Sprint的架构，测试也没省，只是很多自动化测试辅助，所以让测试人员从繁重的体力劳动中解放出来很多。 8
2019-03-07创业公司，目前只做到了
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这种搭建，去买成熟的第三方服务就足够了。
最后一点，要改变，不要着急一蹴而就，一点点去试点，然后再推广，不建议贸然改变太多。 6
2019-03-07如何培养自己维护ticket的习惯呢？感觉写代码是一件愉快的事情，倒是经常会忘记(或者内心去回避)更新ticket的状态作者回复: 这倒是小事了，可以养成习惯，每天下班前检查一下，一次性更新。
我有写过一个小脚本，在CI里面运行，PR merge或者部署测试环境都自动更新，PR里面标题加上Ticket编号就可以。又酷又省心✌️ 5- 2019-03-07在一个以Scrum 为方法的敏捷团队里，
首先，Scrum master是呵护develop team的保护神，他的其中一个职责是保护每一次迭代的工作量是dev team能按时完成的，而且保护dev team 能专注于现有sprint back log的实现，不会被其他干系人的新需求所打断。
其次,Dev team是一个T型团队，技术比较全面，许多事情多能自助搞定，比如，开发人员同时又有测试技能，同时如果结合结对开发，测试驱动开发，那么，交付物的质量就更有保障。
再者，在一个敏捷团队里，人数比较少，dev team的沟通能力都比较强，沟通可以比较充分，所以解决问题的能力就比较强，工作效率比较高
最后，敏捷模式的开展，也依赖于工具的使用，目前常用的CICD工具，与jira/confluence 需求沟通管理工具的打通，部署次数的提高，无疑大大提高了开发发布效率，同时也提高了发布质量。
综上所述，只要在人员组织架构、工具产品、流程这三个方面都达到了敏捷的要求，那么发布质量就有了保证。展开作者回复: 对敏捷了解已经很熟悉很深入了👍
你还可以继续考虑考虑还有没有其他手段可以加强质量的？尤其是可以从瀑布模型那边学习借鉴一些。 4 
2019-03-14敏捷开发中有什么好用的工具推荐呢？作者回复: 具体看哪一类的工具，比如CI的话你可以看看开源的Jenkins（https://zhuanlan.zhihu.com/p/54050436），比如项目管理工具你可以看看Jira或者类似的，自动化测试具体要看你的语言，源代码管理GitHub
3
2019-03-07思考题：一周一个sprint ，要保证每周交付的话，一要看ticket 的粒度（任务拆分）是否合理，二要提前一周做计划，三要每周结束做总结。作者回复: 任务拆分力度可以解决好分工协作问题；敏捷里面每个Sprint开会前会有迭代计划会，团队成员一起安排计划下一个Sprint的ticket；Sprint结束还有迭代回顾会做总结。
交付的问题解决了，质量上再思考思考？ 3
2019-08-211、小厂如何使用敏捷？好些小厂朋友抱怨敏捷玩不起来或不好用。
2、像嵌入式软件等非BS架构产品可使用容器+微服务吗？
3、以前我测试过一款网络管理产品，走的是SNMP协议，但由于各个客户所用产品的厂商不同，比如A用户用华三交换机、B用户用华为交换机、C用户用华中兴交换机、D用户用阿朗交换机⋯，各厂商交换机除了支持标准SNMP协议外，还支持自定义协议，所以该产品测试非常难。现在在DevOps 下可以解决吗？作者回复: 小厂使用敏捷开发，几件事需要做起来：
1. 固定迭代周期，每2-4周一个迭代，迭代结束能交付可用的产品，为了定期发布舍得砍掉功能需求
2. 增加自动化测试的比例，把源代码管理、CI（持续集成）用起来，借助开发流程、自动化测试保证基本产品质量
3. 用好任务管理系统，把所有要做的任务都跟踪起来，按照优先级都排到相应的迭代版本，在一个迭代中，有紧急任务插队加塞，相应的就应该把其他任务移出去。
嵌入式软件能不能用微服务这问题超纲了，我也不懂
DevOps也不是银弹，主要有三点你可以借鉴：
1. 高度自动化
2. 透明可量化
3. 紧密协作
你这个问题可以从上面几个角度考虑，尤其是自动化的角度考虑是不是可行。 2
2019-08-21之前也在团队里实施过Code Review的机制，但是，大家对于Review别人的代码都不是很积极，最后就变成了Team Leader一个Review所有人的代码，Team Leader没有时间做这个事情的时候，大家就敷衍了事，直接通过，让Code Review流于形式。对于这种情况，宝玉老师遇到过么，是如何解决的？作者回复: 我有写过一篇《Code Review最佳实践》发在了博客园：
https://www.cnblogs.com/dotey/p/11216430.html
供参考 2
2019-03-09好的地方是项目透明，对项目情况比较了解，如果成员责任心好，那就很赞。缺陷是外在事务的干扰，我们现在的做法是，有一个人在一个sprint内不参与，专门处理意外情况。希望老师给一个建议。作者回复: 你说的应该是Scrum Master的角色，你们这个是很好的方案，必然要有人去处理对外的对内的杂事，保证其他人可以专注的工作。
另外在后面一篇也介绍了一个轮值的方案，就是每周安排一个人专门去做一些杂事，大家轮流来。 2
2019-03-08我们是小厂，但是也是在尝试敏捷开发，老师提到的我们基本上也都做了，说一下做的不足的地方吧，开会解决问题容易搞成头脑风暴，然后开不出结果，然后因为是敏捷开发，老板和产品经理总是随意的对需求增删改查😂😂😂作者回复: 可以试试“问题停车场”，把问题留在后面在讨论，并且严格限制会议时间。
对于需求更改，严格做到当前Sprint不做更改，另外通过迭代计划会，一起确定下个Sprint的计划，要做的事情。 2- 2019-03-07Git方面也要求团队Master中的代码必须通过Merge Request(Pull Request)来，也作为Code Review的最后一道关卡
持续集成方面大部分通过Jenkins、几个微服务是通过Gitlab CI，我们的终极目标是基于镜像部署发布，屏蔽环境影响作者回复: 是的，基于PR结合CI和Code Review是一个非常好的控制签入代码质量的手段！
2 
2019-03-11一直跟着老师的专栏走，看着留言很激动~~我想问一下：
1. 像我运维刚刚学开发没项目经验怎办？没有地方可以上手实验呀？
2. 敏捷开的有没有好用的免费开始的管理工具，jira是收费的？作者回复: 1. 不知道你是不是已经工作并参与到实际项目中
建议先多观察身边的项目，对你学到的知识加以印证，项目经验其实更多来源于参与后的观察和思考。
举例来说，你可以结合你学到的知识，看看你们项目现在是什么开发模型，看看项目经理是如何处理项目中的问题的。
如果还没参与到实际项目，可以做点开源项目练练手。
2. 除了Jira有很多选择，例如禅道、Worktile，你搜索一下：“项目管理软件”，腾讯、阿里、华为都有自己的 1
2019-03-10宝玉哥 欢迎来到amazon，工程师负责设计开发测试DevOps一条龙，每一个人都欢迎对整个环节的每一个部分提建议。
PS： engineer的responsibility也和他的level有关。作者回复: 哈哈，你们大亚麻是大厂中的超级厂👍
厉害的，一栈到底！ 1- 2019-03-09review很重要，组内有一个持续改进的review清单，依据清单做。
作者回复: Review不仅仅是可以发现很多问题，另外如果知道自己的代码会被Review，也会写的认真一点：）
1 
2019-03-08保证每周都有交付，首先团队成员必须得充分认同敏捷开发的理念，并且有相关的知识培训，其次是项目负责人对每一个需要交付的Sprint的分解到位，团队成员之间相互沟通的路畅通，再一个是对每次的站立会议落到实处。
这节课的内容丰富，需要一段时间的消化，我也试着将敏捷的模式应用到实际的开发项目中。作者回复: 赞👍
可以在一个点一个项目先应用起来，慢慢再更多内容。另外限于篇幅，很多内容并没有介绍特别详细，可以辅助阅读一些书籍和文章，可以帮助你更好了解。 1
2019-03-08在敏捷里面，开发写自动化脚本测试，那是不是就不需要测试这个角色了啊？感觉在敏捷里面，只需要开发这一个角色就可以了啊？作者回复: 在下一篇里面还会有谈到这个问题。自动化测试是辅助的，还是离不开人工的测试。而且开发写的集成测试和测试写的自动化测试还是有一点差别，一个是用程序模拟的操作的模拟的固定数据，而测试则用的是真实的数据真实的环境。
举个例子来说，网页的自动化测试，开发只会用Chrome Headless，数据都是事先写好的模拟数据；测试的话会用主流的Chrome、Safari、Firefox、Edge分别测试（自动化或手动），数据都是测试环境的真实数据。 1
2019-03-08问题停车场真的很有必要，好多时候沟通进度阻碍的站会变成了问题讨论会。作者回复: 是的，开会要高效，就不能太发散，问题停车场是一个很好的方式改进这个问题。
1
2019-03-08宝玉老师您好，公司现在正在推行工程质量落实的战略计划，有些问题想和您私下沟通下，另外请问您是在国外吗？什么时候回国方便来我们公司给大家做个分享吗？作者回复: 抱歉我近期主要在国外，如果你要邀请专业人士去公司分享，给您推荐邹欣老师（微博 @程序员邹欣 ），他比我专业多了：）
1