浅谈敏捷：基础、需求管理

通过本篇，大家能了解到

1. 敏捷发展历程、宣言、原则. Scrum价值观.
2. Scrum整体框架. Scrum角色(PO、Scrum Master、团队)及职责.
3. Scrum三类工件：产品列表、迭代列表、燃尽图.
4. Scrum四个会议：迭代规划会、日会、评审会、回顾会.

• 敏捷不是一套详细的流程说明，而是一种思想和精神，敏捷方法才是具体做事情的方式，敏捷开发是一种以人为核心、迭代、循序渐进的开发方法.
  
  
• 敏捷的前身是早已存在的多种轻型软件开发方法论，它们并不是近年突然出现的新方法，而是数十年来优秀软件开发方法不断演变的结果. 2001年敏捷宣言发布，在明确了共同的价值观和原则后，敏捷迅速向初创企业、互联网公司到传统IT公司转型渗透发展.
  
  
• 敏捷的宣言(价值观)
  • 个体和互动 高于 流程和工具
  • 可工作的软件 高于 详尽的文档
  • 客户合作 高于 合同谈判
  • 响应变化 高于 遵循计划
    
    
• 敏捷宣言背后的原则

1. 最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意.
2. 欣然面对需求变化，即使在开发后期也一样. 为了客户的竞争优势，敏捷过程掌控变化.
3. 经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期.
4. 业务人员和开发人员必须相互合作，项目中的每一天都不例外.
5. 激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标.
6. 不论团队内外，传递信息效果最好效率也最高的方式是面对面的交谈.
7. 可工作的软件是进度的首要度量标准.
8. 敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续.
9. 坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强.
10. 以简洁为本，它是极力减少不必要工作量的艺术.
11. 最好的架构、需求和设计出自自组织团队.
12. 团队定期地反思如何能提高成效，并依此调整自身的举止表现.
    
    

• Scrum
  • 最早原型
    • 1986年，竹内弘高和野中郁次郎阐述了一种新的整体性的方法.
    • 目的：提高商业新产品开发的速度和灵活性.
  • 正式诞生
    • 1995年，在奥斯汀举办的OOPSLA '95上，萨瑟兰和施瓦伯联合发表了论文首次提出了Scrum概.
    • 2001年，施瓦伯与麦克·比窦合著了《敏捷软件开发-使用Scrum过程》.
      
      
• Scrum价值观
  1. 勇气：因为我们不是单打独斗，我们能够感受到支持，而且掌握更多的资源. 这一切赋予我们勇气去迎接更大的挑战.
  2. 承诺：由于对自己的命运有更大的掌控，我们会有更坚定的信念去获得成功.
  3. 专注：由于我们在一段时间内只专注于少数几件事情，所以我们可以很好地合作并获得优质的产出. 我们能够更快地交付有价值的事项.
  4. 尊重：因为我们在一起工作，分享成功和失败，这有助于培养并加深互相之间的尊重，并帮助彼此成为值得尊重的人.
  5. 开放：在团队合作中，大家都会表达我们做得如何，以及遇到的障碍. 我们发现将担忧说出来是一件好事，因为只有这样才能让这些担忧及时得到解决.
     
     
  • Scrum作为一种具体的敏捷方法，在符合敏捷价值观的基础上，也提出了自己的特定价值观. 作为一个持续改进的框架，缺少上述价值观，将难以利用Scrum框架持续地暴露问题，或无法切实解决问题.
  • Scrum 是一个框架，在这个框架中人们可以解决复杂的自适应问题，同时也能高效并有创造性地交付尽可能高价值的产品. Scrum 是：轻量级的、容易理解的、难以精通的.
  • Scrum 基于经验型流程控制理论，那么同样具有透明性、检视、调整等特点.
    
    
• Scrum包括
  • 三种角色
    • Scrum Master
      • Scrum Master促进Scrum过程
      • 去除那些影响团队交付冲刺目标的障碍
      • Scrum Master并非团队的领导，而是负责屏蔽外界对开发团队的干扰.
      • Scrum Master确保过程按照初衷使用.
      • Scrum Master是规则的执行者.
    • 产品负责人
      • 产品负责人代表客户的意愿.
      • 保证Scrum团队在做业务角度来说正确的事情.
        • 编写用户故事 -> 绘制故事原型 -> 形成产品列表 -> 排出优先级
    • 开发团队
      • 开发团队是负责开发并且交付产品的团队.
      • 团队规模要小.
      • 组成：5至9名具有跨职能技能的人(设计者、开发者、测试人员、用户体验设计师等).
        • 人数最好不超过7 -> 相对稳定 -> 自我组织与管理 -> 全职工作 -> 技能大致相当
  • 四个会议
    • 迭代规划：团队能力、产品列表、技术、迭代目标、迭代列表.
      • PO：做什么
        • 澄清用户故事(分析评估).
        • 选取下一迭代的用户故事.
      • 开发团队：怎么做
        • 决定如何实现选取的用户故事.
        • 创建具体可执行的任务.
        • 以人天为单位评估工作量.
    • 每日站会：昨天做了什么，遇到什么问题，今天准备做什么.
      • 属性：每日都开，不超过15分钟.
      • 交流：所有成员发言，仅暴露问题不需解决.
      • 聚焦：避免讨论无关的问题.
      • 透明：团队成员任务都在看板上明确.
    • 迭代评审
      • 简要阐述迭代目标完成情况(文档情况、故事完成情况等).
      • 团队需要演示所完成的迭代工作.
      • 提前准备，不需正式文档，整个团队参与，邀请关注产品的人，收集意见.
    • 回顾
      • 团队需要演示所完成的迭代工作，在每个迭代结束时开始做，整个团队都需要参加.
  • 三类工件
    • 产品列表
      • 需求
      • 项目中待完成的工作列表.
      • 对客户或用户有价值的工作项.
      • 需要排列优先级.
      • 优先级可以调整.
    • 迭代列表
      • 用户故事为产品列表中的子集，规划会议中团队承诺的用户故事.
      • 有具体的可执行的任务项.
      • 任务项工作量评估.
      • 任务项可增删改，任务可以自由认领、分配.
    • 燃尽图：描述了剩余工作随时间变化的轨迹.
      • 目的：让团队掌握进度；尽早发现问题，以便及时调整.
      • 增加或完成任务后，团队成员会更新图表，以体现剩余的工作量.