救火队下伪敏捷开发过程

救火队下伪敏捷开发过程

         救火队. 软件系统中BUG满天飞, 客户不满意. 救火可能是系统快崩溃了, 快速实现客户需求. 但这样需要全栈般能力强的团队.团队中每个人单兵作战的能力必须强，并且他们的协作能力也非常强，彼此之间高度信任。只有这样的团队能够做快速开发。而在短时间内，难以构建起这么一支强大的团队。这需要高层管理者之前就做好计划，未雨绸缪，一直不断建设一支强有力的团队。团队不是临时组建。用人海战术其实是一种蛮力, 没有科学的规划，而最辛苦的就是那些做事的人。如果不顾及每个人的感受，这是提前埋入了不愉快的种子。反观对参与救火的人员又有什么提高呢？是救火能力的提高吗？其实不是。没有一块时间对某个问题的系统思维。是不能把事情做好的。救火队的快速开发不是敏捷开发，是为了做项目而做项目。也反馈出前期项目管理的问题，过程上没有把控，过于追求盈利，忽视了的软件工程本身的核心价值。上升到高层还是管理的问题。应该关注点是

重视人、勤于沟通、注重成果、讲究合作、随机应变

    违背团队成员的意愿, 没有共同的愿景, 没有共同的价值观. 这是伪敏捷.  打着敏捷的旗号实施假敏捷团队士气依然低落.  敏捷中首先要尊重员工,  不考虑员工职业规划也是不尊重.  是的, 关键时刻大家一起上解决难题, 前提信任,是共同愿景. 软件工程有过程化, 而无序的过程, 混沌. 优秀的项目经理能够尽早识别风险并把风险降到最低.

     尊重、协作、改进和学习周期、为所有权自豪、专注于交付价值，以及有能力适应改变。这种心态是培养高性能团队所必需的，他们进而能为客户交付令人惊讶的价值。

• 尊重——大多数团队工作需要从尊重与你共事的伙伴开始。在组织层面，尊重组织各级同事、客户以及产品本身也是维系恰当工作环境的关键。

• 协作——随着待建系统越来越复杂，待处理的问题也随之更为复杂，没有一个人能在完成一项任务时掌握所有所需的信息。此外，与组织其他部分的同事以协作的方式一起工作将降低“手递手”交付的需求。通过工具、办公空间和行为规范对协作的促进，能提升协作讨论的质量和数量。

• 改进环——没有刻在石头上一成不变的过程，总有改进的空间。一个支持这种行为的组织将迎着这束光不断向前。

• 学习环——允许个人去尝试新鲜事物，成功也好，失败也罢，贵在为员工提供了学习和自我提升的机会。不应总向个人碎碎念失败，而应支持他们冒险，从而增长组织的知识水平。

• 为所有权自豪——即使没人为特定代码块负责，也应为预期交付高品质工作的增量交付物而自豪。

• 专注于交付价值——敏捷团队的主要目的是为客户交付价值。团队应该能够随时关注什么是最大的价值，并把这些传递给组织中的其他人（例如管理人员和 scrum master），这有助于消除任何障碍。

• 有能力适应改变——如果客户在会后两个小时给你打电话，说想要改改，组织随之而动。任何应对这种变化的处理过程都不应该成为这种变化的障碍。

我们希望打造的敏捷团队是

纪律性：
纪律性是敏捷研发和交付团队的基础，千万不要因为我们敏捷起来以及团队自组织，就不需要纪律。敏捷团队的纪律性可以说比任何其他研发模式的团队更为甚之。敏捷团队的纪律性无处不在，例如：频密的检视和作出必要的调整，不论是产品本身还是微观工作方式和过程；频繁交付可用产品；严谨的DoD条款；对时间盒的尊重；对团队合作规则的尊重和遵守；节奏；信息可视化；频密提交、持续集成和自动化测试。

