年终总结-敏捷开发实操

年终总结-敏捷开发

又是一年春来到，22年终归还是过去了，疫情也退出了舞台，回首望去，这一年也是有苦有甜，报喜不报忧，只记录一下好的吧，这年初上了课做了敏捷培训，同时也终于有机会将理论东西变现了，此文只是记录一下在开发和带队过程中的一些感悟。

 

什么是敏捷开发

敏捷开发(Agile Development)是一种以人为核心、迭代、循序渐进的开发方法。

通俗点理解就是边做边聊，使客户和开发始终保持在一个频道上。和传统的开发方式比更能适应需求的变化，本质上就是未雨绸缪。
举个去饭店吃饭的例子：传统的开发方式是客户进入饭店点菜后，厨房将全部的饭菜做完后统一上桌，而敏捷开发的特点是加强了和客户的沟通，厨房先做两个菜直接上桌，然后服务员会来询问客户是否满意是淡了咸了辣了还是酸了，后续的菜，厨房可以根据客户的口味进行调整，如果客户吃饱了，后续的不要了，厨房就会及时停止，不会出来多余的菜，厨房做了而客户却不需要并不想为之付钱，服务员的频繁露脸沟通也会极大的提升客户的好感，和被重视程度。

所以相比传统的开发过程中，“服务员”这个角色不再是只负责点菜的人，兼顾客户和开发之间的沟通变得尤为重要！

需求在开发中的作用
需求是软件开发过程的方向标和指南针。
传统的开发强调初期的需求调研及需要分析，这个过程对于一些正规的团队会产生大量的文档，而后交由开发展开产品生产。
然而，事实却不是想象这么简单，无数的例子说明了一点，仅仅在需求调研过程中了解到的需求是无法保证的。数不清的例子告诉我们，需求是会变的，变的原因很多。在极端的情况下，有些客户签字的需求在开发完后，有需要变更也很正常。

所以需求是影响软件开发的第一重要因素，需求来源于业务，我们开发的产品不就是因为这些业务才去做的吗？如何需求都无法把握好，还谈什么开发出好用的产品？

敏捷的特点是经验丰富的大哥，将需求分类，主线任务，支线任务，成就任务，，，按照优先级来决定每一阶段的工作内容，将全部的功能拆分到每次的迭代中去。

文档在开发中的作用

一些相对不成熟的团队，对敏捷开发的一个重大误区就是忽略的文档的重要性，通过每次的迭代计划代替业务文档。
在很多传统开发方法中，特别是很多很正规的开发团队对文档的要求非常苛刻。然而事实是文档不易管理，最痛苦的是不好维护，文档需要随着变化而变化，比如需求调整、技术架构升级、产品维护等等。如果要保证文档的一致性，太难了，没做过对日，但听闻对日的项目对文档的维护堪比疯魔的状态。
而敏捷开发并非抛弃文档。只是更强调更有效的方式使用和维护文档，先搭骨骼再填肉，之前就看过一句话，程序员最烦的两件事，别人不写文档，和自己写文档。而我目前的实践经验来看，文档才是根本，有了文档，甚至成员都有了被替换的操作空间，于是有些人就通过垃圾的编码风格和看不过眼的code来保住自己的饭碗，回到正题，，，我会在每一次为客户迭代demo结束后，员工稍稍放松的时候，要求他们完成文档的整理，在过程中也会对上次迭代过程中不好的地方进行反思。

团队协作

这是一个大的命题，从人员构成到人员安排，甚至小团队的中的“结构”。
以下都是我自己的发现和感悟！！！不绝对嗷

