团队与软件开发模型

    学习程序设计，首先关注到团队与软件开发过程，这是因为，对于软件开发而言，其三要素是团队（人）、过程、技术 & 工具。软件开发是一个智力游戏，建立在沟通与协作的基础之上；技术和工具，只是其因素之一。所以，同学在学校中所体验到的，多是技术和工具的应用，而对于团队和过程，大家则是通过阅读些软件工程的材料去了解。如我们所见的，都会提到瀑布模型、原型开发、螺旋模型等等，材料新的，将会介绍 RUP 或敏捷。

    但对于这些“书面知识”，你觉得该如何理解呢？如何结合你现在的团队或环境？

    我们回到根本上来，软件开发的目标是什么？——如之前所说，学习计算机语言和程序设计，就是学习交流能力，那么交流的目标又是什么呢？

    首先，软件开发的目标是，交付可以工作的软件。如果没有可以工作的软件，再漂亮的代码也成儿戏。就像一轮谈判，没有阶段性共识或了解，漂亮的话也没什么意义。所以，如果你身在一个开发团队中，需要首先学会在过程中审视，这样做真的有利于这一个目标吗？

    其次，一般而言软件一次交付并不意味着终结，而往往是新一轮游戏的开始——维护、升级、迭代等等。因为有这些后续的行为，前一个过程你需要留下足够的信息——为下一个延续行为展示足够清晰的状态。就像一场谈话，如果不了解上下文场景，一个新切入的人是难以继续的。

    对于众多的模型和团队而言，都会在这两个目标上找一个合适的平衡点。其实采取什么样的模型并不是非常关键，重要的是对于你当下的情况，实现目标存在什么样的问题，这些问题可以用什么样的办法去解决？开发模型给我们一种样例，一种思路。

    另外，作为以智力和交流为基本特征的团队，其管理和团队组建也是需要考量的。所以我们会对团队建立各个角色，比如产品经理、架构师、项目经理、工程师、QA人员、surfer、过程改进人员、配置管理人员等等，外部人员还有客户、用户、老板:)等等。对于管理而言，要达到目标是

    （1）如期提供高质量软件

    （2）控制过程风险

    （3）应对需求和团队变化

但管理的目标能否达到，最重要的是执行的过程，执行过程中人的感受。

    比如，对于互联网企业，最大的特点就是需求变化快；为了提供用户喜欢的功能，需要你能够快速跟进、快速得到用户的反馈、快速调整。所以互联网企业有较多的团队都是采取敏捷的开发模型进行组织和过程管理。据我所了解，腾讯是这样，淘宝这边也是这样。现在大家做法较多的是以Scrum的方式进行迭代；其关键词是沟通、反馈、交流、勇气。强调whole team。

在这样的团队中，不同职业角色的人虽然分属不同部门，但日常工作都是跟着项目团队走。产品、工程师、QA相对集中在一些产品线上的，可形成一个team——我们建立为一个Scrum。然后通过Sprint（通常是一个自然月）来进行项目迭代。其实这是一个轻量级的项目管理框架，对于Scrum而言，你会集中体会到上面四个关键词的意义。

首先对于这样的团队，角色上有三种：Scrum Master，保证项目能够遵循Scrum要求进行下去，Product Owner，负责产品要做成什么样子，并进行验收，Member，项目团队成员，则是开发、测试等等所有的人，对于Member而言，团队是扁平化的、且强调随时沟通。

其次，对于沟通而言，我们Scrum有约定的机制进行保证或促进队员的交流，主要是三个会议：每个月初的需求规划会议——需求PK、吹风及Plan meeting，Scrum执行期间的站立晨会，以及Scrum Sprint结束时的总结及成果展示会。需求吹风及Plan meeting的会议，是要求Scrum全员参加的——PM、工程师、QA以及surfer和过程改进人员，这时候确认的是做什么、资源规划及里程碑。晨会则最主要的目的是share你的状态给团队中的每一个人，并报出你的困难，发言权利只有Scrum内部人员才有，而关心该Scrum的人员则可以选择自由旁听。总结及成果展示则是对一次迭代的Review，需要总结出团队的优点、缺点及挑战，就本Sprint而言。

最后，对于Scrum过程中需要交付或使用的视角结构，则是分解好且团队已经规划完毕的项目列表，项目bug任务列表，以及项目的进度图——无论是backlog、白板或者灵活的工具进行展示。重要的是这些信息是大家共识的、为每个人所易于看到。

所以在这样的团队中，沟通和反馈是被尤其推崇，关注的结果是需求被做到了什么程度——每天都会有晨会报告大家你昨天完成的任务，今天的计划以及遇到的困难，并在Sprint结束后回顾做的优点、缺点及需要迎接的挑战。报事贴、白板是最常用的交流工具。

当然，这样的方式中也会存在一些需要考虑的地方。

一方面，并不是采取了敏捷的形式，就具备了敏捷的能力。太多的会议可能为你带来沟通的成果，也可能为你带来困扰；大家都坐到了一起，却未必提高了沟通的效率。广而言之，对于其他模型也是如此，做一个形式并不等于我们就具备了相应的成熟度。这个过程中，仍然是聚焦到我们软件开发的目标完成上，聚焦到人的感受上。

另一方面，因为可工作的软件才是目标，那么文档和流程需要执行到什么样一个力度？这对于团队而言仍然是需要认真考虑和灵活应用的——完全的文档是困难的，时刻保持文档和代码和需求每个细节一致的成本也是非常高昂的，但必要的文档与流程对于过程的控制也是意义很可见的。所以在这个过程中，仍然需要依据业务和团队特点，做一个合适的规范和流程，以辅助沟通确认和过程控制。广而言之其他模型也存在这样一个问题，如果你定义严格的流程和细致的规范，那么对于交付软件的目标，以及变化响应应该如何去做，也是需要考虑。

还有一方面，并不是所有的业务类型适合敏捷——比如，我们的研究性项目，指标难以界定，时间、资源也相对难以界定，方案不是非常明确的情况下，去做敏捷的迭代执行上也会具有很多困难。再比如，对于大型的、周期长的项目，实行敏捷方式也需要考虑——你或许会分割团队、建立超级Scrum，但这中间一定要有规范的、流程化的内容去协调团队之间的协作和控制。

所以，亲爱的同学，针对具体的业务和团队，思考获得合适的开发模型与团队管理协作方式，这对要学习程序设计的你，绝对是非常必要的一课！把问题放在心上，胜于放在脑后。即使今日你忽略之，一旦你要动手开始做，也会不得不抬起头来环顾思索你的环境。

 

对于我们的虚拟团队，也面临非常实际的问题——这时就是机会：我们的目标是什么？我们的效率如何得到提高？

希望这次做作业的两个小组，能够花一段时间考虑一下，我们的团队如何会更有效率？可以指定什么样的流程或规范？如何促进沟通？这不是作业，但对于大家会有帮助。

和大家说明一下，我们的作业有两类，一类是讨论式的，大家对于一个问题收集材料，并给出自己的答案；另一类是小型开发项目——对于这一类作业，我们将采取类敏捷的方式进行。后面随着具体项目的展开，我们的开发协作也将开始。