|
首先看一下一个完整的Sprint流程图：
接下来，我们将按照流程图分析一个sprint周期的全过程。
例如：有一条故事“为数据库表user建立索引”。这个故事的本意是提高用户的检索性能，但是我们可能会发现索引并不是性能的瓶颈。 指出如何解决问题的应该是开发团队，产品负责人只需要关注业务目标。 二、一个故事（Story）、或者说backlog条目需要的字段 ID Name Importance 重要性、优先级 Initial estimate 初始估算 ——单位是man-day（人-天）。估算不保证准确无误，但是要保证相对的正确性（比如，估计2个点的要是4个点的一半） How to demo 怎么演示 Notes 注解 额外的故事字段： Track(类别) ——当前故事的大致分类,例如“后台系统”或“优化”。 Components(组件) ——例如“数据库,服务器,客户端”。团队或者产品负责人可以在这里进行标识,以明确哪些技术组件在这个故事的实现中会被包含进来。 Requestor(请求者)——可能需要记录是哪个客户或相关干系人最先提出了这项需求,在后续开发过程中向他提供反馈。 Bug tracking ID(Bug 跟踪 ID)——故事与 bug之间的直接联系 三、准备Ｓprint计划会议 前提条件——在Ｓprint计划会议前，要确保产品backlog井然有序 产品backlog存在 对一个产品而言，只能有一个产品backlog和一个产品负责人 所有重要条目已经根据重要性评分。（Ａ 100分，Ｂ20分，只是表示Ａ比B重要，不能说Ａ是Ｂ的5倍） 产品负责人理解每一个story的含义，不过不需要知道如何实现，但是必须要知道它为什么在这里。 产品负责人之外的人也可以向产品 backlog 中添加故事,但是他们不能说这个故事有多重要,这是产品负责人独有的权利。他也不能添加时间估算,这是开发团队独有的权利。 Ｊira可以用作bug 跟踪系统 四、Ｓprint计划会议 非常关键，是Ｓcrum中最重要的活动 目的、作用：举办 Sprint 计划会议,是为了让团队获得足够的信息,能够在几个星期内不受干扰地工作, 也是为了让产品负责人能对此有充分的信心。 Sprint计划会议产生实实在在的成果： sprint目标 团队成员名单 sprint backlog sprint演示日期 每日站立会议的时间和地点 产品负责人必须参加 原因在于,每个故事都含有三个变量,它们两两之间都对彼此有着强烈依赖。范围(scope)和重要性(importance)由产品负责人设置，估算(estimate)由团队设置。在 sprint 计划会议上,经过团队和产品负责人面对面的对话,这三个变量会逐步得到调整优化。 对开发团队说： 绝对不能在质量上让步 质量分为内部质量、外部质量 外部质量是系统用户可以感知的。运行缓慢、让人迷糊的用户界面就属于外部质量低劣。 内部质量一般指用户看不到的要素,它们对系统的可维护性有深远影响。可维护性包括系统设计的一致性、测试覆盖率、代码可读性和重构等等。 一般来说,系统内部质量优秀,外部质量仍有可能很差。而内部质量差的系统,外部质量肯定也不怎么样。 不能为了赶进度，而缩减故事时间，可以缩小范围（也就是从当前sprint去掉一些故事）。 无休止的sprint计划会议 一般3-4个小时，可以根据团队项目特色适当修改 Ｓcrum中的一切事情都有时间盒 如果到尾声，还没定好目标，打断会议。这样虽然很痛苦，但是会使得大家在下一次能更有效率。 sprint计划会议时间表 在 sprint 计划会议之前先为它初步制定一个时间表,可以减少打破时间盒的风险。 详细的sprint计划会议时间表： Sprint 计划会议:13:00 – 17:00 (每小时休息 10 分钟) 13:00 – 13:30。产品负责人对 sprint 目标进行总体介绍,概括产品 backlog。定下演示的时间地点。 产品和团队要对‘完成’有一致的定义 sprint目标回答这个问题“为什么进行这个sprint？” 13:30 – 15:00。团队估算时间，在必要的情况下拆分 backlog条目。产品负责人在必要时修改重要性评分。理清每个条目的含义。所有重要性高的 backlog 条目都要填写“如何演示”。 产品负责人和团队对故事要有同样的理解 怎么避免不一样这种事情发生？把重要故事的字段填满，可以鉴定对story的理解是否一致。 每个故事2-8个人-天完成 15:00 – 16:00。团队选择要放入 sprint 中的故事。计算生产率,用作核查工作安排的基础。 sprint中包含多少故事由开发团队决定。因为开发知道一个周期能做多少事情。需要准确预估时间喽。（本能反应、生产率计算（根据历史））。 产品负责人怎么左右sprint包含的故事？调整优先级、缩小某些故事的范围 16:00 – 17:00。为每日 scrum 会议(以下简称每日例会)安排固定的时间地点(如果和上次不同的话)。把故事进一步拆分成任务。 故事是可以交付的，是产品关心的；故事拆分成任务，任务不可交付，产品不关心。 Sprint计划会议优先级列表 目标 演示日期 —— 这是启动sprint 最起码应该有的东西。 经过团队认可、要添加到这个 sprint 中的故事列表。 每个story估算值 每个story的‘如何演示’ 生产率和资源计算,——用作 sprint 计划的现实核查。包括团队成员的名单及每个人的承诺(不然就没法计算生产率)。 例会的时间和地点——这只需要花几分钟，但如果时间不够用，Scrum master 可以在会后直接定下来,邮件通知所有人。 故事拆分成任务——这个拆分也可以在每日例会上做，不过这会稍稍打乱 sprint 的流程。其实也可以由相关人员自己拆分 sprint迭代周期长度 产品负责人喜欢短，开发团队喜欢长 所以这个周期长度是双方妥协后的产物。 推荐3个星期 其实很难定一个特别合适的长度，那么就先暂时选一个大家都可接受的再说。试验一下这个周期长度是否合适。 但是一定确定了这个周期长度，那么就需要长时间的坚持住。 sprint计划会议的其他细节 用索引卡进行解说 不由一个人解说ppt，而是全民参与 可以用索引卡，在墙上贴； 也可以在白板上面书写，任何人有 不同意见可以随时更改。大家相互走动，增强互动性。 时间估算 自己在本子上写你的预估时间，然后一起揭开看。 必须每个人都参与、每个人都要了解故事 最熟悉的人发言，会影响其他人的估算 对全部工作的估算，而不是只对自己的要做的工作。 开发团队的权利，那么怎么估算？ 本能反应、生产率计算（根据历史） 天数估算和小时估算 推荐天数估算，最小的单位是0.5人-天 小时估算比较零碎，容易陷入微观管理 技术故事 非功能性的条目，需要完成，但是又不属于可交付物的东西。 产品无法参与，怎么办？ 变成可衡量业务价值的普通故事 当作另外一个故事中的某个任务 当作技术故事，但是要让所有人都知道，然后跟产品沟通，希望产品负责人同意抽时间完成。 五、OK，计划会议结束了 要开始紧张而又充实的sprint迭代周期了m来喽 |
|
|
