2016-08-12 13:38:43 diyal 阅读数 1483
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10404 人正在学习 去看看 CSDN讲师

##游戏敏捷开发项目管理之我见(三) 沟通

一、沟通过程中的思路
这里写图片描述
1、询问信息

* 明确要问什么,沟通一定要带着目的性,否则就是扯闲篇了。最好是列好条例。
* 信息是否完备,沟通的信息是否完备了,是否都得到自己想要的答案了。
* 信息是否准确?是否掺杂感情色彩,或是片面之词。

2、工作任务

* 安排的工作任务,明确需要对方知道的信息有哪些?安排一个模块开发,首先要让对方知道,这个模块是要干什么,什么时候完成,任务否否紧急,你的诉求是什么,是否有困难,困难的解决方案是什么,通过什么帮助或者调整可以解决这些这些困难?如果delay了怎么办等等。
* 确定对方已经理解,最好是通过反问的方式来确定
* 最重要的是明确任务完成的时间节点,开发者肯定会觉得这个时间没办法给出,毕竟在什么都没干的情况下,谁都不敢轻易给出具体时间。所以最好是在开发者给出的时间留出一定的弹性。

二、沟通技巧,说话的艺术

1、不要说“但是”,而要说“而且”
“我觉得这种想法很好,而且,如果在这里再稍稍改动一下的话,也许会更好……”

2、不要说“首先”,而要说已经
跟老板汇进度,“首先”一词出口,就让人觉得你还有很多事要做,却不会认为你已经做了一些事情了。而且这样的讲话会给人一种悲观的感觉,而往往项目开发需要良好积极乐观的氛围。
“是的,我已经相当熟悉这项工作了……”

3、不要说“错”,而要说“不对”
一个leader最让人钦佩的,是让成员甘心情愿付出,当然犯错误是在所难免的,所以我们必须要注意的是,不要说“错”,而是说“不对”,这样在语气上,更让人接受。总之不管什么情况,你要有跟成员一起面对错误的态度。
“你这样做的确是有不对的地方,咱们最好是为此承担责任”

4、不要说“仅仅”
在一次Bug修改会议,或是一个需求评审的时候,你是这样说的“这仅仅是我的一个建议……”
这样说是绝对不可以的,这样一来,你的想法、功劳包括你的价值都会大大贬值。本来利于项目,团队的一个主意,反而让同事觉得你的自信心不够。
“这就是我的建议”

5、不要说“本来”
你和你的谈话对象对某件事持不同看法,你却轻描淡写“我本来持不同看法的”。这样不但没突出你的立场,反而让你没了立场。类似还有“的确”和“严格来讲”
有威信的领导都是直截了当“对此我有不同看法”

6、不要说“务必”而是“请你”
7、不要再说“老实说”

2013-01-16 20:21:55 viscent_huang 阅读数 19
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10404 人正在学习 去看看 CSDN讲师
敏捷开发与项目管理实战系列文章发布在IBM developerworks中文站上:
敏捷项目管理实战之质量管理
本文以作者黄文海的项目管理实践为基础,介绍基于经验过程控制(Empirical Process Control)模型、缺陷预防以及敏捷价值观的敏捷质量管理思想及其实践。希望通过本文为广大项目管理人员提供质量管理的一些思路和经验分享。

敏捷项目管理实战之在敏捷开发中引入 Story 演示
Story 演示活动可以帮助敏捷开发团队提高开发质量、降低返工带来的质量低下与进度滞后的可能性。本文以作者黄文海的实际敏捷开发与管理的经验为基础,分享了具体实施 Story 演示的注意要点以及如何控制 Story 演示的成本。本文分享的不仅是一个具体的敏捷开发实践,更是一种敏捷开发的思想和思维方法。

敏捷项目管理实战之《孙子兵法》在敏捷项目管理中的应用
《孙子兵法》中的论述虽然是关于战争的,但是其思想在项目管理领域对我们也是有借鉴意义的。本文以作者黄文海的实际项目管理经验为基础,分享了《孙子兵法》在敏捷项目管理中的应用。希望能够对读者的实际项目管理工作有所启发。

敏捷项目管理实战之团队自我管理
自我管理是敏捷开发中的重要管理思想,但是鲜有文献提及相关实践。本文将以作者黄文海的管理实践为基础,探讨自我管理的具体实践。

敏捷项目管理实战之进度管理
本文以作者黄文海的实际敏捷项目管理经验为基础,分享了关于敏捷项目进度管理中缩短项目工期的实践、进度信息的获取与核实、进度信息的展现、传播及其激励作用。并介绍了项目进度管理与风险管理、期望值管理间的关联。希望对读者的实际管理工作有所启发。

