1. 技术团队的开发速度
技术团队的开发速度受制于各种因素的影响，这里我只是分享下我自己想到的一些方法，这些也许能够帮助到你，切勿照搬照抄，团队不同方式不同，也不要把之前公司的工作模式带到新的公司来，每次开发周期结束后，能够定期的复盘和思考之前的问题，才能总结出最合适的方法。
- 敏捷开发，缩短迭代周期，让员工推动工作
这里我强烈推荐吸纳一些「敏捷开发」的方法论，让员工自己去推动工作，而不是工作推动员工，这个是非常大的改变，对于开发团队有质的变化。
很多人提到「敏捷开发」第一反应就是加班，我觉得可能是走入了一些误区，或者是团队 Leader 打着敏捷的旗号让他们加班，告诉他们敏捷就是这样的，我觉得这是非常值得痛恨的。
「敏捷开发」只是个方法论，只是指导团队如何更好的做出软件，但实际还需要人的执行和部署，为什么逐渐演变成了「加班论」了，我觉得和领导应该负有直接责任。
工欲善其事，必先利其器，在开始制定具体的计划方法前，需要选择一些趁手的工具，不过我觉得能够提供看板模式或 Todo 模式的管理工具都可以的，比如 Trello、Basecamp、Tower 和 Teambition 等，这些都是有丰富的功能，不过我个人最常用的是 Trello，功能主要是围绕看板来进行，上手简单和快速。
- 缩短迭代周期
我觉得这个是非常必要的，但是缩短迭代周期不是让大家在迭代内狠加班赶进度，而是寻找出团队的正常速度，且制定出适合在一个较短迭代的周期内可正常完成的工作量。
如果说原来制定一个月的工作内容，迭代周期一个月，我觉得可以全部缩短成两周，这种好处在于可以给团队一个不断交付的任务，这种情况下会让人觉得团队总是在产出，而且可以在这中间出现需求问题时及时调整，而不是在一个月后发现问题，完成度很高的情况下又退回去修改。
迭代周期短了后，可以给已经完成该迭代内的人员分配新的任务，而一个月的迭代周期可能出现人员早早完成任务，但是新的迭代没开始的而手头没有事情可做的空档期。
面对这种情况在迭代内直接加任务是非常不可取的，因为无法保证旧的任务会完美上线，若遇到旧的返工，新的刚开始几天，这种情况抛弃新的，等下个人来接手，可能会出现其他问题，新的功能开发前还是需要一个合理的评估的，单人直接上手可能会受制于个人实力问题无法找出最优解，最终在系统中遗留下一个非常大的坑等后人填满。
- 让员工推动工作
这是看板模式下一个非常好执行的策略，在传统的瀑布流工作方式中，大家在开始时候都定好了属于自己的任务，这种是任务推动员工，大家做完了就可以休息了，等着新的任务指派，在工作中处于被动式。
如何让员工推动工作？其实主要是建立 Trello 上的卡时候，把任务创建的较为单一些，每个卡都是个人可以独立完成的，谁现在有空，谁就去拿一张卡开始做。
比如有「待开发」，「开发中」，「待 QA 检查」，「完成」四个列，若有人将卡移动到「完成」后，只要「待开发」中有卡，那么他就可以挑选一张开始进行，将卡移动到「开发中」，感觉有点像流水线上的工人，不过大概是如此了，这样就是员工自己在推动工作了。
有人说过「敏捷开发」就是榨干每一位程序员的血，会保证每一位员工永远有事情可做，而不是在做完手头的事情后就等待吩咐了，虽然说起来有点残忍，但是实际情况并不会这么惨烈的。
因为大家在 QA 检查到完成阶段是可以休息的，实际工作中，完成一张卡可能也需要数天，并不是无止境的干活，所以对于大家来说，其实就每天有点事情做，并没有把人当作机器。
只是这种开发模式，能够让大家在没事的时候主动去做，那么是不是谁先选走好做的卡谁就比较轻松？其实是的=w=
我说的这些只是「敏捷开发」中一些思想，并不代表「敏捷开发」的全部，我只是用自己的方式实践了一些，希望对你有帮助，也欢迎讨论。