磕磕拌拌的Scrum之行

看来你来javaeye也很晚，居然不认识刘老大。哈哈

关注你们的进展，期待继续分享实际经验。

不想灌水的，关注很久了，RCFans继续哦 ^ ^
预祝胜利

期待能看到后面的进展

经验很多，说一个大家都没有提到的，确定好客户方的一个需求对接人，一个对业务熟悉的人，同时要要求他的工作时间必须腾出一部分来做这方面的工作。这个人需要有一定的决策权。比如你们约好每两周作一次功能反馈及确认，以及时给客户反馈，同时听取客户的意见。

这个接口人非常重要。要不你们项目可能会有问题，如果是一个全新的项目的话。如果是重构的项目，可能需要考虑得更多，客户方希望要增强到什么程度，对现有系统哪里不满意，这些都是必须重视的。

再支一招吧，

8个月的时间，做计划是不能按 8 个月做的。

依据不同团队成员，客户，项目的情况，应该做成 6, 7 个月的。

（二）一直在向下平衡

11月5日，我们第一个Sprint结束了，也完成了，但这个“完成”非常勉强，只是在我的一再“妥协”之下达到了目标。

在数据库设计上比预期超支了100%，原因，对业务不熟悉，与业务人员沟通中有返工，对命名规范执行不彻底，全部返工，命名规范一些细节上的东西没有预先制定，这个在返工中一起制定了。

成员素质离敏捷开发还差的很远，常用的应用模式经验不多，使用的技术掌握也不够成熟，部分成员还会抵触使用现成的框架。在本次开发中，有过两次关于设计的变更讨论，最终在设计风格上达成一致，但本次按现有产出继续走，在下一次Sprint中体现新的设计。能做成这样，与我们的子系统耦合度不高也有关系。

总结就是，本次我们先不管什么代码结构良好，以实现业务功能为第一目标，狠卡数据库设计和命名规范，也正是因为这个原因，在规定的时间点完成了任务。

预计下一个Sprint是做主业务系统，但以目前来看，主业务系统还无法开工，我们会做一些基础框架，借此提高大家对框架的理解力。

项目中另外的一条线是公司请的咨询服务，隔三差五会与我沟通项目的情况，同时会根据项目需要提供人力外包（UI、QA、测试）。本来他们挺水的，但在我们的强力制约下挤出了一点料，我要求他们先了解我们如何工作，然后叫他们配合。争执出现在，咨询师极力想将我们的工作“流程化”，我暂时感觉到没有必要也没有办法。

敏捷的核心在于人，我们必须致力于团队成员的敏捷修炼、自组织，然后使用团队去同化新血液——这是我现在的理解，以及实践。

已要求两人名成员学习一些应用模式，因我事情比较多，所以项目现在还说不上完全掌握之中。

我们是“甲方”，并且和技术总监分享业务决策权，只要不出现违背业务目标的情况，都由我们完全主导。业务平台只是整个项目的一个方面，核心的东西在互联网上，这些都是由我们分析和设计的。

有个好的业务接口人真让项目很舒服。讨论迭代安排的时候不用坑蒙拐骗，唉。

那这样的项目相对还是可控的，尽可能地多了解成员的情况，及时解决存在的问题，把计划定得更紧一些，而不是按目标订计划，目标是用来超越的，我想应该问题不大。