建议使用以下浏览器,以获得最佳体验。 IE 9.0+以上版本 Chrome 31+ 谷歌浏览器 Firefox 30+ 火狐浏览器
请选择 进入手机版 | 继续访问电脑版
设置昵称

在此一键设置昵称,即可参与社区互动!

确定
我再想想
选择版块

无敌哥

发帖: 1粉丝: 2

级别 : 新手上路

Rank: 1

发消息 + 关注

发表于2019-7-8 14:25:41 1981 4 楼主 显示全部楼层
[专家内容专区] 【MVP·微话题】敏捷的本质到底是什么?

微话题 “敏捷的本质到底是什么?”

希望大家能够畅所欲言。如果大家有其他任何与敏捷相关的问题,也可以在本帖回复直接咨询MVP王立杰。

=======【华为云·微话题】敏捷的本质到底是什么? =======

成功产品的特性就是要以用户为中心,快速响应市场变化。在进入移动互联网时代后,这种特性表现的更加突出;对应的项目管理必须能够适应这种变化,如果沿用传统的项目思路来管理,过分强调需求的完备化、WBS分解、甘特图、关键链、大而全的项目计划、按部就班的进度追踪,肯定适应不了当前变化多而快的市场环境。

 

敏捷项目管理,作为最近几年的热点话题之一,已经逐渐成为国内外各大互联网公司的标配,根据最新Version One公司做出的统计,90%的实施敏捷转型的公司,在采用敏捷项目管理方式后取得了非常好的改进效果,缩短了产品交付周期,提高了产品质量,提高了客户满意度,同时提高了研发效率及员工满意度。

 

那么,相对于传统项目管理模式,敏捷的本质到底是什么呢?

期望看到大家精彩的评论:

1. 敏捷强调快速响应变化,是不是根本不需要做计划?

2. 唯一不变的就是变化,在敏捷模式,该如何掌控需求变化?

3. 敏捷中,该如何写文档?PRD还有需要吗?

4. 敏捷强调团队的自管理、自组织,对成员的能力要求到底是什么样的?如何促进团队成长?

5. 如果用一句话或几个关键词来描述敏捷,你会怎么定义?

微话题活动:参与本次微话题讨论,有机会获得优质评论奖,赢取书籍。

活动时间201978-722

参与方式:直接在本帖回复关于以上5个问题中的任意1个或多个问题的理解或评论

获奖方式:活动结束后,将由MVP 王立杰  选取出2名优质评论奖,各送出《敏捷无敌》书籍1本。

评奖标准:回复话题数量和内容质量。


举报
分享

分享文章到朋友圈

分享文章到微博

云集而动

发帖: 55粉丝: 9

级别 : 版主

Rank: 7Rank: 7Rank: 7

发消息 + 关注

发表于2019-8-8 08:38:42 来自 5# 显示全部楼层

感谢参与MVP王立杰的微话题。恭喜以下2位小伙伴获得本次微话题的“优质评论奖”:

奖项社区昵称奖品
优质评论奖ecstatic《敏捷无敌》1本
优质评论奖建赟《敏捷无敌》1本

请获奖的2位小伙伴尽快把联系方式(姓名、电话、电子邮箱、收货地址) 私信给我哈!o(* ̄︶ ̄*)o


点赞 回复 举报

ecstatic

发帖: 9粉丝: 6

级别 : 版主

Rank: 7Rank: 7Rank: 7

发消息 + 关注

发表于2019-7-17 15:04:06 沙发 显示全部楼层

1. 敏捷强调快速响应变化,是不是根本不需要做计划?
   计划是一个项目实践过程中非常重要的工作,它能够保证我们开发的方向性和可预期性,为此通常我们会制定一些文档和注意事项。敏捷开发也非常强调计划的重要性,但制定的过程却非常灵活。在敏捷开发迭代初期,开发人员会和客户一起按照需求的优先级和依赖关系制定一个2-6周的开发计划。这个计划的灵活性在于计划的构成不是按照任务数量来规定时间,而是根据时间来制定任务量,这就解决了需求变更导致的计划改变等问题。

2. 唯一不变的就是变化,在敏捷模式,该如何掌控需求变化?
    a.问卷调查、意见反馈、竞品分析,数据分析、同事反馈、用户观察等方式收集需求
    b.把需求用用户故事表述
    c.判断需求优先级
    d.安排人员实现需求
   
