本文写于很多年前(2006),并在很多地方被引用.而现在,笔者对于Sprint燃尽图的理解有了戏剧性的变化--在看到很多团队滥用它之后.笔者不再建议团队做Sprint燃尽图,因为它们不仅不会增加多少有用的信息,而且还会导致很多坏的行为.笔者差点想删了它,然而觉得更新一下会对大家更有帮助. 笔者观察了很多团队,并注意到了这些团队的Sprint燃尽图可以按图形的特征分成几大类,本文用来讨论几类燃尽图,以及其成因.燃尽图通常被敏捷团队用于让团队成员直观了解到剩余工作量.通常如下: 在下面,会展示7种典

看板: 燃尽图: 例会照: 总结:因为最近刚好碰上端午假期,再加上程序出了点问题,所以导致进度有点慢, 但是我们还是很努力地在找资料把问题给解决了,虽然完成的情况有点不如人意, 但是我们付出的努力还是有所收获的. 小组成员的个人贡献分:(小组团队总分为80分) 103李康梅:23分 109张鑫相:18分 112冯婉莹:22分 149麦锦俊:17分

1.开始一个新的冲刺: 起止:2016.6.1~2016.6.14 按照以下过程进行 ProductBacklog:继续向下细化 Sprint 计划会议:确定此次冲刺要完成的目标 Sprint Backlog:新的冲刺要完成的内容 任务认领 Sprint周期 看板:一个新的看板 燃尽图:从头开始的进度图 每日站立会议:沟通交流,更新看板 Sprint演示 Sprint 回顾 团队博客要求:每天一篇,显示项目进展,简洁地将站立会议的结果.看板.燃尽图等更新上去. 此次冲刺的评分内容:每天的博客,s

产品经理-需求分析-用户故事-敏捷开发 详解 用户故事是从用户的角度来描述用户渴望得到的功能.一个好的用户故事包括三个要素:1. 角色:谁要使用这个功能.2. 活动:需要完成什么样的功能.3. 商业价值:为什么需要这个功能,这个功能带来什么样的价值.作为一个<角色>, 我想要<活动>, 以便于<商业价值>As a <Role>, I want to <Activity>, so that <Business Value>. 用户故事的

项目当前版本的燃烧图是下面这样的 存在的问题: 1.任务在版本起始时期之后再细化,造成了绿线一直在红线上面.解决方案:版本起始日期定为任务录入结束后的日期 2.工时录入不及时,没有实时反映当前项目组的实际情况.解决方案:每天固定5点统一工时录入 3.客户现场的反馈问题需要重复在版本库中维护,没有好的解决方案,版本库修改完毕后再次修改反馈库

中间部分还需要改进 小组评分:(团队总分为80) 团队成员:        101丘娟同学:21        107杨晓霞同学:18        108周诗琦同学:22        124陈程同学:19

部分页面展示

 端午放假,大家都回家了 页面模块的大体设计,因所找的资料不全,还待改善

页面头部的修改