本文摘录自轻松Scrum之旅：敏捷开发故事
1. 当开始研发新产品或者已有产品的新模块时，由于各方面的原因，整个团队没有能力在Sprint的开始就做出一份非常详实的计划，因此，采用“照明弹”策略绝对不失为一个好方法。
2. 对于每一个Story，要尽可能了解它的需求。
3. 在开发过程中，为了提高交流效率，要尽量避免把精力浪费在不必要的文档中，取而代之的是要提倡团队之间面对面的直接交流。
4. 在实际工作中，Scrum提倡团队自我管理，在任务分配时每个人都可以按自己的兴趣来选择任务。
5. 团队成员的技能培训是要在做Sprint计划时就考虑在内的。
6. 虽然每日Scrum会议的持续时间会根据整个团队的大小而有所不同，但是不要超过15分钟。
7. 经理应该充分信任开发团队，不该把每日Scrum会议当成每日汇报。
8. 在Scrum工具的使用上，一定要确保每天都进行准确的更新，只有这样才能让团队其他成员及项目经理掌握及时、准确的项目进度信息。
9. 通过Burndown Chart，Scrum将给项目带来更多的可视性。
10. 每日Scrum会议举行的时间应该在早晨还是下午？
11. 在每日Scrum会议上不要过多地讨论技术难题的细节，如果有团队成员遇到无法解决的困难时，Scrum Master应该将其记录下来，会后再调配资源去解决。
12. Scrum如何解决开发与测试工作同步的问题？
13. 每个Sprint结束后，最基本的目标是得到一个可以工作的产品。Sprint结束时的Sprint评审会议和Sprint回顾会议都至关重要。
以下纯属一家之言，仅为自己在敏捷学习上的粗浅认识：
敏捷开发，是一种应对快速变化的需求的一种软件开发能力，就如同这个名字一般，它可以应对客户快速变更的需求，强调以人为核心，采用迭代的方式，循序渐进的开发软件。敏捷开发项目需要一个拥有自我管理能力的团队，通过与业务专家之间的紧密协作，面对面的沟通等方式来频繁交付新的软件版本，目标是为了实现利益相关者的利益而努力，其核心思想是适应变化。
相比迭代开发，虽然两者都在强调较短的开发周期，敏捷方法的周期可能更短，而且它强调队伍中的高度协作。
相比于传统的瀑布式开发，敏捷能在短时间内完成相对小的功能，强调能尽早将尽量小的可用功能进行交付，且在项目周期内持续改善和增强功能。
从某个角度来看，敏捷看起来是那样的无计划性和纪律性，但是这却同时体现出了敏捷的适应性而非可预见性。
之前提到的都属于敏捷开发部分，接下来是敏捷测试方面：
敏捷测试时遵循敏捷宣言的一种测试实践，强调的依然是人，这里说的是客户，即从使用系统的用户的角度来测试系统，与开发一致的，它的重点在于关注持续迭代的测试开发的功能，而不是传统测试过程中严格的测试阶段，同尽早交付尽量小的可用功能的开发一样，敏捷测试建议尽早开始测试，同时随着测试的深入，需要持续进行回归测试保证之前测试过的内容的正确性。
无论是开发还是测试，敏捷的最大特点是高度迭代，有周期性，并能及时、持续地响应客户的频繁反馈。敏捷测试要求不断修正质量指标，正确建立测试策略，确认客户的有效需求得以实现和确保整个生产过程安全的、及时的发布最终产品。
简单的说，敏捷测试就是持续地对软件质量问题进行及时的反馈。敏捷功能测试=新特性的手工测试（Use Case验证和探索性测试）+原有功能的自动化测试（回归测试）。敏捷测试人员和敏捷开发人员的区别越来越小，理想情况下，敏捷方法中，测试人员和开发人员在不同的迭代周期可以互换，当然，前提是测试人员拥有开发人员的同等能力，这个并不是每个测试人员能做到的。