个人博客作业-week5-敏捷开发方法读后感
满篇英文对一个非单词狂魔来说真的是很吃力啊…
敏捷软件开发方法是一种从1990年代开始逐渐引起广发关注的一些新型软件开发方法，是一种应对快速变化的需求的一种软件开发能力，他们的具体名称、理念、过程、术语都不尽相同，相对于“非敏捷”，更强调程序员团队与业务专家之间的紧密协作、面对面的沟通（认为比书面的文档更有效）、频繁交付新的软件版本、紧凑而自我组织型的团队、能够很好地适应需求变化的代码编写和团队组织方法，也更注重作为软件开发中人的作用。
敏捷软件开发宣言
对于敏捷软件开发方法来说,这段话给我留下了深刻的印象
- 对我们而言，最重要的是通过尽早和不断交付有价值的软件满足客户需要。
- 我们欢迎需求的变化，即使在开发后期。敏捷过程能够驾驭变化，保持客户的竞争优势。
- 经常交付可以工作的软件，从几星期到几个月，时间尺度越短越好。
- 业务人员和开发者应该在整个项目过程中始终朝夕在一起工作。
- 围绕斗志高昂的人进行软件开发，给开发者提供适宜的环境，满足他们的需要，并相信他们能够完成任务。
- 在开发小组中最有效率也最有效果的信息传达方式是面对面的交谈。
- 可以工作的软件是进度的主要度量标准。
- 敏捷过程提倡可持续开发。出资人、开发人员和用户应该总是维持不变的节奏。
- 对卓越技术与良好设计的不断追求将有助于提高敏捷性。
- 简单——尽可能减少工作量的艺术至关重要。
- 最好的架构、需求和设计都源自自我组织的团队。
- 每隔一定时间，团队都要总结如何更有效率，然后相应地调整自己的行为。
的确，正如敏捷软件开发宣言所言，相对于传统的软件开发方法，敏捷软解开发方法所倡导的新理念新方法能够很大程度上提高一个团队的工作效率。
个体和互动高于流程和工具，
工作的软件高于详尽的文档，
客户合作高于合同谈判，
相应变化高于遵循计划。
突然想到一门很坑的课
对于其他几点因为我本人并没有参与过太多软件开发项目而不敢多言，但对于工作的软件高于详尽的文档这一点我深表赞同。
上个学期我曾经上过一门《面向对象建模方法》的课，最后交了一个很水的团队项目，整个课程下来除了对java这门语言有了一定的了解之外，印象最深的就是无穷无尽的说明文档开发文档。我其实很不明白老师为什么会让对基本的软件开发方法尚未了解的我们在学习面向对象建模的一开始，就投身到工程浩瀚的编写文档当中。老师将文档模版发给我们，我们就开始添添补补，而往往大部分文档我们事先就从来没有考虑过，导致很多文档都是不知所云离题万里。而敏捷软件开发宣言中所讲工作的软件高于详尽的文档正好就契合了我的观点，文档固然有其价值，但更重要的是熟练运用开发工具而不拘于文档。若是一直与文档纠结，那么最终只能是顾此失彼因小失大。
敏捷方法
目前列入敏捷方法的有：
- 软件开发之韵，Software Development Rhythms
- 敏捷数据库技术，AD/Agile Database Techniques
- 敏捷建模，AM/Agile Modeling
- 自适应软件开发，ASD/Adaptive Software Development
- 水晶方法，Crystal
- 特性驱动开发，FDD/Feature Driven Development
- 动态系统开发方法，DSDM/Dynamic Systems Development Method
- 精益软件开发，Lean Software Development
- AUP（Agile Unified Process）
- Scrum
- XBreed
- 极限编程
- 探索性测试
极限编程
文章提到了极限编程这一点，极限编程是一个轻量级的、灵巧的软件开发方法；同时它也是一个非常严谨和周密的方法。它的基础和价值观是交流、朴素、反馈和勇气；即，任何一个软件项目都可以从四个方面入手进行改善：加强交流；从简单做起；寻求反馈；勇于实事求是。XP是一种近螺旋式的开发方法，它将复杂的开发过程分解为一个个相对比较简单的小周期；通过积极的交流、反馈以及其它一系列的方法，开发人员和客户可以非常清楚开发进度、变化、待解决的问题和潜在的困难等，并根据实际情况及时地调整开发过程。
极限编程中有四个核心价值是我们在开发中必须注意的：沟通（Communication）、简单（Simplicity）、反馈（Feedback）、勇气（Courage）、此外还扩展了第五个价值观：谦逊（Modesty）。 XP用“沟通、简单、反馈、勇气和谦逊”来减轻开发压力和包袱；无论是术语命名、专著叙述内容和方式、过程要求，都可以从中感受到轻松愉快和主动奋发的态度和气氛。这是一种帮助理解和更容易激发人的潜力的手段。XP用自己的实践，在一定范围内成功地打破了软件工程“必须重量”才能成功的传统观念。
根据我的了解，我想极限编程中最核心的地方在于，它针对软件开发中的两个问题：预测在交付日期前可以完成多少工作；现在和下一步该做些什么。不断回答这两个问题，就是直接服务于如何实施及调整开发过程；与此相比，希望一开始就精确定义整个开发过程要做什么事情，每件事情要花多少时间，则事倍功半。极限编程有两个主要的相应过程：软件发布计划和周期开发计划。一般情况下，客户只有在系统被开发完成以后能真正去体会它。极限编程却不一样，它通过加强客户的反馈来缩短开发的周期，同时获得足够的时间来改变功能和获得用户的认同。
现在在我所在的软工开发团队Z-XML中,每个周都会开一次例会,总结上个周每个人的任务完成情况,制定下个周的任务分配.虽然软工团队作业还没有开始,但是我们已经养成了分析客户需求-指定周期开发计划的习惯,同时在团队项目开始之后,我们同样会指定软件发布计划,让极限编程真正的应用到我们的软件开发之中.
针对极限编程,许多人也许会质疑,is design dead?通过阅读文章,我了解到,设计的本质已经改变,极限编程使我们能够去思考一种更高效的设计方法,极限编程使得设计变成了一种更加合理的策略.
极限编程使得我们的设计需要满足:
努力追求代码的清晰和简洁;
当有需求时即时重构;
掌握和应用设计模式;
设计的时候着眼于未来的变化;
学会团队沟通.
Scrum
对于Scrum,我在往届学长的博客中已经看到了这一点,wiki对于Scrum的解释是这样:
想到软件开发的时候整个team要高频率的进行冲刺就好激动啊...
