正确解读敏捷.pptVIP

* 敏捷关注架构。 敏捷强调简单设计，只针对确定的需求设计，不为未来可能的变化做过多假设，这不代表不关注架构。敏捷需在前几轮迭代标识出对架构影响重大和最高优先级的5-10%的需求开展架构设计，并在迭代中早期验证架构设计的正确性。在后续迭代强调架构的演进性，不断的重构“坏味道”。同时，很多敏捷实践需要强有力的架构做基础，如CI、TDD。 要强调的是架构属于系统工程，是软件产品的基础。软件开发方法学（敏捷、ＣＭＭ）不可能代替系统工程。 * * 高度重视反馈 尽管管理者一直强调质量的重要性，但在实践中发现我司的开发人员大多数以进度优先，究其原因其实很简单，进度是马上看得到的东西，如果进度延迟，主管给员工的压力马上体现出来，在传统瀑布模型下，质量的反馈需要等待很长的周期，质量不能马上形成压力。 迭代开发的一个明显优势就是快速将真实的质量反馈回来，有助于形成质量优先的氛围和树立没有质量的进度，是虚假的进度的导向，从而保证质量管理建立在真实，可工作的产品的基础上。 快速反馈的另一个明显的优势就是非常有利人员的技能增长，人如果总是在最终失败的体验中是不能成长的，最好成长的过程是经过失败后马上能改进，获得快速成功，（以往的CMM项目即使在项目末进行总结，经验不能马上被利用，这就是迭代促人进步的优势所在），在迭代开发中，一轮迭代发现自己做的不足，没有关系，下一次迭代立刻就有改进的机会，只要你认真对待每一次反馈，充分把每一次反馈当做改进的机会，团队就能在不断开发的过程中成长。 反馈在迭代开发实践中无处不在，可利用的反馈机制： 1. 持续集成结果； 2. 特性片测试结果； 3. 阶段回顾会议； 4. system acut 。。。 因此，是否能充分利用这些反馈机制是区分老开发模式和新开发方法的重要标志。 * * * * * * * 目录 统一敏捷认识 敏捷理念解读 敏捷实践解读 Copyright 2011 HiSoft Technology International Limited. All Rights Reserved. Internal * 敏捷管理实践：一体化办公 Copyright 2011 HiSoft Technology International Limited. All Rights Reserved. Internal * 所有的团队成员，包括开发人员、SE、测试人员都围绕同一张桌子坐下，他们在一起工作、讨论、保持良好的沟通。 Page * 敏捷工程实践：用户故事（user story） 什么是用户故事 用户故事是站在用户角度描述需求的一种方式； 每个用户故事须有对应的验收测试用例； 用户故事是分层分级的，在使用过程中逐步分解细化； 典型的描述句式为：作为一个XXX客户角色，我需要XXX功能，带来XXX好处。 用户故事的好处 用户故事站在用户视角便于和客户交流，准确描述客户需求； 用户故事可独立交付单元、规模小，适于迭代开发，以获得用户快速反馈； 用户故事强调编写验收测试用例作为验收标准，能促使需求分析人员准确把握需求，牵引开发人员避免过度设计。 用户故事的关键要点 I – Independent，可独立交付给客户 N – Negotiable，便于与客户交流 V - Valuable ，对客户有价值 E - Estimable ，能估计出工作量 S - Small ，分解到最底层的用户故事粒度尽量小，至少在一个迭代中能完成 T - Testable，可测试 初始需求：1.作为网络规划人员，我想要配置一个媒体网关，因为想要增加网络容量和服务 初次分解：1.1作为网络规划人员，我想把媒体网关参数上传到管理系统 1.2作为网络规划人员，我想从管理系统下载媒体网关参数 再次分解：1.2.1作为网络规划人员，我想用文件方式从管理系统下载媒体网关参数 用例：用户在管理系统上选择以文件方式下载媒体网关参数，执行成功后，检查文件是否正确下载到本地且内容正确 1.2.2作为网络规划人员，我想用MML结构方式从管理系统下载媒体网关的参数 用例:………… 故事样例 用户故事便于团队站在用户角度分解细化需求并制定验收标准 Page * 敏捷管理实践：每日站立会议 什么是每日站立会议 每日工作前，团队成员的例行沟通机制，由Scrum Master组织，Team成员全体站立参加 聚焦在下面的三个主题： 我昨天为本项目做了什么？ 我计划今天为本项目做什么？ 我需要什么帮助以更高效的工作？ 每日站立会议的关键要点 准时开始：按计划会议制定的时间地点开会，形成团队成员的自然习惯； 高效会议：会议限时15分钟，每个人都保持站立，依次发言，不讨论与会议三个主题无关的事情（如技术解决方案等）； 问