作者：程序员罗尼｜发布：2020-12-12 ｜原文：https://mp.weixin.qq.com/s/ayra0QJe1CMfPEYN7aPe0A

本篇文章为《Clean Agile》第二章的读书笔记

专业性

在我看来，专业性就是靠得住，把事情做好，做对

软件已经统治了世界，到处都是电子设备，设备里面有各种软件。但是开发人员的专业素养确需要继续提高，我们做了太多失败的项目，承受了太多的缺陷，做了太多的妥协，也导致了太多的损失，有些甚至威胁生命，比如飞机船舶等控制软件

我们在写下每一行代码的时候，都要充满敬畏之心，很可能一个微小的错误，就会导致汽车失灵，飞机失事

因此，提高我们的专业性，保证软件的质量，是一个有追求的开发人员的原则问题

同时，作为一个专业人员，我们要提供靠谱的服务，其他人也会对我们有专业能力上的期望

合理的期望

开发软件是一个团队性的工作，需要不同角色，不同工种间相互配合，但不同角色之前也会产生冲突

不同角色对软件开发有不同的期望，虽然这些期望都看起来十分合理，但实现起来却相当困难，敏捷是最有希望实现这些期望的方法，下面列举一些十分合理的期望

CTO 对软件工程师的期望

我们不会交付一堆垃圾（测试，重构，简单设计，用户反馈）
从技术上随时做好交付的准备，是否部署只是一个业务决策，我们要保证在每个迭代结束之后技术上都已经准备好了
稳定的生产率，但是前期总是很快，由于没有存量代码的负担，后期由于代码中的混乱越来越多，就会导致速率下降，这个时候多数领导会想到往项目里加人，由制造混乱的人再去训练新人，期望新人能帮助增加生产率，怎么可能，他们只会效仿前人，制造更多的混乱（测试，结对编程，重构，简单设计）
划算的适应性，接受和实现变更，让变更的成本相对划算，这种能力是我们的工作之本（software not hardware）（测试驱动开发，重构，简单设计）
持续改进，随着时间的流逝，系统的设计和架构应该越来越好，代码结构应该得到改善，效率和吞吐率也应该得到改善（实际呢，哎。。。）（结对编程，测试驱动开发，重构，简单设计）
无畏之力，为什么软件会随着时间的推移慢慢腐化？因为恐惧，祖传代码没人敢动，动坏了锅就是自己的，随着业务的发展，只能在混乱的基础上制造更多的混乱，想想如果你有完整的测试套件，当你弄坏了任何一点东西，你都会得到反馈，并尽快修复，那你还会惧怕修改吗（验收测试，测试驱动开发，持续集成）
QA 应该什么也找不到，他们只负责编写验收测试（测试驱动开发，持续集成，验收测试）
测试自动化，不要浪费 QA 去做人肉测试（测试驱动开发，持续集成，验收测试）
我们能相互掩护，团队之前没有知识鸿沟，任何一个人不在岗位，都有其他人可以顶上（结对编程，完整团队，代码集体所有）
诚实的估算，即使无法准确估算，我们也能做出相对的估算或者概率上的估算（计划游戏，完整团队）
你需要说“不”，在我们快要掉下悬崖的时候提醒大家，而不是放任自流（完整团队）
持续主动的学习（完整团队）
相互指导（完整团队）

权利条款

做事得讲规矩，尤其是不同利益团体合作的时候，对软件开发来说，最重要的两个团体就是业务团队和研发团队

敏捷的目的就是为了消除业务和研发之间的鸿沟，通过定义如下条款，充分满足和平衡两个群体的期望

客户权利条款

客户有权制定总体计划，并且知道完成的时间和成本
客户有权在每次迭代得到更多的潜在价值
客户有权在一个真实的系统上看到进展，所指定的测试，都可重复的成功执行，以证明系统正常工作
客户有权改变主意，要求替换功能或者修改优先级，而且不用付出高昂的成本
客户有权在时间表与估算发生变化时得到通知，以便及时选择如何缩小范围来达到项目日期要求，注意，客户无权要求团队顺应项目日程，他们的权利只限于通过调整范围来管理日程
客户可以在任何时间取消项目，并留下一个有用且可用的系统，该系统的价值与迄今为止的投资相称

开发人员权利条款

开发人员有权知道明确的需求优先级排序
开发人员有权保持高质量的工作输出
开发人员有权向伙伴，经理，以及客户提出请求并获得帮助
开发人员有权决定和更新自己的估算结果
开发人员有权决定是否承接某种职责，而不接受指派

我们无法承诺在固定的期限内交付固定的项目范围，要么范围，要么日期，必须有一个是弹性的（为了保证质量）

业务部门无权强迫开发人员破坏自己的职业声誉或者违反职业道德（为了及时交付走捷径或者降低质量）