• 《硝烟中的Scrum和XP》书摘(1)


    Nokia的Scrum标准:
    1. 迭代要有固定的时长(TimeBox),不能超过六个星期。
    2. 每一次迭代的结尾,代码必须经过QA的测试。
    3. Scrum团队必须有产品负责人,而且团队都清楚这个人是谁。
    4. 产品负责人必须有产品的Backlog,其中包括团队对它进行的估算。
    5. 团队必须有一个燃尽图,而且要了解他们自己的生产效率。
    6. 在一个Sprint中,外人不能干涉团队的工作。
    Backlog是Scrum的核心,从根本上说,他就是一个需求、或故事,或特性组成的列表,并且按照重要性进行了排序,一定是客户想要的东西,并且用客户的语音进行描述,没一个条目是一个故事(Story),建议每个故事包含这些字段:
    1. ID(统一标示)
    2. Name(名称)
    3. Imp(重要程度)
    4. Est(初始估算)
    5. How to demo(如何做演示)
    6. Notes(其它)
    每一个故事有3+1个变量(范围、重要性、估算)+质量,无论如何不能在质量上让步。

    质量分为内部质量和外部质量:
    1. 外部质量是用户可以感知的,如运行缓慢,让人迷糊的界面等。
    2. 内部质量一般指用户看不见的原素,它对系统的可维护性有深远的影响,如系统设计的一致性、测试覆盖率、代码可读性等。
    记住,在松散的沙滩上永远不能建立起精美的楼阁,经验证明牺牲内部质量是一个糟糕透顶的想法,现在省下来的一点时间,接下来的日子,你就要一直为它付出代价。

    在Scrum中一切事情都是有时间盒的,到时必须交货。

    “这个Sprint让大家不太好过,但是我们应该看到它的正面影响,整个团队从中获益匪浅,下个迭代会议会更有效率。”

    学会按照时间盒安排工作,学会制定各种合乎情理的时间盒,这对sprint会议的长度同样有效。

    典型的Sprint时间表,每一个小时休息10分钟:
    1. 30分钟的总体介绍,概括产品的Backlog。
    2. 20分钟的时间估算。
    3. 1个小时的Story选择,计算生产率。
    4. 1个小时的站立会议安排和将故事拆分为任务。
    比较理想的一个Sprint长度为3个星期,(目前公司每日的Build版本,发布到测试部进行测试,应该是一个自动化测试的过程,而人工测试的应该是每个月发布的正常版本)

    半死不活的目标比什么都没有强。

    在Sprint中包含多少个故事由团队决定,而不是产品的负责人或其它人,但是产品负责人要对sprint中放入哪些Story产生影响。

    自动生成故事卡的脚本下载地址:http://blog.crisp.se/henrikkniberg/2007/12/18/1197973740000.html

    计划指派的点数:0、1/2、1、2、3、5、8、13、20、40、100、?、Coffee。

  • 相关阅读:
    My first blog in cnblog
    浅析JavaScript中this储存
    input 文本框密码框的只读属性
    Js 数组——filter()、map()、some()、every()、forEach()、lastIndexOf()、indexOf()
    jquery使用$.getJson()跨域大数据量请求方法
    JS中关于clientWidth offsetWidth scrollWidth 等的含义及区别
    JS性能优化
    npm 创建 node.js 项目
    css 垂直居中的几种方法
    字符串转数组
  • 原文地址:https://www.cnblogs.com/Duiker/p/1231609.html
Copyright © 2020-2023  润新知