敏捷团队的随笔

成长伴随迷茫，扛起问题一路前行，念念不忘，必有回响

在敏捷开发方面做了多年的思考，也做了很多的实践，依然困惑重重：

• 多团队维护一套代码如何保持代码风格

• 自组织的驱动力究竟来源何方

• 团队究竟如何组建

把这几个问题的思考记下来，以便后面翻阅。

多团队代码维护

多团队对一套代码进行维护时，总会因为每个团队的要求不一样，导致代码内在质量的逐渐恶化。而对代码洁癖的团队来讲如梗在喉，该如何是好呢？

该问题无解也有解。

说它无解，其一，这跟每个团队看待代码的方式有关，敏捷的目标是多快好省，即使都是敏捷团队，整个实施过程也有很大的差别，何况大家对代码的理解！其二，即使别人写的很烂，那么多任务，其中一个“自以为”代码写得好的团队也忙不过来啊！从此处来看的确很难化解。

凡事无绝对，即使没有化解方法，总有某一些可以曲线救国的方式。

“多快好省”是敏捷的原始驱动力，我们先把“好”拿掉，那是专家级的评价，很难去衡量。所以能做的事情就是先把多、快、省的东西体现出来，这是所有人都认可的事情。

优秀程序员的效率比普通程序员的效率要高很多倍，体现在哪？就体现在同样的时间内能够完成更多的feature，更少的故障！

所以强调优秀代码本身，很难得到一致认可，如果没有优秀的外在表现，谁会去在意你的代码是否clean，架构是否优秀。

因此优秀的代码要体现出优秀的外在表现，当优秀成为一种习惯时，会有人注意到的，此时再拿出来优秀的代码，可能它就是别人必须需要遵循的标准。

此时随着所做守护团队认知水平的统一和提高，才能达到代码统一的可能。

TIPS：
代码质量需要较长的时间周期反馈，使得多团队都高标准难以实现。

团队组建

在团队自组织内驱力问题解答之前，先看看团队的组建，也许内驱力就迎刃而解了。

谈到团队的组建，不得不从团队的目标和团队竞争力来讲了。

团队目标

团队从成立起，就确定了用最优秀的代码，产出最优秀的产品。

实际上优秀的产品在实践中，更多的体现出来故障少，然而故障少其实也可以通过一些流程来做到，例如产品交付的DoD。

实践发现，DoD可以减少故障，但是做不到交付周期的变短。

所以团队目标还是得依靠人和技术来达到。

团队竞争力

团队竞争力就是人才，而程序员本身也需要有研发体验，而研发体验就是团队在人才方面的竞争力。

程序员研发体验不是更快的电脑，更舒服的座位，而是解决问题时被打断的次数有多少和有多快的开发反馈体验，前者代表着有多少自主性，后者是体现着当程序员的成就感。

程序员的大部分时间是工作，幸福感与研发体验强相关。

所以程序员体验优化是一个团队必须考虑的重要问题。

团队能力要求

到此时，敏捷团队的组建就显得比较简单了，只要能够为团队的目标和提高竞争力的做持续贡献的人。

那么问题来了

• 如何减少打断
• 如何快速反馈

如何减少打断

项目的管理会议实际上是有规划的，团队内部的打扰实际上是可控的，但是我们面临着外部来的各种需求、各种临时任务，导致打断变得频繁。

敏捷提倡的是timebox的概念，不希望我们在这段时间内被打扰。迭代的概念就在于这个timebox，你迭代要足够快，你受到的打扰就会降到最低。

例如来了一个临时任务，分析，讨论的过程中，如果能把上一个迭代的任务完成，那么这种打断造成的影响也会降到最低。

为了达到这个目标，就需要需求分析，代码开发能够尽快的完成，测试完成的非常快，这就要求团队的业务分析能力，技术能力，CI能力持续强大才能办到。

如何快速反馈

从需求到用户使用是一个比较长的链条，这里的反馈姑且定义成团队能给的快速反馈吧。

站在开发团队的角度，提交的代码能够快速部署，运行，看到需求的交付到测试部，通过测试部的测试，就算是快速反馈了。

为了能够提高反馈速度，团队级CI的持续运行和自动化用例的部署显得尤其重要。

所以团队的组建就要求能够满足技术，业务，测试，持续集成的人来完成这种事情。

自组织的自驱力

为了达到提升开发人员的研发体验，大家会持续努力的为之奋斗，因为它真的影响到了我们生活的幸福感。

那么努力的方向也就非常明确，别人以月为单位迭代，我们可不可以以周，可不可以以天为单位。

为了达到这个目标，实际上还是会让我们在技术，管理等方面都做到极致。

最后

我们明白所有道理，依然过不好一生

人才是最重要的，我也知道，可我如何找到一个靠谱的人呢？

人才那么贵，不可能挑最贵的，如何破解项目中的人品驱动开发，敬请关注下篇《人才的平台化培养》。