1.开发不够重视测试，用轻视这个词不好但是确实看不起，，，
听过太多次，那个傻逼的故事了，作为一个team leader首先要做的就是扭转或者掩饰开发的这种思想。
谈话第一步：你开发工资比测试高，你确实比他强，所以需要你向下兼容，如果无法兼容，那就自己开发加测试，出问题了自己背锅。----------肯定开发的价值，述说利弊
第二步：她确实啥也不懂，但公司就需要他啥也不懂，这样才能贴近用户，你无法保证不会遇到奇葩客户给你玩出东安点新花样，他们代表的是用户群体。---------肯定测试的价值
第三步：与人合作，这个是一个开发的基本要求，开发是智商，而合作共赢是情商，双商都在线，那就能升级了----------------大饼
第四步：如果你们还是这种状态，两位就要考虑找下家了。------------------警告
都说先打一棒子再给个枣，为什么这里先给枣再打棒子，原因就是，能出现无法掩饰的矛盾的时候，就证明这两个在工作能力或者人情世故中存在比较大的缺陷，都应该是被添加到裁员名单里的人，不会对他们抱有期望，警告留到最后是为了将来更好的开除他们。

 

2.减少对开发的干扰
干扰因素太多了 生活不顺，感情不顺，职场不顺，一个好的leader，更多的是一个好的倾听者（他的不顺，我又改变不了，只能听了）
在工作中发现很多年纪大一些的管理者习惯了高高在上，今天人家分了手，晚上要他加班到10点，第二天被打了，宣扬人家没有教养。
我理解 leader的绩效来自团队，而团队的绩效来自每一个人，心情舒畅的时候 工作效率就会高，所以 就算为了自己也需要为员工提供一个好的环境。
生活上 任何事情都可以聊，分手了可以找我聊天，再给一天假，有事说清楚，能给假就不会让他们在公司闷着，实验的结果也同样很好，欠下的任务，甚至会自主加班完成，部门效率更高了。
工作上 短期内只完成一个工作，任务的确定性避免重复劳动，每个公司的任务都是有周期的，年限久一些的员工会经历很多项目或者产品，经常这边开发着新的项目，那边又有东西需要维护了，公司要节约成本嘛，这个时候需要leader站出来，协调好时间，多线程其实不适合大多数人！

 

3.leader 要参与到工作中去
来自我领导的建议，既然是做开发的，技术一定要时刻握住，各种技术不一定要精通，但一定要略懂,一个技术的主管一定要多写写代码，参与架构等和项目有关的事情中去，而不是坐在那里嘴一张一合的分个任务。一方面是不会让你的成员产生距离感，把自己放到人群中间去，另一方面则是防止因为不了解，问出一些破坏氛围的蠢问题来： 这么简单的功能，怎么做了这么久。。。其实每天都在加班的同事心里想着：“有本事你来？”，即使这个小组长有这个能力，但对于团队来说也不是一件好事，因为大家都抱有怨恨之心，还谈什么好好工作呢？这个小组长就是失职的甚至是蠢的。

时刻在人群中，把握进度，解决问题才是根本。还有一点需要明确自己的地位，90%的公司提升一个人为leader是作为一个劳模起一个模范带头作用的，在此基础之上精进自己的管理能力，继续向上，自知者明，中国的几千年文华，官本位一直都影响这我们，我也想坐在那指挥，自己啥都不用干，但是不中啊

4.发挥团队人员的潜力

这个标题好开放，但是就敏捷开发相对而言更提倡开发任务由开发自己评估并认领工作任务，这样可以激发开发们的潜力，毕竟是自己选的，责任心要比被动的接受任务高很多。
三十年河东，三十年河西，工作年限不长真的发现的了不少被寄予厚望的人渐渐掉队，“普通人”异军突起的，可能是生活中的一些经历或者小事，人开窍是见很突然的事情。所以在管理过程中不要轻视某一个人，加强沟通了解每个人的特点，将他们放在他们感兴趣的工作中，会好很多，减少指派式的任务分配，发挥个人的主动性，整个团队的干劲个凝聚力更强。


最后总结一下吧，我理解的敏捷开发，不是接受变化，拥抱变化，而是主动的掌握变化，通过大量的沟通及时了解并控制变化，不是任由他们肆意疯长。强调沟通和适应性，对成员也是如此。