敏捷团队的组织与管理--- MPD软件工作坊培训感想(下)

注:由麦思博(MSUP)主办的2013年亚太软件研发团队管理峰会(以下简称MPD大会)分别于6月15及6月22日在北京、上海举办,葡萄城的部分程序员参加了上海的会议,本文是参会的一些感受和心得。

今年的大会延续往届模式,以产品创新、团队管理、架构设计、开发管理、测试管理等五个维度作为五个分会场的主题。对于今年来在软件研发中百谈不厌的敏捷开发的问题,大会从团队管理、开发管理等多个角度为与会者全面剖析敏捷开发中所涉及的种种问题,不单单聚焦于敏捷开发本身,更将视线拓展到管理整个敏捷开发团队上。

讲师都是站在自己的立场去阐述一些观点,所以有趣的是,有时你会听到一些完全相反的观点,但是从不同的角度出发,他们又有各自的道理。比如有人说质量高于一切,有人又会说用户体验高于质量。简单来说,要看业务需求,即所做项目的特点。比如同样是做网站,一个招聘网站,和在线证券交易网站的要求就可能不同,同样的对质量的敏感度也就不同。

回到正题,下面谈谈两门课中与敏捷团队的组织管理相关的话题。

敏捷团队自组织是怎样炼成的

我听的第一节课是“敏捷团队自组织是怎样炼成的”,讲师袁店明,是百度的敏捷教练,在做现在这个工作之前,他也是有很多时间实际团队的工作经验的。这节课着重讲敏捷团队的团队建设。一开始,讲师让大家提出分成小组,每个小组讨论,提出自己心目中的好的团队的特质。一开始大家认为没什么好说的,没想到集思广义,提出了接近20条特质,因为与会的都是有团队管理经验的,也多多少少接受过相关的培训,所以到最后,把大家说的集中起来,基本上就行成了我们要讲的主线,当然讲师还有一些个人的补充。

以下是印象比较深的自组织团队中的一些要素:

· 团队所有人掌握需求,从用户角度出发。

· 保持市场敏感性。

· 团队成员互相的信任很重要。

· 在团队中要形成统一的价值观,价值观不同产生矛盾,沟通解决不了根本问题。

· 快速反馈

· 勇于面对失败

因为我们每个人或多或少地接受过项目管理方面的培训,所以我想以上的内容大家都能比较清楚地理解,不需要细说。

袁老师的理念之一是团队管理中提倡高互动,这在后面几位讲师的课程中也有所体现。要让团队中的每个人消除戒备心理,顺畅的沟通,不会因为猜疑或别的原因影响信息的传递,这是我们作为团队管理者都要考虑的一个问题。

另外袁老师也讲了一些敏捷团队实践中的问题。比如有人问他敏捷团队需不需要架构师,他说肯定需要。同时他认为架构师必须写代码,不能脱离团队架在空中,不能画个图让别人实现,脱离团队做不好架构演进。

敏捷团队的人数,袁老师认为以7+-2为最佳。我们的团队就刚好符合J

袁老师还有一个观点,认为团队管理中要慎用激励,他没有细讲,想想觉得挺有深意的。

另外他还让人为Manager要关注每个人的愿望,给他发展空间,给不了他想要的未来,就宁可让他走。

产品创新管理

还有一节课印象也比较深刻,叫“产品创新管理”。讲师Ray Zhang,曾任微软Mac事业部与Excel产品组在大中华区的第一位项目经理。这节课讲的内容非常多,我挑一些重要的说吧。

张老师认为,领导力不等于管理能力,领导力很大程度上是与生俱来的,但是也不是说有领导力的人才能管理好团队,对大部分人来说,掌握一些管理的技能并合理运用,也能把团队管理得很好。

团队中的人,如果你逐个审视,会发现每个人浑身都是毛病。所以这样的挑剔其实是没用的,要学会用人之长,并帮助他提高,给他制定一个又一个小的目标,通过长期的帮助和训练来提高。

达到目标有很多途径:

  • 首先就是运气,但是这种方法不推荐使用,因为根本不可控。
  • 有Leadership的人,可以通过个人魅力,富有鼓动性的讲话来激励士气。
  • 控制:把人放到合适岗位
  • 什么工作什么时候完成,设置检查点。
  • 考核,事先约定好要达到什么目标。

