|
一提到敏捷，脑袋里就自动蹦出两个词。 快速、灵活+1 快速、灵活+1 快速、灵活+1 快速、灵活 敏捷项目管理将大型的项目分解为更小的、方便管理的开发周期，称之为Sprint，然后再将项目团队分为更小的独立团队来完成这些Sprint。 客户在每个开发周期结束时验收产品，团队再根据客户的反馈对产品进行优化和修改。这样在研发的过程中，就可以更方便的将客户的意见用于后期的开发周期里，避免频繁的需求更改，搞乱整个项目节奏。 每个迭代后的 Sprint 评审，可以回顾在哪一部分和独立团队出现了问题，及时改正，再进行和其他小组的复盘交流，将这些复盘后得到的结果应用到下一个 Sprint 中。  注意 这样看起来，敏捷管理确定很方便，但注意，并不是所有项目都适合敏捷管理 ! 首先需要根据项目当前情况，分析是否适合敏捷管理，敏捷管理适用于需求复杂且易变化的项目，帮助客户快速做出决策，验证市场可行性。 而小型、简单的项目则更适用于瀑布式项目管理的方法。 转型 传统项目管理模式想往敏捷开发、精益项目管理转型，该如何做呢？ 预先要换位思考相关干系人阻碍敏捷落地的根本原因可能有哪些，然后定性分析如何应对这些问题，做好充分的思想准备。 接下来你需要跟公司关键干系人沟通，传播敏捷宣言以及敏捷提倡的价值观，沟通过程可结合传统的项目管理方式做对比，体现敏捷的优势。赢得公司高层的支持很关键，其次是各职能部门经理，因为敏捷可能会触碰到他们的切身利益，这是日后敏捷能顺利落地执行的基础。 如果没有得到公司高层支持，就直接硬转型敏捷管理，那就是为搞垮团队埋下了一颗定时炸弹。  然后进一步跟产品、开发、以及测试等未来敏捷团队可能的人员做敏捷培训，让大家对敏捷有初步认识，为组建敏捷团队提前预热。待公司达成共识时，可初步组建敏捷团队，日常工作中便可以逐步给大家渗透传递敏捷的思想价值观。 在做敏捷训练时，要尊重团队成员，不要太激进，否则在转型的过程中，团队很容易就会垮掉。 转型不是一蹴而就，从传统管理方式向敏捷管理方式过渡不能急于求成，可以先逐步采取“混合敏捷”的方式，等团队适应后再全部实施敏捷模式。 例如：在转型初期，可基于传统项目管理，引入部分敏捷思想和管理方法，推行每日站立会议、看板管理、评审和反馈技术、回顾会议；然后逐步引入更多敏捷选择、精益原则。 如何做到敏捷开发与 CMMI 体系融合？ 敏捷开发与 CMMI 体系既对立又互补，两者都包含了一些软件工程的较好的实践。我们想要对二者进行融合，首先要明确它们的异同之处。 CMMI 与敏捷是两种不同的软件研发管理和过程体系，两者的共同目标都是多快好省地做好产品，满足客户需求；两者都是业界最佳实践总结、成功经验的积累和传播。 CMMI 过程标准 关注过程 较为复杂 敏捷 实践方法 关注人 更轻便、更灵活 其实，敏捷并不排斥必要的文档，敏捷的很多实践其实是对 CMMI 的一种实现，比如：每日站立会实际上也是在做项目监控。 同时，敏捷也注重管理和过程，但采用的是更为轻便、灵活、高效的管理方式。 在不违背敏捷宣言主要目标的前提下，可基于 CMMI 体系，裁剪、调整成合适的开发过程，创建一组 CMMI 与敏捷混合模型和方法，选择合适的技术应对特定的挑战，并允许团队做在执行中做必要的弹性修改，尽可能让软件开发过程既遵循 CMMI 规范，又符合敏捷原则。 近期热文 |
|
|
