欢迎来到思摩特项目管理官方网站! 南京 | 镇江 | 扬州 | 常州 | 芜湖 | 马鞍山 | 滁州 等地区指定项目管理培训中心
    联系我们
  • 全国24小时免费咨询电话:
    400-805-8908

    welcome@smartpm.com.cn

  • 当前位置: 首页 > PMI-ACP培训 >

      ACP敏捷开发运用

  • 发布时间:2018-03-28  来源:思摩特 www.smartpm.com.cn  浏览量:
  • 一、知之为知之,并真实的告之
    敏捷开发,其实不仅限于敏捷开发,信任都是大家合作的基础。信任来自于几次成功合作的基础。其中,“知之为知之,并真实的告之”是一个重要的原则。我自己有一正一反的两个例子:
    A、 部署到生产平台上的系统,有一个统计存在误差,有两个可能的原因:程序存在Bug,另一个是业务逻辑设计有问题。前者是开发Team的责任,后者是PO的责任。经过验证,确实是开发Team的Bug,于是真实的告之管理层,得到的反馈是找到改善质量的办法,OK。
    B、 产品在试商用时,一个省公司的用户发现了问题,是邮件通知的,我们这里不能重现,于是以我们的判断告之管理层,并提出了解决方案。自己觉得不放心,第二天去用户的现场实际分析,和我们的判断场景截然不同。于是又向管理层重新做解释。在出现第二个问题时,再向管理层解释时,第一个反馈是:经过验证了吗?
    知之为知之,并真实的告之,反复的重复,就会建立信任。
    二、坚持原则
    敏捷开发中在每一个sprint中都会出现需求变更的情况,特别是增加需求的情况。Scrum理论上讲,Team会拒绝sprint内任何需求变更的情况,但实践中是不可能的,不接受就不会被用户验收,最简单的道理。这里的用户指的是最终用户、公司的管理层,而不只是PO。需求的变更,特别是增加需求,不但会增加开发的工作量,而且会更加测试的工作量,导致发布的产品质量存在问题。所以PM/SM在对待需求变更时一定要坚持原则:
    1. 首先要求PO给出变更需求的Business Value,PM/SM要和PO一起讨论,因为很多时候PO提出的变更需求是市场或者销售临时提出的,并不经过综合的论证
    2. PM/SM要根据变更需求给出影响的工作量,和现在的工作量进行比较。一定不要直接告诉PO不能接受变更的需求而不给出任何原因,或者只是告之影响太大,一定要给出数据,否则会导致情绪上的对立
    3. PM/SM需要给Team留出Buffer,因为变更的需求在短时间内不可能评估的非常准确。我个人的经验是Buffer一定至少有20%
    4. 即使老板自己布置的新需求,也要根据前三步进行分析,并将结果抄送给老板。即使当时老板会觉得不爽,但随后他会赞同你在遵守流程和原则。
    三、开发团队是主角?
    和开发团队的成员经常沟通,听到最多的就是“敏捷开发”中开发团队应该是项目的主导,不应该是业务(也可以说是PO)是主导,而在实践中一般都是业务是主导,开发团队是支撑,这是敏捷开发无法在国内彻底敏捷的原因之一。
    这应该是开发团队的误解。项目的主导是Business Value,PO更多关心的是Business Value,所以PO应该是项目的主导。开发团队可以进行“Self-Organization”,可以提出技术类的Story写入Product Backlog,但Product Backlog的优先级始终应该是以Business Value为出发点,如果开发团队认为某个Story的工作量很大,我们可以拆分此story。当然,在第一、二个sprint,技术类的story会实现的较多,主要是因为技术的infrastructure要先实现。
    内容导航
    四、独立的User Story
    敏捷开发有两个很有意思的观点:“尽量晚的做决定”和“尽量快的定义和实现”。前者是为了规避需求变更的风险,后者是为了快速提交。这些对项目的成功非常重要,但这两个观点看起来是矛盾的。决定的晚了,自然没有足够的时间实现,如何快速提交?敏捷中有一个实践,也是我们正在用的,可以很好解决这个问题,那就是将Backlog分解为User Story时尽量落实为松耦合的User Story。
    五、PO的能力
    敏捷开发中对PO(Product Owner)的要求是很高的,对产品的business value,Roadmap,产品功能,沟通能力等各方面都要可以独当一面。但现实中某些PO对business value没有自己的判断,只是从销售或者市场部门获得需求,同时在产品功能的细节上也没有深入的考量。我们公司现有的PO大多数是在30岁以上,在电信行业都有7年以上的产品经验,合作很好。但也有一位新的产品经理,最初只是做产品经理的助理,后来不知如何也可以设计产品,根本没有business value的概念,只是老板说什么就做什么,还经常自己造一些需求,功能的细节自己也想不清楚,很难沟通。直接的影响就是开发人员需要花费大量的时间帮助 PO分析需求,真正开发的时间就很少了,每次都很被动。为此,我们是这么做的:
    在团队中增加了“RA”(Requirement Analyst)的角色,每次由RA、PO、开发人员共同讨论。
    对RA的要求是既要有技术背景,同时也要可以站在用户角度去根据用户使用场景分析功能需求。其实RA和QA有工作重叠的情况,但为了提高开发效率,增加RA的角色是值得的。
    六、主动性
    敏捷开发要求PO(product owner)和Team要充分沟通,但在实践中往往会出现以下情况:
    1. PO在sprint planning会议中讲了Feature后,Team成员没有主动和PO进行细节的沟通,很多时候有不明确的地方,会按照自己的理解进行设计、编码
    2. 每日构建后,PO不会去review今天完成了哪些feature,是否有不符合需求的,而是要等到在testing server上之后再去验收
    原则上讲,双方的不主动是“习惯”使然,大家习惯于“各扫门前雪”,同时也会和东方人内敛的性格有关。我们在实践中是这样做的:
    1. 在制定sprint plan时,不会在sprint的末端再做Demo,而是将sprint分为更小的阶段,每一个阶段做一个正式的Demo,这样从制度上保证PO对产品的关注,更早的发现风险。
    2. 在绩效考核上,项目奖金的发放对象是PO和开发团队,即PO和开发团队作为一个整体对项目的成败负责,在我们公司PO的项目奖金比例是25%,开发团队是75%。项目是否成功由公司的管理层(其实就是PO的manager)决定。







    经典金牌培训 
    实战培训专家
    中国顶级企业项目培训团队
     

    南京思摩特(SMART)是一家专注于为客户量身定制各类企业管理培训、咨询服务,并可提供相关人才服务、出版发行的综合管理顾问机构。
    主营业务:PMP认证培训,项目管理培训,企业内训,项目管理公开课,项目管理咨询,ACP敏捷管理,产品经理培训认证
    我们的优势:量身定制、专注专业、追求不懈
    公司地址: 南京市雨花台区锦绣街7号绿地之窗D4-318室
    联系电话:400-805-8908
    QQ: 1637938979 2070698291 1258510210 
    QQ群:194584810 179196661 207501934
    网站地址
    http://www.smartpm.com.cn/
    论坛地址:
    http://bbs.smartpm.com.cn/
    公众邮箱地址:

    welcome@smartpm.com.cn 

  • PMI®, PMP®, PMI-ACP® and PMBOK® are registered marks of the Project Management Institute, Inc.

    电话:025-84535055 / 15295551366 / 400-805-8908 / 传真:025-84535055 / 邮箱:welcome@smartpm.com.cn / QQ群:179196661

    Copyright © 2009-2019 南京思摩特企业管理咨询有限公司 版权所有  苏ICP备11012816号-2  技术支持:软月互动  

  • 咨询反馈
    扫码关注

    PMP、ACP项目管理培训顾问-1

    PMP、ACP项目管理培训顾问-2

    思摩特公众号

    返回顶部