主动性：
没有主动性，何来竞争力？对比其他的模式，包括其他敏捷方法，Scrum是特别强调团队主动性的工作方式。我们期望通过多种举措和引导技能带来和培养团队主动性。例如，PO想办法让我们做的产品更有意义和意思，懂得从为什么开始来进行思考和沟通；重视Sprint的目标，特别是业务目标；有一个优秀的ScrumMaster或者敏捷教练来打造团队；鼓励团队在对目标形成共识的前提下，开放地发表想法并热烈讨论，并尽早付之行动和检视成果；鼓励团队追求成长和提升，追求匠艺，并分享；真正落实自组织，不去干预和不去微观管控开始。

合作性：
三个臭皮匠顶一个诸葛亮！但他们需要合作，才能有成效。就算我们大家都是高手，也需要合作。Smart, but willing to work as a team player!（来自谷歌的招聘原则），不然还不如单干罢了，简单多了，还不会内耗。合作性首先来源于对最终成果的共同负责，这太重要了。放下原来的Titles和成见，一起探讨一下我们的共同目标是什么，同时拥抱和尊重多样性，对大家怎样在一个团队里工作制定一些规则，并持续去改进和调整。利用好回顾会议也是一个关键。其他支持合作性的实践还有：跨职能团队和个体；结对编程；内部或外部社区分享（异花传粉）；共有代码权；在一个房间里工作；团队估算.

创新性：
纪律性和主动性带来效率，但合作性和创新性带来价值创造的效果。创新性不容易。我们的教育没有培养过这种心态和能力。我们在努力工作的同时，也要有空间来尝试工作得更聪明。我们总是在有限的人力物力和时间内工作，我们应想尽办法创造出最大的价值，有时候是微创新，有时候是奇思妙想。团队既要关注创造性地解决用户和客户的问题，也要留意创造性的提升我们的工作方法。支持创新性的实践包括：Design Thinking（设计思考）；Impact Mapping；可视化；到客户现场；创造性的排优先级和Kano模型；砍需求；减少冗余的各种岗位品种；流程价值流Mapping；反思反思再反思；拥抱“石头的寓言”；异花传粉；精益创业思想和实践.

实施敏捷需要一直在路上~

---

今天先到这儿，希望对您技术领导力， 企业管理，物联网,  系统架构设计与评估，团队管理, 项目管理, 产品管理,团队建设 有参考作用 , 您可能感兴趣的文章:
2017-2018年Scrum状态调查报告
2016年测试状态调查
2017年IT行业测试调查报告
项目管理－习惯发生范围变更
前端性能核对表Checklist-2018
大型电商互联网性能优化案例
国际化环境下系统架构演化
微服务架构设计
视频直播平台的系统架构演化
微服务与Docker介绍
Docker与CI持续集成/CD
互联网电商购物车架构演变案例
互联网业务场景下消息队列架构
互联网高效研发团队管理演进之一
消息系统架构设计演进
互联网电商搜索架构演化之一
企业信息化与软件工程的迷思
企业项目化管理介绍
软件项目成功之要素
人际沟通风格介绍一
精益IT组织与分享式领导
学习型组织与企业
企业创新文化与等级观念
组织目标与个人目标
初创公司人才招聘与管理
人才公司环境与企业文化
企业文化、团队文化与知识共享
高效能的团队建设
项目管理沟通计划
构建高效的研发与自动化运维
某大型电商云平台实践
互联网数据库架构设计思路
IT基础架构规划方案一(网络系统规划)
餐饮行业解决方案之客户分析流程
餐饮行业解决方案之采购战略制定与实施流程
餐饮行业解决方案之业务设计流程
供应链需求调研CheckList
企业应用之性能实时度量系统演变

如有想了解更多软件设计与架构, 系统IT,企业信息化, 团队管理 资讯，请关注我的微信订阅号：

作者：Petter Liu
出处：http://www.cnblogs.com/wintersun/
本文版权归作者和博客园共有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接，否则保留追究法律责任的权利。 该文章也同时发布在我的独立博客中-Petter Liu Blog。