熊节:极限追问 035
【迭代0做什么？】
背景:在开始正式的迭代开发之前，往往还需要做一些准备工作，让团队进入迭代开发就能正常交付软件功能。这个准备的阶段，我们称之为「迭代0」。
分问题1：你的项目有这个「提前准备」的迭代0环节吗？
分问题2:你会做哪些准备工作？
分问题3:有什么经验或教训可以分享？
吴言
【迭代0做什么？】
背景:在开始正式的迭代开发之前，往往还需要做一些准备工作，让团队进入迭代开发就能正常交付软件功能。这个准备的阶段，我们称之为「迭代0」。
分问题1：你的项目有这个「提前准备」的迭代0环节吗？ 有，团队的反馈是，不做迭代0直接进迭代1的话，往往会造成迭代1交付能力不及计划30%
分问题2:你会做哪些准备工作？ 准备开发、测试、准生产（如果有）、生产环境 框架选型及试手 确定DOD、DOR（如果有） 确定依赖和风险 团队磨合，温习时间盒 导入实践（如果新人比较多） 确定工作协议
分问题3:有什么经验或教训可以分享？ 迭代0之前其实还有相当长的孵化时间，孵化时间里团队可能有人已经参与进来了，但是更多的人应该尚未参与进来。在迭代0里需要对共识进行充分确认，确保大家在一致理解中开工
Page
【迭代0做什么？】
背景:在开始正式的迭代开发之前，往往还需要做一些准备工作，让团队进入迭代开发就能正常交付软件功能。这个准备的阶段，我们称之为「迭代0」。
分问题1：你的项目有这个「提前准备」的迭代0环节吗？
迭代0并不一定只是准备，还是需要围绕交付来进行的。只是可能同质量的交付数量会因依赖问题在迭代0有所减少。
分问题2:你会做哪些准备工作？
迭代0处于迭代刚刚开始，会有一些基础技术依赖，还有UserStory有可能并不会拆分完全。迭代0不应该只做准备，还是应该聚焦价值交付，只是迭代0依赖多，所以价值交付的数量可以减少。
1，需求梳理并确认团队Sprint 0 的Scope。
迭代0，业务拆解、技术准备还不完全，因此有一部分时间是用来做这部分工作，因此迭代0的最终交付内容不一定很多，但是会有。交付多少，需要在Planning Meting上来确认。TL会拆分技术卡并安排优先级，BA会拆分业务，并让一部分UserStory开始实施。并在迭代过程中整理并确认迭代1要交付的内容。
2，基础设施搭建
环境准备不应该迭代0全部的内容。可以根据依赖关系，排好技术依赖的优先级。优先解决Block开发UserStory的依赖。
3，做好信息收集管理
项目开始了，需要把项目中需要的信息开始组建沉淀。例如建立共享的文件目录，建立技术栈描述、业务背景描述等需要的文档。这个不需要多久时间就能建立完一个团队信息记录的地方。可以不是一个人来完成，建立一个目录，大家共同在迭代中随时更新。
4，团队组建和磨合
不同上下文，团队的是不同的。彼此熟悉再好不过了。如果团队中新同学可以选择pair，将上下文、技术栈在做卡过程中传递出去。如果新面孔比较多，可以选车长期磨合，现针对要做的事情达成共识，达成共识的过程可以在做事过程中完成，而不一定单拉时间来处理共识上的问题，哪种对项目有好处用哪种。
分问题3:有什么经验或教训可以分享？
1，迭代0不是只用来做准备的，还是需要围绕价值交付来试试，有些准备工作可能持续几个迭代，有些根本不需要在迭代0进行。所以把block开发问题（技术、业务）先解决掉，进入开发了。 2，如果技术能力差异较大，团队还是还是应该聚焦交付价值，Training要做但是不是目的，Training可以持续几个迭代，因为单方面的Training效率并不高，所以可以针对具体问题来Training。 3，避免只有有了xxx我才能够开发的问题，如果有限应该解决或者看是否不解决同样能够往下进行。 4，迭代0并不是只为了后续的共识，共识在整个项目进行中都会持续达成、添加。例如代码规范有一个能够开发的简单基准就行，后续迭代过程中可以逐渐补充，补充的过程既是达成共识的过程。 5，从迭代0开始就需要持续关注业务。 6，尽早止损。当新面孔比较多是，不要因为刚接触而不将没有做好的事情、没写好的代码讲出来。持续的暴露问题应该就从迭代0开始，暴露这些问题的过程或方式可以使用一些软技能，不让事情太过尴尬。当然遇到做的好的，还是应该肯定和赞美。
陈旭
【迭代0做什么？】
背景:在开始正式的迭代开发之前，往往还需要做一些准备工作，让团队进入迭代开发就能正常交付软件功能。这个准备的阶段，我们称之为「迭代0」。
分问题1：你的项目有这个「提前准备」的迭代0环节吗？ 根据特殊用户故事性质决定，站会上，大家发现某个用户故事没有迅速取得共识，或者需要澄清及准备，会在会后择时进入迭代0环节。
分问题2:你会做哪些准备工作？ 需求澄清，依赖确认，技术选型取得初步共识。
分问题3:有什么经验或教训可以分享？ 一个epic拆分成用户故事后，往往有些用户故事之间依然存在依赖关系，有时候多个用户故事之间，可以提取一个简单的实现框架，减少重复代码，如果类似的用户故事没有被发现，大家各自为战，很有可能一万个程序员心中有一万个实现方法，最后合并代码时返工，资源浪费严重。
罗磊
【迭代0做什么？】
背景:在开始正式的迭代开发之前，往往还需要做一些准备工作，让团队进入迭代开发就能正常交付软件功能。这个准备的阶段，我们称之为「迭代0」。
分问题1：你的项目有这个「提前准备」的迭代0环节吗？ 正式的项目都是有准备工作的。
分问题2:你会做哪些准备工作？ 主要是针对具体项目进行需求向的归纳、总结和技术架构的定义。代码评审，代码管理因为是老团队，所以通常都是沿用之前的套路或者另外讨论更改。
- 需求的沟通理解和需求评审。
- 对评审通过的需求按合适的粒度进行分解，主要用来预估工作时间，对于不能或者不容易预估出时间的需求再次进行分解，直到可以较为准确的预估出工作时间。
- 综合预估时间，需求紧急度，业务向用处，给各个功能点排出优先级。
- 针对优先级，定义每个迭代版本功能。
- 针对迭代版本，讨论技术架构，列出核心技术难点，或者团队不熟悉的技术点，花 1 - 2天分别编写 demo 对核心技术点进行验证。
- 分配任务，进行迭代。Over
分问题3:有什么经验或教训可以分享？ 个人感觉团队做法中规中矩，并没有太多新意，准备虚心听取各种改进意见。 非要说的话，教训就是定义好技术架构后，一定需要针对核心技术点进行早期验证，以及针对不确定的需求及早沟通和明确。 快做完，或者做到一半发现要改核心架构或者部分核心功能需要换方案返工的痛铭记在心。
阿贵
【迭代0做什么？】
背景:在开始正式的迭代开发之前，往往还需要做一些准备工作，让团队进入迭代开发就能正常交付软件功能。这个准备的阶段，我们称之为「迭代0」。
分问题1：你的项目有这个「提前准备」的迭代0环节吗？ 项目如果是新团队，有迭代0. 如果是已有团队切换项目，会弱化迭代0. 分问题2:你会做哪些准备工作？ 迭代0会关注需求roadmap, 技术roadmap, 架构讨论，敏捷流程的运行，团队工作约定，各项敏捷活动的定义和执行 分问题3:有什么经验或教训可以分享？ 经验:迭代0建立起好的工作习惯，后面容易执行和坚持。如果第一个迭代没有开好头，后面纠正不好的行为非常费劲。
夏天
【迭代0做什么？】
背景:在开始正式的迭代开发之前，往往还需要做一些准备工作，让团队进入迭代开发就能正常交付软件功能。这个准备的阶段，我们称之为「迭代0」。
分问题1：你的项目有这个「提前准备」的迭代0环节吗？ -> 全新的项目是需要的。
分问题2:你会做哪些准备工作？ -> 确定服务框架，确定协作方式，明确质量标准，明确业务代码、测试代码、部署构建脚本文件结构，明确性能测试方案。 -> 构建持续集成环境，至少到集成测试环境。
分问题3:有什么经验或教训可以分享？ ->不要一次做完美，基本架构确定就可以实施； ->持续集成环境一定要在迭代0构建好
若有收获，就点个赞吧
0 人点赞
