SharePoint解决方案开发模型系列 - 团队的建立

   本文摘自：http://blog.joycode.com/kaneboy/archive/2009/09/27/115716.joy

 

大约一年前，我曾经在blog上写过一篇文章，讲述了我对于SharePoint解决方案开发模型的一些想法，其中包括了SharePoint解决方案开发的方方面面，从开发团队，到开发环境的建立、物理与逻辑架构的设计、开发流程、信息架构、测试等等等等。这些主题我相信对于SharePoint开发人员、架构师、项目经理而言，都是非常有价值的。

既然直到现在，国内仍然没有任何SharePoint开发书籍（当然也包括我的《SharePoint 2007 开发入门指南》）讲述上面这些主题，所以决定开始在自己的blog上面，陆续就每个主题，撰写一些文章。希望这些文章能帮助到SharePoint技术社区。

每每涉及到比“具体”技术细节更高一层的架构、流程、方法论的东西，通常都很容易引起争议。这是很正常的现象。这些主题和具体的诸如C#语法、怎么做一个Web Part等等都不相同，因为这些主题根本就不会有一个标准答案。每个人心中都对如何设计一个架构、如何实施某个流程都有自己的想法，而环境与条件的不一致，更是使得所谓的“最佳实践”在很多场景中都不适用。所以，如果你对我撰写的文章中的某些内容不认可，没有关系，这些文章中的内容本来就不是“金科玉律”，甚至在你所处的场景中根本就是错误的。这些文章只代表我个人的意见（但其中肯定有不少想法，来自MSDN以及其他人所撰写的博客和文档），同时我也希望它们能成为交流的一个平台。如果你对文章中的内容有意见和想法，欢迎留言。高质量、有价值的留言，通常都能让后来的阅读者受益良多。

任何软件项目的实施，都必须从实施团队开始。所以，首先要讲述的主题，是如何建立一个SharePoint实施团队。

从本质上来说，实施一个SharePoint项目，与其他类型的软件项目，诸如ASP.NET、PHP，都不会有根本的差别。所以一个SharePoint实施团队的组成，也基本上和一个标准的Web项目实施团队相同。在下面的角色描述中，我基本上只会描述和SharePoint相关的部分，而其他通用的内容则会尽量省略。

项目经理

项目经理是整个项目的管理者。他负责指派任务、记录和跟踪进度、向老板们汇报...总之，项目经理的工作就是要保证整个项目处于正常状态，并能顺利完成。在小型团队中，项目经理有可能同时兼任业务分析人员。

业务分析人员

业务分析人员应当与客户充分交流，弄清楚客户的业务需求、流程等等信息（越详细越好）。业务分析人员与架构师一起工作，撰写出应用系统的功能规格说明书（也可能叫其他名字），不管我们叫这份文档什么名字，它都应当至少包含有：
1、整个项目要解决的问题、目标
示例：“ABC公司是一家卖汽车的企业，它总共有300名销售人员，销售人员希望通过一个“客户管理系统”对他们各自的客户进行管理。在这个系统中，销售人员能够查看自己负责的客户、每个客户的详细信息、每个客户的订单历史记录等信息。同时，销售人员还需要通过这个“客户管理系统”提交季度销售预测报告...”
2、针对用户使用场景的User Cases
这里的User Cases信息，应当详尽的描述出用户使用系统的每个具体场景，它将作为整个团队的一个“基础文档”，架构师和开发人员根据这些信息，才能知道程序最终要实现的效果。每个User Case里面都要包含用户几乎每个操作的描述和说明，以及每个主要界面的图示（使用Visio或其他工具绘制），也就是说，它不能含糊，而应该清晰、明确、有针对性。
示例：“User Case 15 - 销售人员Dashboard”
“销售人员在“客户管理系统”主页上点击“Dashboard”按钮（参考User Case 5），就能够打开自己的Dashboard...Dashboard会自动校验当前浏览用户的身份和权限，如果的Dashboard以两栏的方式来展现信息（参考图15-3），其中左栏自上而下会包含5个链接，分别是...销售人员点击了左栏的“历史订单数据”链接之后，页面将转向到“历史订单数据”页面（参考User Case 26）...中间的向右箭头是一个可以允许销售人员将右栏折叠起来的图标，在点击它之后...销售人员可以点击右上角的“返回”图标，以返回到“客户管理系统”主页...”

功能规格说明书不涉及具体的技术细节，不包含如何实现每个场景的技术说明，不包含系统的设计内容。我们可以这样想象，假设团队中突然来了一个陌生人，他希望能了解这个团队到底在做一个什么项目，这个项目是干嘛的，实现了什么功能，我们可以将这份功能规格说明书给他，而他确实可以从这份文档中了解到他希望了解的这些信息。

这份文档不能由业务分析人员一个人独自写成，而一定要有技术人员（以架构师为主）的共同参与。一方面，架构师的参与可以保证规格说明书中的内容，在技术上是可行且合理的，另一方面，也有助于架构师从业务角度了解系统，明白客户的需求。

