被标题“骗”进来的请自觉去面壁三分钟哈哈哈。

真实的标题是《我的敏捷经历-I》

背景

项目

我们的这个项目背景比较简单,本质上是为业务部门做一个类OA系统。它的功能主要是把一些线下的工作流程转到线上处理。只不过与一般的行政管理流程相比,它涉及的业务专业知识更多、处理流程也更复杂。

有一点必须特别指出:我们组是中途接手、而非从零开始做这个项目的。在我们组接手时,这个项目已经完成了一半左右的需求。

之所以强调这一点,是因为有人认为敏捷模式更适合于做新项目,而非接手老项目。但我认为并非如此。我这一次接手老项目的敏捷之旅算得上很成功,但后来与另一支团队以敏捷模式做的新项目却以失败告终。说到底,敏捷能否成功的关键在于人,而非人所面对的项目。

组织架构

组织架构方面,我们整个部门采用的都是强项目、弱职能的矩阵式架构。项目相关的工作由专门的项目团队负责,除了项目工作之外的行政、人事等方面的管理工作则由各成员所属的职能部门负责管理。

强项目的组织架构确实有敏捷有很大的帮助。

有一位高人说,敏捷团队要求项目组成员100%投入到项目中去。这种组织架构确实能很好的保证这一点。而且,强项目架构能够让项目团队更有凝聚力,让大家在项目工作中更有Owner意识、更有自组织性。

但是强项目架构可能会带来其它问题。

最常见的就是项目组之间壁垒森严、沟通协作简直难于上青天。各项目组之间的产品同事之间很少沟通产品方向,开发同事之间很少有分享开发技术。各项目组之间的协作往往要靠更高层的领导来强推——即使如此也经常会有揽功诿过的现象发生,闹得皆大不欢喜。

而且,如果项目划分不合理,项目组之间就容易出现业务重叠、产品雷同、系统重复等问题,很容易出现同一个功能要重复开发、或者同一个bug却没人跟进等问题。不过这属于项目制的问题,与敏捷没有太大关系,这里就不展开讨论了。

矩阵型组织结构

刚开始,我们项目组只有四个人,后来稳定为六个人。

业务部门同事S姐担任产品。拥有四五年工作经验的C姐负责项目管理和部分开发工作;当时只有一年半工作经验的我负责主要的开发和运维工作;后来加入了两个应届毕业的开发小妹妹W和L;测试工作则由多年测试经验的H姐负责。

(也就是说,除了我之外,整个项目组里全是姑娘。而且这个项目做完之后,又招入了两位姑娘。这就是为什么这一篇的标题是“我和姑娘们不可不说的故事”哈哈哈)

由于产品同事的本职是业务人员,所以S姐不在IT职场办公。这为我们的需求沟通制造了一点困难。所幸她对系统有非常明确的规划,对项目需求池、迭代需求和需求优先级都成竹在胸。而且,因为自己就是系统的最终用户,她对需求的理解也入木三分,对我们的疑问总能在一两天内给与明确的答复。所以不在一起办公造成的影响微乎其微。

从与S姐合作的经验来看,产品人员对项目的长期规划和对业务的理解程度这两点非常重要。我甚至认为,产品人员可以不了解技术,但是必须深刻地理解业务需求。否则的话,敏捷迭代从需求阶段就带着“先天不足”,轻则导致后续工作被迫缩减范围、放弃质量或压缩时间,重则引发不断的变更、返工和无用功,不仅打乱迭代节奏和项目计划,而且非常打击项目组的士气,最后事倍功半甚至狼狈收场。

团队中的四名开发人员(S姐、我、W和L)是敏捷团队的主力,但是我们谁都没有敏捷开发的经验,甚至连开发经验都略显不足。这是我们“取经路上”的第一难。

但是,“祸兮福所伏”,“一张白纸”未尝不是我们的一个优点。在《灌篮高手》中,安西教练曾对樱木花道说:你是初学者,动作不自然是理所当然的;好在你没有养成坏的习惯,因此,从现在开始你必须掌握正确的动作要领。魏文帝曹丕也曾说:“从前阳庆劝淳于意放弃旧的不实用的一套,并教给他实用的剑术。现在,我也希望邓将军(奋威将军邓展)舍弃华而不实的剑法,改学实用的剑术之道”。我们是敏捷的初学者,会走弯路是理所当然的;但是,我们也没有养成坏的习惯,没有那些“华而不实的剑法”。面对“正确的动作要领”、“实用的剑术之道”,我们不会受困于过往的经验并泥足不前,而能很虚心也很快地接受、理解并落实新的开发模式和工作方式。

实话说,如果团队没有这种学习和接受新事物的态度和能力,我们的这次敏捷之旅会何去何从,实在未可知也。

安西教练对樱木shuo