3. 敏捷中,该如何写文档?PRD还有需要吗?
   把文档拆分成好几个部分去写,最后才合在一起,
   需要,PRD除了讲解需求的作用,还是产品历史功能追溯、记录的作用,用来保证需求设计、开发实现、测试验证的过程是在同一个基准的理解基础上的,避免出现各自的想法不一致导致的产品形态走样。

4. 敏捷强调团队的自管理、自组织,对成员的能力要求到底是什么样的?如何促进团队成长?
        a.能力要求如下:
        初级敏捷团队
    1、Team内PO角色清楚,PO负责管理Product Backlog;

    2、PO是需求的主要来源,并负责并从各方收集需求,并对需求负责;

    3、PO负责Product Backlog优先级的确定,当变动发生时也是如此;

    4、Team中有一个人可以承担Scrum Master这个角色的工作,基本上由此人长期承担Scrum Master的工作;

    5、基本能够协调Team解决在Sprint内遇到的问题。但是对跨Domain的问题解决推动能力弱;

    6、由Scrum Master协助团队成员进行维护Sprint Backlog,并培养团队成员自行维护Sprint Backlog的习惯;

    7、Scrum Master负责主导和主持站会,站会在固定地点和固定时间,在标准时长内结束,Scrum Master对团队每个成员的工作内容都很清楚,可以通过站会发现大部分问题和风险;

    8、Scrum Master负责各种会议的如期进行,如plan meeting、总结会议、PRD reivew、ERD review、Code review、Case review等等;

    9、Scrum Master负责主导和主持plan meeting,给出工时的评估方式,给出本次sprint的计划内容和优先级别,引导大家进行sprint内容的拆分,引导大家完成工时的评估;

    10、Scrum Master负责主导和主持总结会议,主要由Scrum Master负责总结本次迭代的优点和缺点,并针对缺点制定出改进措施并进行跟进;

    11、Scrum Master负责监控风险和进度,并能知会给利益相关人;

    12、Team大部分情况下能够完成对DOD的承若;

    中级敏捷团队

    1、PO负责管理Product Backlog,Team认可Product Backlog内容;

    2、Team会协助PO收集需求,也会积极提出需求,Team认可需求并对需求负责;

    3、PO协助Team进行Product Backlog优先级的确定,当变动发生时也是如此;

    4、Team中Scrum Master这个角色的工作有Backup,当Scrum Master不在时,Backup可完全承担该角色的工作;

    5、完全能够协调Team解决在Sprint内遇到的问题。对跨Domain的问题解决推动能力较强,但对跨部门的问题解决推动能力较弱;

    6、团队成员自行维护Sprint Backlog的习惯已形成,Scrum Master只需监督和提醒;

    7、Scrum Master协助站会有效进行,站会在固定地点和固定时间,在标准时长内结束,团队成员对于其他成员的工作内容都很清楚,团队成员可以协助Scrum Master发现一些问题和风险,大部分问题和风险还是由Scrum Master发现;

    8、Scrum Master协助各种会议的有效进行,如plan meeting、总结会议、PRD reivew、ERD review、Code review、Case review等等;

    9、Scrum Master协助plan meeting有效进行,和团队成员共同商讨确定工时的评估方式、本次sprint的计划内容和优先级别,进而共同完成sprint内容的拆分和工时的评估;

    10、Scrum Master协助总结会议有效进行,和团队成员共同商讨总结本次迭代的优点和不足,能够针对不足制定出有效的改进措施并进行有效的改进,而优点能够继续保持;

    11、Scrum Master主导,团队成员参与监控风险和进度,并能定期通知给利益相关人;

    12、Team共同完成对DOD的承若;

    高级敏捷团队

    1、Product Backlog由PO发起管理,由Team共同参与讨论完善;

    2、Team共同提出和收集需求,共同对产品负责;
    
    3、Team共同对Product Backlog优先级进行确定并负责,当变动发生时也是如此;
    
    4、Team中任何一个人都可以承担Scrum Master这个角色的工作;

    5、可以帮助Team跨越Sprint中遇到的一切障碍,对跨Domain和跨部门的问题解决推动能力均较强,保障DoD按约定完成;

    6、团队成员自觉维护Sprint Backlog,Scrum Master定期检查团队成员维护Sprint Backlog的情况;

    7、团队成员积极地参加站会,站会高效地效进行,站会在固定地点和固定时间,在标准时长内结束,团队成员对于其他成员的工作内容都很清楚,团队成员积极提出问题与风险,和Scrum Master共同发现所有问题和风险;

    8、Scrum Master辅助,团队成员主导各种会议的有效进行,如plan meeting、总结会议、PRD reivew、ERD review、Code review、Case review等等;

    9、Scrum Master辅助,团队成员主导plan meeting,Team共同对工时评估的结果,本次sprint的计划内容及拆分结果,优先级别确认结果负责;

    10、Scrum Master辅助,团队成员主导总结会议,Team共同对本次迭代的结果负责,能够共同认识到不足的根本原因所在,后期所有团队成员都积极有效的改进,将不足逐渐转变为优点,而优点能够越做越好;

    11、Team共同积极监控风险和进度,并能及时通知给利益相关人;

    12、Team从专注功能实现专为专注产品实现,Team有能力识别产品的正确路线,共同促使产品不断被完善;

        b.团队成长需要:
    1、团队要学会在没有大而全的计划的情况下开始工作;

    2、团队要学会在没有详细需求文档的情况下,通过用户故事和交流分析和理解需求,开始设计和编程;

    3、团队要习惯于频繁递交代码和持续集成;

    4、团队是在高度透明的环境下工作,每个人的进展被所有人都了如指掌;

    5、团队需要进行结对编程,需要频繁的沟通和讨论;



