美文网首页两周读完一本书
不知道敏捷就奥特了

不知道敏捷就奥特了

作者: 卢礼瑾EWBOK | 来源:发表于2016-11-19 23:36 被阅读4次

    “希望敏捷能够达到这一点,我们不再讨论敏捷,不再说‘敏捷软件开发’,我们仅仅说‘软件开发’,当然一定是敏捷的”。这是前言中的一段话,这句话给我留下了很深刻的印象。很显然,敏捷开发已经火成这样,而且能够感受到周围的人经常谈论,甚至如果再不好好认识一下,在IT行业中就属于奥特了。

    什么是敏捷开发?

    敏捷开发(Agile Development)是一种以人为核心、迭代、循序渐进的开发方法。

    可以怎么理解呢?首先,它其实不是一门技术,它是一种开发方法,也是一种软件开发的流程,指导我们用规定的环节去一步一步完成项目的开发;而这种开发方式的主要驱动核心是人;它采用的是迭代式开发;敏捷开发只写有必要的文档,或尽量少写文档,敏捷开发注重的是人与人之间,面对面的交流,所以它强调以人为核心。

    从Scrum认识敏捷

    关于Scrum的基本角色、专业词汇、基本流程不再赘述了,经过此次了解之后发现原来我们的团队已经在运用Scrum敏捷开发框架了,只是根据实际情况做了一些“实例化的裁剪”,原来我已经在跟敏捷打交道了。

    敏捷开发怎样引进才能适合本土?

    第一种方式:以体系和管理工具为中心,拿来主义地进行流程优化,即照搬硬套,用的过程中再逐步完善和优化,以适应组织需要。即先僵化,再固化,最后优化。这种方式,效率高,引进速度快,能立竿见影,但很有可能水土不服。另外,因为企业自身的业务方向,团队能力,对于敏捷开发流程规范的理解等条件不成熟的情况下,很容易引起员工的抵触情绪,很难深入推进,反而事倍功半,浮于表面。这种方式也是目前许多团队采用的,但都或多或少的存在一定问题。

    第二种方式:可以从企业自身出发,循序渐进的进行流程的优化。首先企业需要找到自身的痛处和目前管理方式需要优化的重点。总结当前项目执行过程中遇到的实际问题,然后根据问题的优先级,选择某些方面优先列入优化的计划,并针对组织在该阶段的管理水平,团队能力,想要达到的目标和结果等,进行有针对性的培训,辅导,执行和复盘总结,等后收到了实际效果时,再逐步开始其他方面的优化和改进。这种方式需要经历一个比较漫长的过程,很有可能在应用的过程中因为收效甚微而半途而废,但只要不断坚持不断总结,找到适合自己的方式去融入敏捷,相信会收获颇丰。

    团队自身需要注意什么?

    对于任何一个团队而言,无论是不是采用敏捷,非常重要的一点就是信守承诺。以Scrum为例,对于采用Scrum敏捷开发框架的团队,这点尤其重要。团队中的每个角色都需要具备一定的责任心和团队精神,对其他角色兑现承诺,只有这样才能保证可交付产品的质量。承诺主要分成以下四个层次。

    ●PO(Product Owner)对Team的承诺:Product Owner保证在Sprint计划会议前,把Product Backlog准备好,对于可能在当前Sprint将要做的需求,要足够详细;PO保证在Sprint进行过程中,不随便增删需求项;PO保证会准时参与计划会议、验收会议。

    ●Team对PO的承诺:一旦经过Sprint计划会议确定下来的东西,除非有极大不可抗力,一定要坚守自己的承诺,按时完成,即使加班。

    ●ScrumMaster对Team的承诺:ScrumMaster承诺会保护团队,保证团队在Sprint运行过程中不受外界干扰,专心完成承诺的任务;ScrumMaster承诺当团队遇到障碍的时候,帮助团队即时清除障碍。

    ● 团队成员对Team中他人的承诺:作为一个自组织团队,任务是认领的,一旦认领后,就意味着认领任务的人对所有人有个承诺,承诺会按时按质地完成;Scrum会有四个会议,团队成员要按时参加每一个会议,因为守时是对其他所有人的承诺。

    总的了解下来感觉敏捷要能在项目管理过程中很服水土的融合,除了需要leader的带领,更多的还是整个团队成员的积极参与和团队精神。

    对于敏捷宣言以及敏捷提倡的许多方法还是没有参透,后续可以加入进一步了解和学习的计划中。

    相关文章

      网友评论

        本文标题:不知道敏捷就奥特了

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