分工，协作，团队

    分享一些在最近工作中团队和开发方面的拙见。

 

     过去很长的一段时间都是一个人接洽项目，独自进行开发工作，故而也萌生了一种英雄式程序员的思想。随之后来参与了各种类型的团队开发工作，有的是通过网络沟通协作的团队，有的是独立任务分配式的工作，正式进入工作后，则在一个固定开发环境下相对固定的团队。但是这种英雄式的思想始终存在，想必这也是大部分开发者都有的观念。那一个团队是否需要这种英雄式的程序员呢？

     我们来看一下软件大师们是如何说的：

    “一支程序开发团队之所以成立，是为了承担并完成某项由任何个人都无法独立完成的任务”；

    “由3名程序员组成的团队，只能够完成1名能力相当的程序员所完成之工作量的2倍。另外，如果每个开发组分别由3名程序员组成，那么基于同样的原因，3个这样的开发组协作完成的工作量，将是单个开发组的2倍，或者说是单个程序员所能够完成的工作量的4倍。因此，假设某个工程由单个程序员需要8个月才能完成，如果我们希望在4个月内得到结果，那么我们就需要派上3名程序员；而如果我们希望在2个月内完成工作，就必须分配出9名程序员。”

     随着IT技术发展，行业对于各种IT系统的依赖越来越高，而各种复杂业务的实现，复杂系统的实施，都让本身无法完全实现自动化的程序开发工作更加复杂繁重。对于需求方而言，在乎的是开发方在最快时间交付合格的产品，对于开发方来说，让团队更好的协作，让自身产品工作能在任何时候稳定进行是完成开发任务的关键。

    “首先规划出程序的理想结构，然后按照最优的方式，选取最合适的人选来承担对应的工作。”

     我一直赞同这个观点，合适的才是最好的，英雄不是团队必须的，合适的成员才能给团队协作带来价值，而从一个企业角度而言，把工作环节的顺利进行依赖于某个特定的个人，是具有风险性的，人事变动在所难免，一个团队因一个人的离开而无法进行工作，这就是一种不合理的团队建设，当任何人都是可替代的时候，团队工作才可能达到稳定。当然，我们总是不愿承认自己是随时可以被替代的，特别是对于软件开发这样的特殊生成工作，人的因素是左右项目成败的很大因素，当我们负责了很多开发任务的时候，往往我们就成了看似无可替代的。为了解决这样的问题，于是乎出现了软件工程等相关方法论来指导团队建设。

     不是英雄，但要出色，在团队中找到适合自己的角色，协作能力好，才是个人在团队的价值。为了开发工作的顺利进行，我们会制定出各种规范，制作各种文档来转移风险。

 

     上面谈完了正统的团队建设的一些拙见，再谈一些更切身的东西。

     当一个软件企业经过了长期实践，已经形成了有价值的团队建设经验的时候，便可以将这些适合于该企业本身的经验推广实施，在每一个开发团队中实践。然而，一个还没有成熟实践的软件部门，又该如何去建设它的各个团队？您可能会谈到规范，先用一套规范来把程序员先约束好，再来积累经验。于是管理者就选择探讨了一些个模式，方案，然后盘算着把它一下就推而广之，要求每个人都这么干。甚至对于一些规范或模式细节还没有真正搞清，没弄明白它的优势与弊端，它所适合的领域，就一下把一切都固化了下来，当成大家的经验积累的结晶。这里不是在抱怨什么管理问题，而是不得不指出，在一个管理经验缺乏，团队不成熟的情况下，不加磨合的就以“官方”形式将规范和模式强加于团队之上，等同于遏止了每个人的创造性。

    “为什么要用你的那套？”“为什么大家都要这么干？”“这个东西合适这个项目吗？”于是乎很多种声音在背后议论。

     既然谈到了开发规范和模式的问题，那就再展开一下，对于开发框架，很多软件企业都会自己的一套开发框架，往往是经过长期工作积累下来根据企业项目特色而形成的一些能提高开发效率或者规范产品架构的开发应用框架。既然作为框架，则至少应该在企业内有统一的开发管理和版本发布来保持框架的持续稳定性，具体开发工作中，使用的版本应是已发布的，在一定时期不可变更的稳定版本，具体开发中不应对框架进行直接的代码修改和编译。很多时候，开发框架作用之一就是复用，对于复用，如何理解，是从产品层次还是编码层次？是否开发的产品总是可以复用的？（关于复用，改天再开一篇尝试下细谈）。

      我们继续，假设开发团组建好了，那该开始工作了，那工作该如何分工呢？对于具体开发工作，视项目所选取的开发框架和模式，进行横向或纵向的切割，功能模块的划分等，将开发者的职责进行分离，但我始终对于这种分离有一个导向性原则，就是分离的目的是为了什么，为了各部分设计的统一？还是责任人的单纯划分，为了明确责任人？既然是团队，那责任应是归于团队而非个人，如前面所说的，不应将风险依赖于具体的某个人，所以，工作划分先是项目的合理划分，再来进行可协作安排，然后划分具体任务至程序员。

     各类型团队之间的协作也是不可不提的，需求方，开发方，最为典型的协作场景（描述几个情况）：

     需求方宏图大志，需求框架，项目蓝图庞大健全，开发方讲求敏捷，结果被需求压的无法喘气，系统边界无法定，迭代周期不可知，推进与否无法判断，数据驱动的设计导致一个永远无法稳定底层，敏捷建模成了“敏捷建UI”，敏捷成了瀑布。

     需求方界定明确，开发方妄加揣测，实际开发负责人员没有实际权限，版本无法控制，出现多系统集成情况而未做良好架构进行应对，成员变动，轻易推行所谓重构，对于项目推进毫无帮助，在应当分支的情况下未做合理决策。

    上述种种情况不可避免的出现在类似的开发活动中。选取了某个方法论，但做的形似而神离（或许根本没有实践经验？），诸如敏捷开发中所述：“可以工作的软件胜过面面俱到的文档”，结果文档错综庞大，产品无可用版本；“客户协作胜过合同谈判，个体与交互胜过过程与工具”，结果需求分析，系统分析，策划，需求，管理等等，分立分离，最前线的不是最直接的工作负责者，最无关的人来教你如何沟通。

 

    我们面对工作中的种种，多加探讨便可得新知。