成长伴随迷茫,扛起问题一路前行,念念不忘,必有回响
在敏捷开发方面做了多年的思考,也做了很多的实践,依然困惑重重:
多团队维护一套代码如何保持代码风格
自组织的驱动力究竟来源何方
团队究竟如何组建
把这几个问题的思考记下来,以便后面翻阅。
多团队代码维护
多团队对一套代码进行维护时,总会因为每个团队的要求不一样,导致代码内在质量的逐渐恶化。而对代码洁癖的团队来讲如梗在喉,该如何是好呢?
该问题无解也有解。
说它无解,其一,这跟每个团队看待代码的方式有关,敏捷的目标是多快好省,即使都是敏捷团队,整个实施过程也有很大的差别,何况大家对代码的理解!其二,即使别人写的很烂,那么多任务,其中一个“自以为”代码写得好的团队也忙不过来啊!从此处来看的确很难化解。
凡事无绝对,即使没有化解方法,总有某一些可以曲线救国的方式。
“多快好省”是敏捷的原始驱动力,我们先把“好”拿掉,那是专家级的评价,很难去衡量。所以能做的事情就是先把多、快、省的东西体现出来,这是所有人都认可的事情。
优秀程序员的效率比普通程序员的效率要高很多倍,体现在哪?就体现在同样的时间内能够完成更多的feature,更少的故障!
所以强调优秀代码本身,很难得到一致认可,如果没有优秀的外在表现,谁会去在意你的代码是否clean,架构是否优秀。
因此优秀的代码要体现出优秀的外在表现,当优秀成为一种习惯时,会有人注意到的,此时再拿出来优秀的代码,可能它就是别人必须需要遵循的标准。
此时随着所做守护团队认知水平的统一和提高,才能达到代码统一的可能。
TIPS:
代码质量需要较长的时间周期反馈,使得多团队都高标准难以实现。
团队组建
在团队自组织内驱力问题解答之前,先看看团队的组建,也许内驱力就迎刃而解了。
谈到团队的组建,不得不从团队的目标和团队竞争力来讲了。
团队目标
团队从成立起,就确定了用最优秀的代码,产出最优秀的产品。
实际上优秀的产品在实践中,更多的体现出来故障少,然而故障少其实也可以通过一些流程来做到,例如产品交付的DoD。
实践发现,DoD可以减少故障,但是做不到交付周期的变短。
所以团队目标还是得依靠人和技术来达到。
团队竞争力
团队竞争力就是人才,而程序员本身也需要有研发体验,而研发体验就是团队在人才方面的竞争力。
程序员研发体验不是更快的电脑,更舒服的座位,而是解决问题时被打断的次数有多少和有多快的开发反馈体验,前者代表着有多少自主性,后者是体现着当程序员的成就感。
程序员的大部分时间是工作,幸福感与研发体验强相关。
所以程序员体验优化是一个团队必须考虑的重要问题。
团队能力要求
到此时,敏捷团队的组建就显得比较简单了,只要能够为团队的目标和提高竞争力的做持续贡献的人。
那么问题来了
- 如何减少打断
- 如何快速反馈
如何减少打断
项目的管理会议实际上是有规划的,团队内部的打扰实际上是可控的,但是我们面临着外部来的各种需求、各种临时任务,导致打断变得频繁。
敏捷提倡的是timebox的概念,不希望我们在这段时间内被打扰。迭代的概念就在于这个timebox,你迭代要足够快,你受到的打扰就会降到最低。
例如来了一个临时任务,分析,讨论的过程中,如果能把上一个迭代的任务完成,那么这种打断造成的影响也会降到最低。
为了达到这个目标,就需要需求分析,代码开发能够尽快的完成,测试完成的非常快,这就要求团队的业务分析能力,技术能力,CI能力持续强大才能办到。
如何快速反馈
从需求到用户使用是一个比较长的链条,这里的反馈姑且定义成团队能给的快速反馈吧。
站在开发团队的角度,提交的代码能够快速部署,运行,看到需求的交付到测试部,通过测试部的测试,就算是快速反馈了。
为了能够提高反馈速度,团队级CI的持续运行和自动化用例的部署显得尤其重要。
所以团队的组建就要求能够满足技术,业务,测试,持续集成的人来完成这种事情。
自组织的自驱力
为了达到提升开发人员的研发体验,大家会持续努力的为之奋斗,因为它真的影响到了我们生活的幸福感。
那么努力的方向也就非常明确,别人以月为单位迭代,我们可不可以以周,可不可以以天为单位。
为了达到这个目标,实际上还是会让我们在技术,管理等方面都做到极致。
最后
我们明白所有道理,依然过不好一生
人才是最重要的,我也知道,可我如何找到一个靠谱的人呢?
人才那么贵,不可能挑最贵的,如何破解项目中的人品驱动开发,敬请关注下篇《人才的平台化培养》。