5. 如果用一句话或几个关键词来描述敏捷,你会怎么定义?
       以用户的需求进化为核心,采用迭代、循序渐进的方法进行软件开发

评论
andyleung 2019-8-7 17:37 评论

给力!

... 查看全部
点赞1 回复 举报

建赟

发帖: 257粉丝: 15

级别 : 版主

Rank: 7Rank: 7Rank: 7

发消息 + 关注

发表于2019-7-22 13:26:21 板凳 显示全部楼层

1、 敏捷强调快速响应变化,是不是根本不需要做计划?

个人认为是非常需要的,因为市场的变化会促使客户重新调整需求,以获取最大的价值,因此敏捷强调“响应变化”,迅速调整策略,以帮助客户迅速对市场变化做出响应。由于产品需求的不确定性、甚至是未知的,敏捷项目团队很少能在项目之初建立一份类似于WBS任务分解的进度表和甘特图,但敏捷项目依然是有计划的,和传统的进度计划不同,敏捷的计划不是关注在完成项目的一个个活动或者说任务,比如说需求分析、概要设计、详细设计,模块一编码等等,而是关注在客户的需要,关注客户价值的优先级,其计划的对象是用户要求的功能


 2、唯一不变的就是变化,在敏捷模式,该如何掌控需求变化?

       需求规划完成了之后,我们要确保这些需求能在敏捷开发的过程当中实现。相比较与瀑布模式,需求规划完成了之后,提供一份完整的PRD就可以逐项开始开发了,敏捷模式下需求规划中的功能清单首先有可能不是一次实现,会分多次,可能中间还穿插了别的项目,其次是每个功能清单还是再拆分成开发任务去分别实现,再加上中间的需求变更,所以在需求实现的过程当中是要采取一些措施去避免实现中的困难的,比如需求实现的连续性问题,需求拆分的方式方法,需求变更的处理,敏捷开发过程当中问题的解决等。同时一个好的计划会议可以将需求拆分成可在一个迭代内实现的几个部分,再加上每日站会的过程跟踪,发现问题及时解决,最后通过敏捷测试及时验证已开发完成的条目,这样的过程基本可以保证每个需求的实现都是按照原先的需求规划来的。

      

      3、 敏捷中,该如何写文档?PRD还有需要吗?  

       在敏捷项目中,文档的价值不是通过数量或者是模板规范来体现它的价值。敏捷项目中的文档应该是有目的性的去编写,是为了解决某种问题,而不是为了文档而文档。为了达成不同的目的,不同的文档它的受众也是不同的。