张老师提出一个问题,如果有一件事情要开始做,领导决定怎么做,和团队讨论决定怎么做,哪一种方式好?大部分人回答说民主的方式好。但是张老师的答案是,只要事先决定怎么做,公开透明,效果其实是差不多的。所以有时leader要决定哪些事情其实不需要讨论,效率是把时间花在做事上而不是无休止的讨论上。

激励团队的方式有很多,比如:

  • 授权
  • 成就感
  • Mission
  • 美好前景
  • 搞定一件事的成就感
  • 认同感

在团队中要识别每个人适合以什么方式激励,激励方式应该和都考核有所关联。每个人的标准应该不同,不要把不周级别的人相比较,同时不要盯着每个人的缺点,要充分发挥每个人的长处。

在制定目标时,张老师提出,员工应该自己制定目标,领导可以适当辅助,而且由员工自己提出达到目标后的赏罚措施,当然这个目标要和团队的目标一致,目标要稍大于能力,而且目标应该是可以衡量的。当然衡量应该按照职位描述来做,不能主观评价。要拿相似级别的员工来比较,大范围横向对比。

有新员工加入时,最好的做法是不要对原有团队成员所作的工作做大的调整,但是等新人加入半年后,他的能力各方面都有变代,团队成员和他也经过了好的磨合,这时就一定要对他的工作,他所承担的责任做出调整。

建立学习型团队是如今很倡导的概念,张老师认为所谓学习型团队,就是每个人在每个阶段都能学习不同的东西,要做一个吸尘器型的人,在任何地方都能学习周围人的长处。

最后张老师提出,做为一个Leader,应当避免:

  • 把团队当成自己的延伸,用自己的标准来衡量
  • 在没有很好的领导能力时,不要以leader的方式来管理
  • 不要延续干活的风格,应该关注每个人协助
  • 有技术经验缺乏Engineering经验,风险控制等

要懂得情绪管理,帮助别人提高。而成熟的管理需要大约5年时间去磨练。

他同时也谈到了对招聘的看法,就是所以团队成员都应该参与招聘,要招别人愿意和他工作的人。不同的人面试,每个人考察不同能力,如果所以人都同意招这个人,才可以让他进来。任何一个人不同意,只要能说出合理的理由,就不要勉强。

而招聘最好的办法是推荐。因为人的很多特质很难在短时间做出评价。招聘时一些很重要的原则:

  • 招比自己更棒的人
  • 经验没有学习能力和适应能力重要
  • 校园招聘和行业内招聘不同
  • 自己的爱好和对工作的热诚比名校重要
  • 为工作不同年限的人设定不同的招聘目标

两天的课程,内容很充实,所以感觉时间过得也很快,但是培训中很多老师讲的东西,都值得深刻回味,在我们做工作和管理项目的过程中,或许会对我产生很大的启发,给我的工作带来深远的影响。

时间: 2024-10-24 11:57:16

敏捷团队的组织与管理--- MPD软件工作坊培训感想(下)的相关文章

敏捷开发的道与术---MPD软件工作坊培训感想(上)

注:由麦思博(MSUP)主办的2013年亚太软件研发团队管理峰会(以下简称MPD大会)分别于6月15及6月22日在北京.上海举办,葡萄城的部分程序员参加了上海的会议,本文是参会的一些感受和心得. 这次MPD软件工作坊培训,最大的收获就是培训者引导你了解了为什么,而不是直接告诉你该怎么做.其实只要清楚目标在哪,无论怎么走都是可以到的. 随便百度一下,我们可以了解到项目管理的定义是"在有限资源限定条件下,实现或超过设定的需求和期望".一句话形成了项目管理的铁三角,需求是范围,资源包括时间和

如何在大型开发组织的敏捷团队中实施CMMI

近年来,敏捷开发方法能够更好地适应现代软件开发,逐渐发展成为一种主流开发方法,也正在改变着软件开发过程.然而,敏捷开发方法常常被认为同CMMI过程无法共存,因为CMMI被看做是以规格化方法控制软件开发过程. 2008年,Hillel Glazer, Jeff Dalton, David Anderson, Mike Konrad 和 Sandra Shrum出版了<CMMI和敏捷方法:为何不彼此相容>一书,为那些既想保持项目过程可控又想体验敏捷开发灵活性的开发组织开启了一扇窗口.CMMI过程管

敏捷团队管理:把握介入团队的程度

