软件流程和管理：Tutorial汇总
目录
第一个项目管理流程：initialization 初始化
Project Analysis
Waterfall
Incremental
V-Model
Agile
SDLC Summary
Agile SDLC Risk Management
Agile Risk Process
Challenges vs. Risks
Formal-incremental 和 Agile-iterative SDLC的主要特征差异
Stakeholder Register 利益相关者登记册
Interpersonal Communication
Formal PM Stages
Agile PM Stages
制定项目时间表涉及哪些步骤？
User Story
Scrum Artifacts Overview
Agile Project Mgmt - Initialization
Agile PM - Release Planning
Release Burndown Chart
Activity: Release Scop
Agile PM - Sprint Planning
Burndown Chart
Prepare for the Sprint Planning meeting
Teams Formation
Team Roles
What is the role of QA in Agile?
Testing in Agile
Acceptance Criteria
Agile Quality – Dev Team process
Sprint Review QA评价
QA Requirements
Formal Approach 的质量检查
Contracts: Procurements 合同：采购
Compare ACS Code of Professional Conduct with IEEE Software Engineering Code of Ethics
第一个项目管理流程：initialization 初始化
Project Analysis
Consider the project, people & technology
Evaluate the project, team and specific Case Study constraints.
不是一般的三重约束，(成本、时间、范围)
Evaluate multiple SDLC models
找出优点和缺点
考虑两者的结果和风险Explore relationship between process and project
Justify an effective SDLC process
捍卫你对SDLC的选择
列出与SDLC相关的活动Formal: Requirements Spec
Agile: Product Backlog
Waterfall
What are the Advantages?
- Simple and easy management
- Rigid and sequential
- Documentation produced
- Requirements stable and precise
What are the Disadvantages?
- Bad news known late in process
- Client feedback known late in process
- Discourages change
- Documentation not valued
- Risks and changes have big impact
Incremental
特点
- Requirement - partition into segments 需求划分成段
- Releases - mini waterfall process 每个发布都是一个迷你瀑布模型
- Integrate modules 一些可集成模块
What are the Advantages?
- Smaller, easier modules
- Initial modules released earlier
- Client feedback known earlier
- Change has less impact
- Requirements stable and precise
What are the Disadvantages?
- Management complexity
- Increased cost
- Partition skill
- Integration risk
- Rigid within each partition
V-Model
瀑布模型加上定义好的工件：可交付开发阶段对应测试阶段
What are the Advantages?
- Simple and easy management
- Rigid and sequential deliverable
- Documentation produced
- Requirements stable and precise
What are the Disadvantages?
- Requires discipline
- Bad news known late in process
- Client feedback known late in process
- Discourages change
- Test artifacts are expensive
- Risks and changes have big impact
Agile
Scrum: 组织工作团队的方法
XP: 提高代码质量的方法
What are the Advantages?
- Transparent productivity due to fast releases
- Focus on client satisfaction
- Embraces change
- Requirements emerge
- Efficient and simple code
What are the Disadvantages?
- Requires experience of ceremonies
- Requires teamwork skills
- Giant “TODO” list lacks design overview
SDLC Summary
When to choose Formal Models?
- Customer knows what they want at the start
- Stable, precise and known requirements
- Change is not expected
- Mature technologies and tools
- 顾客一开始就知道他们想要什么\
- 稳定、精确和已知的需求
- 预期不会有改变
- 成熟的技术和工具
When to choose Agile Models?
- Customer gives time to project
- Requirements continue to emerge
- Change is welcome
- 客户给项目时间
- 需求不断出现
- 变化是受欢迎的
When to choose a Hybrid Model?
- Client has a prescriptive model established
- 委托人已建立了规范性模型
Agile SDLC Risk Management
Identify – capture risks in Risk Register 在风险寄存器中捕获风险
Analyze – Product Backlog groomed, and priority given to all User Stories, including those which capture risk 梳理产品积压，优先考虑所有的用户故事，包括那些捕获风险的故事。
Respond – mitigate Risk in Sprint 在Sprint中减轻风险
Monitor – during Sprint Review, Retrospective & Planning 在冲刺回顾、回顾和规划期间进行监控
Agile Risk Process
- Build small piece of working software with minimal features 构建具有最小功能的小块工作软件
- Showcase the product chunk to the stakeholders early 尽早向利益相关者展示产品的主要内容
- Fail fast and as cheaply as possible, & get timely feedback 尽可能快地、低成本地失败，并及时获得反馈
- Capture the risk item in the Product Backlog 在产品积压中捕获风险项目
- The Product Owner sets the priority of the risk item 产品负责人设定风险项目的优先级
Challenges vs. Risks
Challenge:
- 这个特点是已知的，是存在的。
- 该解决方案需要资源，(fitness).。
Risk:
- 这个未来可能发生的事件可能发生也可能不发生
- 最好是制定一个战略来控制该事件。
Formal-incremental 和 Agile-iterative SDLC的主要特征差异
Formal
- Explicit architecture 明确的架构
- Explicit UX design (end user consideration) 明确的用户体验设计（最终用户考虑）。
- Explicit configuration 明确的配置
Agile
- Productivity increase 生产力的提高
- Responsive to feedback (client satisfaction) 对反馈意见反应灵敏（客户满意度）
- Working software 工作软件
这些特点会如何影响风险管理？
- Formal——Plan ahead
- Agile——Plan Just-In-Time
Stakeholder Register 利益相关者登记册
Interpersonal Communication
Formal PM Stages
Initiate » Plan » Execute 执行 » Monitor & Control » Close
Agile PM Stages
Initiate » Sprint Plan » Scrum (or Sprint) » Review & Retrospective (or Adapt) » Release
制定项目时间表涉及哪些步骤？
User Story
(Sprint) User Story
- 详细的技术层面
- 一个开发者的视角
- 一个对话的占位符
Feature User Story
- 产品能力
- 业务层面的细节
- 产品负责人的观点
Epic User Story
- 缺少细节
- 新的商业服务
- 产品
Scrum Artifacts Overview
Agile Project Mgmt - Initialization
- 业务路线图确定了候选项目
- 与外部利益相关者建立产品愿景
- 创建Product Backlog
Agile PM - Release Planning
梳理好的 Product Backlog 是以Epic Story Points来估算的
- 廉价和快速的评估
- 低质量指标
- 允许小的和大的价值估计，如21或100
找出开发团队编码软件的速度
- 编码的速度被称为 Velocity 速度
- 它决定了 Release 发布时间表
Release Burndown Chart
Activity: Release Scop
哪个人工制品记录了产品需求？
Which role identifies the product features?
Agile PM - Sprint Planning
创建Sprint Backlog
- 从产品Backlog中选择高价值的用户故事
- 使用速度来知道故事点的适当数量
在Sprint Backlog上分解选定的用户故事
- 进行及时详细的评估
- 检查故事点的数量是否仍然适合于Sprint
- 详细的高质量估算
- 估算有较小的数值，如1或10是有效的
Burndown Chart
冲刺总结
- 监测实现Sprint目标的速度
- Scrum Master会在每次Daily Standup后更新实际的Sprint Burndown图表。
Prepare for the Sprint Planning meeting
- 产品负责人审查Product Backlog
- Scrum Master审查机密议程（由导师提供）。
- 开发团队为产品负责人准备关于用户故事的问题
- 观察者审查人格类型（由导师提供）
Teams Formation
Team Roles
- Initiator: offers ideas, solutions, brainstorm, lateral thinker
- Information seeker: wants facts
- Information giver: describes own experience, offers facts, clarification
- Coordinator: combine contribution of others
- Evaluator: assess quality of contributions
- Encourager: praising, accepting, cohesion and warmth
- Harmonizer: build consensus, humor to neutralize anger
- Standard setter: focus on goals, standards
- Follower: agreeable
- Group observer: provides feedback
What is the role of QA in Agile?
- 在开发之后，有单独的测试由敏捷团队完成
- 由于开发周期快，没有时间进行测试
- 敏捷的目的是快速适应变化，并尽量减少测试时间
- 测试总是在每个冲刺阶段进行
- 必须在开发和测试之间使用持续集成（CI）工具，实现测试自动化
Testing in Agile
User Story 用户故事描述了需求......
Acceptance Criteria 验收标准提供了定义......用户故事何时 done 完成。
- 每个新功能都在冲刺期间进行测试。
- 测试人员和开发人员紧密合作。测试是由整个团队完成的。
- 每个冲刺都有自己的用户验收测试阶段。
- 在冲刺结束时，会有一小块工作软件交付给客户。
- 客户进行用户验收测试。
Acceptance Criteria
用户故事：作为一个客户......我希望能够分割我的付款......这样我就可以用多张借记卡付款。
测试场景：
- 用户在支付页面上选择“分开支付”。
- 用户选择不同类型的支付选项
- 用户指定他们希望分给每个选项的金额
- 系统自动计算分次支付的总金额是否为正确的支付总额
Acceptance Criteria 验收标准：每个场景可以有多个验收标准
Acceptance Criteria format:
Given a User wants to pay, when they click the ‘split payment’ button on the payment page, then multiple payment card options are displayed. 考虑到用户想要支付，当他们点击支付页面上的'分割支付'按钮时，就会显示多个支付卡选项。
Agile Quality – Dev Team process
邀请多技能的听众进行桌面审计：一个业务分析师、另一个开发人员和一个测试员
在代码被允许提交到共享 git 仓库 GITHub 之前，在开发人员的办公桌上审查代码。
一旦代码被提交到GITHub，它的测试套件就会被持续集成（CI）工具立即运行。
CI工具显示运行代码的通过/失败状态
Sprint Review QA评价
- 构建具有最小功能的小块工作软件
- 尽早向利益相关者展示产品的主要内容
- 尽可能快地、低成本地失败，并及时获得反馈。
- 捕获产品积压中的任何 technical debt item 技术债务项目。(可选择FDD格式：<行动>, <结果> ) FDD: 估计（动词）最后的付款金额（宾语）。
- 产品负责人设置 technical debt item 技术债务项目的优先级
QA Requirements
Write QA requirements as User Stories for the Product Backlog
As the Agile Scrum team:
- We want Quality Assurance guidelines, so that our Sprint has a strong Quality Management focus 我们希望有质量保证准则，以便我们的Sprint有一个强大的质量管理重点
As a Quality Assurance Design team:
- We want to create a QA checklist, so that key categories and attributes are assessed at defined times 我们希望创建一个质量控制清单，以便在规定的时间对关键类别和属性进行评估。
As the System Administrator:
- I want a password policy guideline, so that our application has helpful processes 我想要一个密码政策指南，这样我们的应用程序就有了有用的流程。
- I want a password policy checklist, so that our application is highly secure 我想要一个密码政策检查表，这样我们的应用程序就会高度安全。
Formal Approach 的质量检查
Verification Process 验证流程
质量流程活动
- Design an appropriate formal quality checklist for the group assignment. 为小组任务设计一个适当的正式质量检查表。
- Describe the expected outcome of using this checklist? 描述一下使用此检查表的预期结果？
Contracts: Procurements 合同：采购
- 买方准备一份详细的工作说明书(SoW)
- 买方准备一份建议书（RFP）或报价单（RFQ）。
- 卖方/买方签署合同，包括工作说明书。
- 合同类型不同："固定价格"（卖方风险），"时间和材料"（买方风险）。
- 质量指标是基于服务水平协议（SLA）的合同
Agile Procurements: contentious/divergent
- 与潜在的合作者一起评估松散耦合的服务
- 与协作伙伴一起交付软件
- 敏捷平衡
- 合同的安全性/稳定性
- 和控制结果的反应性
Compare ACS Code of Professional Conduct with IEEE Software Engineering Code of Ethics
