在去年12月底开始接触高校平台项目，到现在也快有小半年了。这次的开发不同以往。是以敏捷开发作为开发方式。以前都是遵循传统的瀑布模型，而新方式的开发思路直接与传统的开发思路来了个正面碰撞，擦出了阵阵“火花”。
在一开始接触敏捷开发时，有些兴奋，有些期许，但是在真正用来做项目时，由于瀑布模式已经根深蒂固，再加上对需求不熟悉，对开发环境不熟悉，新方式的开发反而让人感到别扭，麻烦，甚至抵触。
由于对敏捷开发的不理解，大家也爆发了很多争论，不过也正是这些争论，引导我们逐步走向了敏捷开发的正途上。
记得当初在做yh收银系统的时候，采用的是传统的瀑布开发模式。自己做需求也是很费力气的，首先整理当前版本的系统功能，收集和整理以往的维护记录，整理客户的建议。然后再加上自己维护过程中发现需要改进的地儿和参考同类软件，历时1周，需求算是基本做出来了，但是还是有很多问题，许多想要的动能，自己也不确定到底是什么样的。以至于到概要设计完成后，发现设计与最终想要的差距太大，最终决定推倒重来，又花费了1周的事件才搞定需求。加上前面浪费的时间，光是做需求，就花费了近一个月的时间了。也就是说这近一个月的时间，小组成员大部分的时间（项目方面的）都荒废掉了的。
设计花费的时间就更多了，我们采用的是三层架构+2层接口+抽象工厂模式，实现差不多都是组长去设计，然后画出时序图来，再安排小组成员去完成。做的过程中发现当初设计有问题，还得推到重新去设计。结果就造成了代码没花太长时间，而反复修改设计和各种文档花费时间太多了。
实现过程看着时序图也不一定可以搞定，而且大家当时的水平也的确有待提高，经常被问题卡住，开发停滞了。没有一个例子做参考，做起来也很费劲。甚至有时候为了完成功能，使用简单的但是不安全的方式实现了，以至于后来得反复修改。
而且开发时间跨度有点大（最终耗时5个月），小组中有抵触情绪蔓延。。。
当然我这里只是说在使用瀑布模式做yh系统时，所遇到的问题，并不是说我们开发的一无是处。相反我们开发突破了以前许多设计枷锁，让我们的系统变得很人性化，当然这不是本次讨论的重点，就不在这里说了。
以上这些问题是有部分是能力所限，但是通过改变开发模式也能解决这些问题。而敏捷开发就是其中一种解决方案。
本次在做高校平台项目时，采用的是Scrum敏捷开发模式，在简单了解了敏捷开发模式后，越发感觉敏捷开发的优势了。瀑布模式是以文档驱动的，而Scrum则是以人为核心，只完成必要的文档即可，它更强调人与人的交流。而且Scrum之所以成为敏捷开发，主要还是因为它能快速响应变化，快速迭代。
按照Scrum的开发流程，建立backlog，列story，在迭代计划会上大家一起评story优先级（跟scrum稍有不同），然后制定迭代计划，并一起对本次迭代任务进行评估工时。用集体的智慧和知识对“做什么，怎么做”打成共识。每个人只专注分配给自己或者自己领取的任务模块即可。每日立会也是一个很不错的了解开发进度的方式。每次做完任务后，都要叫Scrum
Master来检查一遍。而且在迭代中期和末期都有集体审查，在很大程度中减少了系统bug，不至于最后bug遍地，无法集成。
当然在这过程中也会遇到问题，被一些难的问题卡住了，会在立会中提到，如果不是很重要的问题，给2天时间解决，否则放弃这个任务，换另一个人去做。或者采取结对编程，这个的确很有效。在对一个大家都了解都比较少的，或者一些逻辑复杂的问题上，一般采用2种方式。一是2个人同时领取相同的任务，各自做各自的，谁完成了就用谁的。另一种是结对编程，2个人坐在一起来完成一个任务。我更推荐爱你结对编程，它在这些问题上的投入往往是1+1>2的，绝对是一个very
good choice。
本次开发设计到许多陌生的知识，如果单纯的理解起来，比较费力，不过如果有工具辅助就是另一回事儿了。本次管理上的不论是“禅道”还是“JIRA”都是非常值得推荐的项目管理软件。也是通过这两款项目管理软件，才使得我能快速了解和熟悉敏捷开发流程。另一个我觉的非常值得推荐的则是Confluence。Confluence则是一个很不错的Wiki，自我感觉要比使用svn更专业，也更方便。
当然并不是所有的项目都适合用敏捷开发来做，选择哪种开发模式是根据项目而定的。对时效要求比较高的比如互联网产品，比较适合用敏捷开发。而一些大型、超大型的项目如军工、航天的，就不太适合敏捷开发。还是那句话，适合的才是最好的。