项目 敏捷 ba角色
上周，我在克拉科夫举行的项目管理协会（PMI）和国际商业分析师协会（IIBA）的PAM峰会上。 我做了一个题为“敏捷中的项目经理和业务分析师有作用吗？”的演讲。 –现在通过SlideShare在线。 伦敦地区的那些人甚至可以做得更好，下周我将在技能问题上重复演讲。 （它是免费的，6月24日下午6.30， 可在Skills Matter网站上注册 。）
对于那些不能解决的人，我将简单地讨论这个问题……
引用“铁三角”或“约束三角”或“项目约束三角”会很有帮助–随便说一下，这里再次是：
以前，许多读者可能看到的版本略有不同。 我的版本既没有成本也没有质量，因为我不认为这代表了权衡：
- 一个软件开发团队的成本是压倒性的工资，您拥有的人员越多，拥有的时间就越长，您所花的钱就越多。 所以Cost = People x Time 。 人和时间都在这个三角形上，因此您可以计算成本，反之亦然。
- 如Philip Crosby所说， 质量是免费的 ，或者引用Capers Jones的话：“具有低缺陷可能性和高缺陷去除效率的项目也具有最短的进度，最低的成本和最佳的客户满意度。” 如果您在质量上妥协（并且质量是指错误，需要返工），那么它会花费更长的时间，成本会增加，并且客户会感到不满意。 如果您想快速交货，则将质量最大化。
所以我的首选版本如下所示：
这使功能/功能/“什么”成为我们进行谈判的唯一场所。
对于BA来说，回答原始问题非常容易。 业务分析师具有围绕该问题的技能。 BA可以通过多种方式提供帮助：也许作为代理客户，作为战术产品负责人，作为详细信息人员或与测试人员合作。 每个团队都应该有一个（差不多）。
对于项目经理来说，事情肯定更加复杂。 他们围绕“何时”进行的许多传统工作都是多余的，因为我们的目标是建立稳定的团队，并在围绕“谁”进行工作时确定工作规模。 我可以想象，确实，我看到过，小型团队完全不需要项目经理。 没有项目经理就可以成功。
但是，对于较大的团队，可能需要填补这个职位。 在最基本的层次上，存在管理和报告，也可能有协调任务，它们可能与利益相关者之间的BA /产品负责人一起工作，并且当存在客户/供应商关系时，双方都可能希望某些经理“管理”关系。
但是尽管有管理工作要做，但我看不到“项目”的作用。
成功的软件可以生存，它可以改变，如果需要增强，适应的话。 只有无效的未使用软件不会改变。 开发软件产品就像建立公司一样：如果人们停止索要事情，那您就倒闭了。
这与项目的PRINCE-2定义相冲突：“需要一个临时组织，以使用预定资源在预定时间产生唯一和预定义的结果或结果。”
成功的软件没有预先指定的结束日期，的确很难确定许多项目何时真正开始！
成功的软件不是暂时的，支持或提供软件的组织也不应该是暂时的。 它们可能随时间增长或收缩，但我们应该以稳定为目标。
而且由于敏捷拥抱变化，所以结果也不是预先定义的。 实际上，由于所有成功的软件都以始发者很难看到的方式进行了更改，因此只有短期的结果。
对我来说，很明显，软件开发从未而且从未真正符合项目的隐喻。 实际上，我认为使用项目隐喻会严重损坏软件：
- 这导致了关于“何时完成”的无休止，毫无意义的讨论。
- 它导致治理流程尝试完成未完成的事情
- 它导致对质量等事物的短期思考
- 它导致公司解散成功，表现良好的团队-这就是我所说的Corporate Psychopahy 。
BAU（照常营业）不是一个坏词，这是正常现象。 支持软件，添加功能，修复错误，增强产品是“一切如常”，我们应该为此感到自豪。
然后，如果我们专门研究敏捷的工作方式，那么许多传统的项目管理假设都将失效：
- 鼓励团队进行自我管理：确定要完成的工作的细节，并决定如何最好地自己解决
- 敏捷团队具有包容性和非等级性
- 敏捷团队通过点对点交流，而不是通过一些集中的通讯中心（即经理）进行交流
简而言之，敏捷假设一种“理论Y”的工作方式，而不是太多项目管理文本中隐含的“理论X” 。
如果您认为我是激进的，那么让我告诉您我是一个温和的人，有些人会更进一步。 看看我去年在Scrum-Scrum-Scrum上发表的帖子以及随后的讨论，或观看Christin Gorman的视频“在Scrum团队中添加项目经理就像用蛋黄酱做蛋糕。”
所有这一切的最终结果很简单：项目经理需要重塑自己的角色。 重塑的角色可能不包含“项目”一词。
对于任何软件开发团队，尤其是希望被视为敏捷的团队，默认选择可能是：没有项目经理。 角色负责人有责任证明他们如何为团队和整个组织增加价值。
项目 敏捷 ba角色