敏捷项目管理

敏捷开发管理

 

敏捷宣言

 

•       个体与交互          胜过     过程与工具
可以工作的软件    胜过    面面俱到的文档
客户协作               胜过    合同谈判
响应变化              胜过    遵循计划

 

敏捷开发

•       迭代

•       用户故事

•       结对编程

•       测试驱动

•       重构

•       沟通

•       持续改进

•       人的持续性

•       核心思想

•       SCRUM

 

敏捷开发－迭代

每次的迭代结束，都有一个新的可执行的应用

 

敏捷开发－用户故事

•       以客户为中心，以客户需求为导向，让客户全程参与项目开发（用户的高度参与）。

用户故事三大要素： Card, Conversation, Confirmation（卡片，沟通，确认）

 

字典

•       什么是用户故事?

用户每一个需求点即为一个用户故事。

举例：用户可以查看到一个人的缺勤信息。(这就是一个用户故事)

 

•       什么是用户期望

用户对一个故事所期望达到的效果。

举例：比如一个增加名字的故事能支持英文名，还是中文名啊，可不可以用数字来作为名字。

 

用户故事实施流程

•       写用户故事（用户故事工作坊）：客户负责、开发人员辅助；

•       估算用户故事（使用storypoints估算用户故事的工作量）：开发人员负责，客户检查结果；

•       迭代开发 （包括确定迭代周期长度、迭代数量和开发速度-Velocity）：开发人员负责；

•       版本规划（包括设置故事优先权和故事分组）：客户负责优先权的最终决定，开发人员做建议、指导；

•       接受测试：客户负责，开发人员接收反馈。

 

写用户故事

•       由客户团队负责

•       客户团队并非百分百由客户组成，它还可以包括客户、代理商，或者其他令软件符合要求的人员，如测试人员、产品经理、真正的最终用户、互动设计者等。（简称客户）

•       用户故事由客户负责。这并不意味着该部分工作全部由客户单方面完成，开发人员在不干预客户主观决定的前提下，给与客户技术上的支持、帮助和建议。

•       用小卡片作为记当载体。记录用户的每个需求点。每一个故事不应该太长。如果太长应分为解为几个故事来记录。

•       一个用户故事覆盖了应有的细节。

•       一个用户故事还可以包含用户期望，可写在对应用户故事小卡片的背面。

 

估算用户故事

•       由开发人员负责。统计用户故事量，评估总体需要多少工作量。

•       反馈用户，用户确认。

 

 

迭代开发

•       由开发人员负责。

•       评估迭代周期，迭代次数和开发速度。

迭代周期和迭代次数要与客户沟通

 

版本规划

•       为用户故事设置优先权

•       将用户故事按优先权的高低进行分组。

•       由客户负责，开发人员辅助。

 

版本规划－为用户故事设置优先权

•       根据前面开发人员对故事的工作量、难度、复杂度的评估信息，由客户来负责，开发人员提供相应的指导。优先级可按下面的分类进行划分。

 

•       Must have – 必须包含

•       Should have – 应该包含

•       Could have – 可以包含

•       Won’t have this time – 这次不需要包含

 

 

版本规划－将用户故事按优先权的高低进行分组

•       由开发人员负责，客户参与

•       对已设置优先权的用户故事按优先权从高到低进行分组分配。这样，就可以在第一个迭代周期内开发优先权最高的一组用户故事，在第二个迭代周期开发优先权次高的那组

 

接受测试

•       客户负责，开发人员接收反馈。

客户提出测试要求，写下测试条款

 

敏捷开发－结对编程

•       每个模块的都由两个人一起探讨，设计，开发，测试。

•       优点：保证质量，通过两个人的角度来看问题，解决问题，能让问题得到更全面，更深入的探讨。有利于问题得到更好的解决。对每个模块都有双重备份的效果。

•       缺点：开发速度和效率有所下降。并不是什么情况下都能实施结对编程。

•       搭挡之间要有充分的磨合，有足够的默契，技术水平和思想要基本相当。

 

敏捷开发－测试驱动

•       先制定测试标准和测试用例再进行设计。

•       并行，测试和设计同时交互进行。

 

先测试后设计模型

 

并行模型

 

 

敏捷开发－重构

•       组件重构（内部重构）

•       系统重构（外部重构）

 

组件重构（内部重构）

•       功能需求不变，对特定模块进行优化性重构。这种重构不会对系统功能造成影响，对系统外部来说，系统功能没发生变化。

 

系统重构（外部重构）

•       外部需求变化，现有系统结构无法满足需求变更。需要在现有系统模块基础上重新构建系统结构来满足当前系统的需求。

 

