Recomendados
Mais conteúdo relacionado
Destaque
Destaque (19)
Mais de AHAConference
翻转组织
- 1. Imagination at work. Fang Jianguo & Huang Zhe Apr 17, 2015 翻转组织 --强监管环境下大型医疗设备企业中启动敏捷转 型
- 2. 2 GE Title or job number 5/5/2015 我们是谁 黄喆方建国 滕振宇
- 5. 成年礼—懵懂的探索 5
- 6. 从内向外的变革 6
- 7. 成年礼--团队自设计 7
- 8. 成年礼:SM竞选 8
- 9. 成年礼:团队组建规则 9
- 12. 成年礼:团队守则 1
- 13. 成年礼:横向联盟雏形 13
- 14. 14 GE Title or job number 5/5/2015 第二个故事：成长的烦恼 码农翻身做主人后，速率腰斩！！！ 成年礼让团队站了起来，但团队还需要时间学习走路
- 15. 15 GE Title or job number 5/5/2015 成年团队学步三部曲 第一步：迈出“扛事儿”的前 脚—勇担当、善担当 第二步：跟上“能力”的后 脚—先功能、后联盟 不断前进：互激励，共前行
- 16. 16 GE Title or job number 5/5/2015 第一步：迈出“扛事儿”的前脚—勇担当，善担 当 通过引导，把项目经理管理 ，转变为团队自己管理 团队为自己制定的目标后成年礼 挑战：团队需要学习如何自己管理进度、质量和发展方向
- 17. 17 GE Title or job number 5/5/2015 第二步：跟上“能力”的后脚—先功能 “群狼”workshop 结对编程2.0—男女结对，干活不累 ! 打造功能纵队的关键是促进团队内部有效的学习 功能纵队 挑战：团队中对功能熟的只有一两个人，其他队员无法发挥
- 18. 18 GE Title or job number 5/5/2015 第二步：跟上“能力”的后脚—后联盟 组件设计联盟：关注组件设计，提升内在质量 测试验证联盟：关注验证技能，提升验证有效性 打造横向联盟的关键是守望，抓住机会，建立机制 挑战：团队专注在功能团队的目标上，忽略了横向协作
- 19. 19 GE Title or job number 5/5/2015 不断前进：互激励，共前行 各团队的Sprint Report & 互赞结 果 团队之间相互感谢 互激励：通过营造“比、学、赶、帮”的氛围，促进团队不断成长 挑战：团队持续前进的动力在哪？
- 20. 20 GE Title or job number 5/5/2015 团队成长三字经 文化 组织 • 成人礼，始自立。 引导 • 学前行，重引导。 自管理 • 勇担当，善担当。 学习 协作 • 先功能，后联盟。 自激励 • 互激励，共前行。 成长 • 积跬步，至千里！
- 21. 21 GE Title or job number 5/5/2015 大象起舞：敏捷传染病 软件敏捷带动了整个研发部进入了敏捷节奏 敏捷 Planning Daily meeting Daily CollaborationReview
- 22. 22 GE Title or job number 5/5/2015 总结：组织转型三板斧 成年人 功能纵队 横向联盟
Notas do Editor
- 医疗背景介绍 上一个项目情况 这个项目情况 引出变化。 我们是来自GE医疗外科软件团队的的XX,XX,还有我们的敏捷Coach Daniel.今天要分享的题目是,翻转组织,说得是在敏捷实践中关于团队和人的那些事. 为什么想分享这个题目呢？因为我们觉得我们团队的经历，对那些采用传统的软件开发方法，还没接触敏捷实践和刚接触敏捷实践不久的团队和人来说，还是有一定代表性的，可能带给大家带来一些敏捷实践中的启发和思考。大家可能有所了解，GE医疗是一家传统的大型工业公司，在医疗设备的研发，生产，销售中有非常深厚的基础和悠久的历史。而且，在医疗设备制造领域，还面临着各种各样法规与机构的监管与约束，这也导致项目的研发面临很多困难与挑战。我们团队是做外科手术中使用的成像设备，这种医疗成设备。在我们上一个产品的开发中项目，历时两年多，软件团队的开发方法采用的是RUP,那时候还没有采用敏捷的方法和实践思想，在项目的后期软件测出了很多bug,软件开发工作从开始到结束一直是项目的瓶颈，最后项目结束时比之前的计划延期了半年。在这一个项目开始前，软件团队开始尝试去做一些改变，期望能够改善一些不好的情况。从目前的观察来看,这个项目还算进展的很顺利.说来也巧，就在今年，公司需要我们当前正在开发的项目能够满足客户需要，早日上市，为了实现这一目标，经过多方讨论与评估，,软件团队的多个角色人员都发挥了作用,为达成这一目标作出了贡献,最后得出需要通过调整项目的部分scope来才能达成目标。调整scope的工作进展的非常顺利，没有对当前的工作造成任何影响。同时也已完成的工作也没有因为调整scope而产生浪费。所有已完成的功能都是项目调整范围之内的。工作都是有价值的。这件事情如果发生在上一个项目，是很难想象的。那么，在这中变化背后，我们的团队到底发生了什么样的变化呢，我们对我们过去一段时间的变化进行了整理，并在此分享给大家，希望能能对大家有所帮助。 背景放一个Carm
- 上一个项目的反思 反思后的尝试 Coach的观察 Manager与coach的讨论 引出成年礼 在上个项目结束后，我们软件团队的manager,组织大家对上一个项目进行了总结和反思，总结后，开始推动团队解决之前的主要问题：问题暴露得太晚。于是开始了一些敏捷实践的尝试。最初的尝试过程中，我们的manager 带领着团队中较资深的工程师讨论并定义了team的组建，以及敏捷开发过程的的步骤与方法。在今年年初时，敏捷教练团队(也就是Daniel他们)来到我们团队，经过几天的观察和评估后，敏捷教练团队就跟我们的manager指出我们当时主要存在的问题有团队之间的依赖比较严重;团队更像technical team, 不像feature team;每个team都维护一份PB，影响了从business的优先级角度去计划和完成feature.要解决这些问题，需要对组织架构作一个调整。Manager非常认同coach的这些观察和总结，然后在manager的强烈支持和大力推动下，决定对整个team进行一次组织架构的调整。下面我们请Daniel描述一下当时manager在于coach进行相关的沟通后做出进行组织架构调整的。（介绍coach与manager的交互及为何要通过自组织设计). 决定要调整组织架构之后，接下来便须要考虑如何进行组织架构的调整了。首先需要定义的组织架构的框架。即整个软件Team到底要分成几个scrum团队，每个团队几个人。谁担任PO，Scrum master有几名，Architect如何定义。整个组织架构的框架是在manger综合考虑多方因素后定义下来的。接下来的问题是scrum 团队如何产生，SM如何产生。仍然是在Manager的大力支持下，采纳了coach的建议，决定采用自组建的方式产生各个scrum团队和SM。 那么为什么要采用自组建的方式来产生scrum团队和SM呢，我们请Daniel给大家解释一下他们当时的所思所想. 当我们得知要自组建团队的消息后，很多人都对这种自主建团队的方式感觉到很好奇和担心，一方面是没想到经理会这么放心的让大家自己做决定，另一方面也担心，这样出来的结果能行吗，会不会对整个Team带来不好的结果。通过这个过程我们可以看出，所有这些变化的开展和推动，我们的manager在其中发挥了关键的作用。
- 上一个项目的反思 反思后的尝试 Coach的观察 Manager与coach的讨论 引出成年礼 在上个项目结束后，我们软件团队的manager,组织大家对上一个项目进行了总结和反思，总结后，开始推动团队解决之前的主要问题：问题暴露得太晚。于是开始了一些敏捷实践的尝试。最初的尝试过程中，我们的manager 带领着团队中较资深的工程师讨论并定义了team的组建，以及敏捷开发过程的的步骤与方法。在今年年初时，敏捷教练团队(也就是Daniel他们)来到我们团队，经过几天的观察和评估后，敏捷教练团队就跟我们的manager指出我们当时主要存在的问题有团队之间的依赖比较严重;团队更像technical team, 不像feature team;每个team都维护一份PB，影响了从business的优先级角度去计划和完成feature.要解决这些问题，需要对组织架构作一个调整。Manager非常认同coach的这些观察和总结，然后在manager的强烈支持和大力推动下，决定对整个team进行一次组织架构的调整。下面我们请Daniel描述一下当时manager在于coach进行相关的沟通后做出进行组织架构调整的。（介绍coach与manager的交互及为何要通过自组织设计). 决定要调整组织架构之后，接下来便须要考虑如何进行组织架构的调整了。首先需要定义的组织架构的框架。即整个软件Team到底要分成几个scrum团队，每个团队几个人。谁担任PO，Scrum master有几名，Architect如何定义。整个组织架构的框架是在manger综合考虑多方因素后定义下来的。接下来的问题是scrum 团队如何产生，SM如何产生。仍然是在Manager的大力支持下，采纳了coach的建议，决定采用自组建的方式产生各个scrum团队和SM。 那么为什么要采用自组建的方式来产生scrum团队和SM呢，我们请Daniel给大家解释一下他们当时的所思所想. 当我们得知要自组建团队的消息后，很多人都对这种自主建团队的方式感觉到很好奇和担心，一方面是没想到经理会这么放心的让大家自己做决定，另一方面也担心，这样出来的结果能行吗，会不会对整个Team带来不好的结果。通过这个过程我们可以看出，所有这些变化的开展和推动，我们的manager在其中发挥了关键的作用。
- 上一个项目的反思 反思后的尝试 Coach的观察 Manager与coach的讨论 引出成年礼 在上个项目结束后，我们软件团队的manager,组织大家对上一个项目进行了总结和反思，总结后，开始推动团队解决之前的主要问题：问题暴露得太晚。于是开始了一些敏捷实践的尝试。最初的尝试过程中，我们的manager 带领着团队中较资深的工程师讨论并定义了team的组建，以及敏捷开发过程的的步骤与方法。在今年年初时，敏捷教练团队(也就是Daniel他们)来到我们团队，经过几天的观察和评估后，敏捷教练团队就跟我们的manager指出我们当时主要存在的问题有团队之间的依赖比较严重;团队更像technical team, 不像feature team;每个team都维护一份PB，影响了从business的优先级角度去计划和完成feature.要解决这些问题，需要对组织架构作一个调整。Manager非常认同coach的这些观察和总结，然后在manager的强烈支持和大力推动下，决定对整个team进行一次组织架构的调整。下面我们请Daniel描述一下当时manager在于coach进行相关的沟通后做出进行组织架构调整的。（介绍coach与manager的交互及为何要通过自组织设计). 决定要调整组织架构之后，接下来便须要考虑如何进行组织架构的调整了。首先需要定义的组织架构的框架。即整个软件Team到底要分成几个scrum团队，每个团队几个人。谁担任PO，Scrum master有几名，Architect如何定义。整个组织架构的框架是在manger综合考虑多方因素后定义下来的。接下来的问题是scrum 团队如何产生，SM如何产生。仍然是在Manager的大力支持下，采纳了coach的建议，决定采用自组建的方式产生各个scrum团队和SM。 那么为什么要采用自组建的方式来产生scrum团队和SM呢，我们请Daniel给大家解释一下他们当时的所思所想. 当我们得知要自组建团队的消息后，很多人都对这种自主建团队的方式感觉到很好奇和担心，一方面是没想到经理会这么放心的让大家自己做决定，另一方面也担心，这样出来的结果能行吗，会不会对整个Team带来不好的结果。通过这个过程我们可以看出，所有这些变化的开展和推动，我们的manager在其中发挥了关键的作用。
- 成年礼的几部分内容 内容背后的逻辑 在决定了进行组织架构的调整后，在coach的引导和帮助下，我们整个团队便举行了成年的仪式---成年礼，也就是我们的团队自设计过程。 那么成年礼要怎么怎么帮助大家走向成年呢？组织架构中还有两大部分内容没有确定，一是团队成员，而是Scrum master。 考虑到Scrum master这角色是为team 服务，是team的仆人？这就决定担任这个角色需要考虑本人的意愿并team的认可。因此决定SM 采用竞选的方式产生。 确定了产生方式后，在竞选开始的前两天，coach也提前在团队的微型群放风出，让大家提前准备。我当时还挺担心竞选会不会因为缺少竞选者冷场，当时共需要选出2个sM，在Coach的忽悠与引导下，结果共8名竞选者参与竞选，大家的热情非常高涨，竞争空前激烈。 SM候选人倒是产生了，但是SM的主人还没有产生，主人还没有，仆人当然还不能确定下来。因此，接下来需要组建出team。我们总共需要产生4个team。那么到底要组建出什么样的呢？怎么组建这4个team呢。为了让所有成员明白这个问题。在coach的引导下，大家给出了很多组建team的规则和点子。大家给出了很多很好的点子，像全功能团队内，像男女搭配，能力高低搭配。加班能力搭配等。在确定出大家都认可的这样一些规则后，就开始按照这些规则，开始第一轮的组合与调配，形成了4个team的初始版本。初始版后，大家再一起按照已确定的规则一个team一个team的review,并指出每个team不满足规则的bug.然后进行第二轮的改bug,调整。形成最终版的team。 事后，4个团队及manager对大家自发组织形成的团队结果非常满意.manager表示这一结果超出了预期，甚至比Manager自己带领着团队中几个资深工程师讨论定义出的团队结构更合理。
- SM选举情况场景介绍
- 介绍与细节的展示。
- 有了
- 有了
- 有了
- 欢天喜的的码农翻身做了主人后。。。。 速率减半 认领任务时，只考虑团队的学习，不考虑项目 功能团队运作不畅（功能团队） 保证了交付，内部质量堪忧（虚拟团队）
- 小孩子走路
- 将团队的目标和项目目标、部门目标进行对齐。 团队目标大会。（后成年礼）
- 侧重说功能团队
- 两步走起后，剩下的 团队之间相互激励 每个Sprint在SOS retrospect上，团队秀出进展 经理和PO给出反馈 团队互相点赞 赞数最多的团队分享好的做法
- （撬动文化，翻转组织） （坚定信念，耐心引导） （变被管理，为自管理） （加强学习，促进协作） （变被激励，为自激励） （循序渐进，逐步成长）