业务实践
作者：程序员罗尼 ｜ 发布：2021-01-12 ｜ 原文：https://mp.weixin.qq.com/s/xbBuphefrhJLKYHoZbU2Mg
2021 年第一篇
本篇文章为《Clean Agile》第三章的读书笔记
为了成功，软件开发必须遵循许多面向业务的实践，主要包括如下几个方面
一、计划游戏
项目初期，都要做一些计划，估算一下大概需要做什么事情，需要多少时间，估算应该尽量准确，又不花费太多的时间
估算依赖于对项目的拆分，对项目拆分的越细，估算的就越准确，极端情况就是将项目拆分为一行一行的代码，但是这样估算就失去了意义，对于开发者而言，技巧在于花少量的时间，选定较小的范围，保证该范围内的确切估计
三元分析
先介绍一种三元分析方法，分别考虑最好情况，一般情况，最坏情况，这种分析适用于长期的项目，对于敏捷开发，我们使用故事点
故事和点数
对故事进行估算，确定工作量，比如1-6，确定业务价值，比如1-10，根据成本收益四象限，决定一次迭代做哪些事情
对于第一次迭代，拍脑门即可，比如完成30个故事点
迭代中期要进行评审，看看实际完成了多少，然后根据情况调整剩余的故事点
一个迭代完成之后就产生了真实的速率数据，可以用于指导下一个迭代，每个迭代都需要做中期回顾，进行相应的调整
故事的原则
INVEST
- Independent（独立）
- Negotiable（可协商的）
- Valuable（有价值的），架构设计，代码清理等不算故事
- Estimable（可估算的）
- Small（小），不应该大于一到两个开发人员可以在一个迭代中完成的工作量
- Testable（可测试的）
故事估算
有几种方法可以对故事大小进行度量
- 衬衫尺码法（Small，Middle，Large）
- 斐波那切数列法（1，2，3，5，8）
- 伸手指头法
分解、合并和穿刺
分解、合并比较好理解
穿刺可以理解为任务调研，是为了估计一个故事需要多长时间而进行的故事
对迭代进行管理
- 完成故事而不是任务
- 开发人员主动拣选任务
- QA 应该先于开发人员完成验收测试的编写
- 定期向利益相关者进行演示
迭代速率问题
迭代速率加快并不一定是好事，也可能是管理人员在向团队施加压力
速率减慢则通常是由于代码质量差
黄金故事，为了避免故事通货膨胀，始终以将实现的故事所需要的故事点数与黄金故事做比较
二、小步发布
持续交付
三、验收测试
业务分析师、QA和开发要相互合作
- 业务分析师描述乐观路径
- QA找出所有悲观路径
- 开发人员确保这些测试在技术角度看也是合理的
验收测试通过即表示故事开发完成
四、完整团队
尽量使整个团队的人坐到一起
此实践被视为业务实践而不是团队实践，因为业务才是从完整团队实践中获益最大的一方
本系列的文章列表
END