敏捷开发讲义---如何打造敏捷团队

PPT下载链接：http://pan.baidu.com/s/1bncprTd

敏捷开发分享讲义-修改版

第1页：个人信息

就不做自我介绍了，我的基本信息就在PPT第一页。7月26日，也就是上周六，我和会成参加了一天的培训，关于敏捷开发的。参加这次培训我们俩主动申请的，因为这次培训适合的听众除了中高层领导、项目经理、产品经理之外，还适合有软件经验希望往项目管理方向发展的人士。“不想当项目经理或者项目主管的IT屌丝是真屌丝”，不想成为真屌丝，所以参加了培训。但这次跟大家分享是被婷姐逼的（开个玩笑！嘿嘿！）。虽然时间不长，但是还是有些有价值的理念和工作方法，所以耽误大家一点时间，今天由我跟大家做其中一部分内容的分享！下周由会成做另一部分的分享。

 

第2页：分享背景

22d—>7.0h—>1.0h

敏捷开发设计的内容比较多，按照那个讲师的计划讲完所有的课程是22天（其中专业人才培养课程是9天，包括：优秀需求分析师、优秀软件设计师和优秀系统分析师的培训各3天。项目经理培养的课程也是9天，包括：项目管理、项目质量和项目评估各3天，中层管理领导培训课程4天，包括：中层领导能力的训练和绩效考核各2天）。22天的课程，这哥们只讲了一天（7小时，本来规划师6小时讲完的，因为内容多又拖延了一个小时）。不少内容都没有讲到，讲到的内容也不是很详细。短时间内无法消化，现在跟大家分享的时间很有限，不会超过1个小时。所以只能讲其中部分内容：如何打造敏捷团队。

 

第3页：分享标题

如何打造敏捷团队

 

第4页：内容大纲

这四点是我们培训那天的学习目标。我今天主要和大家分享第二部分：如何构建敏捷土壤，就是如何打造敏捷团队。敏捷本质和项目管理方面我会提一下，还有关于“学会敏捷需求分析实用技巧”，主要是会成在下周的某一天和大家做一个分享。我们首先了解下敏捷的本质。敏捷这个词很火热，我们经常听到它，而且敏捷确实被很多公司一直运用着，不仅在软件项目研发方面，也运用到了军队、零售行业、学校管理等等。到底什么样的团队才算是敏捷团队，敏捷到底是什么？下面我们从两个方面来了解下敏捷的本质。

 

第5页：敏捷的本质

1. 敏捷的核心基础

2. 敏捷的特点

第一个是敏捷的核心基础，第二个是敏捷的特点。

 

第6页：核心基础

我们在同一条船上

就像地基是建房子的基础一样，那么敏捷的“基地”到底是什么呢？网上各种版本都有，用一句通俗的话来讲就是“我们在同一条船上”。这句话有两层意思：一是项目团队所有的成员都在同一条船上，二是所有员工和公司在同一条船上。这个听起来好像很简单，就两句话，但是没有公司能完全做到，尤其是第二条。因为要做到这两点需要建立在强大的物质基础之上，否则很难的。所以我们常常看到一个项目中，最着急的永远是项目主管，因为整个项目团队中就他的利益最大，一旦项目出事了，老板肯定会找项目主管，不会找团队中其他的人。所以项目负责人还是要帮助那些跟你在同一条船上的人，和你一起着急的同事。这个“基地”打得越结实，楼房才能建得更高，这个项目团队才能站得更高，看得更远。这样的直接结果就是：团队每个人都在进步。现在我们自己思考：我们在同一条船上吗？这里不作讨论，只供大家思考。接下来我们了解下敏捷的特点：

 

第7页：敏捷的特点

1. 所有人对项目成功负责。

2. 所有人直接需求驱动地工作。

3. 所有人都需要跨领域地工作。

4. 持续交付、迭代前进。

5. 小步前进，持续改进。

