初视敏捷

Posted 2021-03-24 atun

背景:在预测型项目中是否遇到计划赶不上变化快？迟迟无法向客户交付产品或项目？交付后因与客户设想的需求不同，导致频繁改动，团队士气、客户信任度严重超支！

身为项目负责人、产品经理、技术负责人的你我遇到上述情况有种回天乏术的感觉？

敏捷的出现，让我们看到一丝曙光。敏捷是一种理念或者说一种理想，也正是你我在项目中所追求的理想环境，不是吗？

现在，我们聊一聊敏捷。

在遥远的过去，软件者的先驱们，采用瀑布式或预测型项目管理，在研发过程中，花费大量的时间和精力在前期需求信息的收集和确定，然后再去开发，并在开发过程中未交付任何或交付少量的里程碑，软件交付日即团队的磨难开始。

终于先驱们在经历无数次“这不是我想的那样”、“$@#%$”、"这是什么垃圾，完全不对，我们不接受"等之类的反馈时，先驱者们提出“是否有一种新的编程方式？基于这种方式，让软件开发进度、质量、客户满意度更好！解放深耕软件开发的码农们，让大伙有更多的时间去做自己想做的事情”。

于是2001年在2月份，漫天飞雪的情况下，一群先驱划着雪，交流着。最终《敏捷宣言》横空出事了。

“个体和互动   高于   流程和工具”

"工作/可用的软件 高于 详尽的文档"

“客户合作 高于 合同/商务谈判”

“响应更改/变化 高于 遵循规范/计划”

可以总结为：

1.以人为本：尊重每一个个体，重视个体间的合作互动

2.以目标/最终交付结果未导向，最终交付的是可使用的软件（相信我，可用的软件是堵住客户嘴巴最好的方法。文档......不浪费A4纸吗？不浪费磁盘存储空间吗？）

3.客户为先：理解客户需求，与客户合作（天平要始终平衡，偏向研发会引起大量客户无法理解操作的逻辑，偏向客户：亏大家都吃过，不赘述，写到这里，忍不住摸一把眼泪，我太难了。）

4.拥抱改变：基于第三条，客户实在不断变化的需求中，明了自己想要的，因此研发团队要拥抱变化。（别钻牛角尖，有人反驳“比白色更白、五彩斑斓的黑”这些梗不讨论）

文档还是需要滴，毕竟可用的软件+规范的文档，会让客户对我们更信任，只是我们应该更关注人、产品模型、写作和迭代。只有随时有成品（原型、功能）交付给客户/项目委员会，才能更好的让项目进行下去，才会将编码工作更好的最大利益化。

讲到这里，笔者不禁要说上几句废话“时间、质量、成本、上级满意度、客户满意度”IE思想不仅仅适用于工厂，同样适用于软件行业，这几条决定我们是否能更好的实现“理想的生活、生活的理想”.......别告诉我，你做软件是为了兴趣等空话，至少笔者目前的觉悟无法达到这种高度。

敏捷原则：

1.我们最重要的目标，是通过持续不断地及早交付有价值的软件是客户满意。

根据GTD四象试图，“紧急的但不重要的、紧急但重要的、重要但不紧急的、不重要不紧急的”这种方式，管理生活、工作，发现会很有用，至少对我来说，收获不错。敏捷中采用迭代事项按照优先级安排、限制WIP、看板、故事卡等方式，未客户尽早提供有价值的功能。同过频繁的刺探和客户的反馈来及时调整研发方向，提高程序的质量，建立客户满意度及客户利益最大化。

敏捷小组关注完成和交付有价值的功能，而不是鼓励的任务。基于“作为【用户类型需求】，我们希望可以【专业技能/能力】以便实现【业务价值】”的故事方式来分析挖掘需求，原型和文档也会需要编写，也是一种交付，只是更多的工作重点，转到口头交流、看板、迭代工具、每日批斗会（手抖，打错了，每日站会。国内大部分都是批斗会，别问我怎么知道的.....）。

2.即使在研发后期，也欢迎更改需求。敏捷过程利用变化来为客户创造竞争价值。

敏捷者不怕变化，只有通过更改需求，才让我们更好的理解市场，成为独角兽，抢占市场份额。（企业做好了，参与者自然....当一天和尚撞一天钟这种想法地人，实际上在蹉跎光阴，趁早改行，不接受任何反驳。）

3.经常性的交付可以工作的软件，交付周期可以从几周到几个月，交付的时间越短间隔越好。

不予玉璞示人，不适合软件研发行业。加入这个行业，就是加入高度不确定性的工作。迭代是受实践框架限制的，意味着要放弃一些我们认为很有创意的功能也必须按时结束迭代。只要我们可以保证交付的软件会很好的工作，那么交付时间间隔越短，我们和客户的协助、信任度、回头度就会大幅上升，产品质量和市场实用性就会更有益。

“需求、分析、迭代、实施、交付”在敏捷的每个迭代周期都会上演，而不是像预测型的项目，只做一次。

4.在整个项目开发周期，业务人员和开发人员必须天天在一起工作。

软件不可能会依照之前设定的计划原路执行，中间对业务的理解、软件的解决方案肯定会存在偏差，所以客户、需求人员、开发人员以及涉众之间必须进行有意义、频发的交互，这样在早期就可以及时的发现并解决问题。

