文化&方法 Scrum 11
文章 发布于 2016年10月12日  阅读 1021
Scrum 是有效管理未知因素和不断变化的产品需求,结束混乱,着重于如何驱动项目实现最高的投资回报。在 Scrum 里面,有3种角色,分别是 Product Owner、Scrum Master 和 Scrum Team头脑风暴,开发一个原则“先紧后松”,必须先把需求了解清楚,这里 Product Owner 可以召集技术团队/用户群体对其需求进行公开征求意见,最后输出一个产品建议表。敏捷实践:需...
作者 张松然  发布于 2015年11月30日  阅读 645
史上最不靠谱的敏捷聚会(来敏捷之旅北京站第六)于2015年11月29日成功举办,此次的主题是"敏于思,捷于行,众享之旅"。敏捷之旅旨在将本地的同行聚集在一起,分享知识,交流经验,将有众多业内知名敏捷实践者分享多年实战经验。
文章 发布于 2015年09月08日  阅读 627
Review 的目的是对团的认可。Retro 的目的是对团队的激励。敏捷的 Review 是在 Sprint 结束之后,给产品、团队进行 Story 的交付。Retro 是对 Sprint 和 Review 中发现的问题进行回顾,总结找到解决经验,让团队更好的前进。但是,每次 Sprint 都会有未完成的 Story,而 Retro 讨论的问题还是那么几个,似乎总不能解决。我在思考,到底是哪里出了...
文章 发布于 2015年07月05日  阅读 452
在敏捷团队中燃尽图的统计是十分重要的,它能即时的反映出团队迭代中的进度和问题。由于在我们团队中,燃尽图的更新是轮流值班的,所以某个人遗漏或计算错误,会使得燃尽图不能真实的反映团队进度和问题。这是一个迭代刚刚开始统计出的燃尽图,出现两次平线,这一种可能是团队忘记更新看板造成的,第二种就是团队真的没有再做迭代中的故事。第一种可以在早会上督促下团队,第二种就要仔细分析问题了。下面,我来介绍一下我们统计燃...
文章 发布于 2014年08月24日  阅读 822
今天参加了"王明兰"老师的"精益与看板"的认证培训,有很多的小游戏更深的学习了敏捷Scrum&KANBAN。培训感受,带来的问题都被解答了又重新系统的学习了敏捷,发现了自己缺失的地方,也找到了解决的方法。第一天在第一天的课程中介绍了Scrum框架和敏捷开发总览,分析了对比了传统预定义软件开发流程和经验性预定义过程的不同和区别。其中包含:Scrum的核心、框架、角色、会议、“Done”的定义、Scr...
文章 发布于 2014年07月25日  阅读 583
今天上午参加了由杜伟忠教练关于实例化需求的敏捷培训。我们知道,我们可以通过TDD(测试驱动开发)进行CI(持续集成),即单元测试用例变成可运行的代码;但是我们还可以通过ATDD(验收测试驱动开发)和BDD(行为驱动开发)进行CI,即将测试人员编写的测试用例变成可运行的代码。实例化需求解决的问题:1. 验收测试自动化2. 可运行的活文档在实例化需求的工程实践中,测试人员将成为团队的核心,其地位将大幅...
文章 发布于 2014年07月11日  阅读 312
问题Standing Meeting之前7~8人的早会,大家都很爱发言;现在15~20人的早会,每个人都不爱说话啦当团队大了之后,且之间合作密切的时候,SOS也不会很好地解决问题Planning Meeting1. 计划会议之前没有设计评审,故事拆分都是调研、设计、开发和测试,评估2周开发,这和瀑布开发有什么区别?迭代过半之后基本没有指导作用如果一个Story拆分出Task A、B、C、D,迭代开...
文章 发布于 2014年07月09日  阅读 362
由于我们是持续交付,上线也变得频繁,敏捷讲究快速发布获取反馈。但当交付的内容过多过细的时候,造成团队尤其测试、产品不知道究竟研发上了什么。还有时因为需求变更,敏捷讲究响应变化快速迭代,造成真实上线交付的内容和Sprint交付的内容不一致。针对这种问题,特别添加了"上线准备项"的泳道。具体说明1. 我们讲究持续集成、持续交付,当每个Sprint结束的时候我们认为所有的Story都应该被完成,而交付 ...
文章 发布于 2014年03月07日  阅读 447
这是团队的第二个 Sprint,从开始到结束,看板的变化,由始至终。还算圆满完成任务。故事都移到后面啦~冲刺结束的第二天,我们就召开了Review和Retro,对我们本次Sprint进行了总结和回顾,并整理出燃尽图。可以发现本次迭代出现了两次较大的拐点,我们通过一个富有创意的情景,来总结其原因。 —— 什么是推动我们前进的帆,什么是阻碍我们前进的锚。回顾和演示之后,我们立即进入了Sprint#3的...
文章 发布于 2013年12月02日  阅读 1957
本周一进行团队第二个冲刺的Review和Retro,在这次回顾中,我们发现在Scrum实践中,由于我们团队每个人几乎要负责两个以上的系统研发,其中又有老系统维护和新系统需求的优化,这就造成了团队成员在迭代中目标不一致。因为Scrum更合适一个团队向着同一个目标冲刺,所以面对我们遇到的问题,在与我们的敏捷教练 - 杜伟忠探讨后,我们团队决定进行转型 —— 我们依然是敏捷团队,但是我们应用了一种更灵活...
共11条记录 共2页 上一页 首页 1