建议使用以下浏览器,以获得最佳体验。 IE 9.0+以上版本 Chrome 31+ 谷歌浏览器 Firefox 30+ 火狐浏览器
请选择 进入手机版 | 继续访问电脑版
设置昵称

在此一键设置昵称,即可参与社区互动!

确定
我再想想
选择版块
直达楼层
标签
您还可以添加5个标签
  • 没有搜索到和“关键字”相关的标签
  • 云产品
  • 解决方案
  • 技术领域
  • 通用技术
  • 平台功能
取消

采纳成功

您已采纳当前回复为最佳回复

追梦柠檬男

发帖: 238粉丝: 2

发消息 + 关注

发表于2020年08月24日 08:57:20 469 3
直达本楼层的链接
楼主
显示全部楼层
[技术干货] 【转载】项目管理之敏捷开发之道(三)

项目管理之敏捷开发之道(三)

举报
分享

分享文章到朋友圈

分享文章到微博

采纳成功

您已采纳当前回复为最佳回复

追梦柠檬男

发帖: 238粉丝: 2

发消息 + 关注

发表于2020年08月24日 08:58:06
直达本楼层的链接
沙发
显示全部楼层

对敏捷开发的误解

  误解一:敏捷对人的要求很高

 

  很多人在尝试实施敏捷时说:敏捷对人的要求太高了,我们没有这样的条件,我们没有这样的人,因此我们没法敏捷。可是,敏捷对人的要求真的那么高么? 软件归根到底还是一种创造性活动,开发人员的技术水平和个人能力对软件的质量还是起着决定性的作用,各种过程与方法只是帮助开发人员、测试人员等角色能够更好的合作,从而产生更高的生产力。不管用什么方法,开发人员的水平永远都是一个主要的因素。

 

  从另一个角度来看:过程和方法究竟能帮开发人员多大忙?对于技术水平较低的开发人员,敏捷方法和传统方法对他的帮助是差不多的,因此看不到显着的效果,甚至有些时候还有反效果;而随着开发人员技术水平的提高,敏捷方法能够解开对人的束缚,鼓励创新,效果也会越来越显着。

 

  敏捷对人的要求并不高,而且会帮助你培养各种所需的能力,当然前提是你处在真正敏捷的环境中。

 

  误解二:敏捷没有文档,也不做设计

 

  这个误解从XP开始就没有停止过,XP鼓励“在非到必要且意义重大时不写文档”。这里面提到的“必要且意义重大”是一个判断标准,并不是所有的文档都不写。例如,用户手册是不是“必要且意义重大”?这取决于客户的要求,如果客户不需要,那就不用写,如果客户需要,就一定要写;再如,架构设计文档要不要写?复杂要写,不复杂不用写。通常架构设计只需要比较简单的文档,对于有些项目,一幅简单的UML图就够了。因此,写不写,怎么写,都要根据这个文档到底有多大意义,产出和投入的比例,以及项目的具体情况决定。实际操作时可以让项目组所有人员表决决定,尽量避免由某一个人(比如lead)来决定。

 

  至于设计,XP奉行的是持续设计,并不是不设计。这实际上是将设计工作分摊到了每天的日常工作中,不断的设计、改善(重构),使得设计一直保持灵活可靠。至于编码前的预先设计,Kent Beck等人确实实行着不做任何预先设计的开发方式,但是对于我们这些“非大师”级开发人员,必要的预先设计还是需要的,只是不要太多,不要太细,要有将来会彻底颠覆的准备。

 

  误解三:敏捷好,其他方法不好

 

  有些人一提到敏捷就大呼好,只要是敏捷的实践就什么都好,而提到CMMI等方法就大呼不好,不管是什么只要沾上边就哪里都不好,似乎敏捷和其他方法是完全对立的。牛顿说过,我是站在了巨人的肩膀上。敏捷同样也吸取了其他方法论的优点,也是站在了巨人的肩膀上,敏捷依然保持了很多历史悠久的实践和原则,只是表现方式不同罢了。

 

  从另一个方面来看,方法本没有好环,好与坏取决于是否适合解决你的问题。每一种方法都有他最善于解决的问题和最佳的发挥环境,在需求稳定、软件复杂度相对不高的时代,瀑布模型也可以工作的很好,而敏捷恰好适用于变化快风险高的项目 这恰恰是现在很多项目的共性。

 

  因此选择一个方法或过程,并不是根据它是否敏捷,而应根据它是否适合。而要了解一个东西是否适合,还是要尝试之后才知道,任何没有经过实践检验的东西都不可信。

 

  误解四:敏捷就是XP(极限编程),就是Scrum

 

  XP 和Scrum只是众多敏捷方法中的两种,还有很多其他的敏捷方法。龙生九子各个不同,敏捷的这些方法看起来差别也是很大的,可是他们之所以被称为敏捷方法,就是因为他们背后的理念和原则都是相同的,这个原则就是《敏捷宣言》。学习敏捷不仅仅要学习实践,还要理解实践后的原则,不仅要理解怎么做,还要理解为什么这么做,以及什么时候不要这么做。

 

  即使将XP或Scrum完全的应用的你的项目中,也未见得就能成功,适合别人的东西未必就适合你。敏捷的这些实践和方法给了我们一个起点,但绝对不是终点,最适合你的方式还要由你自己在实际工作中探索和寻找。

 

  误解五:敏捷很好,因此我要制定标准,所有项目都要遵循着个标准

 

  没有哪两个项目是一样的,客户是不一样的,人员是不一样的,需求是不一样的,甚至没有什么可能是一样的。不一样的环境和问题,用同样的方法解决,是不可能解决的好的。方法是为人服务的,应该为项目团队找到最适合他们的方法,而不是先确定方法,再让团队适应这个方法。因此也不存在适合所有项目的统一的方法。任何企图统一所有项目过程的方法都是不正确的。

 

  同时,对于同一个团队,随着项目的进行,对需求理解的深入,对技术理解的深入,一开始适合项目的过程和方法也会渐渐的不适合。这时候也需要团队对过程进行及时的调整,保证项目的质量和效率。敏捷是动态的,而非静止不变的,因为这个世界本身就是变化的,在变化的世界使用不变的方法,是不现实的。银弹从来就没有过,在有限的将来也不会存在。

 

 

