我在ThoughtWorks中的敏捷实践

此文章同时发表于InfoQ

项目回顾

项目背景

E项目是一个在线的物资跟踪监控系统。由ThoughtWorks团队为客户提供的一套完善的软件交付服务。

该系统为资助物资的跟踪与监控提供了完整的网络解决方案。整个流程涵盖了客户对物资来源的管控、库存管理、物资下发与跟踪、客户与IP(Implementing Partner，合作伙伴)的协作沟通、IP对运输结果的反馈(生成报告，警告通知，短信互动，邮件通知)，以及IP对物资的二次分发后的记录跟踪与监控。

该项目属于海外独立交付项目，整个开发过程由ThoughtWorks团队负责管理。好了，项目信息只能透漏这么多了，不然客户要找我打官司了。

---

成员背景

ThoughtWorks提供完整的交付团队(PM, BA, TL, QA, DEV, UX)，团队为颇具代表性的敏捷团队，规模10人左右。客户团队主要接口人3位。

ThoughtWorks团队成员，犹如一架生猛的战斗机：PM英文一流，敏捷开发管理相当到位，因为看了上万本脑残小说，时不时就用到了生活中来。TL拥有7年以上的开发经验，7年之痒，什么，不用说都懂的。TL还富有学习激情和被黑精神，黑历史墙列满了他的关辉血泪史。QA被誉为IT界的福尔摩斯，DEV都休想逃过她敏锐的鼻子（怎么是鼻子呢？太陶醉了吧，这是境界！），最后，就是'苦逼'的DEV，也就是以程序员自居的我们。

我们每个人特点各不相同，但有一点神似：专业，责任心，追求卓越

我们团队还有一个workout的文化特色，向⬇️看：

PS：我们的workout自开始之日到项目交付之期，不曾落下过一天，且收到良好的反馈。即便团队成员分开了，每个人都能将运动精神传播下去，乃至源远流长…

---

技术背景

我们是一个全功能团队，人人身怀敏捷开发领域的知识和技能，且有一定的经验积累，所以可以说我们天生敏捷，在开发过程中大家都能高效地分工合作。

再说技术栈，项目使用的主要技术栈是Python, Django, AngularJs, PostgresSQL, Docker。而我们DEV在进入这个项目之前，擅长的技术栈是Java, Springboot, C#, Android, jQuery。

---

敏捷实践

项目之所以成功交付，核心在于人，而良好的敏捷流程与实践也是不容忽视的。

早在2001年，17位追求卓越的志愿者聚集在美国犹他州雪鸟独家圣地，讨论一个新的软件开发趋势，它被称作轻量型软件开发过程，后来他们将它定义为敏捷，并且发布了敏捷开发宣言：一种把以人为本、团队合作、快速响应变化和可工作的软件作为宗旨的开发方法。敏捷宣言可以总结为四句话：

个体与交互    优于  流程与工具
客户协作     优于  合同谈判
响应变化     优于  遵循计划
可工作的软件  优于  面面俱到的文档

也就是说，尽管右项有其价值，我们更重视左项的价值。

敏捷开发的核心就是在一个高度协作的环境下，不断的通过反馈来进行自我调整和完善。重点强调的是协作和反馈，协作体现在团队与客户之间的协作，团队成员之间的协作。反馈则是在开发中的任何环节，包括代码质量、自动化测试、部署、项目进度、需求变更、客户验收等，而且反馈越快越好。有句土耳其谚语这么讲的："不管你走了多远，错了就要重新返回"，所以我们越快得到反馈，就能越早确认自己有没有走错路。如果没有错，我们会更加充满信心。反之，及时做出调整，让浪费最小化。

项目中所涉及的敏捷实践主要围绕迭代进行，用一张图概括：

可以总结出以下几点：

• Iteration通常始于IPM ，止于Showcase。
• 每天都会发生事件有Standup 。
• Pair、TDD、Code Review穿插在日常Coding中。
• Story kick-off之后，该Story就进入了开发环节。
• CI属于基础设施，通常在一个名为Iteration0的迭代完成，也就是正是开发开始之前就应该完成CI的搭建。
• Retro较长一段时间才进行的活动，根据实际情况，1个月或两个月举行一次。
• Regular catch up with client也会因项目而异，Daily或者Weekly，甚至某些项目可以省略该项活动。

敏捷的宗旨是减少浪费，所有的敏捷实践也都是围绕着高效协作与快速反馈这两个核心理念展开。

---

IPM

IPM(Iteration Plan Meeting)，迭代计划会议主要是跟客户保持沟通与信息更新的一个会议。

敏捷宣言里面有一条：客户协作优于合同谈判。在Scrum团队中有一个角色叫做产品负责人，Ta的核心职责是确保业务需求的清晰和透明，保证开发团队对业务有足够的了解，并将这些待完成的业务需求（Story）按照优先级排列出来，按照任务卡的方式来驱动团队的开发。并在客户需求有变更后能够第一时间告知团队以做出调整。

在我们团队中，这个角色就是一开始提到的BA。她是IPM主要参与人，另外还有Tech Lead会一起参与讨论（团队中每一个人成员都是可以参与进来的）。IPM按照团队指定的迭代的周期，通常是两周，每隔两周跟客户接口人一起约一个时间，主要讨论以下几个方面的内容：

• 下一个迭代的Story。
• 对下一个迭代的期望。
• 团队的人员可用性。
• 风险的评估总结。

通过这种会议，能够让客户对我们团队状况有一个清晰的了解，而且客户对我们下一个迭代要做的功能有了整体的把控，一起设定好期望，这样也会大大降低风险。

IPM的主要产出是下一个迭代中完成的Story，这些Story即为下一个Story要完成的目标，我们通过敏捷看板工具来管理它们，例如下图