我在ThoughtWorks中的敏捷实践

我在ThoughtWorks中的敏捷实践

项目回顾

项目背景

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

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

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

成员背景

ThoughtWorks提供完整的交付团队(

PM

, 

BA

, 

TL

, 

QA

, 

DEV

)，团队为颇具代表性的敏捷团队，规模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

。每个人在上这个项目之前都是

python

盲。所以我们是在没有任何

Python

编程语言背景下介入，另外因为从其他团队接手过来要立即继续开发（实际上是为前一个团队填坑，或者是救火）。我们的

技术

和

业务

扫盲期很短，这极大地体现了团队成员的学习能力，而我的周末和晚上几乎用来啃书和Coding了。

敏捷实践

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

早在2001年，17位追求卓越的志愿者聚集在美国犹他州雪鸟独家圣地，讨论一个新的软件开发趋势，它被称作

轻量型软件开发过程

，后来他们将它定义为

敏捷

，并且发布了敏捷开发宣言：

一种把一人为本、团队合作、快速响应变化和可工作的软件作为宗旨的开发方法

。敏捷宣言可以总结为四句话：

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

1
2
3
4
1
2
3
4

敏捷开发的核心就是

在一个高度协作的环境下，不断的通过反馈来进行自我调整和完善

。重点强调的是

协作

和

反馈

，协作体现在团队与客户之间的协作，团队成员之间的协作。反馈则是在开发中的任何环节，包括代码质量、自动化测试、部署、项目进度、需求变更、客户验收等，而且反馈越快越好。有句土耳其谚语这么讲的：

"不管你走了多远，错了就要重新返回"

，所以我们越快得到反馈，就能越早确认自己有没有走错路。如果没有错，我们会更加充满信心。反之，及时做出调整，让成本最小化。

我们是一群快乐的逗比，快乐的人做出来的事情也是让人快乐的。逗比们聚集在一起，探讨出一套适合于逗比团队的敏捷开发流程，每个人都愿意遵守并维护这个工作流程，并且在流程中不断追求最佳的实践，来保证我们的项目的交付进度和软件的质量。

项目中实践主要有
IPM
Regular catch up with client
Story kick-off
Showcase
Standup
Pair
TDD
Code Review
CI
Retro

逗比团队的实践也都是围绕着

协作

与

反馈

展开。

IPM

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

敏捷宣言里面有一条：

客户协作优于合同谈判

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

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

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

1
2
3
4
1
2
3
4

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

Regular catch up with client

跟客户建立信任关系是基础条件，而让客户保持愉悦，也是项目成功交付的助推剂。

客户是位于非洲东部乌干达的子民，5个小时的时差没有造成太大的沟通障碍，他们也没有参与到我们Standup中来。所以我们团队在与客户沟通上处理两周一次IPM和Showcase，增加里一个每天的Catch
up环节，在客户上班后的固定时间一起开个小会，会议时间跟Standup差不多，主要涉及内容有：

1. 我们团队昨天的更新.
2. 客户昨天的更新
3. 确认Story。如果有变更，能及时作出调整。
4. 提醒客户使用我们开发出来的功能，以便我们尽早得到反馈。
5. 一些节日的问候，嘘寒问暖，表达我们团队的关怀。

1
2
3
4
5
1
2
3
4
5

所有这些都是让客户有非常强烈的参与感，以及让他们对项目整个进展的把控（他们会觉得自己才是项目的主导者），增强他们的信心以及对我们的信任。另外让客自己己决定功能实现以及及时验收功能，这样也降低了需求变更和打回的风险。最后一条，则是润滑剂了，能够在客户良好的信任的基础上，保持合作关系的轻松愉快，这会为项目的成功交付使上劲。

并不是每一个项目都会有这个实践，有些独立交付的项目，他们每日站会的时候客户也会参与进来，就不需要额外单独的时间去做这件事情了，而有些项目，因为特殊性，客户可能不希望这么频繁的Catch up，这时候需要团队灵活变通，与客户一起商讨出一个合适的时间周期，做出一些权衡，让客户自身觉得舒服。总之，Keep住的一点是：

保持跟客户的信息沟通，尽可能早的得到客户的反馈，保持良好的客户关系

Story kick-off

在一个Story开始前，确保

BA

, 

QA

, 

DEV

对Story的理解达成一致，并严格按照

AC

来验收。当然，前提是Story本身是不容置疑的。

所以在Story kick off的时候，通常是三个角色一起参与：BA、QA以及要开发该Story的DEV。Story卡是BA预先写好的，通过专业的敏捷开发管理工具进行管理。DEV在kick off的时候，BA会给DEV讲解这个Story要完成的功能，以及它的AC。DEV如果对其中的描述有任何疑惑，需要及时提出来，当场弄明白才可以正确的去完成这些功能。在后续的开发过程中，如果碰到任何疑惑，随时找BA或者QA了解清楚，不应该自己猜测着开发，更不可跟着心走，因为在我们DEV界中，有一句邪门的定律：

猜出来的需求往往是不靠谱的，最终需要打回重做！

Story kick off的核心目的是确保DEV开发出的功能都是符合客户期望的。而Story本身描述错误并不在我说的范围内，我们在开发过程中，也未发生过这种情况，只是有时候客户的需求变更后，Story卡也会及时变更过来。对于Story kick off，我总结出了一些实践：

1. DEV自己先完整地过一遍Story的描述。
2. DEV给BA和QA去讲这个Story的功能以及AC。
3. 要能够清晰的讲出来，并且三者达成一致，如果有疑惑，当场要得到答案并弄明白。
4. DEV开始开发Story，并自行将Story参照AC拆分成很多个子任务列表，然后一个一个干掉他们。

1
2
3
4
1
2
3
4

最后一个实践严格上讲不是kick off环节里面的，它发生在kick off后，DEV采取自己怎么去完成功能。我比较推荐DEV在kick off后将Story划分成子任务列表，按照依赖关系和优先级排序，逐个干掉他们。一些敏捷管理工具(Trello, mingle, Pivotal
Tracker, teambition)都支持这种任务拆分，你还可以很容易的记录与跟踪。我个人很喜欢这么做，这个过程不断锻炼了我拆分任务的技能，最值得一提的是当我将任务列表最后一个勾上的时候，我重重的呼出一口气：哈，我又完成了一个Story。轻松加愉快