敏捷开发知识体系整体框架

 

敏捷开发工程实践

 

项目管理

 

迭代开发

风险价值生命周期

多级项目规划

完整团队

每日站立会议

任务板

燃尽图

需求管理

 

需求订单

业务流程草图

用例驱动开发

用户故事

架构

 

演进的架构

演进的设计

基于组件的架构设计

开发

 

结对编程

测试驱动开发

重构

代码规范

测试

 

单元测试

并行测试

测试管理

变更管理

 

持续集成

自动构建

团队变更管理

敏捷开发管理实践描述

 

定义和特征说明

主要角色

主要活动和最佳实践

主要输入输出

工作流程

敏捷开发工程实践描述

 

定义和特征说明

应用说明

案例说明

敏捷开发核心价值观和原则

 

敏捷软件开发宣言

 

个体和互动 高于 流程和文档

工作的软件 高于 详尽的文档

客户合作 高于 合同谈判

响应变化 高于 遵循计划

也就是说, 尽管右项有其价值, 我们更重视左项的价值.

敏捷软件开发的核心价值观

 

敏捷开发的核心理念就是以最简单有效的方式快速打成目标, 并在这个过程中及时地响应外界的变化, 做出迅速的调整.

 

核心价值观

 

以人为本

目标导向

客户为先

拥抱变化

敏捷开发的原则

 

我们最重要的目标,是通过持续不断地及早交付有价值的软件使客户满意。

欣然面对需求变化,即使在开发后期也一样。为了客户的竞争优势,敏捷过程掌控变化。

经常地交付可工作的软件,相隔几星期或一两个月,倾向于采取较短的周期。

