Agile与Scrum培训

最新推荐文章于 2020-09-20 17:11:17 发布

转载最新推荐文章于 2020-09-20 17:11:17 发布 · 1.4k 阅读

文章标签：

#Scrum

Scrum 专栏收录该内容

13 篇文章

订阅专栏

本文介绍了Scrum敏捷开发方法及其在TFS中的应用，探讨了如何通过Scrum提升项目管理效率，包括角色职责、工件使用、会议流程等方面的内容。

Hello，大家好～这是我们项目部第一期培训，主要内容呢，是TFS与Project协同工作。

1. 培训大纲

Agile与Scrum

介绍Agile与Scrum的知识。

可能有的同事就会吐槽了，明明是TFS与Project协同工作的培训，怎么会涉及到Agile与Scrum呢？这有两方面的原因。

第一个原因，最近公司在推广学习Scrum，也组织了两次视频培训，相信参加过的同事都会对Agile与Scrum有个大致的了解。那么，现在我们做一个结合项目部实际情况的Scrum试点与应用，是顺势而为的事情。

第二个原因，其实以前我们有过一次这样的培训，那会不叫Scrum培训，叫TFS培训，培训之后用了TFS一段时间效果不是很理想，我觉得其中一个原因是我们没有达成共识。

其实一开始部门要实施TFS我是拒绝的，因为，你不能让我用，我就马上去用。第一，我要先了解一下，并回答它的三个哲学问题，我不懂就去用，用了之后又没领会精髓，然后又来培训，PPT duang一下，很好很强大，然后你们回去用了之后，觉得效果根本没有这么好，这样聪明如你们一定会骂我。我实施Scrum有将近两周，感觉还不错，有一种滑板鞋在地板上摩擦摩擦的节奏感，所以我觉得Scrum真的有效。我用了之后是这个样子，希望经过这次培训，团队达到共识，你们回去用了之后也会是这个样子。

我们如何实施Scrum

实施模式决定我们的实施策略。这部分将立足我们项目部目前的实施模式，采用Scrum之后，我们的实施策略将会发生怎样的变化。

Scrum在TFS中的应用

将介绍TFS最新的Scrum 2013.4模板以及它在TFS中是如何使用的

TFS和Project协同工作

将介绍如何在Project中制定工作项，以及如何与TFS协同工作

2. Agile与Scrum

2.1 Agile是什么？

它是一种软件开发方法学，包括Scrum、XP极限编程、RUP统一开发过程、Crystal（水晶方法）、FDD（特征驱动开发）、DSDM(动态系统开发方法)、Lean精益生产等敏捷方法。

Agile的体系结构如下图，它囊括了上述所有敏捷方法，它是一种敏捷思想。

2.2 Agile价值观

以价值为导向

我们软件生产的最终目的是以优良的软件产品和优质的服务让客户满意，而Agile的原则之一，是通过可持续迭代及早交付有价值的可以工作的软件，这是开发过程中优先级最高的事情。

强调以人为本

人在软件开发中的作用是举足轻重的，力求沟通无障碍，重视开发团队成员有效的面对面交流、沟通与协作

快速响应变化

客户在没看到成型的软件产品之前，需求是模糊不确定的，因此我们开发出来的产品必然需要应对客户需求的频繁变更，Agile要求客户始终参与整个开发过程，不断获得反馈不断适应需求变更，从而使最终的产品充分符合客户的要求，双方都皆大欢喜。

2.3 Agile宣言

这种精神上的东西只有经过长期实践之后才会有更深层次的感悟，现在只能说说我的一个浅薄的理解。

个体和交互胜过过程和工具

传统开发过程过分强调流程和工具，而敏捷开发强调以人为本，沟通无障碍

可以工作的软件胜过面面俱到的文档

经历过多年的项目实施，大家也了解，文档从来都是为了项目验收而写的，真正开发过程中需要文档的情况是少之又少的，敏捷开发不是不注重文档，而是追求文档简洁，设计灵活，可以工作的软件才是关注的重点。

客户合作胜过合同谈判

开发符合客户设想的功能需要的是持续频繁的客户反馈，而不是依赖合同关于功能的陈述，客户全程参与我们的开发过程，他们可以直观地看到每个功能的演变，直至这个功能满足了他们的需要。

响应变化胜过遵循计划

计划赶不上变化，一味的遵循既定的计划会导致延期交付，如何在开发过程中寻求灵活性与稳定性的平衡，这是个值得反复商榷的问题。

2.3.我们为何需要Agile

