快速迭代只是表象, 不断完善才是王道

之前在的公司做智能硬件，软件团队采用敏捷方式运作，硬件团队采用传统的流程来。
领导的意思是硬件团队需要保持稳定，不需要快速迭代。
但是敏捷真的只能用于软件项目么？当然是不。

敏捷并不是简单的将大的项目周期拆解成小周期，敏捷的本质应该是一个不断迭代的过程。在一个一个sprint的过程中，让产品一点一点地持续改进。
只是在我们的使用过程中，很多时候片面地将敏捷理解为一定要快速迭代。如果没有能够在1~2周内发版本就一定不是敏捷。
经过这几年在各式各样的所谓敏捷团队中担任开发或者SM，个人觉得，目前在国内这个大环境下，完全套用所谓的scrum纯属乱扯，学习敏捷里面适合自己的那部分，并且用到自己的项目中才是真正的“敏捷”。使用敏捷模式运作，不一定要很快速的迭代，需要做的是在一个尽可能短的周期内，发布一个可以被测试且能够被进一步完善的产品，这个才是我们真正应该达到的目标。

传统团队转型

传统团队转型过程中，很多时候都是领导在转型，团队成员只是感觉到现在一个需求的交付周期变短了，很多的转型团队成员都没有感受到敏捷带来的好处，只是觉得加班多了。以前和不少地团队成员都有聊过，大部分感觉敏捷就是加班，时间紧。
团队转型使用敏捷，个人觉得一定不能停留在领导转型的层面，要做转型的不是领导，而是团队。需要一个有经验的SM来带领大家，让整个团队拥有敏捷的思维。在大的环境下让整个团队拥有敏捷的思想。这样，才真正能做到团队的转型。

团队中的人

最后这一点是我最想说的，这里的人我们暂且狭义地指代为开发人员。团队开发人员的个人能力决定了这个团队的敏捷是否能够真正地实施下去。开发人员对敏捷的认识、对工作的态度、以及性格、编码能力这些都不断在影响着敏捷工作的推进。
比如大部分的开发人员在和产品经历交接需求的时候，对需求不求甚解，认为需求都很简单，到时候很快就能开发完。但是到了拆分task的时候，发现不知道要怎么写，甚至把story拆分成“需求分析”、“代码编写”、“功能自测”、“提交测试”之类的固定task。在这个过程中没有做到对需求的充分理解，导致所谓的需求分析稀里糊涂地变成了“已完成”，大部分的时间都浪费在了代码编写和功能测试阶段，更有甚者会出现写着写着发现不知道要写什么了。然后回过头再联系产品经理讨论需求，浪费时间，增大团队成本。

而且，团队中人员参差不齐，有的人连Git分支都玩不转，却不愿意学习，仍然用以前svn的思路去搞，过一段时间就会各种冲突，然后备份本地代码，重新git clone一份代码，一点一点合进去，然后周而复始。

归根到底，个人觉得敏捷运作其实就是在考验这个团队里面的人，如果人人都能很好地理解敏捷思想，并且拥有强大的工作能力，那敏捷必然能够带来很大的效率提升。