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