这要从我们目前的项目实施现状说起。

长周期驻外开发的项目实施模式浪费人力资源和增加时间成本

（项目实施模式决定我们的实施策略，短期内无法改变这种实施模式）

我们的项目实施周期基本上需要一年到两年，而且开发人员是常期驻扎在甲方单位开展工作，那么这种长周期驻外开发的项目实施模式势必浪费人力资源和增加时间成本。

我们曾提过一个设想，就是把项目开发人员集中在公司开展工作，项目现场只留项目经理负责沟通与协调，但是要实现这个设想，要满足两个条件，第一是拥有一支实现实时保障、实时响应、敏捷开发的项目实施团队作为支撑，第二是我们的业务系统必须完全实现产品化。以我们目前的人员配备以及业务系统半产品化的现状，还实现不了，但是这将会是我们项目组的发展目标，我们要走产品化发展道路，打造一支敏捷开发项目实施团队，只有这样，才能真正开创市场与规模齐飞，利润与收入暴涨的局面。

不完整的瀑布式开发模式，造成绝大部分项目延期验收，软件质量不能令甲方客户满意

人员短缺固然是其中一个原因，更主要的原因是我们目前是以传统的瀑布式开发模式为主，遵循预先计划的需求分析、设计、编码、集成、测试、维护步骤顺序进行，严格来说，我们不是完整的瀑布模型，因为少了测试这重要的一环。我们目前的测试是以开发人员自行完成功能测试，由甲方客户完成可靠性测试和易用性测试。可以想象，客户心里是有多吐槽。这势必影响我们公司在甲方客户心中的形象，造成不信任情感情绪蔓延的局面。诸多因素造成软件质量问题，如果我们不改变这种开发模式，将会导致更严重的软件质量危机，到那时将回天乏力，为时已晚矣！庆幸的是，公司内部目前力推Agile与Scrum敏捷开发模式，这是我们突破现状走向产品化发展道路的契机。因此，我们转变开发模式，引入Agile与Scrum。

实施团队实行分布式管理模式，管理人员无法实时把控项目进度

我们的项目遍布大江南北，实施团队人员也分散各地，实行的管理模式是分布式的，导致管理人员无法实时把控项目进度。往往到了年底前两个月，为了回款才突击进度完成目标，相信这点大家也深有体会。

分布式管理模式的好处之一，就是我们的现场实施团队是相对自由的，项目工作任务基本自行安排，项目进展自行控制，基本上完成年底回款目标就行，但这要求现场项目经理具备较高的管理能力和执行能力。Agile的理念之一，就是信任开发团队，给予充分自由，可以说我们现在的分布式管理模式天然带有Agile的基因。

为赶工期，人员经常加班加点，一点也不愉快！

这点相信大家也深有体会了。

那么Agile是否能解决上述所有问题呢？答案是

Agile不是银弹，不能指望它能解决所有问题。

那么它到底能帮助我们什么呢？上面提到了Agile是一种软件开发方法学，它囊括了众多优秀的敏捷开发方法，我们不能所有方法都尝试，而Scrum是全球范围内应用最广泛的一种。所以我们也顺应潮流趋势，引入Scrum敏捷开发方法。

2.4 Scrum是什么

它是一种迭代式增量软件开发过程。这张图基本上囊括了它的所有要素。

三大角色：

Product Owner产品负责人
Scrum Master敏捷教练
Scrum Team敏捷团队

三大工件：

ProductBacklog产品待办工作项
SprintBacklog冲刺待办工作项
Working Software可工作软件

五大会议：

产品Backlog梳理会议
Sprint迭代计划会议
每日立会、Sprint评审会
Sprint回顾会

实施流程：

产品负责人PO负责产品需求的提炼、条目化、优先级排序，创建和维护产品待办工作项。
召开迭代计划会，PO讲解重要条目，由开发团队估算工作量和选择本次迭代工作项。
进入迭代周期开发，在这个过程中会进行每日例会，惯例回答昨天干了什么，今天要干什么，我遇到了什么困难。
一次迭代结束之后是迭代评审会，敏捷团队演示迭代成果，产品负责人以用户故事是否成功交付来评价迭代完成情况。
迭代反思会，也称回顾会议，这个会议主要是总结好的方面，改进不好的方面，同时提出解决方案。
Scrum Master在整个流程中扮演的角色是同时服务于产品负责人PO与开发团队，结合实际情况，提出适合的Scrum实施方案，确保Scrum过程的顺利执行，这个角色关乎到实施Scrum的成败。