如何在小团队里面实践软件工程

小团队的问题：

1）成本敏感：难以招聘到优秀的程序员，进度催的紧，工具用免费和开源的，项目并行。

2）人少活多：大家每天都很忙，但是感觉技术上积累有限，对个别技术大牛的依赖性强，他们一旦离职，影响非常大。

3）缺少流程规范：开发效率低下，软件产品质量不高，项目计划难以遵守甚至没有计划。

解决方式：

1.  团队建设：招人、培养人、管理人和开除人

招人：不意味着要大幅降低标准，比较现实的方式就是招聘有潜力的程序员培养，考察候选人的学习能力、解决问题能力。

可以招聘实习生，但是不能比例过高，不能一味节约成本，要注意梯队的建设，中间要有几个有经验的技术骨干帮助

把控好代码质量。

培养人：培养人主要还是靠内部形成好的学校分享机制。好的开发实践（

新人要有师傅带，代码审查、自动化测试、持续集成都可以帮助对工作结果进行及时的反馈。在小团队推行这样好的开发实践，让团队获取及时准确的反馈，有助于整个团队的成长）+内部技术分享（分享本身就是最好的学习总结、听得人可以学习一些新鲜的知识、每个团队成员都学会分享，整个团队分享讨论的技术氛围形成的很好）+合理分工（大牛一半的精力负责一些重要的架构设计、框架开发的工作上，一半的精力在代码审查和带新人上，帮助其他人一起成长，整个团队的发展才能更健康）

管理人：小团队的管理，核心在于营造好的氛围，鼓励员工自我驱动去做事。具体做法上可以参考敏捷开发的一些做法，比如说通过任务管理系统和看板，让团队成员自己领取开发任务，在制定一个迭代的计划的时候，让团队成员一起参与对任务的打分，参与计划的制定。除了这些鼓励员工自驱动，发挥主动性的做法，在营造好的团队氛围上，还要注意的就是遇到线上故障、进度延迟这些不太顺利的情况，更多的是提供帮助，一起总结复盘，而不是甩锅问责。

开除人：在应用软件工程的时候，团队中可能有人会成为障碍，要么是能力不足无法落实，要么是态度有问题抵触软件工程的实施。如果是能力不足，就给予帮助，给时间成长，对于态度有问题的，明确指出其问题，限期改正。但如果最终结果还是达不到预期的话，那就必须果断地将这些员工淘汰。

2 流程建设

一开始不宜有太多的流程规范，不然，如果流程不合适反而会成为一种束缚，最好只是先设置最基本的流程规范，然后在实践过程中针对团队特点和业务特点去逐步完善。

2.1 选择适合你的软件开发模型

能采用敏捷开发最好，但是如果大家没有完全理解敏捷的价值观和原则，那么最好不要贸然直接换成敏捷开发，因

为这样团队需要去摸索如何敏捷开发，可能反而会降低开发效率。

可以先逐步借鉴敏捷开发中好的实践：

• 开发周期上，应该缩短交付的时间，使用快速迭代的开发模型。在做迭代的规划时，优先选择当前最核心最重要的功能；在一个版本内，不轻易接受新的需求变更，有需求变更放到下一个迭代中；在迭代时间结束了，无论新功能是否开发完成，都按时发布新版本，没完成的放入下一个迭代。通过这样的变化，可以保证在一个迭代中整个团队的开发状态是稳定的，不需要受到需求变更的干扰，也可以慢慢形成适合团队的迭代节奏。
• 每日站立会议，可以帮助团队及时了解项目进度，解决进度上的障碍；每个迭代的计划会议，可以让大家一起参与到计划的制定中；每个迭代的验收会议，可以让业务部门、老板及时的验证工作成果，看到大家的工作进展；每个迭代的回顾会议，可以帮助阶段性复盘总结，不断优化开发流程。
• 基于看板的任务可视化，也可以帮助团队直观的看到当前迭代中的任务进度，可以主动选取任务，而不需要去问项目经理下一步该做什么。

2.2 构建基于源代码管理工具的开发流程

• 小型团队完全没有必要自己去从头搭建自己的源代码管理工具、持续集成工具，应该尽可能采用在线托管的服务，这样可以节约大量搭建、维护工具的人力和时间成本。类似的策略也应体现在技术选型上，小团队应该尽可能使用现成的工具、框架、而避免自己造轮子，把主要精力放在业务功能的开发上面。

2.3 建立外边提交需求和任务的流程

• 让所有人都基于任务跟踪系统去提交需求和开发任务，所有任务都先进入Backlog（任务清单），然后在每个开发迭代中，去按照优先级选择当前迭代的任务，如果有优先级的冲突，应该需要实现沟通解决。对于提交需求和任务的人，也能通过任务跟踪系统，及时的了解到任务的进展。

  在团队之外推行这样的流程是会有一定阻力的，最好是能事先去找几个关键的业务负责人私下沟通，取得理解和支持，让他们知道这样做对他们的好处，比如说可以更好的跟踪任务的进展，让开发效率更高，更好的位他们完成任务。