2019-06-04我觉得两周为一个发布周期，很有可能导致代码质量低下。例如：两周一迭代里，我们可能没有时间在上个迭代里就做好下个迭代需求的分析，只能遗留到当前迭代，这个时候，需求分析、代码设计、接口设计就要花好几天，好了，由于限制死了两周要发布一次，导致测试人员死盯着发布日期，进行倒推，让开发人员尽量在某个时间点提测，不然迭代上线就风险很大，这样就导致了开发这边压力很大很大，开发时间短，代码质量低，提测后，又各种bug，也进而阻碍测试进度，整条线都非常疲惫紧张。最惨的是，由于测试人员急着测试，也未能做到详细测试，就上线了。又是各种线上bug。因此这种两周一上线，会容易让人死盯着上线日期，给全部人员带来很大的压力，相当于是给自己挖矿和约束了。很不应该的
我觉得软件工程里，开发阶段是最关键的阶段，得给到合理的时间，不然这个阶段被动了，乱了之后，就会产生一系列的不好级联反应。因此，我觉得应该有开发人员来把控节奏，给出工作量，给出哪些可以优先测试。展开作者回复: 👍好问题！你说的担忧完全合理，也确实可能会出现这样的情况。
我来解释一下为什么2-4周是可行的。我们假设你现在的项目是三个月周期，一共是12周，然后你大约2-3周在需求，2-3周架构设计，4周左右在编码，2-3周测试。
那也就是说需求分析期间，其实开发、测试做不了啥事，架构设计的时候，主要是架构师在忙，编码的时候，主要是程序员在忙，测试的时候，开发和测试在忙。
再假设你大概要完成10个功能，也就是这10个功能从设计到开发预计花了10周时间，平均每周一个功能。
如果换成2周一个迭代，那么我们可以考虑每个迭代只选取2个功能，但是在这两周，整个团队的运作可能是这样的：
迭代v1.1（2周）
- 产品设计，准备下一个迭代v1.2的产品设计
- 开发，设计和开发这个迭代v1.1的功能，同步修复发现的v1.0的Bug
- 测试，测试上一个迭代v1.0开发好的功能
- 开发完成后，部署开发完成的v1.1到测试环境
- 发布测试验收完的迭代v1.0
迭代v1.2（2周）
- 产品设计，准备下一个迭代v1.3的产品设计
- 开发，设计和开发这个迭代v1.2的功能，同步修复发现的v1.1的Bug
- 测试，测试上一个迭代v1.0开发好的功能
- 开发完成后，部署开发完成的v1.2到测试环境
- 发布测试验收完的迭代v1.1
也就是你差不多还是有两周时间开发新功能，两周时间测试，但是每两周可以发布一个小版本，而且整体节奏比较平缓。
如果到时间内完不成所有功能，那么就发布完成的，没完成的放到下一个迭代，这样可以保证每周都可以发布。
配合代码审查和自动化测试以及基于分支开发的流程，可以保证合并后代码质量相对是可靠的。
如果这样操作有难度的，那么采用4周一个迭代，但是每个迭代功能减少，还是一样可行的。还有每个迭代结束后的上线发布，可以有两种类型，小迭代可以不发布生产环境，只是测试环境，几个小迭代后再发布生产环境。
也就是说，方法其实是有的，观念上可以先调整，因为这样的迭代周期肯定是可行的。 5
2019-06-05请教宝玉老师，研发过程文档，是否有必要进行统一模版，比如方案设计文档、功能测试报告等。
我们公司的现状，整个研发部门1000人左右，如果不设置模版，大家五花八门，别人不好检查；如果设置模版，研发人员又说限制他们的想象力等。作者回复: 我倒是觉得有模板的文档好写一点，填空就好了。
对于文档模板，我没有什么建议，毕竟每个公司情况不一样。
我经历过的公司没有强制规定要模板的，但会提供两种模板，一种是风格样式的，字体颜色什么的都采用公司品牌的风格；一种是基于内容的模板，把大标题小标题都列出来，写的时候填内容就好了。
文档审查重点是检查内容，而不是格式。 3
2019-06-07像小团队比较乱的话，最好是规范哪些关键的地方？
像我们小团队开发，首先看这个功能也没开发过，如果是开发过，就直接基于以前开发过的代码直接改了。
然后就导致运维有问题，有些路径没有替换完，
手工输入命令可以运行，用shell脚本监控，发现程序异常，就重启。
结果就报错了，用脚本死活启动不起来。然后一发现没有路径及文件，叫开发改，要一拖再拖，都不愿意改。老是说赶其他项目😂😂作者回复: 流程规范的建立是一个逐步的过程，发现单个的问题，首先解决问题，解决完后就需要思考一下：是不是可以通过流程规范规避类似问题。
就拿你这个例子来说，可以先把CI持续集成环境搭起来，然后在发现这个问题后，就针对这个路径的问题，提一个Ticket，要求补上这部分的自动化测试代码。这样以后每次提交代码，CI都会自动运行这个测试，出问题了就能及时发现，不至于到了生产环境再发现。
开发人员任务多可以理解，但是你需要把这些任务通过任务跟踪系统统一管理起来，写一个Ticket给他，排上优先级。等其他任务忙完，就该把这个任务给做了。
所以小团队乱，任务跟踪管理、开发规范，这都是需要优先建立的流程规范。 2- 2019-06-07宝哥，像我们之前公司，小团队一个项目就2-3个开发，2-3个项目共用美工、有时甚至前端，公司就一个运维…
有时候为了赶项目进度，有的开发，只是在很关键的，一般做了个简单的注解。
两三年基本，原来开发的项目人都走完了。
如果出现问题，人家都不知道怎么改。
是不是docker化比较好，但是如果有些客户要更改需求，那是不是没得玩了？作者回复: 这种情况跟Docker应该没关系。
这种情况应该从几个方面着手：
1. 首先还是代码要规范，日常通过lint工具和代码审查强制代码实现的时候必须满足代码规范
2. 要有必要的文档，例如设计的文档、架构的文档，可以建一个Wiki，日常有问题就记录在上面，尤其是一些操作手册什么的。 2 - 2019-06-05就“选择适合你的软件开发模型”，这一点，我谈谈想法。软件开发模型是瀑布还是敏捷对于软件开发管理来说有很大的不同；但即使采用瀑布模型，对于团队管理来说，我们是可以借鉴敏捷模型的。比如，我们可以采用看板管理来提高任务管理的效率和透明度，可以通过站会来加快问题的沟通，对于“建立外部提交需求和任务的流程”我们也可以借助敏捷管理的思路，通过每天站会或者周例会的时候，一起做个新需求评估。对于技术交流，也可以像敏捷团队里说的培养T型技能的人员为目的来开展。而且，先通过团队管理方式的转变，培养大家的敏捷文化，然后再切到敏捷开发模式，就会更加顺畅。我觉得，小团队管理，一定要培养自主自治合作分享的文化和能力，通过用轮值scrum master 的办法，一点点提高这方面的文化和能力。
作者回复: 赞同，敏捷开发很多实践可以借鉴。另外团队成员的自主自治合作分享的文化和能力也很重要👍
感谢分享 2 
2019-06-04一直在小团队，最多的时候也就20几个人，然后分成2-3组开发
碰到最多的问题：
1. 公司或产品目标不明确，团队凝聚力不强
2. 需求管理混乱，很多都是拍脑袋的需求，没有可行性分析
3. 老师文中也提到的人才专业度欠佳，招牛人难，如果像我们二三线城市的那就更困难了
另外问宝玉老师一个问题，在之前团队管理上的疑惑点，这篇文章中提到的团队内部分享，又让我想起来了，如下：
小团队可能就10来个人，每个岗位可能就1-2个人，这种情况下做内部分享，希望大家都来参与，那么分享内容不好把控，如果太局限于本岗位知识，其它岗位参与度不高效果也不明显，浪费时间，如果只是本岗位的知识分享，那么就2，3个人讨论下就行了，很是纠结，有什么好办法解决这个问题？谢谢展开作者回复: 可以设定一些学习的课题分享，比如说最近有什么新技术很火，但是大家都不知道是什么，也很想了解，可以让一个人去学习研究，然后跟大家一起分享，分享的过程其实以讨论为主，分享的人也不需要太多压力，自己也能学到东西，其他听的人在讨论的过程中也能学到东西，共同学习提高。你可以从中做好主持的作用，最好提前也学习准备一些。
2
2019-08-31我们公司两个开发，三个老板。项目涉及8种语言（不包含js）。现在基本上是老板提需求我估算个时间直接做，天天催进度，没时间搭建一套自动化的流程；项目上线直接替换指定代码重启就算部署完成；以前别人开发的项目不支持集群，只能大半夜没人的时候发布，重构的成本太高，只能维持现状。看完软件工程感觉不能被这样的公司束缚，我是一个很喜欢自动化的人，包括我自己开发一些代码生成工具，让我更高效的完成任务。作者回复: 你说的这种情况其实很普遍，要单独抽时间出来确实不容易，只能是日积月累，一点点改进，一方面要保证现有业务运行，一方面逐步增加自动化比例。
比如说新项目、新需求、修复Bug，都可以针对性的增加一些自动化测试代码，不用贪多求全，一点点来。
项目间隙或者其他时间，写一些自动化脚本替代一些重复的体力劳动。
另外尽可能使用现成的甚至收费的服务，通过简单的配置就可以帮助你实现自动化构建、部署等工作。
总的来说这些自动化工作都是磨刀不误砍柴工，长远看收益很大。 1
2019-11-27小公司赚到钱可能是首当其冲的，但需求方总在变需求，又不多给钱，阻碍了其他项目的接单，对于这个问题如何处理。作者回复: 如果说软件工程上那些控制需求的办法都用了还是没用，那还是得考虑其他方式了，比如寻求法律帮助，签订变更的合同，比如从人情关系想办法办法，找找关系什么的