笔者经历的项目，一般会和客户组件项目委员会，参与者有：业务、对方负责人、实际使用人等组成。避免出现负责人不是使用人，使用人不是负责人这种现象，别问什么。

只有通过不断的刺探、不断的交付、在一起工作，双方理解中的差异会越来越小，软件质量会越来越高，团队士气会越来越好。

5.围绕被激励的个人来构建项目。给他们提供所需要的环境和支持，并信任他们能够完成工作。

看到这里，请大伙回答一个问题“团队里面什么最重要？”答案是：“人”。

SO，码畜、码农都是研发人员自嘲的，企业、客户、团队负责人别真把研发人员当成.....。一群人，一件事，一定赢，要激励、善于消除影响团队士气的因素，个人目标要和团队目标一致，团队也要兼顾个人目标，做到互惠互利，任何偏差都会引起风暴效应。信任、授权、平等的地位、良好的办公环境会提高生产力！

不以人为本，以人民币为本的时代已经过去了，身处信息时代、流动的时代要想办法留住该留的人、淘汰该淘汰的人、沉淀该沉淀文化氛围，才能把利益最大化.....扯远了，回归主题。

6.在团队内部，最具有效果并且富有效率的传递信息的方法，及时面对面的交谈。

笔者的每周往返于分部和总部进行沟通，原本一周可以完成的跌打，硬生生拖到两周以上。效率太低了。好在最近要进行集中办公。

说到集中办公，敏捷提倡9人左右的团队集中办公，面对面的交流，效率从经济学角度来说，是相当有回报的。

7.工作的软件是首要进度度量的标准。

用户是否可以使用、用户满意度如何，是首位。笔者在一个长达8年的电商平台项目中，团队贯彻的理念，始终是“功能可用、用户体验度友好”为首要衡量标准。

我见过，也带过前端、后端、DB的小伙伴，我发现有两个极端：1.只管做，不注重结果/质量。2.保质保量。最终给产品带来的市场反馈是完全两个样子。没有测试通过，写在多行代码，在怎么厉害的算法都是无用。质量始终是首位！

8.敏捷过程提倡可持续的开发速度。责任人、开发、用户应该能够保持一个长期的、恒定的开发速度。

什么是可持续性的开发速度？要理解持续这两个字，国内流行风气”996“、加加班辛苦一下、突击一下等等这种观念。

”昨天为什么你不加班，其他同事都加班了“

”咳，老板，加班会影响我心情、影响我心情会影响我的效率“。

不仅让我想到，曾遇到过的一位小伙和BOSS的对话，最终结果，小伙跳槽，薪水客观。老板目前苦苦支撑。

一个项目指望加班、不切实际拍脑袋决定工期，其质量、可用性、团队士气都会大大折扣。笔者提倡”计划-执行-反馈“，日日请，事事清这种工作氛围，才是可持续性、健康的氛围。

9.不断地关注优秀的技能和好的设计会增强敏捷能力。

GITHUB、开源项目、敏捷方法等有很多好的技术实践，可以增强产品的敏捷能力和健壮性。很多的原则、模式和实践也可以增强敏捷开发能力。

”实践是检验真理的唯一方法“、”要想知道梨子的味道，你必须咬一口“，多么真挚的感悟。

10.简介文本....极力减少不必要的工作量的艺术。

后期的需求如何变化，我们不得而知。所以不可能一开始就构建一个完美的架构来适应以后的所有变化，事实上也不可能做到。笔者经常给组员灌输“一个中等的实现方法需要30分钟，一个优等的实现方法需要3个小时，那么，要毫不犹疑的选择前者。”

也曾见过，一位小伙迟迟无法交付任务，仔细询问得知，“我在考虑该模块对最后期模块的影响”，这种做法，不能够说是错误的。但，试问一下，当下的模块都无法交付，那有必要要考虑一下这种工作方式对后期迭代的影响了。

赢在当下，如果明日那个问题很简单，明天可以很好解决，SO，那就留给明天。如果明日的问题很复杂，那也请留给明天，完成今日任务。

11.最好的架构、需求、设计出自组织团队。

笔者曾有一个想法“每日上班后，组员相互询问是否需要协助、自发的处理任务、扁平化管理模式、没有等级之分”，后细思极恐，容易出现信任危机，无人对分歧决策、无人对结果负责。

虽然敏捷小组是以小组为整体工作的，但也需要一些人来承担一定任务的角色；产品负责人、架构师、UI设计师、程序员、需求人员、测试人员、文档撰写者等，还需要一个团队促进者，项目经理、SCRUM主管、项目团队等领导或者团队敏捷教练。但这么多角色，要时刻关注仆人式领导而非脱离群众高高在上。

12.每个一定的时间，团队会在如何才能更有效的工作方面进行反省，然后相应的对自己的行为做出改变。

很多不利因素会时刻导致计划的失败，如成员减员、技术应用效果、用户需求更改等都会对我们造成影响，也会迫使我们做出相应的改变。

敏捷不是基于预定义的模式工作，则是基于经验性的方式，对以上这项变化，需要小组一起不断的“反省”来调整保持团队的敏捷性。

常用的敏捷实践方式有：Scrum、XP极限编程、水晶、DSDM动态系统开发、FDD功能驱动开发、BDD、AUP敏捷统一过程、精益（IE）、看板、OpenUp等，快看看你用了哪一种？