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

大约一年前,我曾经在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表...”

posted on 2009-09-27 01:53  kaneboy  阅读(226)  评论(0编辑  收藏  举报

导航