敏捷研发规范

摘要

本文为作者阅读《敏捷实践指南》一书的摘抄笔记，没有整理，比较乱。仅供参考。

内容

团队建设：如何保证团队高效运作
团队成员：
敏捷团队规模，3到9个人
协同合作，避免陷入迷你瀑布陷阱
团队成员为团队100%专职工作
克服组织孤岛
构建一个具有基本信任和安全的工作环境；
确保所有成员都有平等的话语权
成员意见都可以听到并被考虑。
仆人式领导：
促进合作而不是管理协调
敏捷团队的领导形式，仆人式领导为团队赋权
与团队一起制定团队章程，以获得团队成员的认同
鼓励团队成员勇于接受具有挑战性的任务
制定激励机制

会议开展主持：如何保证迭代的顺利进行
每日站会：固定时间，固定地点
时长不超过15分钟
会议内容只聚焦于昨天已做、今天计划和存在的问题或风险。
避免将站会演变成报告会，鼓励任何团队成员主持站会，保证每日站会是自组织和相互承诺的会议。
避免将问题展开讨论

迭代会： 计划会、评审会、回顾会
迭代周期：2周
定期开展回顾会议。回顾会是一个重要的实践，回顾会能让团队学习、改进和调整其过程。
回顾会的召开节点可以是：
迭代结束
每两周一次
团队解决了一个重大问题后
团队达到了里程碑之后
回顾会议重点在于学习和总结，而不在于追责和惩罚。
评审会/展示会，每两周举行一次，以便研发团队及时获得反馈，避免朝错误的方向前进。
计划会，由团队决定迭代周期内完成的用户故事数量

无论产品如何，都要频繁地将工作集成到整体中去，然后再进行重新测试，以确定整个产品仍然按照预期工作。
对端到端信息使用系统测试，对构建模块使用单元测试。
建立自动化测试，对每次迭代的工作产品，进行冒烟测试。
冒烟测试，有助于测试工作产品是否良好，每次集成后，都需要进行一次冒烟测试。

用户故事编写：如何保证需求收集的有效性

用户故事是一个有序列表，按照优先级顺序排列。产品负责人来决定优先顺序。
产品负责人决定每次迭代需要完成的用户故事，并细化用户故事。用户故事细化到何种程度，由敏捷团队决定

团队每周用不超过一小时的时间，来为下一批工作细化任务。

控制迭代中的用户故事数量