敏捷开发-0216.pptVIP

敏捷软件开发 英雄连 彭科 敏捷软件开发 敏捷软件开发 软件工程 传统的软件开发方法 瀑布模型 传统的软件开发方法的优点和缺点 敏捷的软件开发方法 敏捷就是快速 敏捷软件开发方法的优点和缺点 敏捷软件开发宣言 我们正在通过亲身实践以及帮助他人实践，揭示更好的软件开发方法。通过这项工作，我们认为： 人和交互 胜过 过程和工具 可以工作的软件 胜过 面面俱到的文档 客户合作 胜过 合同谈判 随时应对变化 胜过 遵循计划 虽然右项也有价值，但我们认为左项更加重要。 敏捷宣言遵循的原则 在团队内部，最有效率也最有效果的信息传达方式，就是面对面的交谈。 在整个项目开发期间，业务人员和开发人员必须朝夕工作在一起。 围绕斗志高昂的人构建项目。给他们提供所需的环境和支持，并且信任他们能够完成任务。 敏捷方法——我的观点 没有一成不变的方法 XP——极限编程 Scrum——英式橄榄球争球队开发模型 在过程中符合敏捷原则的就是敏捷方法 合适的方法就是好方法 方法是给人用的，不能让方法限制人的发挥 敏捷开发实践 敏捷开发实践 敏捷环境：现场客户 客户作为团队成员 客户是谁? 策划 玩家反馈 需求提出者 何谓团队成员 能够每天始终与研发团队在一起 时刻能够看到项目目前的开发状态 至少每隔几天能够看到发布版本并与开发团队讨论 客户能够最快看到成果，并提出修改意见 敏捷环境：开放的工作空间 所有成员都在同一个房间工作 墙壁上挂满任务进度、任务明细等图表 所有人可以在房间中自由走动，与其他人交谈 所有人都随时了解其他人是否碰到困难，并提供帮助 大家工作在适合激烈讨论的位置 敏捷环境：结对编程 工作环境给每台计算机配置两把椅子 所有工作都由两个人一起完成 典型工作方式:一人鼠标一人键盘,每隔一段时间两人互换 结对关系需要频繁更换 通过结对 所有人都熟悉项目各个部分的设计，项目不依赖于某一个人 大家的开发水平能够迅速提高 提高代码质量，改进设计 提高工作效率? 敏捷环境：集体代码所有权 结对编程需要多人编写代码 所有开发人员都有能力在任何时间修改任何部分代码 保留意见 敏捷环境：每日站立会议 每天安排一段时间作为会议时间 站立会议：时间控制在15分钟以内 每个人汇报如下内容： 昨天做了什么？ 今天打算做什么？ 遇到了什么困难？ 敏捷开发实践 敏捷开发实践 敏捷计划：相对工作量 使用小工作项作为工作量评估标准 工作量过大的工作项必须分解为更小的工作项 每个工作项必须在最长两天/16小时内能够完成 敏捷计划：短发布周期 发布周期应该尽量缩短，让客户能够在最快时间看到确实可用的产品 发布计划 时间：一般选择2-3个月 在可控范围内，制定产品下一个发布将实现的需求列表 需求列表可以比较粗略，不需要详细设计 敏捷计划：迭代式开发 每次迭代代表一次小的发布 迭代时间：一般为两周 迭代开始后，不允许更改工作项相关需求，如有变化，必须作为新的需求进入下次迭代 在迭代中点，可以分析工作项完成情况，并考虑增加或者减少工作项 每次迭代的能够完成的工作量以上一个迭代完成的工作量为参照，不能制定更多的计划 每次迭代能够完成的工作将逐步趋于平稳，保证正常工作时间而不需要加班工作 敏捷计划：计划和总结会议 在迭代开始时，分析该次发布计划的需求列表，将可以在本次迭代实现的需求进行详细分析，并分解为工作项 迭代结束，演示产品并接受修改意见，所有意见加入需求列表中，等待后面的迭代实现。 每次迭代结束时，都总结分析该次迭代的经验和教训，保证优点继续发扬光大，而错误不会在今后的迭代中重复。 敏捷开发实践 敏捷开发实践 敏捷设计：少量文档 没有文档是一种灾难 过多的文档比过少的文档糟糕 产品的功能和设计总是在不断的变化中 大量临时文档 少量正式文档 编写和维护一份简短的系统原理和结构方面的文档 敏捷设计：编码标准 尽早确定——有法可依 命名——望名知意 必须遵循——有法必依 所有代码应该都看上去像同一个人编写的 在项目过程中不应对编码标准随意更改 敏捷设计：简单设计与拥抱变化 KISS. 只有必须时才做，只做一次，一次做好 没有不变的需求，简单的设计更容易改变 需求变化时，积极响应变化 当某一个特征上的需求改变，更改设计后，保证在该特征上的下一次改变将更容易 及时重构 敏捷设计：设计模式 设计模式——前人的经验总结 积极采用设计模式应对变化 在不同时机使用不同模式处理问题 不要怕用错模式 敏捷设计：重构 重构——改善既有代码的方法 重构是一个持续进行的工作 发现代码中任何“坏味道”，马上重构 当现有设计不符合新需求，马上重构 一旦出现重复代码，马上重构 重构是改进程序设计的最佳手段 借助于重构工具，减轻工作量 使用单元测试，保证没有新的bug 敏捷开发实践