业务人员和开发人员必须相互合作,项目中的每一天都不例外。

激发个体的斗志,以他们为核心搭建项目。提供所需的环境和支援,辅以信任,从而达成目标。

不论团队内外,传递信息效果最好效率也最高的方式是面对面的交谈。

可工作的软件是进度的首要度量标准。

敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。

坚持不懈地追求技术卓越和良好设计,敏捷能力由此增强。

以简洁为本,它是极力减少不必要工作量的艺术。

最好的架构、需求和设计出自自组织团队。

团队定期地反思如何能提高成效,并依此调整自身的举止表现。

敏捷开发管理实践

 

Scrum

 

Scrum是一种迭代式增量软件开发过程,通常用于敏捷软件开发。Scrum包括了一系列实践和预定义角色的过程骨架。Scrum中的主要角色包括同项目经理类似的Scrum主管角色负责维护过程和任务,产品负责人代表利益所有者,开发团队包括了所有开发人员。

 

Scrum中的角色

 

“猪”角色

 

产品负责人(Product Owner)

通常由市场部门的人担任

敏捷教练 (Scrum Master)

通常由开发组组长担任

开发团队 (Scrum Team)

包括开发,需求,测试

“鸡”角色

 

用户

软件是为了某些人而创建!就像“假如森林里有一棵树倒下了,但没有人听到,那么它算发出了声音吗”,“假如软件没有被使用,那么它算是被开发出来了么?”

利益所有者 (客户,提供商)

影响项目成功的人, 但只直接参与冲刺评审过程。

管理者

为产品开发团体架起环境的那个人

主要活动和最佳实践

 

迭代式软件开发

两层项目规划 (Two-Level Project Planning)

整体团队协作 (Whole Team)

持续集成

冲刺规划会议 (Sprint Plan Meeting)

每日站立会议 (Sprint Daily Meeting)

冲刺复审会议 (Sprint Review Meeting)

冲刺回顾会议 (Retrospective Meeting)

scrum方法中得主要活动和交付件

 

主要输入输出

 

产品订单(Product Backlog)

冲刺订单(Spring Backlog)

燃尽图(Burndown Chart)

新的功能增量

工作流程

 

scrum方法全景图

 

项目管理过程

 

Scrum项目管理过程中产品负责人获取项目投资, 并对整个产品的成功负责.

产品负责人协调个中利益干系人, 确定产品订单中初始的需求清单及其优先级, 完成项目商业价值分析和项目整体规划, 并任命合适的敏捷教练开展项目工作.

项目开发过程

 

Scrum软件开发过程中, 每个冲刺就是较短的迭代, 通常为2~4周.

 

在每个冲刺开始时, 产品负责人和敏捷教练通过召开冲刺规划会议和”两层项目规划”的最佳实践, 制定冲刺订单(类似迭代计划)

产品负责人明确在本次冲刺中实现的需求清单, 响应的工作任务和负责人.

在每个冲刺迭代中, 团队强调应用”整体团队协作”的最佳实践, 通过保持可持续发展的工作节奏和每日站立会议, 实现团队的自组织, 自适应和自管理, 高效完成冲刺工作.

在每个冲刺结束时, 团队都会召开冲刺复审会议, 团队成员会在会上分别展示他们开发出的软件(或其他有价值的产品), 并从产品负责人和其他利益关系人那里, 得到反馈信息.

在冲刺复审会议之后, 团队会自觉招开冲刺回顾会议, 回顾整个项目过程, 讨论哪些方法做的好, 哪些方面可以改进, 实现软件交付过程的持续, 自发的改进.

XP

 

OpenUp

 

Lean

 

敏捷开发工程实践

 

迭代式开发

 

敏捷迭代开发是指每次按照相同的开发方式短期的开发软件的部分, 或前期开发并不详尽的软件, 每次开发结束获得可以运行的软件, 以供各方干系人观测, 获得反馈, 根据反馈适应性的进行后续开发, 经过发福多次开发, 逐步增加软件部分, 逐步补充完善软件, 最终开发得到最后的软件. 每次反复开开发叫一次迭代, 在Scrum中成为Sprint, 中文常译为”冲刺”.

 

