关于敏捷开发实践的一些思考.md

date	tags
2019-10-12	思考

两个快速：敏捷开发是一种面临快速变化的需求快速开发软件的能力 --《敏捷软件开发》 两个能力：敏捷开发管理能力，敏捷软件开发能力 两个小：需求拆得小，迭代周期小

发展史

• 1995年有了scrum
• 1998年有了XP（极限编程）
• 2001年一批业界专家成立“敏捷联盟”，并提出了“敏捷软件开发宣言”

所以值得注意的是

敏捷开发价值观和原则

下面思考部分来自smq，价值观和原则的列举来自《敏捷软件开发》这本书

敏捷开发价值观

• 个体和交互胜过过程和工具
• 可以工作的软件胜过面面俱到的文档
• 客户合作胜过合同谈判
• 响应变化胜过遵循计划

实践中的关于敏捷开发价值观的思考

• 第一条，毋庸置疑人肯定是最重要的。如果只是一两个人做纯技术类项目，甚至都不需要项目管理工具。
• 第二条，在实际的迭代过程中，文档作为一种需求管理工具，往往结局都是与实际运行的软件失配，原因一般是：1）一些本来就有歧义的文档。2）后续有一些口头上的需求对接，没有落到文档。3）单个模块存在多个文档，最后多个文档叠加在一起才能完整的梳理整个模块的逻辑，结果是当产品想了解某个模块的某个功能点时，代码反而是更好的“文档”。
• 第三条，这点在做内部系统的时候尤其能体现，如果与客户（可能是内部员工or兄弟部门）沟通的更频繁，迭代的过程就会更顺畅一些，也更可能开发出符合客户预期的产品。这时候更考验产品经理的沟通能力。
• 第四条，或许对于一个程序员来讲，遵循计划比相应变化要更舒适，但是从技术挑战来讲，当程序更能响应变化的时候是更有成就感的。痛苦不在于响应变化本身，而是对于变化的响应，我们束手无策。所以在《敏捷软件开发》这本书里面，作者不仅在讲概念，也讲了如果做好敏捷开发。

敏捷开发原则

1. 我们最优先要做的是通过尽早的，持续的交付有价值的软件来使客户满意
2. 即使到了开发的后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势
3. 经常性地交付可以工作的软件，交付的间隔可以从几周到几个月，交付的时间间隔越短越好
4. 在整个项目的开发期间，业务人员和开发人员必须天天都在一起工作
5. 围绕被激励起来的个人来构建项目。给他们提供所需要的环境和支持，并且信任他们能够完成工作
6. 在团队内部，最具有效果并且富有效率的传递信息的方法，就是面对面的交谈
7. 工作的软件是首要的进度度量标准
8. 敏捷过程提倡可持续的开发速度。责任人，开发者和用户应该能够保持一个长期的，恒定的开发速度
9. 不断的关注优秀的技能和好的设计会增强敏捷能力
10. 简单--使未完成的工作最大化的艺术--是根本的
11. 最好的架构，需求和设计出自于自组织的团队
12. 每隔一段时间，团队会在如何才能更有效地工作方面进行反思，然后相应地对自己的行为进行调整

实践中关于敏捷开发原则的思考

