ACP-初视敏捷

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

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

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

现在,我们聊一聊敏捷。

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

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

于是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等,快看看你用了哪一种?

你可能感兴趣的:(ACP-初视敏捷)