6. 有效、简单。

这里我们简单了解下就行。1.所有人都对项目的成功负责，并不是只有项目经理一个人着急，忙个不停。2. 所有人直接需求驱动地工作，而并不是技术驱动地工作。因为需求一旦确定，就不应该修改了。所以需求的确认是很重要的，需要和直接研发产品的人沟通好。3. 所有人需要跨领域地工作。设计和研发、美工和设计，测试和研发都是可以跨领域工作的。4. 持续交付、迭代前进。5. 小步前进、持续改进。6. 有效和简单是敏捷开发最直接的特点。敏捷的目的就是为了“简单和高效”，最后是盈利。

 

第8页：

如何打造敏捷团队？

 

第9页：团队概念

设计、美工、研发、测试、实施等等

既然是分享，想跟大家小互动一下。我问下老刘吧，一个简单的问题：随便挑一个你正在做的项目，说出现在有几个人？（你肯定会说一个人或者说事两个人，还有咏爷。）这是不对的，除了研发人员，首先得包括项目负责人吧，还有设计、美工、测试、实施等等，只有和项目有关的人，都算项目团队成员。这是我们很多人常犯的一个概念上的错误，问研发人员你们这个项目团队有几个人，他只会说研发人员的人数，不会把测试人员算在里面。你问测试人员，你们项目组有几个人，测试人员也会只会把研发人员算在里面，把自己都抛弃了。好，下面我们通过介绍两个经典的团队架构，导出优秀的团队应该具备怎样的特点。

 

第10页：经典团队架构

SCRUM团队架构

MSF团队架构

第一个是SCRUM团队架构，大家有谁听说过吗？好，没有就好！（好，知道的人不多就好！）现在很多人把SCRUM和敏捷划等号。第二个是MSF团队架构，这个团队架构，上周五涛哥给大家讲过，MicroSoft Solution Framework，微软解决方案框架，后面我也会给大家简单介绍一下。我们首先来聊聊SCRUM团队框架。

 

第11页：SCRUM团队架构—创始人

这么经典的团队模式，我们至少得知道他的创始人是谁。SCRUM是由两个美国佬提出的：JS和KS。这两个都挺传奇的。JS再哥们今年快60了，起初是飞行员，参加过美国越南战争，飞行超过100次任务。11年军旅生涯结束之后，获得科罗拉多医学院的博士。先后担任过11家软件公司的CEO、CTO。KS也很牛，这哥们比JS正好大十岁，45年出生。刚开始是做商船经理，说白了就是管海上运货商船的。后从事软件开发40多年，曾给IBM大型机开发系统软件，自己也创过业。两人在一个IBM项目合作时候提出的SCRUM。下面我了解下这个团队主要有哪些角色构成。

 

第12、13页：SCRUM团队架构—角色

角色主要分为三个：1. 是产品负责人PO，即ProductOwner。2. 是Scrum主管SM，即Scrum Master，此SM非彼“SM”。3. 是开发团队Team。PO主要的职责是为产品提供愿景，确定范围和优先级。这个提供愿景很重要，大部分时候只有项目经理和主管才知道项目愿景，这个项目做成了，有多好多好，可团队其他成员根本不知道。这也是导致有时候只有项目经理一个人为项目着急的原因之一。像这张图一样，只有站着的那一个人看到前面美丽的景色，坐着的人根本看不见，即使喇叭声音再大也没有，最多是应付一下！要是拿喇叭的人说：“大家使劲划啊！前方的沙滩都是比基尼大妞啊！”大家想想这种效果会怎样。哈哈！

 

第14页：SCRUM团队小结

每位成员都对项目成功发挥独一无二、不可替代的作用。

各成员可能经验、能力等不尽相同，但都有条件有机会成为一等一的高手。

可让各成员为项目成功各展所长。

可让各成员有充分的成长空间。

此架构应是阳光开明、激励进步、让人身心愉快的。

 