持续集成

 

持续集成(Continuous integration)是指当代码提交后, 马上启动自动编译, 自动部署金额自动化测试来快速验证软件, 从而尽快的发现集成错误.

 

多级项目规划

 

多级项目/产品规划, 在软件开发领域, 是指以迭代开发为基础, 形成多层次的, 逐步细化的项目或产品计划. 这些层层相关的项目/产品规划包括:

 

项目/产品愿景

项目/产品路线图

版本发布计划

迭代计划

每日实现

项目/产品愿景

 

在计划阶段, 首先, 项目stakeholder, 项目/产品负责人将参与并组成工作组, 他们负责阐述项目的重要性, 给出项目成功失败的关键标准以及项目整体层面”完成”的定义; 在过程中, 可以利用形成项目愿景的一些个工具, 包括愿景盒子(Vison Box), 业务收益矩阵(Business Benefits Matrix), 项目范围矩阵(Scope Matrix), 滑动器(Slider), 成本收益矩阵(Cost/Benefit Matrix)等; 最后, 项目愿景需要使用尽量简要的文档固定下来, 并保证项目团队成员都能了解.该文档需要包括:

 

当前的问题

机会描述和理由(描述项目的重要性)

项目的价值

项目如何和组织的战略目标达成一致

解决方案综述

项目包含的关键功能

项目必须服从的技术和约束条件

项目范围

项目的关键时间线

项目收益分析

项目和其他项目的依赖性

项目的相关风险以及如何消除

项目/产品路线图

 

主要描述为了达到产品愿景而需要交付的关键功能和特性, 这些特性基本处于Epic和特性层面, 不包裹用户故事(User Story). 它从时间的维度来表述对愿景的支持和实现. 它从时间维度来表达对愿景的支持和实现. 当项目/产品需要发布多个版本时, 项目线路图就非常重要, 否则, 它和发布计划相同, 项目/产品线路图由项目负责人和项目经理维护, 并保持更新. 通常, 会形成路线图问题或幻灯片, 使用大图标显示重要的里程碑, 包含的功能和发布日期等, 让所有项目/产品相关人员都清楚产品各个组件的可能发布日程.

 

版本发布计划

 

版本发布计划由团队成员和项目/产品负责人共同制定, 并通过版本发布计划会议讨论通过. 它包括了当前版本需要交付的, 达成一致的关键功能, 并经过优先级排序, 可以包含EPIC和User Story. 版本发布计划中常使用的概念包括:故事点, 迭代团队速率和优先级排序. 通常, 项目/产品负责人提出本次发布的目标, 团队成员根据目标和功能特性的重要性对故事进行排序, 并依据团队速率觉得本次发布需要包含的故事点. 前几次版本发布使用估算值, 其准确性随着项目/产品的时间持续而逐步精确. 版本发布计划是剧本适应性可调整的计划, 会随着项目演进而改变.

 

迭代计划

 

迭代计划是对版本发布计划的再次细化, 同样由团队成员和项目/产品负责人共同制定, 并听过迭代计划会议讨论通过. 迭代会议负责两件事情:

 

根据当前状态确定是否需要对版本计划做出更新

为当前的迭代计划制定迭代计划

迭代计划中常使用的概念包括: 拆分Epic和User Story, 任务, 任务估算. 在迭代会议上, 成员首先根据当前的项目变化对发布计划进行更新, 然后根据更新后的, 重新排序过的故事制定当前迭代需要完成的故事, 并对这些故事进行详细的任务拆分. 成员在认领完任务后, 会对任务的实现时间做出估算, 估算值需要具体到这些估算信息可以方便任何成员追踪任务的进度.

 

每日实现

 

没事实现是团队成员完成任务的具体过程, 它依据任务估算值并根据任务最终实现情况更新该值. 在敏捷方法中, 使用每日站会议来报告进度. 通过15分钟的站立形式, 团队成员报告故事或者任务的完成,未完成状态, 而解决层面的问题则在会议之后处理.

 

