敏捷开发：我在路上

Posted 2020-11-23 sunchong

略有耳闻

行业变化真的很快~思想更新迭代更是应接不暇。

我在最早最早听到敏捷开发的时候是2014年，入行刚刚两年。

犹记得当初领导引出这个话题，大家讨论开来。

“咱们敏捷不起来，那是外国玩的东西”

“敏捷就是快，极限编程，到时候代码都是坑。还得重构”

其实很多对话已经很模糊了。但是整体的氛围就是，想玩会把自己玩死。

当时作为一颗小白菜的我~，完全听不懂他们在讲什么。只能从字面意义去畅想。

敏捷--就是快速的意思呗，快就对了。

极限--是不是就是给你个需求你能超出极限干出来。

这太恐怖了。后面这个话题慢慢就不知不觉中烟消云散

痛苦

对敏捷的认识，我的思想依旧停留在之前的认知。一直没有人讨论，也没有过自己主动补充。

主要原因，周围的人习惯了这种跨度长，按部就班的迭代方式。

即便是有人提出过异议，依旧还是寡不敌众，重回其道。

2017年11月 到 2019年元旦，这是我感触颇深的一段时间。

因为分组原因，起初有一个很不起眼的系统放在了我们组，然后这个系统从无到有，我们进行快速开发上线。直到我一个人维护这个系统两年。

后面因为我还有另外一个重要的工作，使得这两个工作项，在冲突中迭代，在痛苦中来回切换。

其中的痛苦对于没有管理经验的我来说真的是炼狱。

我向管理层提出了我的想法，是不是可以改变一下这种节奏？

通过深思熟虑我从.NET组转到了php组（可以理解为也是技术栈的完全切换），就是我们说的转语言。

但是转过的我，依旧痛苦。需求不断，我依旧使用C#迭代着这个内部系统。

10月份接到一个高层领导们提出很多需求，准备一个大版本迭代。必须在元旦前上线。

首先：

人不够 -- 找外包和我一起来做

时间长 -- 砍掉估时的一半，加班做

资金 -- 外包2人，算是增加了预算

结果可想而知：

好在上线了（元旦加了几天班，一个外包没来，另一个最后一天因为胃不舒服回家了）

我现在想起元旦自己一个人在一个项目群里回复着4~5个测试（系统测试、性能测试），

一个人改着bug，改完bug列表，刷新后马上又多了几个bug的崩溃。

php组的领导也确实帮不上忙，默默陪着我，协调资源和处理其他问题。多亏领导的陪伴，要不我真的能放弃。

这个时候，我的小孩出生也有4个多月了。

那一年的8月，也就是2018年8月，我从老东家离职。

我给我的理由是：离家远，想早点回家看孩子。

这个理由真的很牵强。我真的感觉倦了，感觉无休止地看不到头，感觉自己更加迷茫。

反思

我从上一家公司离职后，到现在一年多。我才慢慢体会到我所说的痛苦都是有原因的，而且完全可以避免和克服。

入职新公司，参与了一个项目，并尝试着管理一个项目。公司有整个项目周期的管理流程。

我从流程中学习如何管理项目。经过一年多的学习和转变，我学习着分析当初我的痛苦。

没有项目管理经验的我

因为我最熟悉代码和业务，所以组织外包分配任务。但是没有经验和想法的我把这个项目管理得一团糟。

我应该可以更加清晰地分配任务，使得任务相对独立。

我也可以更加详细地拆分任务，因为我对逻辑非常熟悉，所以可以将复杂操作拆得更加详细

我在项目中开发，无法脱身，完全可以从上层角度来提前协调资源。

我当时的技术面比较窄，无法从更高的技术角度看代项目。

我知道当时的外包很贵，领导可能出于预算，分析了任务量，确认了2个外包。

整个开发没有层次，测试都在最后一拥而上，我们不得不在群里说着这个功能的实现细节。然后测试再去测试。

对这个项目预估不足

没有预估到这个内部系统如此复杂的业务缠绕

没有预估到这个系统整个迭代如此混乱，没有节奏，没有章法。

心态

一开始我就输了，输在了心态

我总是想着2年的系统没有文档，重构是完不成的。

我总是想着完不成也有理由，因为A,B，C

遇到困难或在极其艰难的时候，没有正面困难的勇气，我选择了抱怨和唉声叹气，我选择了消极应战。对，我的士气确实没有了。

如果

如果，再有如果，我使用一些项目管理的方法和在实践中总结的方法，再次迭代这个项目，那结果会是怎样？

如果我再负责一点，把模块拆开，任务分细，即便是外包来做，也不会被项目吓到？

如果我在开始前，做了详细的项目迭代规划，可以先交付什么，后交付什么，前后没有大的关联。测试资源可以尽早介入。

如果我在开发前，做好风险准备以及应对方案，是不是开发中有时候就不会那么被动？

我总结就是：层次、心性、管理

为什么是这三个词，这也是我觉得我从一个普通程序员转变成初级管理的一个总结。

层次：我当初压根就没有转管理的这根线，所以分析问题都是从自身角度，层次可想而知。

心性：做好了转管理的准备，心性也要做好准备，遇到棘手的问题，客户的催促。我必须放下抱怨、冷静分析选择最合适的解决方案。

管理：我思想和心里都做好了准备，我确实需要一些指导，比如老领导的帮带，一些书籍的阅读。从认知上再次提升

       剩下的就是在实践中不断打磨自己的认知和理解，总结后再尝试。

重新定义自己

2018年8月中旬来到现在的公司，这里我接触了一些项目管理的流程。

我尝试管理项目，我尝试总结问题，我尝试全局分析。

这一年我犯了很多错，回过头发现当初的自己是多么幼稚不堪。

还好，我在同事和领导身上，慢慢学习他们的优点和经验。

如何管理项目、把控流程、协调资源、拆分任务

如何和上级沟通

如何和同事更好协作

如何把自己身上的任务合理分下去，同时关注带的人的成长

比如购销合同一个紧急项目，如何跨部门协调，如何在紧急情况下做出合适的方案并协调资源。

... ...

重新认识敏捷

2019年3月，我们部门来了一个新同事，了解到他之前公司一直是敏捷开发。

我们时不时一起讨论敏捷开发等相关问题。

“我们的任务是尽早持续交付有价值的软件，并让用户满意”

这一敏捷宣言，细细品味，确实蕴藏了巨大的能量。

围绕着这一句话，我们可以想象到很多的方面进行改进，以接近这一宣言。

用户为中心

价值导向

持续集成

优先级

自主管理

协作沟通

以人为本

等......

我们所使用的这些方法和策略，就是在慢慢打造更高效的团队。发挥价值。

发挥价值，然后慢慢改造流程，发挥更大的价值。

就是在一个循环往复中，螺旋上升。

起初会有不适应，因为人都是有惰性的，组织和规范都是有平衡的。

敏捷的这些思想，无时无刻地冲击着这些人性、组织以及规范。

当在坚持实行的过程中，信任他人，成就他人，这样慢慢激发人性的能量。团队收获的是能量，个人收获的是成长。

坚持实行敏捷，是一项艰巨的任务。这需要团队不断磨合，不断找到合适的相处方式，找到每个人的能力成长点，并激发它。

敏捷最终落脚的地方是人，所以如何将敏捷这些思想，灌输给团队。然后沿着方法论尝试、总结、修改、再尝试。

这样的敏捷，我不确定是不是也是敏捷的一种。

总结

不断实践，不断吸收，不断激发，不断优化