敏捷开发讲义---怎样打造敏捷团队

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页：核心基础

我们在同一条船上

就像地基是建房子的基础一样，那么敏捷的“基地”究竟是什么呢？网上各种版本号都有，用一句通俗的话来讲就是“我们在同一条船上”。这句话有两层意思：一是项目团队全部的成员都在同一条船上，二是全部员工和公司在同一条船上。这个听起来好像非常easy，就两句话。可是没有公司能全然做到，尤其是第二条。由于要做到这两点须要建立在强大的物质基础之上，否则非常难的。

所以我们经常看到一个项目中。最着急的永远是项目主管，由于整个项目团队中就他的利益最大，一旦项目出事了。老板肯定会找项目主管。不会找团队中其它的人。所以项目负责人还是要帮助那些跟你在同一条船上的人，和你一起着急的同事。这个“基地”打得越结实，楼房才干建得更高，这个项目团队才干站得更高，看得更远。这种直接结果就是：团队每一个人都在进步。如今我们自己思考：我们在同一条船上吗？这里不作讨论。仅仅供大家思考。接下来我们了解下敏捷的特点：

 

第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！

祝大家周末愉快！