曾经执行了一个时间紧，任务重，需求还不明确的软件项目，利用瀑布型的开发方式是不适合的，不知道怎么处理而差点惊慌失措的时候，憋了两天，设计出一个全新的管理框架，和迭代开发类似，就是项目团队和客户坐在一个屋子里，也别区分太清晰的角色，每个人都开发，每个人都测试，先利用两个两周开发一个核心业务流程和功能模块，让系统运转起来。然后每周根据新的需求，经过评估后认为一周内可以完成后，制作界面级的功能原型并进行确认，然后进行开发和测试，形成一个可以使用的软件，每周五上午向客户演示完成的功能，下午交付一部分可以面向用户使用的功能，如果有问题则放到下一个迭代周期解决。在那段时间里，大家非常高效的合作、工作，效果很好，后来得知这个方法几乎和Scrum方法几乎一摸一样，Scrum的核心就是关注团队互动，经常交付可以使用的软件。
按照现在已知的Scrum敏捷框架进行总结，当时项目过程中，没有产品负责人和敏捷教练的角色，只存在这样的工作，但区分的不是那么清晰。需求不是用用户故事模式进行的，而是传统的需求规格说明书，但设计确实是简化了，利用界面功能原型的方式进行设计。在开发过程中，开发和测试并行执行的不错。Scrum的几种会议也有类似的模式，每周五系统演示交付和新需求确认会，说明已经完成的需求，还有没有完成的需求，像燃尽图一样。周一的原型设计确认和任务部署会，即将任务放到TBD列表中，并说明完成标注，每天的工作完成会和第二天的计划会。总之，真的很神似。项目意想不到的一个结果是，客户积极参与了，验收付款很快。
貌似项目进行的很顺利，在当时项目结束以后进行总结，但这种方法没有被上层经理和公司所认可，所以这种方法没有在公司内被继续推广下去，不过这种方法深深影响了我，以及后来真正学习Scrum敏捷框架的时候，也是非常有收获的。在后来的新公司中，终于使用了Scrum框架，通过快速反馈和持续改进机制的建立，提升了交付效率。但用的不是很多，大多还是传统方法。除了Scrum框架本身，有一些经验是可以借鉴的。
1、适应变化和不确定的风险。对于一个用IT系统实现的一个新业务而言，外部的需求并不是那么清晰，换句话说，大家都没有想好想做什么。往往是客户、用户见到了开发的成果以后，才知道自己想要做什么，虽然不是全盘推翻，但也是略有不同。只有利用敏捷框架才能适应这种变化。
2、短期迭代迅速交付新功能。传统的IT系统交付方式是整个系统都完工了，然后组织培训，交付使用，然后得到了非常多的反馈意见，然后又用很长的开发周期去完善，然后再次交付后，进行验收。有的时候迫于形势，验收后，还得继续完善部分功能。而敏捷方式交付一个功能以后，用户的学习成本很低，举个例子，就几个功能，容易进行学习和反馈。新的功能交付以后也是如此，很快就学习完毕了，即使存在问题，也很快就能更正。不仅是在应用系统的开发中可以利用敏捷框架，做其他的事情也同样，例如在编写大系统的验收报告时，先完成一个框架，每周重点突破编写一部份内容，提交以后让客户先审核，持续接受反馈和改进。
3、团队沟通、共享知识和开发测试工作是交叉的，每个人都可以做所有的工作，即使是产品负责人或敏捷教练，都可以作为用户角色完成一些技术性的工作。采用敏捷框架还需要一些工具的支持，沟通的工具，迭代任务和任务分配、Kanban、自动化测试的工具等。此外，作为敏捷教练更容易的关注小项目组中的每一个人，容易优化开发流程，团队每天在一起，容易让关系更融洽，工作更默契。
我认为思维观念的更新和公司层级的支持是最重要的，也是最不容易做到的，往往是因为这个做不到，而影响到前面三条都无法做到。敏捷框架，不是用一块白板贴若干个即时贴就完成的，也不是平时的坐着开会变成站立开会就可以的，这需要太多的转变，敏捷不是工作快，不是快速开发和交付，而是更好的应对不确定，对不确定的迅速响应和应对。如果做不到思维的转变，敏捷也是空谈。
总之，我认为敏捷框架是容易让人进步的，但没有共同的目标和意识的转变，做起来却是也不容易。