完整团队

 

Scrum团队必须具备的三个完整性:

 

团队职责完整性

 

产品负责人(Product Owner)

 

确定产品的功能。

决定发布的日期和发布内容。

为产品的收益(profitability of the product)负责。

根据市场价值确定功能优先级。

30天内调整功能和调整功能优先级。

接受或拒绝接受开发团队的工作成果

敏捷教练 (Scrum Master)

 

负责监督整个Scrum项目进程, 调整开发计划

保证团队资源完全可被利用并且全部是高产出的。

保证各个角色及职责的良好协作。

解决团队开发中的障碍。

做为团队和外部的接口,屏蔽外界对团队成员的干扰。

保证开发过程按计划进行,组织 Daily Scrum, Sprint Review and Sprint Planning meetings。

需要知道什么任务已经完成,哪些任务已经开始,哪些新的任务已发现,和哪些估计可能已经发生变化. 根据以上的情况更新反映每天完成的工作量以及还有多少没有完成的燃尽图

需要找出阻碍Scrum的障碍和依赖, 根据优先级指定计划解决这些障碍

个人问题或冲突在Scrum里是需要解决的。这些都需要被澄清,或通过内部的沟通解决,或向管理层和HR寻求帮助解决

Scrum Master需要知道什么任务已经完成,哪些任务已经开始,哪些新的任务已发现,和哪些估计可能已经发生变化。Scrum Master需要根据以上的情况更新反映每天完成的工作量以及还有多少没有完成的Burndown Chart。 Scrum Master还必须仔细考虑进展中的开放任务数,进展中的工作需要得到最小化,以实现精益生产率的收益。

Scrum Master需要找出阻碍Scrum的障碍和依赖。他们需要的优先次序和跟踪。根据优先级指定计划解决这些障碍。其中有些问题可以在团队内部解决,有些则要团队之间的协调,还有的要管理层的介入来解决.

开发团队 (Scrum Team)

 

具有不同特长的团队成员,人数控制在5-7个左右, 跨职能, 包括开发, 需求, 测试

弱化分工, 每个人都参与设计, 开发与测试

确定Sprint目标和具体说明的工作成果。

在项目向导范围内有权利做任何事情已确保达到Sprint的目标。

Product Owner演示产品功能。

团队素质完整性

 

要具备很强的集体协作精神.

要具备良好的沟通能力

必须能积极主动的接受新的事物, 要具备创新能力

要具备极强的自我管理能力和积极主动的精神

沟通的完整性

 

Sprint启动会

每日站立会议

Sprint回顾会

案例

 

验收测试驱动开发ATDD

 

TDD 只是开发人员的职责,通过单元测试用例来驱动功能代码的实现。ATDD在准备实施一个功能或特性之前,首先团队需要定义出期望的质量标准和验收细则,以明确而且达成共识的验收测试计划(包含一系列测试场景)来驱动开发人员的TDD实践和测试人员的测试脚本开发。面向开发人员,强调如何实现系统以及如何检验。

 

挑选用户故事

为故事写测试

实现测试

实现故事

结对编程

 

结对编程可以看做是一种敏捷化的Code Review

 

新结对编程

 

两位程序员新成结对小组, 每人一台电脑, 坐在临近的工位上, 两人合作完成一组功能(可以是两个或多个独立的模块)的设计, 代码实现. 但对已某一个模块来说设计和代码是分开的, 一个人负责设计, 另一个人负责写代码, 对于其他模块则反之.

 

确定冲刺计划

 

定义和说明

 

目的: ST和PO共同决定在接下来的冲刺周期内的目标以及那些功能和任务需求要完成

主要角色: ST, PO, SM

主要输入: Product backlog, 团队的能力

主要输出: Sprint Backlog

冲刺会议分两个部分

1. 解决本次冲刺要完成哪些需求

2. 解决这些选择的需求要如何被完成

 

案例

 