敏捷开发－自动化测试

•       由于敏捷开发当中，测试需要做到覆盖全面，而且在整个开发过程中，需要不断迭代和重构，这需要在迭代和重构中不断的重复测试。如果用手工测试，那工作量就太大了。所以在敏捷开发中，实现自动化测试是相当重要的。

 

 

敏捷开发－文档很重要

•       敏捷虽然是要求简约的文档，但并不是说文档可有可无，在任何软件项目当中文档都是相当重要的，包括敏捷的软件项目中。文档是也沟通的一种重要方式，可以减少很多不必要且重复的口头沟通，而且能够把沟通的结果进行一个明确和保存。

 

敏捷项目中的文档可以分为下面三类进行管理

 

•       需要急时跟进的文档。

•       需要但不用急时跟进的文档。

•       需要但可以在后期补充的文档。

 

文档很重要－代码文档管理

•       敏捷项目中，代码文档是最重要的。整个项目中，团队人员是协调工作的，代码亠档不是自己一个人看的，一个人写的代码文档要让其他人也能看得懂，所以对代码文档要有严格的规范。

 

敏捷开发－沟通

•       敏捷项目当中，一条非常重要的准则就是人与人的沟通。能不能充分的沟通是决定敏捷成败的关键。

 

•       客户与开发人员之间持续的沟通。

•       开发人员之间持续的沟通。

•       沟通也是需要成本，所以要有一定的文档辅助，以减少很多不必要且重复的沟通。

 

开发团队内部沟通

 

客户与开发团队之间的沟通

 

 

•       通过各种沟通和交流让每一个开发人员都清楚自己所负责的任务在整个项目或系统中的位置。让每个开发人员都充分自己任务的需求。同时每个开发人员都清楚自己的任务和团队中其他人所负责任务的关系做到团队中的成员对项目都有一个整体宏观的视角，明确目标。

•       通过沟通让团队中的所有成员都充分发挥出自己的潜能，参与讨论，设计和开发。能让每个成员的智慧都集中起来。

 

 

敏捷开发－持续改进

•       小粒度的迭代，持续改进，不断调整。

•       敏捷项目的管理本身也是不断调整，持续改进的过程。

 

 

敏捷开发－人的持续性

•       敏捷并不是百米赛跑，他通过迭代在软件的整个生命周期里持续的对软件进行改进。所以敏捷项目是一场马拉松赛跑。

•       团队中的每个人每天都需要有合理的工作时间和休息时间。

 

 

人的持续性

•       团队成员每天需要保持充足的精力来做事情。因为这样才能高效，高质量的完成任务。

•       一个人疲惫时，工作效率低下，容易犯错。

•       在软件项目中，如果在一个工作中出犯错，要查找和修正一个错误的时间和精力远大于完成这件工作所需要的时间和精力。

 

 

敏捷开发—核心思想

•       以人为本，以变应变。

•       通过开发团队持续的改进，不断的调整来适应环境变化，满足需求的变化。达到高效，简结的开发过程。

•       包括项目（系统）和团队管理。

 

 

敏捷开发—SCRUM

•       Scrum是一种迭代式增量软件开发过程，通常用于敏捷项目软件开发。

•       自发组织管理的团队

•       由商业价值[BusinessValue]驱使的频繁而快速的检验和规划,使功能不断更新和加强

•       及时控制需求利益等因素的冲突和矛盾

•       实时地监测和扫除障碍

 

SCRUM基本概念

•       三个基本角色(Role)

Ø 产品主管(Product Owner):

Ø Scrum师傅(ScrumMaster):

Ø 团队成员(Scrum Team):

•       三种会议(Meeting)

Ø 迭代计划会议(Sprint Planning Meeting):

Ø 每日晨会(Daily Scrum Meeting)

Ø 迭代回顾会议(Sprint Review Meeting)

•       三项工件(Artifact)

Ø 待开发任务列表(The Sprint Backlog)

Ø 待修复缺陷列表(The defect backlog)

Ø 进度图(BrunDown Chart)

 

 

SCRUM

 

Scrum研发过程

•       Scrum的进程由一系列迭代过程Sprints（短跑）组成

•       需要研发的功能在ProductBacklog（产品订单）中列表

•       表中的项目是商业和技术功能的动态序列

•       Sprint从Sprint Planning Meeting（Sprint 计划会议）开始

•       Product Owner从Product Backlog中选择最高级别和最优先的项目去实现

•       Scrum Team决定该项目有多少可以在Sprint中开发完成

•       经同意要实现的功能转到SprintBacklog （产品冲剌订单）

