部门采用敏捷开发了3个月，这3个月利用敏捷的思想在部门实施了敏捷开发的大部分实践和尝试，这里总结一下这3个月实施敏捷开发的一些工作状况。
1. 整体人员进行敏捷开发培训，在部门内选择不同的人员担任产品负责人（PO）、ScrumMaster；
2. 敏捷团队的人员架构：敏捷团队到底是1个组（20人）好，还是分为多个开发小组（每个组5-8人）好，网上敏捷实施教练各说各的好，没有统一答案，我们尝试过、根据功能模块分为三个小组进行第一期开发、然后第一期开发完成后进行缺陷修复的时候，把团队分为1个大团队；
3. 敏捷开发的周期的时间，尝试过2周和1周一个Sprint周期；
4. 敏捷开发项目管理软件：Excel、RTC 、ScrumWorks 、禅道、白板。最终选定禅道来进行项目管理；
5. 利用Product BackLogs方式进行需求管理，采用故事叙述的方式进行需求描写；
6. 每日早会、工作估算
7. 其他等等
1. 实施敏捷的范围太大：错误的低估了敏捷开发的管理难度，当时我们认为相对与整个公司来说，部门20几个人实施敏捷开发已经是很小的一部分，我们没有敏捷教练、公司没有敏捷实施经验的人、所有的尝试都是摸着石头过河，导致实施敏捷过程中很多没有做到位，对整个过程来说效果不好，最直接的影响就是缺陷比较多、加班比较多等；
2. 团队磨合不足：部门刚成立，团队成员彼此之间的相互了解程度与整体磨合还不够，在分为多个小组进行开发时，小组之间的衔接不够好，开发、测试、需求之间的衔接做得不好，以往都是通过详细的需求文档、评审、设计文档进行沟通，忽然之间这些东西都弱化了，导致开发没有按照需求的设计开发、需求变更或通知不及时、需求没有验证开发产品、测试摸不着路。
3. 个人素质：敏捷开发要求人员的素质非常高，假如团队内有10个人，9个人很努力，但是有1个不努力然后又拿着同样的待遇，这个团队的生产效率绝对不会是90%，团队目前的大部分成员都没有达到敏捷开发所需要的素质；
4. 绩效管理：在实施敏捷开发中，个人绩效怎样和团队贡献结合，缺少针对团队绩效考核机制和细则，对团队考核机制实施的经验不足，带来的激励也不足。
5. 需求的管理：需求缺少一个总体的产品负责人对整个产品的需求从版本、整体需求管理进行把控，组内需求人员不足，更多的是UI人员充当需求的角色，出现的问题主要是在沟通的环节，需求的变更不能有效的通知到开发等我难题。
6. 开发：开发过程中首先犯的一个错误就是完美主义，开发这边在架构上花费的时间较多，导致很多重复工作，我们的架构尽量的简单，应该尽早进入开发，尽早的交付工作成果、通过不断的重构进行完善架构，我们想先把架构做得完美，做了很多现在还用不着的。
1. 敏捷开发中，发现了能够适合敏捷开发人员，这些人都能积极的沟通、发现问题、主动帮助部门成员。
2. 原型工作方式、在这3个月之中，我们不断的尝试怎样利用较好的原型方式加快开发和减少沟通的成本。
3. 部门内部的气氛较好，相互之间的沟通、帮助比之前好了非常多。
4. 沟通意识的提高、例如每日晨会（5-10分钟）的方式，这个习惯一直保持，养成了在团队内部能够快速响应，现在慢慢养成了一种比较好的快速沟通方式。
5. 部门内核心人员的素质提高、虽然敏捷开发过程中遇到了非常多的困难，但是部门核心人员之间能够主动提出问题、一起讨论和沟通、及时把偏差的问题纠正，在政民通第一期结束后，发现缺陷和问题较多，马上根据数据进行问题总结，提出解决了方案。
1. 绩效考核：目前公司的绩效制度与敏捷开发的有一定冲突，公司的考核制度更注重考核个人，并不是说用来敏捷开发就不考核个人，而是选择了敏捷开发，就意味着需要选择比考核个人更有效的提升绩效的方法。敏捷开发更注重考核团队，敏捷开发对于提升绩效的主要机制：不是依靠一个有强大控制能力的领导或一个固定的流程，而是一种能自我适应和改进的机制，进而让团队进入自组织状态，以自己的方法解决问题。
2. 激励机制：移动互联网人员工作需要很多外部的激励，如：工作成就感、晋升机会、较好的工作环境、他们天生需要很好的激励机制，但是对于我们公司目前的状况和所做开发的项目对于开发人员来说成就感不高，所以我们需要在做我们自己的项目之余努力寻找能够找到一些公众项目，然后利用20%的资源进行开发，建立更为有效的激励措施和机制实行。
3. 从前2个月来看，不适应全范围内实施敏捷开发，可以精选少部分人员进行创新型新产品开发（1-3个月的产品），如我们后期要做的几个项目；
4. 后期的社区类产品的开发，不能走敏捷开发的老路， 需要把CMMI和敏开发结合，敏捷开发中确实有一部分能够加快开发效率，比如原型工作方式、晨会、Sprint周期等。可以把CMMI进行裁剪适合移动应用开发的流程模式