一. 敏捷开发
1.1 背景
- 目标： 开发一个多系统通用的优惠券平台
- 团队： 产品经理（1人）/UED（1人）/iOS开发（2人）/Android开发（2人）/H5开发（2人）/Python开发（1人）/测试（2人）
- 周期： 35天
1.2 概念
- 敏捷开发(Agile Development)是一种以人为核心、迭代、循序渐进的开发方法。
- 敏捷开发不是一门技术，它是一种开发方法，也就是一种软件开发的流程，它会指导我们用规定的环节去一步一步完成项目的开发。
- 敏捷开发的主要驱动核心是人。
- 敏捷开发采用的是迭代式开发。
1.2.1 为什么以人为核心
- 敏捷开发它只写有必要的文档，注重的是人与人之间，面对面的交流，强调以人为核心。
1.2.2 什么是迭代式开发
- 迭代是指把一个复杂且开发周期很长的开发任务，分解为很多小周期可完成的任务，这样的一个周期就是一次迭代的过程。
- 每一次迭代都可以生产或开发出一个可以交付的软件产品。
1.3 开发方法
1.4 工具
- taiga
- 白板
- 便利贴
- Markdown文档
- 会议室/茶水间
1.5 执行
1.5.1 产品负责人（Product Owner）
- 提供愿景(确定产品的功能和达到要求的标准)
- 提供边界(指定软件的发布日期和交付的内容，同时有权力接受或拒绝开发团队的工作成果)
- 每个团队只需要一个产品负责人(对外联络的工作，了解和顺应市场趋势；对内与团队一起建造产品的工作)
- 产品负责人团队(把产品负责人的角色的职责分散到一个产品负责人团队，在该团队中挑选出某个人作为有最终责任和权力的人即可)
1.5.2 流程管理员（Scrum Master）
- 需要知道什么任务已经完成，哪些任务已经开始，哪些新的任务已发现，和哪些估计可能已经发生变化
- 要根据以上的情况更新反映每天完成的工作量以及还有多少没有完成的Burndown Chart
- 考虑进展中的开放任务数，进展中的工作需要得到最小化，以实现精益生产率的收益
- 阻碍Scrum的障碍和依赖,根据优先级指定计划解决这些障碍
- 做为团队和外部的接口，屏蔽外界对团队成员的干扰
- 保证开发过程按计划进行，组织Daily Scrum, Sprint Review and Sprint Planning meetings
1.5.3 开发团队（Scrum Team）
- 具有不同特长的团队成员，人数控制在5~10人
- 确定Sprint目标和具体说明的工作成果
- 在项目向导范围内有权利做任何事情已确保达到Sprint的目标
- 高度的自我管理能力
- 向产品负责人演示产品功能
二. 开发周期
2.1 产品原型
- Product Owner出一个产品原型图
- Product Owner确定一个Product Backlog（按优先顺序排列的一个产品需求列表）
- 上传原型图和产品需求列表到taiga
- (待补充)
2.2 需求讨论
tips:
- 一般不建议流程管理员由产品经理担任，由理解该业务的开发工程师或开发团队负责人担任会更好点。
- 由产品负责人召集流程管理员进行初步的需求讨论，假如产品负责人或者流程管理员的经验不够丰富，对业务理解不够透彻时，可让其他经验更多的人介入
- 初步确定哪些需求可做，哪些不可做，由产品负责人整理好，出一个可开发的Product Backlog，工期紧张的情况下，可去掉弱需求
2.3 方案设计
- 由开发团队负责人对产品负责人提出的需求进行技术性分析，设计该系统的初步方案
- 召集开发团队和产品负责人评估初步方案，确认是否是否可行，讨论直至得到一个可行且可接受的方案
2.4 建模
- 由开发负责人建立一个初步的系统设计模型，在开发团队进行内部讨论，确立一个可开发的系统模型
- 开发负责人召集全部人员进行一个会议，讨论此系统模型是否满足需求和后续的业务发展
2.5 拆分任务
tips:
- 任务拆分一般可分成五个步骤，1 范围确定 2 目标分解 3 优先级确定 4 可执行化任务分解 5 进入跟踪系统
- 任务拆分可在taiga上执行
- 范围确定，确定需要做的需求范围，有哪些难点，需要哪些支持，针对不同的情况制定不同的策略
- 目标分解，目标应该是精确定义的，没有歧义的，可借助思维导图，重新梳理需求之间的关系，小需求聚类，大需求再继续分解
- 优先级确定，流程管理员最重要的一点是必须有全局的视角，从更长的周期和更多的维度来看事情，这样才好把握住优先级。在拆分任务，可标出哪些是核心目标，哪些是重要目标，哪些是次要目标。此外，作为一个管理员，必须有意识的去推进一些重要但不紧急的事情。
- 可执行化任务分解，把分解后的任务写下来，附上任务开始和截止时间，并标注进度如何，以最直观的方式把握整个任务的进展情况，在执行过程中，任务的细节可调整
- 进入跟踪系统，即使对任务有个好的分解，但如果没有任务执行和跟踪，那也无法促使任务的完结，流程管理员应每天过一遍taiga上的看板，必要的时候，每天进行一次五到十分钟的早餐会议
2.6 任务实现
2.6.1 协同合作
目标
- 团队内的目标明确且一致
- 每个成员都对目标负责
规则
- 制定团队内部约定好的规则，比如文档规范、编程规范、原理图设计规范等开发规范，违反规则者有惩罚措施，优秀的有奖励措施
- 规则即流程，应是可以不断优化的
沟通
- 坐到一起，每日站立会议，Review会议
- 每个必要的会议都应有一个目的，遵循什么宗旨，需要达成什么结果，如无必要，会议可以不开
工具
文档协作
- 石墨文档
- Markdown文档
项目协作
- taiga
团队协作
- 企业微信
- 微信
文件存储
2.6.2 开发语言格式规范
2.6.3 Git使用规范
2.6.4 关系数据库设计规范
2.6.5 缓存数据库设计规范
2.6.6 接口定义规范
2.6.7 持续集成部署
2.6.8 监控系统部署
2.7 测试
测试用例
单元测试
压力测试
回归测试
故障管理
三. 上线准备
3.1 代码机器
3.1.1 系统配置
- CPU
- 内存
- 磁盘
- 内核参数
- 防火墙
- 同步和备份
- 计划任务
- 开机启动
- 时间同步
- 软件版本
3.1.2 监控
- Sentry
- Prometheus
- Grafana
3.1.3 日志
日志收集
- Fluentd
- ELK
日志分析
- Hadoop
- Spark
3.1.3 网络
- 带宽
- 专线
3.1.4 第三方对接
安全通信机制
- 请求头的secret和key验证
- oauth token验证
- IP白名单
接口逻辑
- 测试/正式环境
- 接口定义规范
3.1.5 域名
域名申请/备案/解析
3.2 数据库
3.2.1 存储数据库
- MySQL数据库设计规范
- 访问权限
- 操作权限
3.2.2 缓存数据库
3.3 HTTP和反向代理服务器
四. 线上验证
4.1 接口验证
- 日志记录
- 接口数据结构
- 接口返回
- 业务逻辑
4.2 队列验证
- 日志记录
- 业务逻辑
4.3 同步数据验证
- 日志记录
- 数据库数据
- 业务逻辑
五. 复盘总结
5.1 需求盲点
5.1.1 逻辑梳理
- 对整个产品的影响
- 对每个层级涉及产品线的影响
- 对运营/市场等部门的影响
5.1.2 规则/算法规划
- 架构的规则规划，预计至少半年内不会调整
- 底层的算法设计，预计至少一年内没有大调整
5.1.3 后端规划
- 增删改查效率优化
- 后台交互
5.1.4 前端规划
- 交互统一风格
- 交互合理性
- 功能可用性
5.1.5 内部涉及部门
- 运营/市场等部门协调
- 从立足的部门出发，站在不同部门的角度看待问题
5.1.6 外部涉及部门
- 第三方部门之间的沟通协作，一般是先外后内，外部因素很难把控
- 合作之间出现的问题，大多可以归根为人的问题，要有同理心
5.2 开发难点
5.2.1 需求不明确/不清晰
- 需要明确的需求，清晰的描述
- 组织涉及部门/人员讨论需求，确认做什么，怎么做
- 由于外部因素不能确定需求，则寻求相关人员去促进
5.2.2 需求反复变动
- 确认了需求方案，进入开发阶段，原则上不允许需求变更或者插入其他需求
- 确认需要更改需求或插入需求，重新讨论需求带来的影响，工期/产品线/人员等等要重新落实
5.2.3 需求粒度过于粗糙
- 与需求不明确类似，需求粒度太大，则太抽象，需要拆分
- 更小粒度的需求可落在接口交互的功能逻辑
5.2.4 不理解产品逻辑
- 产品背景介绍
- 整体产品的抽象
- 产品线的把控
希望部门的每个人员对产品都有一个整体的了解，涉猎到产品线的逻辑实现。
5.2.5 技术/产品经验缺乏
- 积累经验，多向老司机请教
- 学会提问
5.3 文档撰写
- markdown文档
- 文档记录工具
- wiki
- 清晰/可维护
5.4 开发效率
- 逻辑思维
- 技术储备
- 辅助工具
- 定时总结
5.5 团队合作
- 全局统筹
- 学习能力
- 沟通能力
- 自制能力