[url]http://www.ibm.com/developerworks/cn/views/rational/libraryview.jsp?search_by=%E6%95%8F%E6%8D%B7%E9%A1%B9%E7%9B%AE%E7%AE%A1%E7%90%86%E5%AE%9E%E6%88%98[/url]
2012-08-09 20:24:45 viscent_huang 阅读数 29
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10404 人正在学习 去看看 CSDN讲师
本文以黄文海的项目管理实践为基础,介绍基于经验过程控制(Empirical Process Control)模型、缺陷预防以及敏捷价值观的敏捷质量管理思想及其实践。希望通过本文为广大项目管理人员提供软件质量管理的一些思路和经验分享。
[url]http://www.ibm.com/developerworks/cn/rational/r-cn-agiletestingbestpractice[/url]
2019-05-16 09:59:58 xuexiiphone 阅读数 215
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10404 人正在学习 去看看 CSDN讲师

前言

此篇文章目的在于整理博主与好友就敏捷开发如何在中小型团队中应用的一点思路。本文梳理的目标包括以下几点:

  1. 探讨如何基于华为软开云实现敏捷开发管理;
  2. 如何在分配项目任务时,化被动分配为主动领取;
  3. 通过项目一二季度对比,确认本方法的使用效果;
  4. 其他临时想起需要探讨的内容;

可能需要说明的目标有点多,大概率会分阶段完成。可能会写个(1),(2),(3)之类的吧,最近确实也比较忙~

问题一 基于华为软开云实现敏捷开发管理

下面是本公司使用上的一些情况,或许其中某些观点不是特别正确,欢迎大家一起探讨;
另外,我要做的肯定不是如何贯彻敏捷思想到项目中,而是如何通过我手中的软开云软件,结合一定的敏捷思想,高效的管理的公司研发团队。

问题背景:

在项目管理使用过程中,我没有使用Scrum方式,而是使用了看板方式创建项目基础管理架构。原因有以下几点:

  1. 之前公司一直用看板方式管理项目任务,大部分的项目成员熟悉这种方式的运作。
  2. 软开云在看板基础上,提供了迭代周期的概念,从而通过看板+迭代的方式,将敏捷开发的思想贯穿到项目中;
  3. 都说一千个读者,有一千个哈姆雷特。在我的管理生涯中,对我而言敏捷思想最重要的特质就是快,快速开发、快速实施、快速的推向客户、快速的回笼资金。天下武功,唯快不破。
  4. 刚好我们有一个项目进入了一个比较特殊的阶段,一年期的信息化项目,60%的任务是增量模块开发任务,40%的任务是维护任务。我个人认为这个阶段的项目很具有代表性,所以特意拿来研究一下。
  5. 目前项目的结算周期是按照季度的,这将是我后面划分迭代的一个重要标准

实现思路:

  1. 首先我需要创建迭代周期,在软开云中的这个迭代周期,我并没有将其定义为敏捷开发中的一次迭代。这个迭代周期在我的设计中,是让我统计该周期内我需要完成的任务,以及任务的完成情况,并且最后能够导出相关的任务清单便于结算的一个周期。此处相当于取巧做了一些操作,因为按照之前公司内部管理规定,这个周期应该叫结算周期,一个结算周期中包含多个迭代周期。

  2. 在现有的看板管理的工作项(新建、进行中、已解决、已测试、已关闭)中,我需要添加两个工作项,一个叫“本期任务”,一个叫“部署中”。

    本期任务,顾名思义就是本次我需要完成的工作。这个才是通常意义上的敏捷开发中的迭代概念。这个任务中,会有项目经理、产品经理以及测试经理一起讨论本期任务中需要包含哪些内容,并且这些内容是经过团队人员(最起码是核心人员)确认的。

    部署中,则是根据公司实际项目实施流程,我们会在镜像服务器上进行分批测试,但可能由于各种原因并没有按批次部署到相应的生产环境中时,就需要将需求放到部署中这一列,从而保证部署时,能够在生产服务器上验证(只能是特别初级的验证,因为无法在生产服务器上创建数据)所有的需求,不产生遗漏。但通常意义上来讲,我们将每一期任务,都归结到一次版本部署上,保证任务的收尾是干净的。

  3. 现在产生了一个问题,如何在大迭代(结算周期)中,统计小迭代(本期任务)的完成情况,如何跟踪,管理。在实际操作过程中,我使用的是标签功能。我会在每一个本期任务中,分配一个小迭代标签,例如2019-2-HH-1。意思就是这是2019年2季度HH项目的第一次迭代。华为软开云中,提供了一个高级搜索的功能,能够通过标签查询。这里面它会自动的将我们添加过的标签以下拉列表的形式展示出来,从而实现小迭代版本的管理功能。

基于本公司项目运作的情况,当我每个月导出报表的时候,我能够看到几个事情:

  1. 当前周期内,团队一共做了几次迭代
  2. 每次小迭代中,都修复了哪些内容

一点心得:

当团队渡过了最开始由于更换项目管理工具导致的混乱期之后,收益反馈主要来源于以下几个方面:

  1. 由于每期任务是由开发团队和产品经理一起确认的,优先级由他们协商决定,因此无论是对客户,还是对团队成员来说,工作强度的安排更加合理。
  2. 目前的工作进度更清晰,对我而言,如果有时间可以关注一下具体的版本迭代,如果时间不是太充裕,我只需要看一下仪表盘中的数据,对大体情况有个了解即可
  3. 能够看到全部的任务需求以及本期要做的任务需求,对于员工的自主性而言,有了很大的提高,大家做事情更专注于眼前的内容。
  4. 最重要的是,结算统计更方便和快捷了,以前总是要花几天的时间梳理所做的开发和维护工作,现在1个小时基本上就搞定了。
  5. 通过方法改造,同时也对我们的项目经理和团队核心人员提出了更高的要求,要求他们工作更主动,对业务理解更深入,同时具备更强的沟通能力。
