常用的敏捷实践包含：精益、看板、Scrum、XP极限编程、水晶、DSDM动态系统开发、FDD功能驱动开发、AUP敏捷统一过程、OpenUP。
《敏捷实践指南》将敏捷方法和看板方法是为精益方法的子集。因为他们都符合精益思想的具体实例，都反映了“关注价值”、“小批量”、“消除浪费”。
- 精益软件开发LSD
| 面对场景 | 解说 | 原则 | 解说 |
| 过度 | 对员工和生产/研发过程施加不必要的额外压力 | 消除浪费 | 无法带来价值的事务就是浪费 |
| 违规 | 不切实际的需求导致过生产/研发程中的不均匀 | 尽快交付 | 短期迭代或小批量提供有价值的反馈，促进有效的决策 |
| 浪费 | 非增值活动或过程 | 增强学习 | 通过短迭代周期、重构、继承测试和频繁客户反馈会议增强学习 |
| 团队授权 | 精益专注于团队，因为决策制定和管理的来源让团队了解最佳选择和成本。 | ||
| 较迟决定 |
管理不确定性的最佳方法是收集信息，最后的责任时刻给予承诺，打破部件 间的依赖关系。 |
||
| 建立整体 | 确保质量是嵌入在整个系统的，系统需要构建自动化测试，安装和持续集成。 | ||
| 目光长远 | 脚踏实地，快速试错，快速学习。 |
- Scrum 参见我的另一篇文章，ACP--Scrum
- 极限编程
极限编程 (XP)是一种基于频繁交付周期的软件开发方法。该名称基于这样一个理念：将特定最佳实践提炼到最纯粹和最简单的形式，然后在整个项目周期内持续运用该实践。
核心思想：鼓励从最简单的解决方式入手再通过不断重构达到更好的结果，主张“不对将来可能的需求上投入精力”，这么做的好处，设计与代码上的简化可以提高交流的质量。
价值：沟通、简单、反馈、勇气、尊重
- 沟通：追求有效的沟通而非无意义的会议。强调项目组成员、客户之间有效地、及时沟通，打破信息孤岛，确保信息的畅通。
- 简单/简洁：实现最贱的可行方案。应该尽快保持代码的简单，只要能满足工作需要即可，有利于代码的重构和优化，确保频发的发布功能。
- 反馈：通过对当前系统状态进行不断的反馈，达到迅速沟通、编码、测试、发布的目的。
- 勇气：勇于放弃和重构，这点太难了。
- 尊重：尊重每一位成员，从人性的角度为项目组成员考虑，确保项目的质量和交期。
敏捷编程的开发过程核心活动：“需求→测试→编码→设计过程中，因此对工作环境、需求分析、设计、编程、测试、发布等提出了新的思路、要求和挑战。
| 动作 | 解说 |
| 工作环境 |
项目开发人员都需担任角色，并履行相应的权力和义务 开放式的工作环境，方便面对面交流 强调每周工作40小时，不加班 |
| 需求分析 |
开发人员和客户一起编写Story，并根据经验经将user stroy组合或分解，最终记录在stroy card； 根据记录的stroy card，按照商业价值、开发风险有限顺序逐个开发 |
| 设计 | 强调简单设计，即用最简单的方法实现每个小需求，满足系统客户在当前的需求即可 |
| 编程 | 提倡结对编程，共同完成一段程序的编码，可以提高纪律性等等 |
| 测试 | 开始编程之前，先写好测试，提高软件的可测试性。通用方法：单元测试、整合测试、功能测试、系统测试 |
| 发布 | 按照开发计划/时间盒，没完成一个时间盒，发布一次。通过敏捷的迭代和增量交付实现客户利益最大化 |
标签：重构,21,编程,反馈,精益,测试,敏捷,打卡 来源： https://www.cnblogs.com/atun/p/12040650.html
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。