敏捷方法在组织中的应用与分布式规划工具评估

# 敏捷方法在组织中的应用与分布式规划工具评估 ## 1. 敏捷方法在不同团队的应用情况 ### 1.1 敏捷软件开发团队 - **理念解读** - 团队以敏捷为傲，认为敏捷是一整套方法论，而非个别行为。如他们能每两天交付一次成果，体现了敏捷性，且客户满意度高。 - 强调与客户的协作，将客户视为团队一部分，以获取最大商业价值。例如团队领导表示要与客户交流，而非单纯按自身需求开发。 - 注重减少浪费，通过持续获取反馈，快速交付小成果并逐步完善，避免交付无用的东西。 - **实践元素** - 遵循极限编程（XP）的大部分原则和技术，在组织采用敏捷之前就已实践，并采用了一些变通方法来适应组织内不兼容但已确立的流程，如事后编写详细设计文档以符合系统。 - 关键实践是持续的客户反馈，主要通过维基和每两周一次的电话会议。团队使用“墙”展示用户故事卡和图表，维基记录进度，方便远程成员，如离岸测试人员。 - 该团队虽知晓敏捷手册，但未完全阅读或用作指导，获得了组织内的敏捷奖项，但仅在程序员和软件工程师角色内应用敏捷技术。 ### 1.2 Project Z团队 - **理念解读** - 认为敏捷能使交付解决方案的速度比平时快很多，这一观点得到开发人员、交付和可用性经理、产品经理及技术架构师的认同。 - 可用性和用户界面设计师认为敏捷能让最终用户更接近设计和生产过程，使用户体验团队在生产周期中发挥更连贯的作用。 - 团队未能完全采用敏捷而感到沮丧，如话语和文档中缺乏用户故事，员工觉得未感受到组织的敏捷变革，高层决策未传达至基层。 - 强调所有利益相关者之间需要加强协作和沟通，特别是营销经理和 IT 交付经理之间存在问题，如营销经理想要特定成果并立即实现，而 IT 交付经理需拆解任务。 - **实践元素** - 实践体现了对协作和沟通的需求，但组织架构是层级式的，产品需求确定后用户输入过程受限。 - 有站立会议和用户故事研讨会等行为，采用了一些变通方法，如“温室”研讨会汇聚关键利益相关者构建和完善原型并确定 90 天交付计划，从详细的“营销需求文档”（MRDs）中提取用户故事。 - 团队成员提到“根深蒂固的流程”影响敏捷采用，如合同和与大型系统的集成问题。鼓励使用维基和电话会议来保持地理分布团队成员的沟通。 - 技术架构师、交付经理和可用性经理发现员工尝试以 90 天周期交付，但只是“缩小”了瀑布流程，无质的改变。 ### 1.3 “业务”（或客户代理）团队 - **理念解读**：认为创建用户故事没有价值，因为 MRD 已反映用户研究工作，无需重复，但未讨论或评价生产过程中持续用户或客户反馈的价值。 - **实践元素**：营销部门与 IT 部门在物理上分离且距离较远，影响了两个部门之间协作的数量和质量。 ## 2. 不同团队敏捷应用情况总结 |团队|对敏捷的理解|实践情况|面临问题| | ---- | ---- | ---- | ---- | |敏捷软件开发团队|接近敏捷宣言，注重整体方法论、客户协作和减少浪费|遵循 XP 原则，有持续客户反馈实践|需适应组织内不兼容流程| |P