高效技术团队-03七牛在看板方法上的实践.pdfVIP

七牛在看板方法上的实践 李道兵 lidaobing@ 2014-07 两打程序员，三年，4732个bugs，和对非凡软件的不懈追求 最后做了一个没人用的软件 梦断代码 • Chandler 项目： • 个人信息管理软件，跨平台，Python语言 • 文档数据库作为存储层 • 支持分享，通信，合作 • 两打员工，牛人不少 • 2001年成立，2008年发了 1.0 版本，很多杀手级特性被放弃，最后一个版本发布于2010年，现在网站 已经打不开了. • 失败原因 • 管理: 完全没有管理才是这个项目失败的原因 • 两打程序员对现在的项目来讲已经不是一个很大的团队，有很多轻量级的管理方法来帮助你解决团队 管理问题，比如我今天想讲的看板方法。 目录 • 看板简介 • 七牛应用看板的情况 • 杂谈 软件开发管理的演化历史 • 瀑布式: 越到后期返工的成本越高，所以要重需求分析，重文档，重审核 • 迭代式: 功能变更不可避免，错误不可避免，改为多个小瀑布式的流程 • 敏捷宣言(2001年): • 个体与沟通优先于过程和工具 • 可以工作的软件优先于求全责备的文档 • 客户协作优先于合同谈判 • 随时应对变化优先于循规蹈矩 看板的演化历史 • 敏捷宣言 • 极限编程: 20条原则 • Scrum: Scrum Master, 冲刺周期 • Kanban: 我们今天准备讲的 看板的特点 • 可视化工作流 • 限定在制品数量 • 衡量并管理周期时间 可视化工作流 可视化工作流 • 可视化 • 玻璃板/白板/网站/共享文档 • 工作流 • Backlog - 待开发 - 开发中 - 待测试 - 测试 中 - 待部署 - 完成 • 任务在工作流的各个状态中流转 限定在制品数量 • Backlog - 待开发 - 开发中 - 待测试 - 测 试中 - 待部署 - 完成 • 除了 Backlog 和 完成，剩余的都要限定 七牛的特点 • 业务方向: 云存储，云分发，以及相关计算 • 业务特点: • 存储部分要求稳 • 计算部分要求快 七牛的看板实践 • 开始了一年多 • 七牛的所有研发团队 都已经使用了看板 实体看板还是软件 • 可视化工作流 • 现有的软件在可视化方面都很差 • 如果是跨地域协作，推荐trello • 如果是集中办公，推荐实体看板 发布周期 • 随时发布/一天多次发布: • 多用于一些 2C 的网站，Lean Startup 也推崇过 这个做法，在摸索方向的时期可以减少反馈循环的 周期（当然需要先做好效果测试方面的工作） • 广告投放系统: 快速推进算法进化 发布周期 • 每周发布一次 • 应用得非常广泛(特别是在线系统)，适中的一个节 奏 发布周期 • 更长的发布周期 • 基础系统以及客户端系统 七牛的发布策略 • 网站/计算: • 每周一次发布+hotfix • 存储: • 每月一次，主要是性能优化 技术故事 • 技术故事 • 重构，新技术调研，依赖库版本更新这些都属于技术故事 • 修 bug 很重要，上新功能也很重要，但别忘了技术故事 • 我们的做法 • 可视化，技术故事放在 TODO 里边 • 按比例掺入，每周要完成多少个技术故事 别忘