敏捷认知/感想
1团队建设（团队配置，团队效率）
2产品管理（产品目标，关键结果，如何引导）
3过程管理（发布计划，持续交付）
4工程实践（产品迭代，从0到1）
“小步快跑，快速迭代”这是我们听到的最多的关于敏捷开发的描述，关于个人工作经历中的实践，谈谈我的看法：
- 团队协作
我对于传统开发的认识可能是基于建筑开发，市场调研-经济可行性分析-项目开始-设计规划-承建方建设-监理验收-甲方验收-交付-销售环节，其实软件开发和建筑开发基本思路流程相同，只是所涉及的知识域和具体方法不同而已。而敏捷开发作为IT开发中的一种理念，应该是全员的思想动员，涉及到的业务、运营、产品、设计、开发、测试、运维等所有项目成员，而作为敏捷项目经理，就需要将这种理念传达给项目团队，从需求的收集-规划-开发-测试-验收环节，达成全员的流程认同和工作协同
- 轻流程、重效率
所谓的重实践、轻流程其实更侧重于转型过程中的团队，项目团队在执行过程中有很多的决策环节，传统的项目需要有人拍板或者说是承担责任，高效的团队协作应该是团队对流程已经清楚，每个人在做好自己手上的事情后能快速的移交至下游环节，出现问题团队也能找到问题点并迅速寻求解决方案
- 快速反应
敏捷开发团队更像是特种部队，能随时应对各种变化情况，但着并不代表就可以随意改变需求。所谓的快速反应，是基于瀑布开发的长周期对比而言的。但也要求我们在面对客户需求、开发执行、验收测试、缺陷修复等时能做到快速反应、快速实现
- 全员参与
敏捷的持续应对变化需求特性就要求我们做好沟通，尤其是全员沟通，一方面当期需求有一定变化要及时的通知全员，评审需求变动所带来的项目风险，及时做到全员知晓，全员参与；另一方面，在整个开发周期内，从前期的项目需求收集、需求评审、需求排期、测试验证、上线发布的所有工作细则及项目排期都需要做到全员参与，公共制定，只有在全员认可的情况下，才能减少过程风险
- 张弛有度
敏捷冲刺其实就是把一个大需求分割成若干个可分期实现的小需求集合，在完成每一轮冲刺后需要团队一起回顾上个冲刺后的遗留问题，归纳总结留与下个冲刺排定优先级，尤其是再经历几个连续冲刺后，需要安排一个修复版本，不做新功能开发，一方面是消化连续工作积累下的技术债，另一方面保障团队休息，缓和工作节奏
