扫码阅读
手机扫码阅读
硝烟中的Scrum和XP读书笔记
16 2024-10-01
我们非常重视原创文章,为尊重知识产权并避免潜在的版权问题,我们在此提供文章的摘要供您初步了解。如果您想要查阅更为详尽的内容,访问作者的公众号页面获取完整文章。
查看原文:硝烟中的Scrum和XP读书笔记
文章来源:
麦哲思科技任甲林
扫码关注公众号
Scrum框架摘要
CH1: Scrum的本质
Scrum不是一种方法学,而是一个需要根据实际情况调整的框架。
CH2: 产品Backlog和故事细化
产品Backlog包括故事、特性、需求以及优先级,使用用户的术语表达。故事的细化通过how to demo来实现,作为验收准则。开发团队负责解决问题,产品负责人关注业务目标。
CH3: 迭代策划的准备
迭代策划会议前应准备好Backlog,确定故事优先级,产品负责人需要充分理解需求。
CH4: Sprint计划
举办Sprint计划会议让团队获取足够信息独立工作数周。故事含三个变量:范围、重要性(由产品负责人设定)和估算(由团队设定)。若产品负责人无法参加策划会议,需寻找解决方案。内部质量的保证是必要的,Scrum中一切都有时间盒,要学会制定合理的时间盒。短的sprint周期带来更快的学习和改进速度,sprint长度是妥协后的产物,要有迭代目标并用业务术语表达。
CH5-CH16: 其他关键实践
信息公告更新项目进展,物理看板管理sprint backlog,站立会议更新任务板,鼓励团队自愿领任务。Sprint演示可以获取反馈,回顾避免重复错误,适当休整。结对编程、TDD和持续集成是推荐的实践,测试人员需确认完成,多团队协作需要一致的节奏和良好的协调,远程协作和在家办公的模式也应被考虑。
想要了解更多内容?
查看原文:硝烟中的Scrum和XP读书笔记
文章来源:
麦哲思科技任甲林
扫码关注公众号
麦哲思科技(北京)有限公司总经理 敏捷性能合弄模型评估师 认证的Scrum Master 认证的大规模敏捷顾问SPC CMMI高成熟度主任评估师 COSMIC MPC,IAC 成员,中国分部主席
379 篇文章
浏览 58.9K
麦哲思科技任甲林的其他文章
快速学习COSMIC方法之三:度量策略阶段的执行要点
很多公司在度量规模的时候,不重视度量策略阶段的活动,但是在后续的度量过程中往往就会遇到疑问,在遇到问题时,才发现原来没有做到度量策略的定义,没有确定好度量的前提,因此度量策略阶段虽然可能很简单,很快速,很例行公事,但是不能忽视。 1)确定度量目的:为什么执行本次度量。 软件规模度量的常见目的有: 作为估算项目的工作量输入; 作为计算缺陷密度的输入;
需求变更的5W1H分析
why,需求为什么变化? 甲方的特殊原因: 不知道如何说清楚需求; 没有明确的需求; 没有确认乙方描述的需求; 乙方的特殊原因: 理解错了需求; 没有很好的诱导客户的需求; 共性原因: 业务就是变化; 人与人之间的沟通本来就存在障碍; 特殊原因是可以消除的,共性原因是难以消除的。 who : 谁会提出需求变化? 客户:客户方的
程序员必读之作:重构
十月一之后安排了我去培训《设计模式》,由于听众多为C与C++的新手,我想先从重构开始讲起,循序渐进,于是我决定仔细阅读〈重构〉这本书。 这本书我很久之前买的,当时大概读了读,感觉不错,就拿给了我表弟去读,他是程序新手。 这次是系统地读。 有个朋友曾经跟我说过,这本书不错,只是有点罗嗦,他是十多年经验的老程序员了,有此感觉很正常。写一个好程序的道理其实就如一层窗户纸,一点就透。但是,难得的是这本书系
白话SCRUM 之二:product backlog
在SCRUM方法中明确要求了3个文档: 1 product backlog 2 sprint backlog 3 burn-down chart Product backlog 中列举了本项目应该实现的需求,需求采用了用户故事的方式进行描述,用户故事是一句简短的采用用户熟悉的术语表达的需求,是用户讲给开发人员的故事,不是开发人员讲
聊聊故事点背后的故事
聊聊故事点背后的故事Q1、敏捷项目能不能不估算故事点,直接估算工作量?【观点一】:在策划扑克法中先估算故事点有其固有的优点,最无法替代的优点是故事点不是绝对的工作量,避免了团队在迭代早期盲目的承诺,第一个迭代可以只估故事点不估工作量,是一种保护团队的行为,体现了敏捷以人与团队为本的文化,多数策划扑克法没用起来的团队往往也是这种文化薄弱甚至背道而驰的。此时策划扑克就不是最适合的方法...
加入社区微信群
与行业大咖零距离交流学习
软件研发质量管理体系建设
白皮书上线