一次SharePoint开发的敏捷实践

　　一直都才尝试用敏捷的方式作项目，在此记录最近一次SharePoint项目开发的敏捷实践。希望能和大家更多的交流关于敏捷开发以及SharePoint开发的经验。

起因：公司希望将资产管理纳入公司的SharePoint Portal之中，由于资产管理名目繁多，现阶段从PC管理开始，而项目第一期是关于PC购买，分配的流程管理，这里只记录其中一部分。

　　首先了解需求，整理user story，确定user story的优先级，确保每个user story都是deliverable&testable。

　　我们设定了2周为一个Iteration，在对每个User story的point进行评估以后，选择了其中优先级较高的可以在一个Iteration完成的user story，在这个Iteration内完成，例如本次Iteration选取了下面的user story:

1.As a user, I can apply component/PC from SharePoint site.

2.As a manager, I want to be able to get new pc application and approve/reject it.

3.As a director, I want to be able to response the application after manager approved/reject it.

我们采用了TDD的方式来开发，先写test case(开发人员和测试人员一起达成共识)。我们采用了一个开源的测试框架Fitnesse，在这里不具体介绍Fitnesse的使用方法了，有兴趣的朋友可以去看 http://fitnesse.org/.FitNesse.UserGuide， 有比较详细的介绍。Fitnesse本身是一个Wiki，我们的test case在fitnesse上都表现为一个个table。我们细分了user story，在fitnesse上创建针对各个user story的test case。Fitnesse的table是一种很直白的表现Test case的方式，也很直接的表现了需求。

写完了test case，跑test case，不过。然后开始写business代码。完成business代码（.dll），再跑test case，这次通过了。

然后我们需要把business代码和SharePoint相结合起来，这里由于业务流程不是很复杂，放弃了SharePoint的workflow开发方案，直接选用了Eventhandler解决方案，当用户提出一个application时，会促发SharePoint的eventhandler，来完成这一系列的workflow。由创建的eventhandler来调用我们的business代码。再这里不帖具体的business和eventhandler实现代码了。当所有的这一系列工作（包括前台页面的开发）都完成后，2周的时间也差不多到了。

　　一个Iteration结束后，在demo meeting上我们为公司资产管理的admin演示这个Iteration所完成的user story。demo完成后，她对大部分完成的需求感到满意，提出了一个小小的改变，就是在manager审批过申请后，不直接将申请发送到director审批，而是中间需要由admin来review这个申请。由于中间加了一个review的环节，在下一个Iteration中，我们修改了test case，再跑test case。有一部分test case通不过了。于是我们再修改了business 代码，再跑test case，通过。这样也确保了所有没有涉及到修改的代码没有因为我们修改的部分而出错，这个就是TDD的好处之一。

　　在TDD的开发模式下，我们将business代码分离的出来，这样有助于我们优化我们的代码结构，同时这部分代码可以被automation test，确保了代码质量。

　　敏捷开发的好处在这里也不再赘述了。