美文网首页
2-2.1敏捷需要全员参与

2-2.1敏捷需要全员参与

作者: Macfang | 来源:发表于2019-07-15 23:08 被阅读0次

第二章 变革要以人为本

2.1敏捷需要全员参与

1、不同角色参与者对敏捷的误解

    很多企业刚开始导入敏捷的时候,大部分人都以为敏捷转型与自己无关; 而感觉跟自己可能有点关系的人则认为,变革就像一阵风,过去后一切照旧。

    1)高管

        敏捷是一种项目管理方法,让下面的职能经理以及项目经理们搞敏捷就可以了。

    2)职能经理

        我们经理层都懂敏捷,但我们不干具体的活,团队自己搞就可以了。

    3)开发工程师

        领导怎么搞,跟我们没关系,我干我的活。领导让我干的时候,咱再动。

    4)产品经理、用户体验设计师(User Experience,简称UX)

        敏捷是研发团队的游戏,我们该咋干还咋干。

    5)测试工程师

        敏捷只在开发团队里转,咱们该怎么测试就怎么测。

2、不同角色参与者都需要做出改变

    如果大家都以为不关他们的事,那么敏捷转型到底关谁的事呢?其实,敏捷转型是一场涉及所有人的变革,所有角色都需要做出改变。

    1)高管

        高管不但是需要深入理解敏捷的人,更是组织转型的领导者和最终负责人。如果你不懂,或者懂了又不关心,那么敏捷转型就无法继续,因为每个员工都在看你的眼色行事。

    2)职能经理

        职能经理以为自己懂敏捷,但实际上在很多企业里成为转型障碍的往往就是职能经理。为什么会这样?因为很多职能经理其实不懂敏捷或者只对敏捷有肤浅的理解,但是他们却自以为很懂。此外,即使他们懂了也很难自我转变,因为改变自己比改变别人要难得多。如果你不服,那么说说看,如果作为职能经理的你真的懂了,为什么还吆五喝六的指挥团队怎么工作,还向团队要周报、日报,还用那些旧的度量体系衡量团队的工作进展?

    3)开发工程师

        你是产品每一行代码的真正交付者。你的交付方式、沟通和协作方式将会彻底改变。你闷着头,憋了好几天提交了一次代码,自己没测就直接仍给测试工程师,测试工程师提交了bug之后你也不着急解决。这种方式将一去不复返。

    4)产品经理

        产品经理的需求提供方式必须改变,不能再把几十页的需求文档扔给研发团队,然后就再也见不到人。你需要与团队一起梳理产品需求,并对它们进行拆分和优先级排序,更重要的是,你需要每天都能让研发团队找到你。

    5)UX设计师

        你花了一个月的时间做了那么完美的设计,但这样的效率跟不上团队的开发速度。所以你必须快起来,你的设计节奏要跟随团队的迭代而快速迭代。

    6)测试工程师

        如果你还在过着每日闷头用手测试、提交bug单的生活,那么你已经彻底被淘汰了。

    7)测试经理

        你不要因为自己有个庞大的测试部门而骄傲,你的部门越大,你越应该检讨为什么你的部门需要这么多的测试工程师。如果你所在的企业里,测试工程师人员与开发人员所占比例越高,说明你们企业的产品测试自动化成熟度越低。测试活动一定要逐步在团队里完成,而不是单靠测试部门来把质量关。敏捷发展到最终境界,就是测试部门逐渐消亡。

