当前位置：首页 > news >正文

敏捷项目管理

news 来源：原创 2025/6/25 13:12:01

虽然一直在践行敏捷开发，包括站会、尝试使用Confluence做知识wiki、每周分享等等，当然项目日常使用的coding、禅道、jira 项目管理和 jenkins 、git之类的CICD工具更不必说，但确实没有系统地去学习过敏捷开发管理。昨天被人问到敏捷开发到底是什么的问题，于是决定系统了解一下。

先上总结：
以人为本、面向变化、持续交付、客户参与。

解决什么问题：
为了高效、灵活地应对快速的需求变更
小型团队模式：
5-9人最佳，不超12人。
尽早和持续交付：
开始时尽量简单、尽早交付一个可用软件，而后拥抱变化、根据需求变更迭代开发、持续交付，一般以1-4周为一个迭代周期。
刚开始时避免过度设计建模、避免大而全，只需考虑核心的、必须的功能。后续可以根据需求进行重构。
透明性：
交付的所有参与者：包括需求、产品、开发、测试和和管理，对于所有影响交付结果的内容，全都应该知道并理解。
面对面交谈：
最有效率、也是最有效果的信息传达方式。
不断总结、调整：
总结如何更有效率、然后成员相应地调整自己的行为。

敏捷项目管理三大角色：

产品负责人：制定产品愿景、确定需求优先级，与利益相关者沟通，确保敏捷开发过程中能够关注最重要的任务
敏捷团队：由跨职能团队组成的，包括开发人员、测试人员、设计人员等，团队需要自我组织、自我管理，并保持高度协作和沟通，以确保项目成功。
敏捷教练：是敏捷方法学专家，负责指导和支持团队的敏捷实践和流程。

敏捷项目管理具体内容

迭代开发
持续改进
团队协作
客户反馈
灵活应变
目标导向和透明度
快速交付：尽早和持续交付

常用框架和方法
Scrum框架、kanban方法、极限编程XP、统一过程、敏捷建模
PingCode、Worktitle、Coding

价值观：
沟通、简单、反馈、勇气、谦逊

个体和互动优于流程和管理
是首要强调的价值观。强调个体的主观能动性、沟通。
可用软件优于详尽文档：
文档去繁就简，不懂的面对面沟通。
客户合作沟通优于合同谈判：
客户不应仅在最终交付时参与，而应全程关注并协同
适应变化优于遵循计划：
传统观念认为变更带来额外的开支、应尽量避免。敏捷认为变化带来提升机会、和更好的成果。

核心原则：

主张简单：最简单的方案就是最好的解决方案。项目开始时，不要过度建模(over-model)，只需基于现有需求，如果当前并不需要某项额外功能，那现在就不要考虑它。日后有需求变更时，可以重构。允许模型重构。
拥抱变化：需求时刻在变，人员对于需求的理解也时刻在变，人员本身也有离开和新加入。首先思想认知上必须要意识到变化是正常的，而后需要我们的开发方法应该是能够正常处理这些变化的。
递增的变化：这个概念似乎和简单性、变化性重叠。意思是不要一开始就准备好一切（过度建模），不需在最开始的时候就试图建立一个囊括一切的模型，只需开发一个小的模型、或者概要模型，然后慢慢地改进模型，或者是在不再需要的时候丢弃这个模型，这就是递增的思想。
可持续性：系统必须有足够的鲁棒性（健壮），以适应以后得扩展。不仅要构建高质量的软件、还要创建足够的文档和支持材料，以实现可持续性。

AM

“敏捷建模”（Agile Modeling，简称AM）是对已有方法的补充，而不是一个完整的方法论。 AM的主要焦点是在建模上，其次是文档。也就是说，AM技术在你的团队采用敏捷方法（例如eXtreme Programming，Dynamic Systems Development Method （DSDM），Crystal Clear）的基础上能够提高建模的效果。

AM强调在快速变化的环境中，采用灵活和迭代的方式进行软件项目的设计与管理。这一方法主要应用于软件开发的需求分析和系统设计环节。

在Scrum框架中，虽然主要关注项目管理和需求跟踪，但实际应用时常常与极限编程（XP）和敏捷建模等方法相结合，以覆盖软件生命周期的各个阶段。

在当前的系统开发趋势中，统一过程（UP）、极限编程（XP）、敏捷建模（AM）和Scrum等方法都是关键的组成部分。基于敏捷建模的软件需求分析和信息融合系统自适应敏捷建模，都是其在实际项目中应用的例证。

总的来说，敏捷建模不仅是一种方法论的缩写，更是一种高效且灵活的软件开发方法，对于提高团队协作和适应变化的能力具有重要意义。

AM

相关文章：