[敏捷开发] 敏捷开发在团队落地的总结反思及改进建议

敏捷开发] 敏捷开发在团队落地的总结反思及改进建议"/>

[敏捷开发] 敏捷开发在团队落地的总结反思及改进建议

以前，当讲到我们团队采用敏捷开发进行APP迭代的时候，我会把“敏捷”二字打上引号。但是最近总结、反思、参加TAPD分享会、公司组织的敏捷培训以及系统的学习了敏捷的理论知识后，我觉得应该把这个引号给去掉。
本文将从 什么是敏捷、待优化的地方及建议 及 总结 三个方向阐述。

什么是敏捷，我们敏捷吗？

个人认为，敏捷的核心就是：“小步快走、迭代优化”。
“小”：指Stroy要小、落地开发的Task要小，要可独立提测。这个APP团队逐步做到了。
“快”：当落地开发的Task足够小，对于整体工作的评估会更加准确，团队对于需求的考虑会更充分，需求变更的可能性会更小，当开发的兄弟专注于开发的时候，快是水到渠成的结果。这个我们有一定进步，但是没有找到方法去衡量速度。
“迭代优化”：这个是核心中的核心，一直抱着优化的心态对待迭代制度、对待我们的产品、对待我们的代码。。。我们的迭代由两周优化调整成为三周；我们通过持续沟通，需求变更的频率有所减少；开发基本每个迭代都有优化重构的任务规划落地；晨会效果不是很理想，但一直在调整优化方案。。。经过17及18年的持续优化，我们迭代的可控性、可预期性是有很大进步的，开发对于18年迭代的满意度是比17年更高的（没有跟产品、设计聊过这个话题）。
综上，我认为我们是在落实敏捷开发的。
是，并不代表好，实际上我们有很多地方需要提升，且提升空间非常大。其主要原因在于，大家对于敏捷的理论并没有深入系统的学习，对于其背后的本质更没有了解。

待优化的地方及优化建议

团队互信、团队负责

• 问题
  当产品、设计不完善、或者产品、设计发生变更的时候，开发的兄弟往往会抱怨PM、设计师的输出质量差，PM、设计师也会质疑开发的开发效率、开发质量。
• 目标
  产品、设计有问题的时候，开发应该主动去帮忙完善，提建议，一起提高产品、设计的质量；PM、设计师觉得开发效率低、质量差的时候，需要的是帮忙一起分析࿰