灯火阑珊处——Agile

虽然已经走出了校园，离开了导师的团队，但心底总有那么一个东西在隐隐作祟。

起源：

        研究生的生活着实充满了挑战，期间的项目开发着实深深的影响了我，乃至我的职业规划。那时，有幸通过导师的选拔参加到了他所负责的某985项目及项目依托部门的筹建当中。难得的机会，参加了项目中的一些工作，并负责了其中某系统的设计及开发，几个同门和师弟师妹一起参与进来形成我们的团队。也就是这个系统让我“痛苦”了一番，合作对象是心理学、教育学方向的团队，需求交流的过程中，体会到了如何将业务需求与技术结合起来考虑问题，当然始终应该是技术服务需求，而不应该是业务需求屈从于技术。而更痛苦的则是不断变化的需求。前前后后不下五六个版本，推倒重做，推倒重做……终于，系统还好基本能按要求跑了起来，但留给了我很多值得总结和思考的问题。

       经历了研三找工作、写论文、导师项目、家庭问题多方面的压力，虽然一路坎坷但更清楚自己的去向。现在的工作并不像开始说的那样，开始面临转型，但我还是不愿就这样舍弃coding，因为那个隐隐作祟的东西还未抚平。我开始思考怎么去做好一个软件，难到专业的公司中在面对需求变化时，也是修修补补，甚至推倒重来？我觉得不可能，于是才有了开始。

初遇：

      关于更好的应对需求变化，也许传统的瀑布方法很难做到。而紧贴用户需求，甚至在用户自己都不能很好阐述需求的时候“快速原型开发”是个不错的选择。但在应对需求不断变化的情况，我却最初听到的是Agile。它提倡的是以人为核心，通过不断的交流、反馈，根据收集的用户故事版，采用测试驱动开发，进行不断迭代开发方法。这非常新鲜，至少对我来说是这样。Agile中的核心原则之一就是我所面对的问题“拥抱变化”，于是，我的问题的解答，总算有个方向了。

续缘：

    也许我的问题比较大，如何做好软件，可能是一个非常复杂的问题，不止是技术，甚至是团队的组织和管理等非技术因素。但至少有了个方向，需要一个入手点，那么在很多敏捷开发介绍中，不止一次的提到重构和设计模式、UML，当然还有很多其他内容，比如TTD等。对我而言我想以UML、设计模式、重构的顺序比较适合我这Agile新手，但工作之余能学到什么程度、能走多远……，我想至少我在前进，而且有了开始。