【北邮果园大三】Software Engineering 软件工程 - Block 1 Day 5 - 敏捷内的需求

• • 1.1.
  • 1.2.
    • 1.2.1.
    • 1.2.2.
  • 1.3.

1. Day 5 - Requirements in Agile Development 敏捷开发的需求

1.1. User Stories 用户故事

1. 两个主体
   1. 客户customer根据优先级和时间估计their priorities and the schedule estimates选择下一个版本的用户故事
   2. 开发团队development team分解为实现任务，作为进度与成本估计的基础basis of schedule and cost estimates
2. 定义：User stories are short, simple description of a feature 对功能的简短描述
3. 模板：
   • As a type of user,
   • I want some goal e.g. feature,
   • so that some reason for benefit or value.
4. 注意：
   1. 讨论比撰写更重要In fact, these discussions are more important than whatever text is written.
   2. 非功能需求也可以写为用户故事，若不明确，也可以使用自然语言
5. 形式：Story cards故事卡（用户故事写在故事卡上），Acceptance Criteria验收标准（写在故事卡背面），Story wall故事墙（故事卡贴在故事墙上），Project glossary项目词汇表（定义关键术语，解决同义词和同音异义词，与相关方讨论define key terms and to resolve synonyms and homonyms, discuss the system with the stakeholders），Epics大故事（更高层级的用户故事，包含多个小用户故事）
6. 用户故事的书写人 Who write user stories?
   1. 任何人都可以撰写
   2. 团队每个成员都应能写出
   3. 写用户故事远不如far less important参与讨论involved in the discussions重要
7. 什么时候写用户故事 When are user stories written?
   1. 在整个敏捷项目中撰写User stories are written throughout the agile project.
   2. 敏捷项目开始时举办故事撰写讨论会story-writing workshop，创建产品待办事项清单product backlog，全面描述整个项目（或3-6个月内）过程中要添加的功能
   3. 大故事在随后分解为小故事，更好融入单元迭代fit more readily into a single iteration
   4. 任何人都可以撰写新的用户故事
8. 好的用户故事 Good user story - INVEST原则
   1. Independent
   2. Negotiable 可协商
   3. Valuable 有价值
   4. Estimatable 可估计
   5. Small 小型
   6. Testable 可测试

1.2. Product backlog 产品待办事项清单

1. 定义：A prioritised list of the functionality to be developed in a product or service.一个产品或服务中要开发的功能的优先列表
2. 最受欢迎的形式：用户故事User stories
3. 注意事项：用户故事必须在讨论后填写，将其视为实际需求的指向标
4. 工具：Excel, Kanban, Trello, Jira, Axosoft…

1.2.1. Prioritisation of stories 故事优先级

1. 确立优先级的标准：商业价值business value + 正投资回报率positive return on investment(ROI) + 风险risks
2. MoSCoW法（DSDM动态系统开发方法最青睐）重要性逐级递减
   1. 必须Must have: features must be implemented, and if not, the system would not work. 最必要的功能
   2. 应该Should have: features are important but can be omitted if time or resources constraints appear. 功能很重要，时间或资源不够可省略
   3. 可以Could have: features enhance the system with greater functionality, but the timelines of their delivery is not critical. 功能做了更好，但不必要
   4. 想要Want to have: features serve only a limited group of users and do not drive the same amount of business value as the preceding items. 受众有限，业务价值不高，不重要的功能

1.2.2. Estimating 估计

1. 定义：how long the work is likely to take 工作花费多长时间
2. 方法
   1. T恤法T-shirt sizing（工作等级法Level of Effort）分为small, medium, large, extra large…
   2. 理想时间法Ideal Time: under ideal circumstance 估计理想状态时间
   3. 小时法Hours: actual clock hours 实际工作按小时计
   4. 故事点法Story points: 一种任意（根据实际变化）的度量an arbitrary measure that allows the teams to understand the size of the effort
      1. 首先按照斐波那契数列排列Fibonacci Sequence，数越大，不确定性degree of uncertainty（难度）越高A
      2. 抽象可协商：使用相对的大小relative sizing估计，使得团队所有成员都同意故事点大小

1.3. Prototyping 原型设计

1. 定义：物理用户界面设计Physical user-interface design（绘制界面，获得反馈） + 逻辑用户界面设计Logical user-interface design（描述界面中元素样式look like，如何关联elements related to each other，怎样操作be manipulated）
2. 分类
   1. Low-fidelity Prototyping 低保真度原型设计：使用纸张和草图Paper and sketch的形式
      1. 优点一：快速Quick
         1. 不用学习其他技术No technical learning curve
         2. 适合早期概念Relevant feedback on early concepts
         3. 提供概念方向Provides conceptual direction
      2. 优点二：高效Effective
         1. 低投入 Low investment of time/resources
         2. 快速淘汰不良方案 Fail early, fail fast
         3. 加快详细设计Expedites detailed design
   2. Medium-fidelity Prototyping 中保真度原型设计
      1. 定义：功能有限Limited functionality，但可以点击clickable，便于显示交互与导航presents the interactions and navigation
      2. 范围：通常在故事板和用户场景上建立Usually built upon storyboards or user scenarios.
      3. 工具：Fliplet.com, Proto.io, Adobe XD…
   3. High-fidelity Prototyping 高保真度原型设计
      1. 定义：基于计算机的交互展示Computer-based interactive representation，在细节和功能details and functionality上与最终设计最相似closest resemblance to the final design
      2. 术语：用户界面user interface (UI) and 用户体验the user experience (UX).