对于PRD,个人感觉是需要的。原因如下:稍微大一点的团队产品经理未必能向每个人传达产品需求,这就需要有一个文档的形式来向项目的所有成员来传达需求,这就是文档的来源;由于产品经理经常会变更需求,经常爱拍脑袋,容易变卦,所以程序员就想到用一个文档来约束产品经理;测试人员需要根据产品需求文档来验收产品质量;当你的项目有新人进入的时候,可以让新人更快的了解产品。当你离职的时候,继任的产品经理也可以根据你的文档来熟悉产品迭代的内容;有利于你装逼。你面试的时候拿着一份写的很规范的PRD文档,面试官会觉得你碉堡的,哈哈。


      4. 敏捷强调团队的自管理、自组织,对成员的能力要求到底是什么样的?如何促进团队成长?

      个人认为对成员的要求有三点:A very good team player很好的团队合作者。敏捷强调团队,如果只是个人能力强而不懂得合作,这样的人在敏捷团队里就没法混Excellent communication skills优秀的沟通能力。这一点的重要性不言而喻,敏捷里最强调的就是沟通,最有效的沟通方式就是面对面的交流。那种只会埋头干活,不会沟通的不要Open minded, pro-active, and self-motivated敏捷团队成员必须能够敞开思想,随时接受新事物,积极主动,自我激励

   对于如何促进团队的成长,个人认为这不是几句话能讲清楚,明白的。

首先团队需要充分发挥团队的主观能动性;当适当放权,避免管的太细;对于版本一般两个星期会发布一个版本(可能是对内,可能是对外);同时要以身作则:从自己做起,让团队看到真实的例子;平衡心态:别让团队的反应乱了阵脚;循序渐进:耐心,逐步改进;谨言慎行:注意言辞,说话要基于团队的立场; 边走边学:尝试,反思,从错误中学习。对于考虑可选方案的方式有暴露问题:让团队看到问题;公开讨论问题:和团队讨论这个问题;静观其变:搁置问题,如果情况变得更糟糕,团队也许自己会发现问题; 暗度陈仓:说服团队内或团队之外的其他人认识到问题;根因分析:寻找问题的根本原因;教育团队:提供更多信息帮助团队找到解决办法; 予人权责:将此职责转交给团队或某个团队成员;在受阻时,可以想象其他教练面临同样的情形时所采取的措施。等等


       5. 如果用一句话或几个关键词来描述敏捷,你会怎么定义?

        从字面上理解,顾名思义,敏捷一词包含了两层含义,一是“灵活”——闪转腾挪,游刃有余;二是“快速”——天下武功,唯快不破。在这两层含义里,都包含了一个核心——躲避危险的能力。当变化无可避免成为常态时,我们干脆勇敢的面对、拥抱变化。所以,需要了解实现敏捷的理念,才能创造开辟适合于自己的踏上向“敏捷”转化的道路。



评论
andyleung 2019-8-7 17:37 评论

给力!

... 查看全部
点赞1 回复 举报

andyleung

发帖: 12粉丝: 4

级别 : 版主

Rank: 7Rank: 7Rank: 7

发消息 + 关注

发表于2019-7-25 10:45:42 地板 显示全部楼层

1. 敏捷强调快速响应变化,是不是根本不需要做计划?

不是,计划还是要做的,知识敏捷强调的是在基于原来的计划要支撑可以快速响应变化;

2. 唯一不变的就是变化,在敏捷模式,该如何掌控需求变化?

就是做每一个动作的时候,要必须考虑可以存在的变化有那些,预留好变化的改变空间;

3. 敏捷中,该如何写文档?PRD还有需要吗?

写文档就是必须简单够用就好不要存在多余的任何一句话,PRD个人觉得还是需要的,不然没有去收集需求信息,你如何开始项目呢?

4. 敏捷强调团队的自管理、自组织,对成员的能力要求到底是什么样的?如何促进团队成长?

就是团队的成员不单有团队的精神也必须要有整体的思维,要有项目整体观,也要做好自己的那部分;个人觉得团队个人发展都自己把自己看成一家公司去合作这样就是最好的;

5. 如果用一句话或几个关键词来描述敏捷,你会怎么定义?

快速迭代升级(类似git server的思维,软件不断迭代升级)


点赞 回复 举报

游客

富文本
Markdown
您需要登录后才可以回帖 登录 | 立即注册