3、敏捷对不同角色参与者的价值

    每一个参与转型的人要的不是变革本身,而是变革给他们带来的价值。

    1)高管   

        如果你和你的管理团队领导转型比较成功,你的企业就会获得前面所述的敏捷转型的收益,从而实现你的变革愿景。

    2)职能经理

        如果你领导的部门转型比较成功,你的部门就会得到相应的收益。此外,如果你学会运用敏捷领导力,就能够逐渐感觉到团队的改变,他们再也不是以你为中心,一切等着你来监督才会使项目顺利推进。相反,团队会通过自我管理、主动协作来解决问题,并且他们会在自己的职责范围内敢于决定和承担结果。总之,你会发现由团队逐渐产生的由内而外的驱动力在激励他们工作。

    3)开发工程师

        你会发现自己的工程技能得到了极大的提高,即从前可能只是做模块的后端代码,现在可以不止做架构设计、编程,还能有机会在前端和后端都得到锻炼,还可以做自动化测试。你还会发现你的工作效率得到了极大的提升,即从前全手工做编译、集成、测试、部署,现在可以用学习到的各种自动化工具完成这些工作。这为一名开发工程师的职业发展打下了坚实的基础。   

    4)产品经理

        你可以看到自己提的需求在每个迭代中落地,而不需要等到最后一刻。你可以在每个迭代结束后变更需求或提出新的需求,团队便可以马上将其落实到产品中,从而让你的产品与市场或用户当下的需要更加匹配。你还会发现,团队跟你的协作更加紧密,团队更懂需求、更懂你,也更懂用户。

    5)UX设计师

        如果采用敏捷用户体验的设计方法,你会减少大量虽然精致、美丽却没有在团队中落地而浪费的设计稿。你会为能够频繁获取到用户对你的设计的反馈而兴奋。

    6)测试工程师

        你的测试工作会大大提前,你不再只是在项目后半段验证,而是全程参与需求的讨论,这增加了测试工程师对产品的话语权,以及对自身工作的自豪感。同时,你的工作效率会得到极大提升,因为你的工作以手工为主转变为全部以自动化为主。因此,你不会再继续做大量重复、枯燥的手工操作性测试,而是将精力放在测试的设计、需求的反馈,以及自动化测试的开发上。这有助于测试工程师的职业发展。

    了解更多内容,请微信关注:

    

    

相关文章

  • 2-2.1敏捷需要全员参与

    第二章 变革要以人为本 2.1敏捷需要全员参与 1、不同角色参与者对敏捷的误解 很多企业刚开始导入敏捷的时候,...

  • 敏捷开发之站立会议注意事项

    敏捷开发-站立会议要点: 1、站立会议全员都需要参与; 2、当值员必须提前准备,识别出问题和风险,做好协调; 3、...

  • 为什么改善需要全员参与?

    美国管理学大师彼得.德鲁克曾说过:“依赖天才或超人管理的机构都没有可能存续。只有凝聚了所有普通人之力,公司组织才能...

  • 浅谈敏捷开发每日站会-Standup

    什么是stand up 频率:每天举行 成员:敏捷开发全员参与 时长:一般10-15分钟的简短会议 内容:1、昨天...

  • Daily Scrum 每日站会

    每日站会,日常敏捷中的最重要的团队活动,必须团队全员参与,鼓励团队每日同步更新: 1)昨天我做了什么 2)今天我要...

  • 全员参与经营

    李光明 (稻盛哲学学习会)打卡第126天 姓名:李光明 部门:业务部 组别:利他二组 【知~学习】 全员参与经营 ...

  • 全员参与经营

    2018-07-28 (稻盛哲学学习会)打卡第96天 姓名:祝新华 部门:业务部 组别:待定 【知~学习】 经...

  • 全员参与经营

    2018-07-28 (稻盛哲学学习会)打卡第129天 姓名:王燕君 部门:分水碶 组别:利他三组 【知~学习】 ...

  • 全员参与经营

    (万尚学习会)打卡第145天 姓名:陆春菊 部门:财务部 组别:反省一组 【知~学习】 《京瓷哲学》001部分:第...

  • 全员参与经营

    企业如大家庭 每个阿米巴都独立自主地开展经营 每一个人都可以发表自己的意见 为经营出谋献策及参与制定经营计划 要求...

网友评论

      本文标题:2-2.1敏捷需要全员参与

      本文链接:https://www.haomeiwen.com/subject/rnzokctx.html