#敏捷开发#用户故事可以用3C表示，分别是Card(卡片)、Conversation(对话)和Confirmation(确认)。卡片上是故事的文字描述，然而需求细节通过对话获取，对话所确认的需求在卡片上记录。注意：卡片代表客户/用户的需求而不是记录需求。开发人员的沟通对象是客户团队（测试人员，产品经理，实际用户等等）
#敏捷开发#编写用户故事时，开发人员协助编写，并和客户团队交流。客户团队负责编写，并和开发人员沟通。当开发人员被问及实现故事的的技术或者框架信息时，应该从用户的角度回答，而不是技术术语回答。
#敏捷开发##用户角色建模#明确项目中有哪些用户，并且整合用户，提炼用户， 把用户虚拟出人物，并且把虚拟人物的描述写在纸上，挂在墙壁上，供团队了解。
敏捷开发#渔网不能捕获所有的鱼，所以不能捕获所有的需求，捕获的鱼也可能是死鱼或废物，无效需求使需求膨胀。第一遍，用大网捞大需求，形成对软件的整体感觉，中网捕获中等需求，暂时不用顾忌小需求。
#敏捷开发#用户故事验收测试，测试点是在写代码之前有客户团队写好。测试的目的是找到缺陷，而不是为了覆盖率。
#敏捷开发#估算故事点，故事点是故事的复杂度，工作量的相对估算。整个团队来估算故事，而不是一个人。一般一个故事点为理想个人日的工作或者是理想结对日的工作。开发人员，估算时，要考虑到故事需做的所有事情，全盘考虑测试代码，客户沟通，协助测试人员或验收测试等，估算时尽可能对故事了解详细。
#敏捷开发#迭代计划会议，1、根据优先级讨论故事，2、开发人员分解故事，3、根据分解的人物估算大小并且确认。
#敏捷开发#测试驱动开发，重构，集体所有权，持续集成，结对编程等技术实践提高团队的综合能力。
#敏捷开发#每个迭代潜在可交付的软件，可以提前并鼓励反馈进度，需要时可尽早发布。潜在可交付意味着测试过，意味着集成已做好，并不意味着功能完整性。