软件工程学习笔记13——案例解析篇

一、小团队如何应用软件工程

本文讨论的小团队，小公司或者三五个人的小开发团队。

1、小团队在软件开发中存在的常见问题

（1）小团队成本敏感

对成本的控制也衍生出一系列大公司可能感受不到的问题：

• 开不出好的薪水，难招到优秀的程序员；
• 进度都催的紧，毕竟多干一天就要多发一天工资；
• 舍不得在工具上的投入，都得要尽量用免费的、开源的；
• 通常几个项目并行，一个人可能要同时在几个项目中切换。

（2）小团队人少活多

从分工上来说，通常在大厂前端后端几个人合作完成的事，在小团队就得一个人从前端写到后端了，可能甚至都不会有专业的产品设计和功能测试人员，都是开发兼任。

从人员构成来说，大厂在组建技术团队时会注意梯队的搭配，整个团队像金字塔的结构，顶部有几个特别资深的开发人员，中间有一些丰富经验的，底部的是有潜力但经验比较少的。而小团队就算是运气好，也可能只有一两个技术大牛，更多的是水平一般、经验比较少的。

这样的分工协作和人员构成，导致的问题就是大家每天都很忙，但是感觉技术上积累有限。对个别技术大牛的依赖性强，他们一旦离职，影响非常大。

（3）小团队缺少流程规范

在流程规范方面，恐怕是大家对小团队吐槽最多的地方：

• 项目开发比较随意，拿到需求可能就开始直接写代码了，没有严格的需求分析、架构设计，写完了后简单测试一下就上线了，上线后再修修补补；
• 需求变更是家常便饭；
• 多个项目并行的时候，每个项目的负责人都觉得自己的项目是最重要的，希望你能把他的项目进度往前赶一赶；
• 老板权力很大、想法多变，经常会直接干预项目。

这样不规范的开发流程，导致的结果通常就是开发效率低下，软件产品质量不高，项目计划难以遵守甚至没有计划。

2、小团队如何应用软件工程

成本敏感的问题，如果这个是客观存在的，就没有太好的办法去解决，只能说我们在做一些决策、制定流程的时候，需要充分考虑好成本因素，减少浪费。

人少活多，那么我们就相应地提升个人和团队的整体水平和效率。

缺少流程规范，那么我们就建立适合小团队特色的流程规范，让开发流程规范起来。

所以接下来，我就从团队建设、流程建设这两个维度来谈谈如何应用软件工程。

（1）团队建设

要实施好软件工程，也要同步做好团队建设，让你的团队有一点基础的软件工程知识积累，有几个技术骨干可以帮助一起推广和实施。

如果对软件工程知识的推广能扩大到团队之外，比如你的老板和业务部门，那么在后续推进一些流程规范，会起到事半功倍的效果。

团队建设，绕不开几件事：招人、培养人、管理人和开除人。

小团队如何招人

小团队招人，难点在于成本有限，品牌也不够吸引人，能否直接招到技术大牛就得看运气了。但这不意味着就要大幅降低标准，比较现实的方法就是招有潜力的程序员培养。

在招人时，也不能一味节约成本，还要注意梯队的建设，中间要有几个有经验的技术骨干帮助把控好代码质量。

小团队如何培养人

相对来说，小团队不像大公司有完善的培训制度，资源也有限，难以请到外面的人来讲课，所以培养人主要还是要靠内部形成好的学习分享的机制。

• 采用师傅带新人的机制；对新人来说可以快速融入，及时获得指导，对于师傅来说，通过带人，也能促进自身的成长。
• 让团队获得及时准确的反馈，有助于整个团队的成长。软件工程中，像代码审查、自动化测试、持续集成都可以帮助对工作结果进行及时的反馈。
• 内部的技术分享也是很好的共同提升的方式。
• 技术高手要注意不只是闷头干活，也要承担一定的带人的工作。

小团队如何管理人

小团队的管理，核心在于营造好的氛围，鼓励成员自我驱动去做事。

要鼓励团队自驱动，具体做法上也可以参考敏捷开发的一些做法，比如说通过任务管理系统和看板，让团队成员自己领取开发任务；在制定一个迭代的计划的时候，让团队成员一起参与对任务的打分，参与计划的制定。

除了这些鼓励成员自驱动，发挥主动性的做法，在营造好的团队氛围上，还要注意的就是遇到线上故障、进度延迟这些不太顺利的情况，更多的是提供帮助，一起总结复盘，而不是甩锅问责。

有关开除人

在应用软件工程的时候，团队中可能有些人会成为障碍，要么是能力不足无法落实，要么是态度有问题抵触软件工程的实施。

在这种情况下，首先对于有问题的成员肯定是要努力挽救：

• 如果是能力不足，就给予帮助，给时间成长；
• 对于态度有问题的，明确指出其问题，限期改正；
• 但如果最终结果还是达不到预期的话，那就必须要果断地将这些成员淘汰。

（2）流程建设

