背景
项目
我们的这个项目背景比较简单，本质上是为业务部门做一个类OA系统。它的功能主要是把一些线下的工作流程转到线上处理。只不过与一般的行政管理流程相比，它涉及的业务专业知识更多、处理流程也更复杂。
有一点必须特别指出：我们组是中途接手、而非从零开始做这个项目的。在我们组接手时，这个项目已经完成了一半左右的需求。之所以强调这一点，是因为有人认为敏捷模式更适合于做新项目，而非接手老项目。但我认为并非如此。我这一次接手老项目的敏捷之旅算得上很成功，但后来与另一支团队以敏捷模式做的新项目却以失败告终。说到底，敏捷能否成功的关键在于人，而非人所面对的项目。
组织架构
组织架构方面，我们整个部门采用的都是强项目、弱职能的矩阵式架构。项目相关的工作由专门的项目团队负责，除了项目工作之外的行政、人事等方面的管理工作则由各成员所属的职能部门负责管理。
强项目的组织架构确实有敏捷有很大的帮助。有一位高人说，敏捷团队要求项目组成员100%投入到项目中去。这种组织架构确实能很好的保证这一点。而且，强项目架构能够让项目团队更有凝聚力，让大家在项目工作中更有Owner意识、更有自组织性。
但是强项目架构可能会带来其它问题。最常见的就是项目组之间壁垒森严、沟通协作简直难于上青天。各项目组之间的产品同事之间很少沟通产品方向，开发同事之间很少有分享开发技术。各项目组之间的协作往往要靠更高层的领导来强推——即使如此也经常会有揽功诿过的现象发生，闹得皆大不欢喜。而且，如果项目划分不合理，项目组之间就容易出现业务重叠、产品雷同、系统重复等问题，很容易出现同一个功能要重复开发、或者同一个bug却没人跟进等问题。不过这属于项目制的问题，与敏捷没有太大关系，这里就不展开讨论了。
人
刚开始，我们项目组只有四个人，后来稳定为六个人。业务部门同事S姐担任产品。拥有四五年工作经验的C姐负责项目管理和部分开发工作；当时只有一年半工作经验的我负责主要的开发和运维工作；后来加入了两个应届毕业的开发小妹妹W和L；测试工作则由多年测试经验的H姐负责。
（也就是说，除了我之外，整个项目组里全是姑娘。而且这个项目做完之后，又招入了两位姑娘。这就是为什么这一篇的标题是“我和姑娘们不可不说的故事”哈哈哈）
由于产品同事的本职是业务人员，所以S姐不在IT职场办公。这为我们的需求沟通制造了一点困难。所幸她对系统有非常明确的规划，对项目需求池、迭代需求和需求优先级都成竹在胸。而且，因为自己就是系统的最终用户，她对需求的理解也入木三分，对我们的疑问总能在一两天内给与明确的答复。所以不在一起办公造成的影响微乎其微。从与S姐合作的经验来看，产品人员对项目的长期规划和对业务的理解程度这两点非常重要。我甚至认为，产品人员可以不了解技术，但是必须深刻地理解业务需求。否则的话，敏捷迭代从需求阶段就带着“先天不足”，轻则导致后续工作被迫缩减范围、放弃质量或压缩时间，重则引发不断的变更、返工和无用功，不仅打乱迭代节奏和项目计划，而且非常打击项目组的士气，最后事倍功半甚至狼狈收场。
团队中的四名开发人员（S姐、我、W和L）是敏捷团队的主力，但是我们谁都没有敏捷开发的经验，甚至连开发经验都略显不足。这是我们“取经路上”的第一难。但是，“祸兮福所伏”，“一张白纸”未尝不是我们的一个优点。在《灌篮高手》中，安西教练曾对樱木花道说：你是初学者，动作不自然是理所当然的；好在你没有养成坏的习惯，因此，从现在开始你必须掌握正确的动作要领。魏文帝曹丕也曾说：“从前阳庆劝淳于意放弃旧的不实用的一套，并教给他实用的剑术。现在，我也希望邓将军（奋威将军邓展）舍弃华而不实的剑法，改学实用的剑术之道”。我们是敏捷的初学者，会走弯路是理所当然的；但是，我们也没有养成坏的习惯，没有那些“华而不实的剑法”。面对“正确的动作要领”、“实用的剑术之道”，我们不会受困于过往的经验并泥足不前，而能很虚心也很快地接受、理解并落实新的开发模式和工作方式。实话说，如果团队没有这种学习和接受新事物的态度和能力，我们的这次敏捷之旅会何去何从，实在未可知也。