刚读了《敏捷软件开发原则、模式与实践》第一章敏捷实践，对照现在正在进行的2个项目，感触挺深，特别是设计与文档，在当初实际编码的时候看来就存在意识上的偏差，所以借此机会写下来。
前段时间公司在过CMMI2，由于之前在软件开发过程中极不规范，特别是项目管理，完全是出于项目经理个人意识的管理，所以在推行CMMI的时候特别强调开发过程，一切都按规范来走，因为CMMI2是项目管理级，所以这也是重中之重了。这是这2个项目启动时候的大环境，再来说说项目环境。这2个项目都是学校项目，一个是学校门户与协同办公，一个仅为协同办公，在前期，就决定用MOSS2007来实现，包括与Exchange和LCS的整合。
第1个项目我是全程参加的，从投标到后面的验收，这个项目难道不大，需求很明确，通过2个星期左右的需求调研，形成了比较完善的需求文档，用户也签了字。这个项目的参与人员包括一个项目经理、2个开发人员（我是其中一员，并带另一个今年毕业的同事）、QA、CM、测试人员2名。我和刚毕业的同事没有使用SharePoint做过开发，只有很少的使用经验来自于使用公司内部信息门户，对SharePoint的认知算是很少吧，虽然我在前一个项目投标中搭建过MOSS2007环境，并完善了投标书系统部分功能，其实这个项目就是我要说得第二个项目了。
需求确定下来后，我开始概要设计文档的编写，在这过程中，和项目经理发生了一些分歧。项目经理的想法是我必须把文档写得足够清楚，一步一步怎么做别人看了就明白，能让我的那个同事按照设计文档就能很好的实现客户需求，和我的设计想法完全切合，而不用时常来问我这里什么意思，那里怎么去具体实现，当时就考虑对详细设计做适当裁剪，对SharePoint自带实现部分不做设计。我觉得项目经理的想法脱离了我们的实际情况。第一，概要设计说明书的阅读者是程序员，不可能让所有人看了概要设计说明书就明白是怎么回事，比如不知道SharePoint列表、文档库是什么，还怎么看概要设计说明书呢？得有起码有SharePoint得基本知识，这是最基本得前提，第二，他要求非常详细地说明每个需求的实现步骤和细节，这即是不可能也是效率低下的（当他和我这样说的时候，一个以前做过SharePoint开发的同事也表达了同样的建议），从我自身来说，我没有任何SharePoint开发经验，对于需求的具体实现，肯定得有一个摸索和实践的过程，如果要求我在概要设计阶段来定好每个详细步骤是不可能的，就算有个很详尽的步骤，即得花费很多时间，而且对结果也不能保证其是正确的，因为我没有用编码来验证，不可能考虑得那么详尽，毕竟我只能根据资料和有限的实践来想，而不是实际编码的过程，当然我答应尽量详尽，至少对于每个客户需求说明将用什么来实现，比如有些信息发布直接用列表和文档库来实现，而不是自己去设计数据库实现；对我同事来说，情况类似，我只能指明我能确定的东西，也就是方向性的东西，而不是根据我的文档他就能完全按照设计意图还原客户需求。
最后，项目经理和我都做出了些让步，不过我仍然很郁闷，比如怎么在页面添加WebPart、怎么给列表和库自定义栏、配置搜索，我都需要一步一步的写清楚，这些东西耗费了我不少时间。我的想法是当我要在概要设计说明书中某个地方说到给页面添加WebPart时，这样说就可以了，而不用去详细得写该怎么一步一步去添加，特别是自定义列表的栏，这些只要是对SharePoint有些微认识的都会明白，能读懂和按我的设计意识去做的前提是开发者有一定的SharePoint基础，而不用我去解释导航栏在那里怎么一步步去设置，我之提供简单步骤和方向性的指南，而不设计到太具体和细节的实现。
事实证明，我的想法是对的，在编码基本完成的时候，再回过头来看概要设计说明书，很多需求在实际实现的时候已经完全变了样，当然方向性的东西没变，比如有些东西用表单来实现，有些则开发用户控件通过WebPart包装器来添加到页面。概要设计时间耗了很多，而效果却不明显，如果把这些写所谓概念或简单配置步骤的时间发在编码上，肯定进度能提前了，最主要的是这样的文档并没有减少我和同事交流沟通的时间，毕竟很多东西用文档不能完全表达清楚，面对面的沟通效率更高。
所以，结论是在项目领域对开发人员来说完全陌生或比较生疏时，我们要花一定的时间来研究实现客户需求的方法，对于实在是复杂的问题，至少得有个方向性的指导，分析利弊，确定是用这种方法来实现而不是用另一种方法来实现；对于很简单只要有这方面知识就明白的步骤，则没必要发太多时间在上面，只要写个简单得步骤就可以了，因为当你走到那一步，你马上会明白或者花很少时间就会明白，这个属于项目成员需要发时间去主动认识的东西，而不是文档非得写清楚的东西，更不要认为这个会花掉多少沟通时间。保证进度并且开发出让客户满意的产品是最重要的，文档适可而止，文档是为了让开发更加顺利和可控，如果花大量时间去写不重要、很简单甚至可有可无的东西，这时候这部分文档成了进度和最终产品的绊脚石，应该剪裁掉。在项目组的努力下，目前该项目已顺利部署，将于月底验收。
第2个项目我仅参与了投标，这个项目很特别，没有客户调研（客户条件不允许，结果直接对着投标书完善需求），而且时间相当紧，从完善需求到部署系统仅一个半月左右时间（时间定死了，不能延期只能提前），在这样的条件下，项目经理决定让软件功能缩水（决定分期实现功能），项目组加班（基本上晚上加到9点，星期六加班），同时，部门经理决定把该项目作为产品来做。在是否作为产品上，项目组内部有不同意见，一边认为客户费用很贵（需要MOSS许可之类的），而且把客户套死在SharePoint平台上客户是否愿意（比如想实现邮件和即时通讯整合，就最好都用ms的了）；另一边想法正好想法，利用MOSS的强大平台打招牌，而且升级维护以后都有保障，当然这只是内部意见而已了。
在项目分工上，基本上分为2组：一组使用传统的ASP.NET开发方式，实现整个系统的权限管理及很多需求，另一组则使用SharePoint开发部分功能，这中间又包括专门一人开发公文管理，用WF实现。经过紧张的加班，进度有点滞后但还可以，这其中有些问题让人对SharePoint产生了敌意，比如新建或打开文档需要输入用户名和秘密（实际上系统验证过了的，但是每次都要，似乎2套认证系统了），对于开放了匿名访问的更烦，它会弹出2次对话框，取消2次就ok，如果记住用户名和密码，则不适用多人使用同一台机器了，类似这样无法解决的问题还有几个。现在公文管理部分需求也基本上用WF实现了，但是项目经理好像对WF很有看法，在说后面版本是不是不用WF，推倒重来，诸如此类问题很多。
在做前面那个项目的时候，我认识到，SharePoint对开发有些限制，比如前面说到的新建打开文档，当然也许是因为我们水平不够，没有研究透彻，毕竟都是初学者。但是，既然它是二次开发平台，当然就有很多扩展点，比如权限。如果你决定要用SharePoint，那么我们遇到SharePoint本身功能不够来支撑需求的时候，首先应该考虑是否可以去扩展它的功能，而不是一味得把它给抛弃，用传统的ASP.NET而不带任何SharePoint独有特征的开发方法来实现，如果真不能实现再采用传统ASP.NET方法实现，对于项目成员来说，这也是个学习机会。对于WF，我只能说有点点了解吧，在WF没出来前，为了实现工作流等效功能，很多公司都花很大力气做了自己的工作流框架，而有了WF，我相信很多在.NET上做应用的公司估计都不会这么干了，而是直接利用WF来做工作流开发，而且随着.NET的发展，用WF开发工作流肯定会更简单和方便。因为客户的原因，该项目并没有如期部署，这正好给了项目组时间来修复bug。
对于学校和政府行业的项目，大概也就如此吧，我们永远都是被动的，他们是上帝，极端的情况下，我们不能和上帝经常接触（这个项目需求都不能获取，也不能分功能块部署以获得反馈），时间卡得很死，所以这样的项目，最后也只有失败，当然，这正好符合上帝的特征，实际并用不了多少功能。这样的项目，不知道需要什么样的项目经理才能带好？
来源：https://www.cnblogs.com/Charly/archive/2007/09/13/891244.html