小团队被人诟病较多的地方就是在于流程规范的缺失，但像大公司，流程规范繁多，也容易造成效率低下，人浮于事的情况，这也就是为什么现在大公司的开发团队也在分拆，从大团队拆分成小组，精简流程规范。

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

那么哪些流程是软件开发中最基本的流程规范呢？

• 选择适合你的软件开发模型
• 构建基于源代码管理工具的开发流程
• 建立外部提交需求和任务的流程

二、程序员的业余项目

1、为什么程序员的业余项目大多都死了

• 想法大，时间少
  这是一个常见的现象，很多程序员在业余做项目开始之前激情满满，经过一段时间没有进展，没有正向反馈，很容易就激情消逝，不想再继续了。尤其是一段时间后，可能又有新的项目想法了，于是就又开始了一个新的循环。
• 过于追求技术，缺少约束
  因为缺少成本、时间和范围的限制，没有设置 Dead Line 约束，所以经常会天马行空，只为了追求技术上的兴奋点，恨不得把新酷技术都用上。
• 缺少产品能力和运营能力
  而那些真正成功的独立开发者，无不是能兼顾产品设计能力和产品运营能力，既能设计出真正解决用户需求的产品，又能通过一定的运营让用户了解产品，为之买单付钱的人。

2、怎样提升业余项目成功的概率

（1）怎么样让项目不至于半途而废

金三角理论解释了如何去平衡软件质量与时间成本范围的关系。

• 对于业余项目来讲，其实时间是很难去控制的，也就是你不可能像每天上班那样投入大量的时间在上面，所以这条边要被固定起来。
• 虽然理论上来说你可以花钱请人帮你，但是一般来说前期不会投入大成本的。你也可以假定它是固定的。
• 那么最适合调整的边就是范围这条边，毕竟作为一个业余项目，你可以先实现最核心的功能。

在决定做什么项目之前，一样要充分考虑项目的可行性研究，去从经济可行性、技术可行性还有社会可行性方面，去分析一下项目是不是真的可行，再动手不迟。

（2）怎么避免陷入过于追求技术，项目难以交付的困境

• 要把业余项目也当作一个正式的项目，做你的业余项目时，也要站在项目的整体去思考项目的进展，而不是沉迷于局部的技术实现。
• 要去做项目计划，去设置里程碑。
• 还要敢于把计划和里程碑分享给你的家人和朋友们，公开的做出里程碑的承诺，让他们帮助监督你的计划执行。

在你的业余项目难以交付的时候，记住一句话：Dead Line 就是第一生产力。

三、失败的软件项目

项目管理协会（PMI）认为成功的项目必须满足六个条件：

• 按时交付。
• 成本在预算范围内。
• 能按照当初的设计正常运行。
• 有人使用。
• 满足项目最初的目标。
• 项目出资方对项目满意。

相应的，如果上面有一个或者多个条件没有满足，那么项目就有可能是失败的。

1、分析失败软件项目的原因

对于一个失败的软件项目案例，要去分析：外部环境、技术管理、项目管理和组织文化，这样才能帮助你找到项目失败的根源。

外部环境
如果你去看看历史上那些有名的失败的项目案例，其中政府主导的项目占大多数，而且通常主要因素不是成本，而是各种政治因素导致的不切实际的项目进度，或者是频繁变更的需求，从而严重的影响了成本和质量。

而对于商业软件项目，很多是由于缩减成本导致的。因为商业竞争的大环境，企业为了节约成本，总是希望用更少的人做更多的事情。

还有一些常见的场景就是在一个项目开始之前，销售为了拿下项目，通常会过度夸大项目的成果，而又会相应的压缩项目预算、时间，并且也可能低估了技术实现的难度，最终项目要开发的时候，开发人员才发现根本无法如期完成当初承诺的项目目标，最终导致项目失败。

技术管理
很多软件项目失败的原因也是技术原因导致的。比如说在项目中使用了不成熟或不熟悉的技术，最终导致技术不可控，或者浪费大量的时间在技术的学习上。此外，项目规模越大，失败的概率也更大。

项目管理
在一个软件项目中，项目经理掌握了资源的分配，还要制定项目的计划，对任务进行分配，组织分工协作，管理风险，项目成员的日常沟通等等。而这些决策通常很难量化，需要基于当时的情况进行权衡，一旦这些决策出现大的失误，就会导致项目的失败。

组织文化
在软件项目中，一个开放、平等、注重沟通协作的团队或组织更容易及早发现和解决问题。

如果细化一下，还可以总结出一些具体的常见的失败原因：

• 不切实际或者不明确的项目目标；
• 对项目所需要的资源估算不准确；
• 需求不明确或者频繁变更；
• 没有对风险进行有效管理；
• 和客户之间沟通不畅；
• 无法解决项目的复杂性；
• 没有好的开发实践；
• 糟糕的项目管理；
• 上层的政治斗争；
• 商业压力。

其实软件项目失败并不可怕，最重要的还是在失败后，总结原因，吸取教训。