• 第一条，这里我首先想到的就是MVP这个词，以及前leader总跟我们“唠叨”的“小步快跑”，这个比喻很恰当（小步子拐弯更灵活），第一个版本要小（MVP），以及迭代更频繁（小步快跑），让产品的提供的功能偏离用户实际需求的可能性更低。
• 第二条，同价值观第四条
• 第三条，同原则第一条
• 第四条，同价值观第三条，不过大概率不能像这条原则所说的那样，像是我们在为兄弟团队提供软件时，兄弟团队也有自己的工作，后来也只能是每周对接一次，其实已经够用了
• 第五条，以人为本，改变阻碍人的因素，没什么好说的，干的开心，效率自然高
• 第六条，面对面沟通的方式很赞，如果拉群以及找会议室当然也能解决问题，不过相比于面对面，效率还是太低了（不过也别忘了把共识写到文档中）。前提是人最好是在同一个团队里，第一，时间安排以及工作更近，第二，更重要的是大家立场更接近。在一个多职能组成的敏捷开发团队中，往往不同角色在协作过程中会达到双赢的效果，且总是会朝着roi最高的方向努力。
• 第七条，想实现这一条，要求产研团队把任务拆解的足够细，与原则的第一条类似，也类似与“小步快跑”的模式，这意味着更高效的纠偏。
• 第八条，人不是机器，每个人的运行模式不同，按各自的节奏走，在保证正常迭代计划的前提下，找到每个人最舒服的节奏，那么如何防止大家卷起来？1）管理者尊重研发排期，轻易不challenge，基于第七条的拆分更细的原则，实际上关于排期时间这个信息可以做到相对更对称。2）研发之间别互相卷
• 第九条，这一条的意思是，对于代码优化不要太拖延，今天设计的糟糕，未来的敏捷开发能力就越差
• 第十条，用最简单的方式解决当下问题，保持高质量高标准的交付，并相信这样做系统在未来会有更好的拓展。实际上也不是绝对了，如果能明确的预知问题，当然可以预先选择更适合的方式（元信息，微服务）
• 第十一条，“自组织是指混沌系统在随机识别时形成耗散结构的过程，主要用于讨论复杂系统，因为一个系统自组织功能愈强，其保持和产生新功能的能力也就愈强。”，我的理解是保持个体的主动性，能使团队产生更强的战斗力，算是第六条的归纳和拓展，比如除了需求的沟通，更多的技术分享或许也是自组织能力强的体现？
• 第十二条，也就是复盘，包括了第五条，以及所有的不适合当前团队的地方，可能后续连敏捷开发本身也不适合了

极限编程

下面思考部分来自smq，极限编程介绍来自《敏捷软件开发》这本书

极限编程是一个敏捷开发的实践，有下面一些具体的实现：

1. 完整团队
2. 计划游戏
3. 客户测试
4. 简单设计
5. 结对编程
6. 测试驱动开发
7. 改进设计
8. 持续集成
9. 集体代码所有权
10. 编码标准
11. 隐喻
12. 可持续的速度

关于极限编程所推荐的实践的思考

极限编程的每一个实践都敏捷开发的价值观和原则支撑 在实践中，我们不一定严格按照其推荐的实践，可能弃用一些实践，可能略作调整

1. 第一条：完整团队的意思是，不同职能的同事在一起组成一个完整的团队，即使是临时组件，也要有共同的目标。这个实践让面对面的沟通更容易（原则6），以及如果团队里包含客户，还可以在更好与客户沟通（原则4）
2. 第二条：评估工作量，给用户反馈预算情况，再根据需求的收益情况，便可以按roi排期，高频次迭代，长此以往让用户对产研团队更有预期（原则1， 原则3）
3. 第三条：黑盒测试。现在的项目太复杂了，黑盒测试都有些扛不住了，之前做c端的时候，QA会搞一些黑盒测试。
4. 第四条：杀鸡牛刀问题。但目前程序员市场太卷了，各个公司各个团队之间也卷，适当搞些新技术，也是能吸引一些候选人。
5. 第五条：结对编程。不可能，一个人都是拆成两个人用的。
6. 第六条：说的很对，只不过现在黑盒测试，甚至点点点越来越多了，且一个人当两个人用，结果导向，极少有项目会写白盒测试。不过这里关于可测试性和可维护性的正相关关系值得我们关注，如果我们认同这样的关系，那么可测性就是要关注的，跟是否实际去写白盒测试无关。
7. 第七条：最好的办法就是code review。
8. 第八条：放在一起测试，集成是重点，feature总是要放在一起跑的，即使没有白盒测试，甚至黑盒测试也没有，也要把所有feature合在一起跑一跑测一测。
9. 第九条：提倡大家都更可能的掌握整个项目的情况，不符合实际情况，根本没时间了解。那做其他模块啥都不了解怎么办?没事，我们还有deadline以及睡眠时间...
10. 第十条：基于第七条，第九条，以及需要在仓库里加自动格式化的工具
11. 第十一条：不懂
12. 第十二条：行军打仗，士气很重要。这要求管理者能组织更好的计划，能定期组织会议发现风险，协调资源，要求开发成员能把需求拆解的更细，且能准确的评估需求的风险点，以及联调和测试的复杂度。