摘要
敏捷方法是一套关于软件开发的思想方法和工具体系，通过遵循一系列的宣言、价值观和核心原则，并由此演化出来的实践方法和工具，来实现更早的和持续的交付有价值的软件，最终帮助客户最大化投资收益和提高影响力和竞争优势。本人有幸在2017年加入一个践行敏捷方法的项目组，该项目是受某石化的委托开发基于地震数据分析平台来指导石油勘探的项目。需要澄清的是这里所指的地震数据并非自然灾害中的地震，而是通过主动对地放炮。分析后来采集到的地震波数据。项目在零迭代时，就确定使用hadoop来分析hdfs格式的数据，同时应用IBM的RTC来协同完成代码管理和持续构建流水线。敏捷方法在此项目中帮助很大。本人作为高级工程师和敏捷教练的身份带领团队实践了scrum过程管理。文章先会从认知理论入手，再结合项目经历分享心得。
正文
敏捷方法中主要的角色有三类：产品负责人，这是对产品投资收益代表的一类人，通常是甲方， product owner，po。开发团队简称dev。这里说明一下，团队人数应该在5~6人的规模，是以特性团队建立，最好成员中多为全栈工程师。第三类角色就是本人在项目中担当的敏捷教练，简称为sm。敏捷方法区别于其他开发方法有两个关键的判别：第一个就是敏捷是面向人，而非面向过程；第二，敏捷面向事实性、适应性而非预设性。
下面介绍敏捷方法的宣言价值观和部分原则。宣言包括个体和交互高于流程和工具，这是以人为本的体现，强调人与人之间的尊重。在项目中有高工和普通工程师，也有内部和外包等。大家彼此无缝沟通，没有等级的区别，直呼英文名，当工作出现问题时不必汇报上级可直接找到解答者。对于，沟通在一个项目开发过程中的重要作用是不言而喻的。很多人说，项目成功的70%是靠沟通，30%才是靠做任务。第二，敏捷倡导可工作的软件高于详尽的文档。曾几何时，许多项目中，文档在不同的角色中来回变换，改来改去消耗人力和物力，也没有拿出客户满意的结果。可工作的软件成了与客户与沟通的新媒介，及早地暴露风险，好过于项目失败。这一点与微服务的小独轻松的特点有共同之处，通过快速上线来得到用户反馈，降低了风险。客户在看到投资有了实质的反馈，可工作的软件并在迭代中逐渐完善，这是敏捷方法结合原型来改造传统开发方法的关键手段之一。第三点，客户合作高于合同谈判。这一点是体现着客户至上。当客户真正的参与进来，敏捷项目的流产风险才大大降低，负面抱怨慢慢会变成微笑。本人作为敏捷教练，在项目中强调指出：客户必须派驻人员在项目组，按时参加敏捷scrum管控会议。最后在客户理解了敏捷方法的要义后，承诺每周至少有一人常住项目组，确保会议至少有两人参加。一个成功的项目不一定要在合同上咬文嚼字，评审会上面红耳赤，谈判桌上拍案而起，人身攻击。客户也不是主宰的上帝和敌人。斗智斗勇的旧式项目经理也不可取。敏捷中我们不怕检查工作，审核进度。反而怕你作为客户一个月不闻不问，不来项目组。真正优质的客户看完敏捷的理念就立刻茅塞顿开了。紧接着第四点，拥抱变化高于遵循计划。事实上有许多软件按瀑布模型开发或结构化步骤，在开发还没有完成时，软件就已经被淘汰了。因为商界的变化莫测，永远是无法预估的模型。例如：安全软件460宣布永久免费后，一下子瞬间占领了8成的市场，这种例子在互联网圈中举不胜举。变化存在，而开发不响应又何谈为客户投资利益最大化和帮助客户提升竞争优势？在变化出现时，对需求变更做管理是自然必要的，但是不遵循旧计划才是敏捷所倡导的。当需求变化后，大家坐在一起重新审视用户故事，调整后续的迭代和排列product backlog item的优先级，风险共担是解决问题的基础。上面介绍了4个宣言，但注意一下，虽然敏捷倡导宣言左向的价值，但不可忽略右项的重要，流程、文档、合同、计划也是必要的。网上有人发问敏捷要不要写文档的人就走了极端。敏捷还有12条核心原则是对价值观的解释和实践的指导，是敏捷项目得以成功的基石。此处不一一展开原则，举例一下最小工作量原则，原文是：以简洁为本，极力减少不必要的工作量的艺术。它是帮助项目提高效率的指导，以防在开发中画蛇添足的工作浪费项目人员的精力。
敏捷发展到现在有许多流派，他们之间不是明显的分支，而是有共性的。在某石化敏捷项目中借鉴了极限编程XP它其中的tdd。倡导测试先行，每一个开发工程师，都要在提交代码前完成自己的单元测试。虽然编写给这gtest和junit的测试代码会占用开发时间，但每日构建时就能排除低级的错误了。对XP有借鉴的同时也有弃用项。极限编程中提出的结对编程被我主张排除使用，毕竟中国程序员的习惯还是要考虑在内的，否则破坏了团队的氛围有时更为危险。对于scrum的过程管理，在实践时会碰到各种问题，其中有一种较传统的工程师，他不能理解敏捷背后的理念问题，他很机械地执行每日站会，有时无精打采，无话可说，有时又滔滔不绝，超时每人2分钟，他讲4分钟。有一次我们在sprint回顾会议上终于听到了抱怨声音。他认为每日站会是一种监督工作和体罚，怕员工迟到等。这时SM敏捷教练就必须站出来了，于是我开了专题会正面解释。每日站会一般控制在15分钟，每人之所以要回答三个问题：我昨天做了什么，今天要做什么，我需要什么资源。这是在拉平小组内开发情况的信息，信息对称就消除了隐患，及时了解开发速率，就像协调1个车子的4个轮子共同前进。而sprint的评审会，这是将迭代的成果集成，汇总和向客户演示。而sprint的回顾会议更像是对轮子的一种清洁和检修。是要汇总在上一个sprint的过程中出现的制度或团队瓶颈问题，讨论对策和完善规则的。为防止大家对会议多且密有反感，我们在和领导讨论后决定在回顾会议上摆上水果和零食、茶水，这下子让头脑风暴环节的发言率提升了两倍。经过了几次sprint后，大家直接把回顾会议称为了水果会议了。本人作为SM，同时需要考虑到少部分人可能对敏捷知之甚少或没有敏捷团队的经历时，需要慢慢的转变。在实践中，后期加入dev的人员就很难对敏捷的此前细节完全了解。新加入到dev中来，仅简单培训了开发环境就开始干活了。所以，SM要抽时间给他们“补课”。比如，讲解敏捷项目中需求开发中使用3C的标准去采集用户故事，同时用invest来衡量一个好用户故事的标准。在sprint的计划启动会中一般会有两个阶段，第一个阶段解决why。由po来介绍自己排序的pbi，并解释明白哪些是近光灯范围，哪些是远光灯的代办项，所以远光灯暂时并不急于排到下一个sprint的任务中。而第二阶段就需要dev和SM一起研究how。即如何分解任务，如何建立架构模型、算法模型、技术准备等。二阶段时，当对PBI有问题时，可以找来po再解释和协调。在经过了第二阶段后，sprint的计划就会可以输出 sprint待办事件列表了。计划会实现一个由PBI到SBI的分解过程。SBI是sprint backlog item。此时的列表不仅仅是用户故事的分解，还包括许多质量属性（非功能需求的）的或者一些技术工作的任务加入。由于，由于在某石化敏捷项目中开发和交付应用了IBM的RTC协同工具，所以代码管理，定时抽取，每日构建都是自动化的。所以提交sprint的成果并不用占用一条sbi。所以在敏捷方法指导项目开发前需要准备好 devops的工具链，这样能让项目事半功倍。有人把这种技术选型、创建工程、基础设施的准备和自动化部署结合统称为零迭代。有句话说得好，磨刀不误砍柴工。同样在实践时如果估计不出团队的速率，可以牺牲第一次迭代来投石问路，这样为以后准确地制定计划提供了参考。
某石化敏捷项目最终上线受到了客户的好评，帮助了地震数据指导石油勘探方向上许多创新的探索。纵观目前的众多开发方法，能在客户、研发团队和公司管理层之间游刃有余，协调资源到位的方法非敏捷方法不可。在未来也希望更多的项目应用敏捷或借鉴其中优秀的特性，本人仅以个人经历和项目场景为探讨契机，提出观点供大家参考。下面就列出一些文中提到的术语解释。