scrum读书笔记

读硝烟中的scrum和xp，临时记录一下，刚刚有点体会...，有时间好好整理整理。

 

迭代要完成可交付的工作片段
短交付周期=短反馈=在错误方向上花的时间更少=学习和改进的速度更快

backlog :功能、故事、用户想要的东西
说明，优先级（重要性）、估算、测试规范、（产品backlog停留在业务层次上，关注业务目标）

sprint（sprint计划会议（决定哪些故事应该在这个sprint中完成、时间、重要性）  三周  确定sprint目标（业务术语而非技术术语，让团队以外的人能够理解））
product backlog ---> sprint backlog

处理就处理到自认为已经很完善，而不要暂时先这样吧的累积，不能再质量上让步!
把事情完全做完，达到可以交付的状态（小，是无所谓的），事情只做了一半，他的价值就是0!!!(敏捷、精益要求)
少构建些功能，然后把他们都弄稳定点是合算的

无休止的sprint计划会议：1.人们认为他花不了多长时间2.。。。实际上他们会的！

把故事拆分成任务：故事是可以交付的东西，任务工作内容而非可交付物
用户管理-->新增、编辑用户，查询用户   这是故事拆分为更小故事
查询用户--->理清需求，write test case,实现查询结果列表，实现查询form，集成测试、重构    这是故事拆分为任务
故事拆分为任务会发现一些导致时间估算增加的工作，最后得出的sprint计划更接近现实，这样拆分给每日例会效率带来提高(sprint计划会议中就应该做这件事，如果时间允许的话)

几乎每个故事的第一个任务都是“；编写一个失败的测试”，而最后一个任务是重构（提高代码可读性、消除重复）!!!

技术故事：或者叫做非功能性条目，需要完成，但又不属于可交付物的东西，跟任何故事都没有直接关联，（故事应该是业务相关、业务语言描述）

sprint回顾  改进的最佳时机（哪些是好的，哪些应该更好，应该怎样改善，时间估算比较的话问题出在哪，应该怎么改进），目的是在下个sprint中怎样才能做的更好
也可带有部分技术交流

scrum注重的管理和组织实践，而XP关注的是实际的编程实践
scrum: backlog sprint计划会议 sprint backlog  sprint回顾、每日例会
XP : 段周期迭代、小步前进、快速发布，结对编程、测试驱动、持续集成、每日例会、可发布物强于规范的文档 ...

永远，永远，永远不要在没有记录堆栈跟踪信息或是重新抛出异常的情况下捕获异常（保证别丢失堆栈信息）

加班工作在软件开发中会降低生产率