敏捷开发—初识庐山真面目

   为期两天的学术交流会议，身体上感觉很累，但是内心却是满满的喜悦。鉴于自己目前的水平，虽然说学术交流会议上能吸收到的并不多，但是起码解决了不怕不知道，就怕不知道的这么一个问题。 

   还记得前段时间在做教务系统的时候，总是开各种各样的会议。有估时会议、每日立会、测试会议等等。当时觉的挺纳闷的，感觉这种方式跟以前很不一样。而且听前辈们说过“敏捷开发”，但是并不了解。在今天会议上，前辈们再一次的给我们揭开了它的神秘面纱。再结合前段时间教务的一小点经历，对敏捷开发有了一个小小的认识。

   敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。在敏捷开发中，软件项目的构建被切分成许多个子项目，各个子项目的成果经过测试，具备集成和可运行的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可用状态。

开发宣言

•  个体交互胜过过程和工具
• 可以工作的软件胜过面面俱到的文档
• 客户合作胜过合同谈判
• 响应变化胜过遵循变化

开发流程

   建立产品功能列表，罗列Story,在迭代计划会上大家根据罗列的story进行优先级评价，然后进行迭代会议，每个迭代会议启动时，所有的团队成员畅所欲言，明确迭代的开发任务，并对任务评估工时。任务的迭代时间一般为一到六周。再每个迭代中，对产品功能进行细化一个个的story。以便准确的估算任务完成时间。每日立会，通常在同一个地方，同一个时间点，所有的团队成员，聚在一起开一个高效率的会议。会议通常控制在15分钟之内。主要是成员汇报自己的开发进度，以及下一步要改进什么，遇到什么问题，但不浪费所有人的时间立刻解决问题，而是会后个别沟通解决。每次做完任务后，都要叫Scrum Master来检查一遍。而且在迭代中期和末期都有集体审查，在很大程度中减少了系统bug。 总结和反思。每个迭代结束以后，项目组成员召开总结会议，总结好的实践和教训，并落实到后续的开发中。

敏捷开发困惑

   1.可工作的软件胜于繁杂的文档

   传统的开发方法，是以文档驱动进行开发。而敏捷开发是面向人而开发。但这并不意味着不写文档。我们这里忽略了”繁杂的“，这也就是我们一个判断的标准。可是什么样的文档是不繁杂的呢？这又是需要我们去思考的。这个标准该怎么衡量，我觉得还是主要是看客户和公司的需要。首先，你开发的软件毕竟基于客户的需求的，但是如果你开发出来的软件，连你最起码的客户都不会使，那这个软件有存在的必要吗？所以用户手册这时候就是必要的文档。 其次，为了公司的可持续发展，一些变更文档还是很有必要的。   

   

   2.代码就是文档

   必要的文档说明，可以增加你代码的可读性。

   引用别人的一段话：编写文档也是我们更好地学习和享受生活的需要。“勤劳的中国人”生怕在工作中空下来，喜欢乐此不疲地重复解答别人所问和身体力行地传授自己所能。难道不能写成文档与人分享，然后空出时间来学习和享受生活？

   3.结对编程

   结对编程是指两个开发人员结对编码。结对编程的好处是：经过两个人讨论后编写的代码比一个人独立完成会更加的完善，一些大的方向不至于出现偏差，一些细节也可以被充分考虑到。但是结对的方式，最好是每个人都有自己的电脑，在必要时候进行结对。 

   总结：敏捷开发是以快速变化的思维来进行开发，其最终目标是让客户满意，所以能主动接受需求变更，则就使设计出来的软件有灵活性，可扩展性。此次在学术交流会议上，针对敏捷开发还进行了一次非常有意义的讨论，将在下一篇博客中进行介绍。