敏捷开发
白云庄主
这个作者很懒,什么都没留下…
展开
-
敏捷开发之每日站立会议
1) 在 Scrum 方法中,Scrum 会议非常重要,整个会议可能会比较混乱粗略,但推进进度的目标却非常清晰明确,并促使团队齐心协力朝共同目标迈进。 2) 团队应召开每日 Scrum 会议,以便确定下一天所需执行的工作,以最大可能地履行其承诺。 团队的每个成员都应该描述自上次会议以来所做的工作。 3)他们计划在当天完成的工作,以及可能对其他团队成员产生影响或需要获得其他转载 2011-12-28 17:08:42 · 12664 阅读 · 2 评论 -
敏捷开发之用户故事
用户故事(User Story)描述的是一件用户通过系统完成他一个有价值的目标,用户故事只是描述系统的外在行为,完全忽略系统的内部动作。用户故事形式简单,故事写作者使用起来方便;用户故事从用户角度出发描述需求,利于用户、需要分析人员和开发人员之间的沟通。 一个 User Story 的大小和复杂度应该以能在一个 Sprint 中开发完毕为宜。尽量在系统的开始阶段,尝试找出所有的用转载 2011-12-28 16:47:24 · 1840 阅读 · 0 评论 -
敏捷开发之故事点估算与故事点燃尽图
一个团队/个人花 10 小时能完成的任务,另一个团队/个人或许需要 100小时; 也有可能团队花了 100小时但是什么都交付不出来;作为一个用户故事,只有“完成”与“未完成”两种状态,不能使用一个百分比来表达“部分完成”,例如我们不能燃烧掉一个用户故事 1/3 的故事点=来表达它已经完成 1/3了;基于小时的估算是不精确的,不同人在同一个任务上要花不同的小时数;花了几个小时在一个任转载 2011-12-29 09:16:36 · 6926 阅读 · 1 评论 -
Noki迭代开发的基本要求和Scrum准则
迭代开发的基本要求• 迭代要有固定时长(被称为“时间盒——timebox”),不能超过六个星期。 • 在每一次迭代的结尾,代码都必须经过 QA 的测试,能够正常工作。 • Scrum 团队必须要有产品负责人,而且团队都清楚这个人是谁。 • 产品负责人必须要有产品 Backlog,其中包括团队对它进行的估算。 • 团队必须要有燃尽图,而且要了解他们自己的生产率。 •转载 2011-12-29 15:53:47 · 809 阅读 · 0 评论 -
我们如何让产品 backlog 停留在业务层次上
如果产品负责人有技术相关的背景,那他就可能添加这样一个故事:“给 Events 表添加索引”。他为啥要这么做?真正的潜在目标也许是“要提高在后台系统中搜索事件表单的响应速度”。 到后面我们可能会发现:索引并不是带来表单速度变慢的瓶颈。也许原因与索引完全不相干。指出如何解决问题的应该是开发团队,产品负责人只需要关注业务目标。 只要发现这种面向技术的故事,我一般都会问产品负责人 “但是为什转载 2011-12-29 16:23:09 · 976 阅读 · 0 评论 -
Scrum master 检查列表
sprint 开始阶段Sprint 计划会议之后,创建 Sprint 信息页面。 1.1 在 wiki 上创建从 dashboard 指向所创建页面的链接。 1.2 把页面打印出来,贴在通过你们团队工作区域之外的墙上,让经过的人都可以看到。 给每个人发邮件,声明新的 sprint 已经启动。邮件中要包括 sprint 目标和指向 sprint 信息页面的链接。 更新 sprin转载 2011-12-30 11:55:03 · 1203 阅读 · 0 评论