转载请注明出处:http://blog.csdn.net/horkychen 来源 Check In, Don't Check Up (照看而不是介入!) 我从来不是微观管理者(micro-manager),特别是应用agile和Scrum之后.初入职场时,要不是太忙于和别人搅和在一起处理问题,我很可能就会成为一个微观管理者.但是当尽量避免同大家一起检讨细节问题时,仍要认真地照看(check-in)他们.我是从这篇文章(细小的成功多么重要)得到启示的.   介入(check-up) & 照顾(c

传统团队如何转变为敏捷团队?

问题 问:传统的团队如何转化为敏捷团队(步骤,要点,注意事项等)? 问:如果使用敏捷开发,在公司组织架构上有没有什么建议? 分析 在谈到何为敏捷团队之前,先看看传统团队的问题,不要把团队转化完了,问题还存在:换言之,解决问题是目标,转化团队是手段. 1.各部门打架严重 来自于分工中的灰色地带 / 各自目标和绩效的不一致. 典型的是开发/测试团队,扩展而言,还包括市场/销售团队. 后两者也很关键,很多时候开发和测试团队和谐了,联合起来和销售团队打架,公司的整体效率仍然上不去. 不过,如果没有在市场

如何打造敏捷团队 这是一场思想观念上的变革

ShineScrum公司创始人及国际Scrum联盟认证培训师(CST)--Jim Wang王军,10月15日受邀参加2016杭州云栖大会云效专场分论坛,现场为大家带来<How To Make Your Organization Agile?>演讲,为大家揭示敏捷领导力背后可以遵循的原则.云效专场分论坛以"用技术驱动企业提效"为主题,邀请业内多位技术大咖进行专题分享,共同演绎技术魅力!     敏捷,目前是互联网开发领域经常被谈及的热词,在Jim看来,敏捷是一场自上而下的变革

黄灵 | 敏捷团队的激励手段

题图:Volleyball team by KeithJJ@Pixabay 编辑:冷锋 敏捷团队的激励手段 作者: 黄灵 企业级精益敏捷实施专家 米么金服精益敏捷管理总监 敏捷团队与传统团队的最大区别莫过于其自组织.自管理形式. 既然是自组织自管理,在跟PO共同定下迭代目标以后,如何实现迭代目标就该是团队自己的事. 就这一问题,我在敏捷培训和咨询过程中,无数次被问到: 既然是团队自己决定怎么做,他们在估算的时候就可以放水,如何解决呢? 这种环境必然会造成一部分团队成员消极工作,本来可以完成5个任

怎么才能保证你的敏捷团队不会被指标毁掉

我认为敏捷社区要改变评测敏捷团队是否成功的方法.我们收集指标以及从这些指标中获取信息的方法实际上妨碍了我们做出能用的软件,而这才是最重要的东西. 强推个体指标有时会导致过于关注其他人,影响团队的协作.这会歪曲我们要评测的内容,摧毁我们的真实意图. 在我看来主要有两个问题: 观察者效应: 观察者效应是指对一个流程进行观测可能会影响它的输出.比如告诉一个团队你会密切关注他们的速度,该团队可能会为了加快速度而过度估算他们的工作内容.这在处理 故事点 时尤其危险,因为根本就没有依据可以判断估算是否有效.

敏捷时代的建模:敏捷团队的扩张除了代码还需要什么?

敏捷方法已经成为了当前软件开发的主流模式,可工作的代码(以及自动化测试)被认为是团队最重要的产出. 那么是否不再需要建模了呢?UML真的已死?我并不这么认为. 在本文中,我将探索在敏捷时代,建模方法依然适用并且扮演关键角色的所在.尤其在开发规模扩张到多个团队后,对整个系统的"Big Picture"达成共识将变得非常关键. 敏捷中的"设计"在哪里 虽然代码表现了事实,但它并没有表现事实的全部 – Grady Booch 在开篇部分,我将描述一个使用Scrum的敏捷团

关于软件测试的几点反思 - 关于测试团队的组织

这一篇是系列文章的第三篇,前面两篇分别谈了测试的必需性<关于软件测试的几点反思 - 测试是必需的吗?>,以及测试工作的一些内容<关于软件测试的几点反思 - 测试工作的三个阶段>,接下来想聊一下测试团队的组织. 要讨论这个话题,首先要讨论下测试人员本身的归属,因为通常是人多了才有组织的必要,很多东西都是一点点长出来的. 我在读研期间实习的一家公司,根本没有专职的测试人员,回头想想当时还是挺大胆的,因为做的是比较核心的系统,而且当时像我这种实习生都写了很多核心的涉及金额计算的代码,然后