第15页：MSF团队架构

MSF团队上周五涛哥讲过，这里我就简单介绍就OK了。MSF团队是已沟通为中心，团队成员之间的关系是：相互依赖，相互协作，平等。大家都对项目或产品的成功发挥自己所长，缺一不可。

 

第16页：MSF团队的核心思想

项目团队中每个人都是同等重要的，

项目团队由各专业人士组成的，

每位成员在自己的专业领域发挥领导作用，

每位成员对项目的最终成功负责。

 

第17页：优秀团队应该具备的特点

所有成员同等重要，每位成员都是主人翁，

能力高的人更有责任推动项目组人员提高水平，

学习、总结、进步。

前面两点，我们前面都提到过，这里不再过多解说。第三点：学习和总结是过程，进步是结果。怎样学习？怎样总结？给人的感觉总是很朦胧。我这里抛砖引玉，给大家分享下自己的一点经历。

 

第18页：抛砖引玉之学习总结

1）每周五研发部的技术分享或者说经验分享

2）Android小组阶段性的代码走查

3）坚持写技术博客

前面两点是我在上家公司的经历，也是我参加工作第一家公司的经历。第三点是我从参加工作以来一直在坚持做的一件事情。引用上周五涛哥讲的“紧急和重要”的关系，学习和总结属于“重要但不紧急”这一类的。学习重要吗？当然重要，紧急吗？当然不紧急。随着时间的推移，会转变为“即紧急又重要”的事情。所以我们常常感叹：书到用时方恨少！当然大家也有自己的学习方法。

 

第19页：如何看待“犯错”？

软件研发是创造性和发明性的工作，不犯错是不可能的。大家赞同吧？其实其他部门也是一样的。孔子都说：“人非圣贤，孰能无过？”

 

第20页：如何看待“犯错”？

但是我们得知道犯错的原因，犯错分为两种：高级错误和低级错误。你是因为低难度的或者是反复做过的工作犯错，还是因为高难度的工作犯错？那如果是前者，那就是犯低级错误，领导应该少批评并多帮助其改进；如果是后者，我们应该鼓励“犯错”，在高难度工作中犯错进步是最快的，鼓励“犯错”其实就是鼓励进步。

 

第21页：“犯错”有感！

失败不是成功他妈，总结才是成功之母！

敏捷的本质和打造敏捷团队就分享到此。接下来咱们聊聊项目估算、计划和跟踪。

 

第22页：

项目估算、计划、跟踪

项目整个流程应该是：估算-->计划-->跟踪-->交付

 

第23页：项目估算

我们先看下粗糙的估算：（展示图片）几个人讨论，取个平均值，差不多就OK了。这样还算好的，有时候领导直接冲过来把功能大概跟你讲一下，需求也不完全清晰，就让你给项目估算个时间。你估算的时间短了，领导说：“这是你说的啊，到时候得准时完成啊”，完不成你就死定了，就算加班勉强完成了，到时候出问题你也死定了；你估算的时间长了，领导又会说：“这么点功能要开发这么长时间呀！”，又让领导误以为我们没有信心或者能力不行。那怎么估算才合适呢？

 

第24页：项目估算

我们在看看比较细的项目估算。至少应该分别从这四个方面对项目进行估算：需求细化（确定），软件设计，代码实现及修复缺陷，测试。这样做出来的估算相对而言比较有依据可言。应该是比较好的一种估算方法。

 

第25页：项目计划

按功能模块做项目计划，以时间为节点，并指定相应功能模块的负责人。

 

第26页：项目跟踪

项目跟踪应该有这么一个表格：todo将要做的，doing正在做的，done已经做完的，filished通过测试的。

 

第27页：内容回顾

将内容给大家回顾回顾即可。

 

第28页：6min短视频分享

直接放视频即可，效果应该不错。

 

第29页：Thank You！

祝大家周末愉快！