|
简化：为了达到一个长远的目标，先实现一个较为容易实现的目标，但是这个目标仍然能够给我们带来好处。项目管理者联盟
有些实践我们有一个长远的目标，但是对于这个长远的目标还不太清楚，或者要达成这个长远目标，要走的路还很长。如果有些做法可以给我们带来一些好处，虽然不如长期目标带来的好处那么大，我们仍然可以先做起来。项目管理者联盟
系统测试和低成本测试的拉通。系统测试和低成本测试拉通是个长期而艰巨的任务，比如可能需要良好的基础设施的配合。但是我们可以做一些简单的事情来获得相似的好处。项目管理者联盟
暂停：暂不实施某个实践。
有些实践，团队不具备实施条件，或者对团队的冲击较大，可选择暂不实施。例如TDD。实施TDD需要较高的条件。如果团队不具备这样的条件，贸然推行难度非常大，这个时候常常选择暂停。项目管理者联盟
上面的5个模式所在维度并不相同。比如，并行是从组织的维度考虑的，而阶石和简化是从目标维度考虑。另外，在不同范围内看，同样的实践也可能属于不同的模式，需注意模式的目的是为帮助参与者清晰把握问题本质，认识解决方案在时间和范围上的局限性。所以把实践与模式绑定的做法也不提倡。项目管理者联盟
项目管理者联盟
中国敏捷实践中的误区(四) 误区常源于主观臆断blog.mypm.net
自从接触敏捷以来，已经在公司里帮助建立了不少的团队去实施敏捷，也参与了不少社区的交流活动，在这些实践和交流的过程中，感觉对于敏捷，还是有很多不同的理解，其中也包含了不少对于敏捷的误解，在这里和大家一起讨论一下比较常见的几条。项目管理者联盟
敏捷就是追求速度项目管理者联盟
一次在和几个朋友聊天的时候，有朋友说最近装了有线数字电视，他觉得开发数字电视频道服务的团队应该是采用了敏捷的团队，因为每隔一段时间，就会有新的功能发布，只是系统不稳定，不得不经常的重新启动机顶盒。项目管理者联盟
这无疑是个非常有趣的关于敏捷的理解，似乎敏捷就是关注软件功能的投放市场速度，而往往忽略质量。我想这是很多有关敏捷的理解中，比较典型的一种误识。如果我们重读一下敏捷的四句宣言以及12条敏捷原则，应该不难看出，敏捷实际是关注实现客户的价值，而这一价值体现在“可工作的软件”之中，这其实是对质量的要求，它意味着交付的软件是客户需要的并且质量稳定的，是同时对需求质量和开发质量提出要求。另外，因为市场的变化会促使客户重新调整需求，以获取最大的价值，因此敏捷强调“响应变化”，迅速调整策略，以帮助客户迅速对市场变化做出响应。所以，个人的理解，敏捷真正的含义应该是：training.mypm.net
快速实现客户的价值(可用的软件);项目管理者联盟
快速灵活的响应变化。项目经理圈子
一个不重视质量，只关注简单堆砌代码的团队，不是真正的敏捷团队。club.mypm.net
敏捷项目没有计划项目管理者联盟
敏捷项目团队确实不会，或者说，很少会在项目之初建立一份类似于WBS任务分解的进度表和甘特图，但敏捷项目依然是有计划的，和传统的进度计划不同，敏捷的计划不是关注在完成项目的一个个活动或者说任务，比如说需求分析、概要设计、详细设计，模块一编码等等，而是关注在客户的需要，关注客户价值的优先级，其计划的对象是用户要求的功能，例如用户故事，计划活动的产出是一个设置了优先级的用户需要的功能列表。敏捷计划分为以下几个层次：PgMp.mypm.net
愿景–制定产品的长远目标;项目管理者联盟
路线图–制定实现长远目标的分步实施计划;club.mypm.net
发布–制定一次发布的目标，包含在一个发布中希望交付的需求清单，并设置了优先级;talent.mypm.net
迭代–制定一次迭代的目标，包含了在一个迭代中团队承诺交付的需求清单及为了达成目标而设置的工作任务;
每日计划–制定每天的工作目标，包含了团队中每个成员的工作任务。项目管理者联盟
其计划的过程是一个持续的过程，从项目开始时制定产品的愿景，到每个迭代开始时制定迭代计划，敏捷项目的计划不断的细化，不断的根据变化而调整，是Just-In-Time的计划。项目管理者联盟
敏捷只适用于小型项目和团队项目管理者联盟
敏捷实践确实很多发源于小型的项目团队，但并不是说敏捷只适合小型项目团队。其实，早期的Scrum项目就已经有在500多人的大型项目中成功实施的案例。可能是由于大多数的敏捷团队一般都希望在5～9人的规模，并且希望团队成员在同一个工作区域，所以很多时候被认为不适合跨地域，跨团队的大型项目的开发。项目管理者联盟
|