我个人对功能规格说明书的重要性非常推崇。在项目中，可能我们不会撰写详细的设计文档，可能我们不会撰写详细的部署文档，但一份详细的功能规格说明书确是不可缺少的。它的重要性体现在：
1、让团队中的所有人都明白我们要构建的是一个什么东西。如果没有这样的一份清晰的功能规格说明书，就不能保证团队的所有人都一致了解团队的目标。如果没有它，业务分析人员会根据客户的描述，在自己的大脑中想象出系统应该有的样子，然后口述给开发人员，并假设开发人员完全明白了自己大脑中的想法，而开发人员则会根据自己从业务分析人员那里听到的，在自己的大脑中又试图去想象系统做出来应该是什么样子的，并假设这就是业务分析人员想要的样子...总之，每个人都会根据自己的“想象”，去猜测别人的意图。而最后当开发人员把最好的东西给业务分析人员演示的时候，通常是业务分析人员大吃一惊：“我kao，怎么是这个样子？这根本和我告诉你的是完全不一样的东东...”而开发人员则会辩解：“胡说，这分明就是我根据你告诉我的要求做出来的...”
2、我们有了一个可以和客户讨论的东西。这份文档可以尽早的交给客户审阅，客户可以根据这份文档，了解到系统做出来会是什么样子，如果不满意，客户也可以及早的和开发团队进行沟通：“嗯，不对，在这个地方，其实我们更希望看到一个选择框，而不是用户自己填...”
3、它是业务分析人员与开发人员之间的一份“合同”。业务分析人员可以充分的假定，开发人员最后交付的，就是功能规格文档中所描述的样子，而开发人员也可以充分的假定，业务分析人员需要的，也是文档中所描述的样子。

值得一提的是，功能规格说明书并不会（也不应该）限制开发人员的“自由”。它仅仅包含对业务场景、系统功能的详细描述，但是不会写上应该如何实现。它肯定不会包含诸如“在这里，我们要创建XYZ类和ZYX类，前者用于从数据库中查询QWE表...”，也不会包含诸如“我们将使用3层结构，并由5个主要模块来构成整个系统框架...”之类的信息。如何设计、如何实现，应该由架构师和开发人员讨论并确定，而没有必要写到功能规格说明书里面。

架构师

架构师首先应当与业务分析人员一起撰写功能规格说明书，以保证其中所包含的内容在技术上的可行性，这同时也能保证架构师非常了解整个系统的业务需求。其次，架构师应该以功能规格说明书为基础，为整个系统设计物理架构和逻辑架构，将整个系统合理的拆分成各个更小的模块与组件，并将模块与组件的开发任务分配给开发人员。架构师还要与开发人员非常紧密的一起工作，与每位开发人员讨论并确定每个模块的实现方式。架构师应当是技术负责人，确保整个项目在技术上畅通无阻。

系统物理架构也就是整个系统在物理上、网络上的拓扑模型。整个系统需要多少台服务器？每个服务器是什么角色？网络设置应该是怎样的？是否需要DMZ区域中也要部署一台SharePoint服务器（如果用户需要从Internet访问的话）？或是使用DMZ中ISA Server来进行Internet发布？这些设计都是属于系统物理架构上的设计。

系统逻辑架构是从逻辑上描述整个系统的结构。整个系统有几个SharePoint服务器场？有几个SharePoint Web Application？几个Site Collection？每个Site Collection是做什么的？会包含哪些内容？为哪个群体的用户服务？各个不同区域的安全模型是怎样的？这些设计就属于系统逻辑架构设计。

子模块与组件的拆分也是架构师需要承担的工作。如何将整个系统拆分成更小的模块与组件？按何种方式与原则进行拆分？比如，是按照传统的N层架构来拆分（将“数据层”模块交给一个开发人员做，将“业务逻辑层”模块交给一个开发人员做，将“UI层”模块交给一个开发人员做...）？还是按照业务功能来拆分（将“客户数据维护”功能模块交给一个开发人员做，将“订单历史数据查询”功能模块交给一个开发人员做，而每个功能模块实际包含了实现那个功能所需的所有从数据到业务逻辑到Web Part展现相关的所有部分...）？不同的拆分方式，就决定了如何为开发人员分配工作，并会影响到后续一系列的诸如集成测试之类的环节。

开发人员

终于，开发人员登场了。开发人员的工作就是理解自己所负责的模块与组件相关的业务需求，仔细阅读（并可能参与编写）功能规格说明书，与架构师紧密合作，将功能实现出来。

作为一个SharePoint开发人员，是非常有挑战性的。需要学习和掌握的知识点非常的多，才可能从容不迫的将手头的开发任务完成。拥有强有力的SharePoint开发人员，是整个项目能否顺利完成的关键因素。

SharePoint开发人员需要掌握的知识包括：SharePoint、ASP.NET、XML、Windows Workflow Foundation、JavaScript、InfoPath，未来还可能需要加上Windows Communication Foundation、LINQ、Silverlight、PowerShell...

测试人员

当我说到“测试人员”时，实际上包含了两类人。一类是对开发人员写出的代码进行测试的人，这种人可能由开发人员（通过贯彻Unit Test流程）兼任，第二类则是在SharePoint解决方案开发过程中，进行集成测试和最终环境测试的人，这种人也可以由某位开发人员兼任。

集成测试是指，在一个独立的集成环境中（通常是一个“干净的”SharePoint服务器场），定期将所有开发人员交付的模块与组件部署进来，并对它们的功能以及它们相互之间的关联进行测试。一个集成测试环境对于SharePoint开发而言是必不可少的。

网络与系统管理员

网络与系统管理员是那些负责建立和管理开发团队所使用的各种环境的人。这些环境包括位于每个开发工作站上的开发环境，进行集成测试的集成服务器环境，进行部署前测试的最终测试环境，以及生产环境。网络和系统管理员负责将开发人员交付的模块与组件，部署到各个环境中（比如测试环境、生产环境）。将有了环境管理员，开发人员也可以快速的得到一个标准的SharePoint开发环境。网络与系统管理员可以由某位非常熟悉SharePoint管理的开发人员兼任。

当然，根据各个项目需求的不同，团队中还可能有其他的角色存在，比如美工、文档编撰人员等。这些我们就不再一一详述了。本系列的下一篇文章，将讲述SharePoint解决方案开发中所涉及到的各个环境。