领导力大挑战
在实施Scrum项目的过程中，Scrum Master的角色是相当关键的，因为他是团队的推动者。本文围绕什么是仆人式领导、仆人式领导的起源、如何将领导力传达给团队、Scrum Master作为仆人式领导者的角色展开叙述，同时重点阐述仆人式领导者应有的基本内外特征。
新闻
该内容已经被标记书签！
标记书签错误，请重试！
敏捷管治：管理和资讯科技的桥梁
作者 Vikas Hazrati 译者 麦天志 发布于 2009年4月18日
传统的项目管治（project governance）是 指一套确保项目成功的规则和过程，传统管治方式尝试以流程形式去管理项目。但是使用到工时单，成本和日程安排等却使更重要的事情如项目利益、风险管理、持 份者参与、质素、范围、目标控制等得不到应有的注目。这样看管治这概念和敏捷开发互不相容，但是大多敏捷开发使用者认为足够的管治对敏捷项目好处多于坏 处。
Andrew Clifford 提出引入项目管治带来以下好处：
- 改善股东价值，因为资讯系统以商业资产来管理
- 改善业务和资讯科技部门关系，因为资讯基建要求能转化成可量度目标
- 改善资讯基建投资回报，因为管理层可以留意及执行新资讯基建的使用
- 减低项目失败，因为技术和规管（compliance）要求都能及早发现
- 减低符合规管和内部标准要求的成本，因为这些都在管治框架内管理
- 减低因为不同标准要求所有来长远风险和成本，因为管理层可以清析看到符合格标准的程度
- 改善资讯系统部门作为管理商务系统方面的考衡，这对于管理外包服务更为重要
Mathew D. Laudato指出，虽然项目管治对于工程部门很难磨合，但对资讯系统预算的使用还需向公司高层负责，他同时建议敏捷开发过程应该包括项目管治，他指出：
在每一个迭代回顾的时候应花些时间以业务角度纪绿项目的进度，这报告最少要包括有什么功能已完成、完成这些功能所花的成本、这些功能的部署安排、以及现在有多少比例的需求已完成。
虽 然项目团队很独立自主，但也不是完全不受控制，管理层放下足够检查关口去避免不稳定、含糊、压力演变成混乱状态，与此同时，管理人员也要避免硬性控制窒碍 创新，重点应放在「自我控制」（self-control）、「透过同僚压力的控制」（Control through peer pressure）、「以爱来控制」（Control by love）。
根据Ross Pettit的观点，敏捷管治最根本是回应以下两条问题：
- 我们的投资能否得到应有回报？
- 付运的方案能否达到我们的期望？
第一个问题是关于金钱使用的效益，回答基于事实的量度去衡量未完成的范围、已完成工作、总支出以及准确的趋势。第二条问题关于这方案的完整性，如何应付不同的企业政策包括保安、架构、质素、风险等，Ross认为良好的项目管治可使到：
减少「惊讶」、提高信任和信心、配合公司策略的执行方案，让资讯系统较少陷入本身的问题，从而更能适应业务上的转变。
有了足够理由相信项目管治的重要性以及对项目带来的好处，现在问题是在敏捷开发项目中如何最佳引入项目管治？
Ross提出以下方法：
- 良好管治要成就敏捷，就不可以成为日常运作的负累，要做到这点，需要一些统一而不繁累的方法在组织里收集数据。
- 要考量方案有多完整，资讯系统管治必需在整个部门有著积极参与的角式，包括资讯保安、基建、架构、风险管理、业务管理、项目管理办公室等，然后不同资讯功能的部门也积极参与这过程。
- 资讯系统管治不能变成神秘独立的圈子，相反要成企业的核合部份，我们必需以各有关人事熟识的方法来沟通，更重要的是以业务的语言和业务人员沟通。
Dean Leffingwell提出以下方法来设置轻量的管治过程，他指出，管治模型应该：
- 订定敏捷的准则来指出敏捷对公司的意义，清楚定义敏捷、单元测试、回顾、站立会议等
- 保持轻盈，不多于三至五页
- 建议但不指定
所以敏捷的管治能成为管理和资讯科技的桥樑，重点在于避免过度管制，窒碍创作力以及在敏捷开发环境下的热诚。
查看英文原文：Agile Governance: The Bridge Between Management and IT
译者附注：
管治和规管的问题是目前企业当前流行讨论的议题，资讯系统部门难免虽要配合，不过，对于硬性加入管治过程，这也是一种浪费，特别是对于还未有相关管治过程的组织。纇似的讨论也曾在风险管理、系统保安等出现，他们都指出敏捷开发所未有顾及的范围，但同样提出硬性要求，还是需要时才加入才是比较适合的做法。
译者 麦天志 现就职于Odd-e从事团队教练工作，从小对编程产生兴趣，毕业於香港大学，主修计算机科学。
没有回复
关注此讨论 回复