scrum-and-xp读书笔记

scrum: 一种敏捷开发框架，可以避免经理问你在管理上做了啥功课时回答做了冥想。

scrum和xp的参考网站：
http://agilemanifesto.org/
http://www.mountaingoatsoftware.com/scrum
http://www.xprogramming.com/xpmag/whatisxp.htm

backlog：订单/故事，一个或一组需求，从客户而不是开发者的角度进行描述。规模不宜太大或太小，一个可参考经验值是2-8人日。
sprint： 冲刺，可理解成一个迭代周期。在每一个sprint前举行一个会议，确定sprint目标、团队成员、backlogs、截止时间等。
sprint周期：长短应该合适，经验值是三周，确定后最好形成惯例。
规模估算：一开始可以根据直觉，在几个sprint周期后可以根据历史数据+直觉。
任务：从技术角度出发对backlog进行的细分，可以在每日例会时进行。
sprint backlog：随着sprint进行，本次sprint所属backlog状态会持续发生变化，对其进行跟踪记录就形成了sprint backlog。
燃尽图：一张图，横轴是本次sprint的工作日，纵轴是剩余的工作量。
微观管理: 任务划分太细，如1-2个小时，引起管理成本上升，应该要避免。
sprint演示：简练，关注功能而非技术，集中精力在主要功能而不是细节上。
sprint回顾：经验流程首先是Scrum master向大家展示sprint backlog，在团队的帮助下对sprint做总结；然后大家各自发言，头脑风暴，总结做的好的和可以改进之处；最后由Scrum master总结。
sprint团队内角色：产品负责人，scrum master负责主导scrum过程，tester负责验收任务

难点：处理技术类backlog。如公共库开发维护、性能优化等耗时长对产品外观影响小的backlog。目前不用担心这个，因为产品负责人好像也只能是我。通用的处理办法有：把它隐藏在普通backlog之后；说服产品负责人接受；强迫产品负责人接受。
难点：bug与backlog之间的关系。处理方法：产品负责人将其转换成backlog加入backlog库；使用bug管理系统管理backlog即bug等同于backlog；把修复bug当成sprint的平行任务，降低预期生产率，留出足够时间修复bug。
难点：bug与sprint的关系。处理方法：提供代码质量，减少bug数目；给予bug比其他backlog更高的优先权；每轮sprint留出时间处理bug。如果救火任务太多可考虑划分专门的救火团队。
难点：有些东西不容易演示。比如性能优化，可以用报告而不是demo的方式来演示。
难点：在大团队中使用scrum。合理拆分到3-8个人，最好同步所有scrum团队的sprint周期。
难点：多个scrum团队在一个代码库上工作。不得已时才使用branch and merge，一定要尽早、尽快地合并。