2019-05-24 14:28:43 xuexiiphone 阅读数 53
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10404 人正在学习 去看看 CSDN讲师

上一篇文章:
【软开云】基于华为软开云用敏捷思想管理项目团队一点思路

之前我们花了一些篇幅讨论如何用一种“近乎无赖”的方式实现了敏捷迭代式的项目管理。这种管理方式可能不适用于大多数企业,但最起码来说,它解决了困扰我们团队很长时间的问题。下面,我们花一些时间讨论一下第二个问题

问题二 如何在分配项目任务时,化被动分配为主动领取

公司内部在讨论这个问题时,发现想要实现主动式的领取任务,需要在完成一些必备前提的基础上实现。

前提

1. 明确任务价值
经过研讨后发现,想要明确任务价值,就必须为任务赋予一些公认的衡量标准。就像商品可以通过货币进行买卖一样。我们决定通过为任务确定标准时长来衡量任务的价值。

所谓标准时长,公司内部可以按照整体员工的业务研发水平而定。以我们公司为例,有从业十几年的老码农,有刚刚毕业的小鲜肉,我们将标准时长确定为2年左右工作经验完成该模块的时间。通过确立标准时长,就能够反映出任务的价值。

标准时长的制定,一定是能够通过大多数人的参与和认同。只有这样才能让大家打心底接受这套标准。而不是对标准怨声载道。标准时长的制定同时要根据公司情况实时调整。创业公司和大公司不一样,如果将员工比作食材的话,大公司的厨师只需要提出食材需求,自然能做一桌子精美佳肴。创业公司往往有着种种自身局限性,因此厨师更应该根据现有食材,量身定做一桌合口的美味。

2. 自我能力认知
员工想要领取任务,就必须衡量自己能力和完成任务所需能力之间的差异。并不是一味的完成高时长的任务才能够获取最高的收益。不断的完成自己能够快速完成的任务,且提升自我能力。只有这样,才会在任务收益上获取最大值。

3. 自我成长认知
部分年轻员工面对任务体系时,由于业务或者技能的不熟悉,导致本可以挑战完成的任务不敢于去接手。此时就需要团队内其他成员给予帮助,帮助他分析这个任务所存在的难点和技术要求,并且帮助年轻员工分析自身能力能否胜任这个任务。

我们的标准是,只要大家一直在完成稍稍有点难度的任务,不断的自我拔高。那自我成长的未来是可期的。同时,在这个过程中,个人和公司的收益也会呈现一个良好的上升曲线。

4. 价值兑现
通过阶段性价值兑现的方式实现反馈激励。保证大家领取任务的动力。
千里奔波只为财,永远不要想着只靠理想就能笼络住所有人。

弊端

这种领取任务的方式一定会有一些弊端存在,由于公司并未全面展开使用本制度。所有目前的弊端只能是通过反推使用过程推导出来的。

1. 高手不断领取低阶任务
把这个制度比作游戏里面的任务奖励方式。那么肯定会存在一种行为,就是高等级的账号不断刷次一级的任务,以求短时间内通过最少的消耗获取最高的经验以及奖励值。

我想这种问题,想要避免,那就一定要给出部分溢出值。溢出值的目的就是在于让中高级的员工有意愿通过学习、研究等方式,完成高等级的任务。

例如,做一张分析数据报表,标准时长是5天,在需求分析过程中发现设计实现上可能有一些需要研究攻关的疑难点,于是在标准时长的基础上,附加学习时长2.5天。这样的话,可能会避免一些这类情况出现。

此外,最重要的仍然是项目经理(或者敏捷教练)这个岗位对任务的领取进行宏观调控,从而保证任务完成的质量和迭代进度。

2. 对项目经理的任务描述能力略高

在需求任务的制定、分配标准时长的过程中,我发现这个制度有个根本性的难点在于需要一个能够将不同需求描述转换成任务说明的项目经理或产品经理。这样一个角色的存在,能减少大量由于需求不明确产生的沟通成本。

例如:
客户需求是,将某字段标准化,填充内容仅限于(A,B,C,D);
项目经理转换后:将某字段从String类型改为Dictionary字典类型,字典值从(A,B,C,D)中选择。且要注意处理该字段的历史数据类型不匹配问题。

如果有这样的一个项目经理存在,那么大部分员工领取任务时,实际上是无需二次沟通的,也不存在理解需求的时间成本了。这种方式,某种程度上能够降低对开发员工的能力要求,从而部分降低公司运营成本。

当然,哪怕是普通的项目经理,依然可以尝试这种制度,我也期待大家尝试后分享的结果。

敏捷开发初学体会

阅读数 1814

没有更多推荐了,返回首页