•       Scrum Team一步步开发需要的功能,Scrum Master通过Daily Scrum会议关注每天的进展

•       Sprint结束时,在Sprint Review Meeting会议上Sprint向Product Owner给出Production-Quality和Demonstrable Business Functionality

 

Scrum团队的组成:ProductOwner

•       代表产品线的利益,与Scrum Master和 Scrum Team合作

•       负责管理和确定产品记录（订单）的优先次序,相应按照商业价值开发产品更新换代的功能

•       侧重于投资回报ReturnOf Investment

 

 

Scrum团队的组成:ScrumMaster

•       为Scrum Team服务,确保每一个成员都认同Scrum价值观和遵守其游戏规则

•       组织每天的DailyScrum会议

•       负责保证ScrumTeam的持续进展

•       决策和免除障碍

•       帮助Scrum Team规划Sprint计划

 

 

Scrum团队

•       自我管理,自我组织,多功能,通常由6 – 10 人组成

•       负责将ProductBacklog转化成Sprint中的工作项目

•       所有团队成员协调,合作和完成Sprint中每一个规定的工作

•       所有团队成员和ScrumMaster负责每一个Sprint的成功

 

 

产品记录（订单）

•       产品订单（productbacklog）是整个项目的概要文档。产品订单包括所有所需特性的粗略的描述。产品订单是关于将要创建的什么产品。产品订单是开放的，每个人都可以编辑。产品订单包括粗略的估算，通常以天为单位。估算将帮助产品负责人衡量时间表和优先级。

•       产品主管负责优先级的制定。

 

冲刺订单

•       冲刺订单（sprintbacklog）是大大细化了的文档，包含团队如何实现下一个冲刺的需求的信息。任务被分解为以小时为单位，没有任务可以超过16个小时。如果一个任务超过16个小时，那么它就应该被进一步分解。冲刺订单上的任务不会被分派，而是由团队成员签名认领他们喜爱的任务。

 

Sprint规划会议

•       整个会议通常需要一天

•       在Sprint开始时进行

•       Product Owner描述Product Backlog中最高级别的项目

•       Product Owner回答Scrum Team关于项目内容,目的和具体功能的问题

•       Scrum Team估计可以在Sprint中完成的任务

•       被选择的项目转移到SprintBacklog

•       Scrum Team确定Sprint的目标

–      简单描述哪些任务回在Sprint中完成

–      概括终结SprintBacklog

 

•       Scrum Team分别讨论规划Sprint

•       用户故事(UserStories)分化成具体的工程任务进行时间和人数上的估计

•       Product Owner保证在这次Sprint中其内容不会更改

•       如果重要改变发生使得ProductOwner预料Sprint内容需要更改,那么该Sprint就被取消,新的Sprint产生,需要进行另一个Sprint Planning Meeting

 

Scrum 每日小会

•       Scrum每日小会。（会议不能太长，十五分钟左右）

•       昨天做了什么？

•       今天做什么？

•       遇到有什么问题？

•       不是项目状况更新会议,或关于某个成员是否落后于时间安排

•       是Scrum成员互相的承诺

•       不能分散精力成为系统设计讨论会

•       会议中提到的问题应会后解决

 

 

Sprint评估会议

•       Scrum Team向Product Owner或其他有兴趣的人员演示和报告Sprint开发的成果和进展

•       产生对比于Sprint PlanningMeeting定义的需求和功能的评价

•       评估是非正式的,是对Sprint的一个自然总结报告,不应分散ScrumTeam的注意力

•       每一个月举行一次

 

Sprint回顾会议

•       Scrum Master鼓励每一个Scrum Team成员去修正Scrum的研发和管理过程,使下一个Sprint更为有效和愉快

 

Scrum调整

•       使得Scrum适合于大型软件开发的主要方法:"Scrum of Scrums"

•       每一个Scrum Team同样有一个代表(通常是 ScrumMaster),参与Scrum of Scrums会议协调多个Scrum Teams的工作

•       这些会议类似于DailyScrum,但每周召开一次

 

总结：

再好的项目管理方式，管理技巧，管理规范都不是根本，最根本最重要的管理是人，是对人的管理。要让团队中的每个人都觉得是一条心的，工作是开心的，是轻松愉快的，不是压抑的，要让团队的中人保持对所做的这件事有希望和激情。要让大家都发自内心的愿意去完成自己的工作。而不是为了条条框框的规定。这样才能让大家齐心协力。才能让好的管理方式，好的管理技巧，和好的管理规范发挥出它的作用。不然再好的管理方式都是徒劳的。