故事点估算

 

故事点是表述一个用户故事, 一项功能或一件工作的整体大小的一种度量单位. 数值本身不重要, 重要的是这些故事之间对比体现相对大小.

 

计划扑克

 

开始时, 美人得到一张扑克, 上面有任务点(?, 0, 1/2, 1, 2, 3, 5, 8, 13, 20, 40, 100, 无穷).?代表无法估算, 无穷代表故事太大

开始对故事进行估算, 先由PO介绍这个故事的描述. 接着澄清问题

每一个组员从扑克中挑选可以代表这个故事的卡片, 集体亮牌

最高分和最低分的组员像团队做出解释

全组成员自由讨论几分钟

重新打分, 直到全组统一.

敏捷估算2.0(Agile Estmating 2.0)

 

PO像团队成员介绍每一个用户故事, 确保所有需求相关的问题都在做估算前得到解决

整个团队参与游戏: 一次由一人将一个故事卡片放在合适的位置, 规模小的在左,规模大的在右, 一样大的竖排. 轮流移动故事卡片, 直到整个团队都认同白板上故事卡的排序为止.

团队将故事点(Story Point)分配给每个故事.

需求订单(Product Backlog)

 

记录用户需求的列表, 包括产品所有需要的特征.

 

每一项包含了需求标题, 描述, 重要性, 故事点(或其他表示大小的数字)

需求订单式开放的, 团队每个成员都可以编写和维护

在整个项目开放生命周期内, 需求订单需要不断维护, 管理与跟踪需求变化

燃尽图

 

在项目完成之前, 对需要完成的工作的一种可视化表示. 燃烧故事点.每天更新一次

 

具备可视性

具备风险预估, 提醒团队目前完成情况

具备可估量, 直接显示当前还需要的时间.

燃尽图常见问题

 

每日站立会议(Daily Scrum)

 

每日站立会议旨在让团队统一目标, 协调内部问题的解决, 绝非进度汇报.一般不超过15分钟.

 

我们上次开会后你都干了什么

在我们下次开会之前你要做什么

每个你负责的、正在做的任务还剩下多少时间

你的工作被阻碍了吗

任务板(Task board)

 

为项目团队提供一个便利的工具用于管理他们的工作

是团队成员对本冲刺的工作一目了然

任务板通常设立与项目团队日常工作的公共空间的一面墙上. 任务板上得信息包括该冲洗计划完成的用户故事和相应的任务, 分别卸载卡片上, 按照一定的方式贴在任务板上(To Do, In Progress, Done). 团队成员通过调整任务卡得位置和上面的信息反映任务的执行情况.

 

用户故事卡

 

每张卡片记录一条用户故事, 故事点.

 

任务卡

 

每个用户故事卡片通对应的多个任务卡. 每张卡片记录一条任务, 到目前为止完成该任务所需的工作量(小时).随着进展试试更新.

 

任务板的使用

 

用户故事

 

作为<某个角色>, 我希望<实现何种功能>, 以便<带来何种价值>.

 

: 作为一个用户, 我希望在每次退出系统前得到是否保存的提示, 以便所有内容都被成功存储了.

 

测试驱动开发(TDD)

 

先开发测试用例, 然后再开发代码


点赞 评论 引用 举报

采纳成功

您已采纳当前回复为最佳回复

lte网络工程师

发帖: 320粉丝: 16

发消息 + 关注

发表于2020年08月24日 09:47:32
直达本楼层的链接
板凳
显示全部楼层

感谢分享

点赞 评论 引用 举报

采纳成功

您已采纳当前回复为最佳回复

氟西汀

发帖: 393粉丝: 28

发消息 + 关注

发表于2020年08月24日 13:39:23
直达本楼层的链接
地板
显示全部楼层

感谢分享~

点赞 评论 引用 举报

游客

富文本
Markdown
您需要登录后才可以回帖 登录 | 立即注册

结贴

您对问题的回复是否满意?
满意度
非常满意 满意 一般 不满意
我要反馈
0/200