敏捷开发流程
敏捷这个词听起来就是反应灵敏迅速而有效，而在软件按工程里，敏捷不同于现有做法之处在于：敏捷的价值观和流程是个人和交流、可用的软件、与客户合作、响应变化，而现有做法的则是流程和工具、完备的文档、为合同谈判、执行原定计划。敏捷的开发原则是尽早并持续交付有价值的软件以满足顾客需求；只有不断关注技术和设计，才能越来越敏捷；只有能自我管理的团队才能创造优秀的架构、需求和设计。.敏捷的流程可以分为以下四步：第一步－找出完成产品需要做的事情；第二步－决定当前的冲刺需要解决的事情，整个产品被划分成几个互相联系的冲刺，产品订单上任务被进一步细化，被分解为以小时为单位，订单上的任务是团队人员根据自己的情况来认领；第三步－冲刺，在冲刺阶段，外部人士不能直接打扰团队成员，一切交流只能通过scrum大师来完成，这一措施较好地平衡了“交流”和“集中注意力”的矛盾，冲刺期间，每日都开个例会，每日例会强迫大家向同伴报告进度，迫使大家把问题摆在明面上，同时启动每日构建，用建民的图表来展现整个项目的进度，图表可以是燃尽图，想象我们把一堆待完成的事完成了，冲刺阶段是时间驱动的，时间一到就结束，这个特点看似不起眼，其实有效地断了各种延期的想法，很棒啊；第四步－得到一个软件的增量版本，发布给用户，并在此基础上又进一步计划增量的新功能和改进。但理论遇上现实或多或少都会出现问题，比如在第一步中我们应该怎样体现各个需求和任务间复杂的依赖关系呢，第二步中成员认领任务不均怎么办呢，第三步中每日例会都是流水账怎么办呢，以及燃尽图只列出任务的数目，无法展示项目的拖延情况；这时就可以有更好的改进了，应该明确定义好一个任务，还应记载完成这个任务还需要多长时间，已经花了多少时间虽然重要，但那不是管家（已经是沉没成本了），关键是我们离目标还有多远。还有燃尽图，书中作者提出了以时间来度量，比如实际剩余时间，预估剩余时间，实际花费时间等。敏捷适用于产品可靠性不高，容忍经常出错，需求经常变化，团队人员数量不多，有资深的程序员带队，公司鼓励变化等情况，而不是必须有较高可靠性、不容许出错的商业情况，也不是要有极高可靠性、精益求精的科学计算、复杂系统的核心组件，这两种应该用计划驱动和形式化的开发方法。
我们团队冲刺就用了敏捷开发的流程，但是自我组织能力不够，往往是大家都完成了自己的任务，但是有人的工作有些落后或者是突然发现还需要去做某项工作没人去做。这时候就需要我们自觉地顶上去。
总结不足之处。大家在这方便都还很稚嫩需要多加练习。