敏捷研发规范

摘要

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

内容

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

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

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

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

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

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

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

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

你可能感兴趣的:(解决方案,敏捷开发)