V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
passerbytiny
V2EX  ›  程序员

推荐一本“老”书——硝烟中的 Scrum 和 XP,有额外的推荐点:产品与开发的关系、可持续的工作时间

  •  
  •   passerbytiny · 2019-04-18 10:36:48 +08:00 · 933 次点击
    这是一个创建于 1807 天前的主题,其中的信息可能已经有所发展或是发生改变。

    主题

    书籍信息:

    核心推荐点:

    • Scrum 实践
    • 众多实践要素,能帮助人区分“快”和敏捷。

    额外的推荐点:

    • 时间估算是开发团队独有的权利,故事重要性是产品负责人独有的权利。
    • 如果产品负责人想当甩手掌柜,就整死他(见摘录)。
    • 一天 = 6 小时,实践说明加班起负作用(见摘录)。

    感概

    一直以为敏捷开发在大多数时间里都是探索阶段,最近才通过 Scrum 等进入了大范围实践,现在发现自己错了。这本书翻译版本是 2008 年出版的,可能是 2006 年编写的,而当时作者已经有了至少一年成功的 Scrum 实践。现实的情况很可能是:2006 年 Scrum 已经证明很好了,然而大公司因为体量太大只能慢慢转换,最近才完成标志性的转换( Win10 更换发布计划、Java 更换发布计划……)。


    摘录内容一

    有时候产品负责人会不太情愿跟团队一起花上几个小时制定 sprint 计划。“嘿,小伙子们,我想要的东西已经列下来了,我没时间参加你们的计划会议。”这可是个非常严重的问题。
    ...
    在某些情况下,团队对故事做出的时间估算,跟产品负责人的想法不太一样。这可能会让他调整故事的重要性;或者修改故事的范围,导致团队重新估算,然后一连串诸如此类的后续反应。
    如果产品负责人还是坚持没时间参加怎么办?一般我会按顺序尝试下面的策略:

    ...
    推迟 sprint 的启动日期,直到产品负责人找到时间参会为止。同时拒绝承诺任何交付。让团队每天都可以自由做他们最想做的事情。

    摘录内容二

    在讲述 Scrum 的书和文章中,大多数都是用小时而不是天数来估算时间。我们也这样干过。我们的通用方程为1 个有效的人-天=6 个有效的人-小时

    很多有关敏捷软件开发的书都声称:加班工作在软件开发中会降低生产率
    经过几次不情愿的试验之后,我完全拥护这种说法!
    大约一年以前,我们中有一个团队(最大的团队)在疯狂加班。现存代码库的质量惨不忍睹,他们不得不投入绝大多数的时间来救火。测试团队(同样也在加班)根本没时间来认真地做质量保证工作。我们的用户很生气,小道流言也快把我们活活吞掉了。
    几个月后,我们成功地把大家的工作时间缩短到了适当的范围。他们正常上下班(除了有时候在项目关键期要加班以外)。令人惊异的是,生产率和质量都取得了显著提高。
    当然,减少工作时长绝不是带来改进的唯一因素,但我们都确信它的影响很大。

    1 条回复    2019-04-18 14:10:28 +08:00
    passerbytiny
        1
    passerbytiny  
    OP
       2019-04-18 14:10:28 +08:00
    结束语摘录:

    哦,最后请不要忘记......

    这只是一份工作而已,不是么?
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   2450 人在线   最高记录 6543   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 636ms · UTC 15:56 · PVG 23:56 · LAX 08:56 · JFK 11:56
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.