- 有新项目时，建立一个新的微信群，将相应的参与者拉到微信群，项目进展和协作都在微信群中进行。
- 需求文档、反馈文档记录在石墨文档，先写文档，然后将文档链接发到微信群。
- 阶段性工作产出会以私信或者邮件的形式发送给相关人员
- 所有沟通在微信中沟通，沟通没有汇总，每个人将任务项分别记录在自己的工具中，没有同步。后加入群的成员无法知道前期的沟通。
- 微信群中发出的石墨文档页面独立，分布比较零散。
- 开发过程中还没有制度化的会议，理解不足够一致，反馈时间参差不齐，影响进度，导致项目成员目标不明确。
- 开发活动一般开始于微信群中发了一个任务、一个反馈、一个 bug，没有排队、讨论、确认等环节，开发成员比较被动，工作没有体系。
- 产品负责人制度化地在特定节点引入相关人员，沟通时间差会影响产品开发进度，导致抱怨。
- 项目开发和优化过程中没有明确的时间节点，项目进展没有段落感，没有工作完成的仪式感。
- 大段工作完成的段落感，可以让所有人，更好地感知项目的进展，提升团队士气。
- 未参与项目的人员无法了解项目开发的情况，无法给予足够的支持。
- 一方面因为这些未参与项目的成员不在微信群中，无法知道大家到底在做什么。
- 另一方面和项目进展基于单个任务，没有大段工作完成的段落汇总有关。
- 使用工具，集成项目微信群中的消息、石墨文档，方便后期参与者了解情况，提供支持。
- 迭代开发模式，整体立项，迭代开发，每次迭代有明确的阶段、会议，每次迭代的完成形成段落感。
在微信群中加入微信群助手，将所有的对话记录到一个外部系统中。可以在系统中看到群里的所有沟通记录。同时将石墨文档提取出来，显示在专门的列表中，方便查阅。https://github.com/Chatie/wechaty
这里所说的项目是和开发部门相关的软件开发项目，开发项目立项一般有以下场景：
- 公司经过调研和用户反馈，决定扩展一个新业务。立项开发这个新业务相关的系统。
- 运营过程中，不断接到用户反馈。为了系统解决这些反馈，专门立项。
- 运营过程中，不断涌现对一个工具的需求，专门立项开发工具。
总之，立项是因为有一整块任务项需要处理，并且预期会持续一段时间。立项是为了系统化、有条理地地解决问题。
定义流程是为了解决前面阐述的问题，强制大家彻底改变现有工作流程模式并不是目的。所以流程主要在目前的基础上进行，加入制度化的检查点和任务项。这是一个 sprint 的模板：https://shimo.im/sheets/tn0t12YoOUYdIrX3/MODOC
我们把每次迭代称为一次 sprint，有具体的目标和完成预期时间，一般一次 sprint 为 1周或者2周，每次迭代有多个工作段落：
- 需求收集
- 平时有一个地方收集各方的需求，汇总到和当前项目对应的一个列表中
- 产品负责人按照对用户、业务、商业价值的影响程度，将需求设置优先级
- 需求确认
- 目的：确定一系列能对用户和商业价值产生最大影响的需求，经过多方参与者的权衡，得到此次 sprint 需要完成的需求列表
- sprint 会：每个 sprint 开始前需要由各方在一起开一个会议，确认需求。sprint 会一般在 1 小时 以内。
- 参与人员包括：产品负责人、设计师、负责开发该项目的前端、负责开发该项目的后端、产品影响的其他人员（使用者、相关合伙人）
- 产品负责人需要确认参与人充分理解此次 sprint 的目的，产生的商业价值，鼓励每个相关人员参与进来
- 一次 sprint 应该有命名，便于之后沟通时指代
- 参与人除了 sprint 目的外，需要考虑自己目的：
- 设计师：了解产品谁在用、通过怎样的操作、带来什么价值，用户怎样才能有更好的体验
- 使用者：这个产品我在用的时候，方便程度是否可以接受，怎样才能提升我的使用效率
- 开发者：需求有哪些难点？目前的技术能力是否能满足需求？是否有开源实现可以替代或集成？哪些需求会提升复杂度和开发成本？通过什么技术手段可以减少成本？是否可以需求减少成本同时满足主要需求？
- 产品负责人：理解其他参与人的诉求，帮助大家达成一致意见
- 需求列表的产生流程：
- 产品负责人按照优先级，从列表中挑选候选需求，形成候选需求列表
- 产品负责人召集相关人员，召开 sprint 会。 会议中从候选需求列表中根据优先级和相互依赖关系挑选能在一周内完成的任务，形成 sprint 任务列表
- 产出：产品负责人在 Phabricator 的项目中创建新的 Milestone，命名为 sprint 开始的周数，按照候选需求列表，在 Backlog 列中创建任务项
- 设计确认
- 产品负责人和设计师沟通产品展示的设计，经过一些沟通和反馈后，形成初稿。
- 产品负责人召集 sprint 与会人，召开设计初稿确认会，让大家尽早提供对实际产品的反馈。
- 初稿后每次设计产生的版本，通过蓝湖链接发送给大家，反馈可以直接在蓝湖上添加。如果前期争议比较大，可以再召开会议。
- 开发确认
- 目的：产生具体的、可行的、符合需求的软件设计方案。
- 形式：产品负责人召集开发人员，开会解决软件设计相关问题。
- 由开发负责人主导会议，围绕设计稿，阐述每一部分实现的效果和基本方法。在这个过程中产品负责人提出问题、确认每部分的实现最终效果是否符合需求。
- 产品负责人确认每部分最终实现效果后，开发可以独自开会，确认前后端的设计方案。
- 产出：
- 前端
- 有哪些页面，每个页面分成几个部分，页面每个部分需要什么数据支持，数据从哪里来，如何和后端对接
- 是否可以重用以前的开发成果
- 是否可以使用开源实现
- 后端
- 有哪几个新概念，概念形成什么名字的 model，model 保存哪些数据，model 之间有什么关系
- 以前的概念有怎样的调整，调整后是否有兼容问题，兼容问题如何解决
- 提供哪些接口
- 是否可以重用以前的开发成果
- 是否可以使用开源实现
- 前端
- 功能测试
- 目的：
- 确认所需的功能开发完成
- 确保功能符合需求的要求
- 确保相关人员知道如何正确使用
- 确保上线后用户使用不出问题
- 要求：
- 开发能通过简单的命令将系统部署到一个新的环境上，有单独的链接访问
- 测试人员将测试反馈记录到页面，并且汇总到 sprint 页面
- 目的：