关于敏捷的思考

智力的度量是
改变的能力。
阿尔伯特·爱因斯坦

前言


我正在向IT社区介绍“对敏捷的思考”,或者可以将本文称为“敏捷,这仍然是一种哲学还是一种设计方法?”

本文的目的是与IT社区讨论我在多年的项目实践中遇到的敏捷问题,基于对该问题的分析得出的结论和简历。

问题本身被引用得较低,因为为了继续进行下去,陈述一些论点和结论是有意义的。

在哈布雷(Habré)的各种讨论话题中已经提出了类似的话题,因此这个问题很紧迫,有其历史。

我认为,大多数文章并没有明确回答我的问题,因此许多人可能会对本文感兴趣。

关于此主题的有关哈布雷的几篇文章:


简要介绍主题


为了弄清楚“风向”在哪里,我注意到我在ICT领域的经验超过10年。 在他职业生涯的开始,他就积极地从事电信行业。最近,我从事软件开发工作的时间不超过四年。

在他的整个职业生涯中,他以项目经理的身份参与了各种IT和电信项目,近年来,他还是一名业务分析师,并尝试过担任程序员。 短暂但大量地沉浸在Java开发中的结果是,他在独立开发方面并没有获得过丰富的经验,但是获得了丰富的经验,这使他成为了初级程序员。

现在,我以项目经理的身份积极从事软件开发领域的工作,可以选择担任业务分析人员。

因此,本文的讨论主题是与国内开发相关的软件产品开发的项目管理实践。

了解作者的问题


在他的ICT项目经验中,他提出了一条关键规则:使用项目方法论管理项目是好的,没有方法论就不清楚。

鉴于上述观点,需要研究各种设计方法,ITSM方法,有关该主题的各种商业书籍,以及简单的“智能”和复杂书籍。

鉴于PMI普遍流行,尤其是我的本地电信行业,我开始在PMBoK学习。 尽管这个棘手的Talmud并没有立即被理解,但是在阅读下一章时,我不止一次地思考该书中所有相同的编译器所冒的东西。 结果,知识体系被分解为原子并被完全采用。 顺便说一下,它甚至没有一次在具有“无产阶级的热情”,耐心和敏捷性的多个项目中实施(当然不是PMBoK,但是已经引入了它的工具)。

了解PMBoK具有丰富的经验。
@PM

除了这项“史诗般的”工作之外,还研究了其他方法,研究人员仅撰写了有关项目管理的书籍(尽管T. Demarco,S。Berkun和S McConnell等人物不仅是作者,而且是更多的人物),但并非全部这是有道理的,而本文并非如此。

总而言之,关于该主题的文章的作者力图紧跟世界潮流,不要忘记经典。

深入研究软件项目管理


经过八年的工作,他对电信感到无聊,并决定继续前进,他急忙涉足IT。

事实证明,IT部门不希望生活在经典的“瀑布”的清晰框架中,GOST 34并非时尚,除非当然考虑到了州。 部门。 全球项目管理中的项目管理还有其他趋势。

敏捷清单无法通过。 研究了许多书籍并与几位同事交谈之后,我认为敏捷至少是有趣的。 但是在俄罗斯如何使用它尚不完全清楚,哲学还没有达到方法论上,在我们国家,人们普遍认为“禁止不禁止的东西”。

总结:我得出的结论是,敏捷当然是一件有趣的事情,但是尽管如此,它更适合于时尚书籍和小型项目,但是如何将其付诸实践尚不清楚。

对哈布雷的文章的分析总体上确认了上面给出的简短摘要。

在从书本上学习敏捷的几轮迭代之后,我很“幸运”,我碰巧参加了几个国内敏捷项目。

这样的敏捷性一点都不好玩,而拥有规划和管理电信行业项目经验的RP简直令人难过。 当试图控制这些同伴的自发发展时,一切都彻底崩溃了,这些家伙一致说:“我们有创造力,我们有敏捷性,不必理会生活/工作/发展。” 他们不想学习和思考,只想着敏捷。

但是,尽管我对此表示怀疑,但敏捷还是走遍了全国,由G. Gref积极推广,并由西方和国内各种IT行业专家进行了宣称。

但是,正如个人经验所表明的那样,敏捷以自己的方式使用了所有内容,我们以我们的心态创建了“俄语敏捷”。

结果,问题变得越来越严重,没人能回答。

敏捷到底是什么,关于心理学和劳动组织的哲学堆栈,理性的奢侈,而不是按规则工作的欲望,还是从方法论的角度来看仍然隐藏着更严肃的东西,可以在这里应用国土,在严肃的项目上,值得关注的是什么?

在完成本节之前,需要注意以下几点:

  1. 在2018年发布第六版PMBoK之后,敏捷问题变得更加有趣(在第六版中,作者包括使用敏捷的案例)。
  2. 为了阅读,我阅读了劳伦斯·利奇(Lawrence Leach)的书“准时且预算内”。


劳伦斯·利奇(Lawrence Leach)的著作《按时按预算》
关于使用“关键链”方法进行项目管理的一本有趣的书,作者可以归因于繁重管理的思想家。 L. Lich的书描述了将E. Deming和E. Goldratt的理论应用于项目规划的一种困难但极为有趣的方法。

有了所获得的理论和实践知识,对敏捷的不完整理解就成为了在国内项目中适当实施敏捷的一种方法。

残局


迈克·科恩(Mike Cohn)的正确敏捷或自适应PMBoK。

偶然地,或者就像他们所说的那样,“突然无所作为”,我碰到了另一本关于敏捷的书。 这是某位迈克·科恩(Cohn Mike)所著的《敏捷。 评估和项目计划。”

一开始,他建议这是另一本商业书籍,描述敏捷很酷,时尚,年轻。

因此,决定阅读该序言,但在阅读了第一章之后,已经变得很有趣,他是谁,这位迈克·科恩,以及他为什么写如此正确的东西。

快速参考谁是科恩·麦克

流程和项目管理咨询公司Mountain Goat Software的创始人。 他专注于帮助公司实施敏捷方法来提高效率。 在Mike的背后,他拥有超过20年的从初创企业到财富40强公司的各种规模的经理经验,他是敏捷联盟的联合创始人,也是其董事会成员。

我不打算在本文中完整地描述这本书,因为最好是自己(需要的人)阅读。但我要指出的是,迈克的书是考虑到敏捷清单哲学的修订版PMBoK PMI。

我将立即注意到,迈克并没有写出另一套无聊而又难以理解的知识,他没有抄袭PMBoK。 相反,迈克·科恩(Mike Cohn)创作了一本有趣,易读且相关的书:

  • 描述了敏捷中应遵循的原则和规则;
  • 描述用于计划和评估工作的工具;
  • 提出想法并主管开发管理;
  • 还有更多。

这本书描述了整个项目生命周期,侧重于项目计划阶段,描述了非常有趣且合理的方法来规划和评估工作,并描述了项目,监视和控制阶段的方法和工具。

尽管该书的功能,适用性和方法学成熟度令我惊讶,但Mike还是运用了一种非常有趣且难以描述的方法来缓解不确定性风险,Lawrence Leach在他的书中对此进行了描述。 通过以上所有内容,Mike以一种简单易懂的语言提供了如何在实践中实现和扩展此方法的信息。

要建立任何流程,您需要规则,规范和原则,Mike为我们介绍了它们。

总结


我认为,自2001年以来,我们面临几个有趣的问题:

我们需要敏捷哲学,方法论还是足够的原则?
我们是否要高效,清晰地开发高质量的软件,还是选择保留这种特权,而继续“发明自行车”?

我认为,迈克的书定义了许多人想摆脱的规则,但经验表明,仍然需要这些规则。

除了上述内容外,Mike的书还就如何构建敏捷软件项目管理提供了清晰的方法论说明(尽管有人可能不喜欢这个词)。

无论如何,一切都会与我们同在,但有一件事很清楚,一切都需要规则和原则,并且它们是敏捷的。

对这些原理进行了描述和固定,可以研究它们,也可以使用它们。

为了确定我的简历,我将指定以下内容:

Ageli不在危机中,敏捷不是问题,敏捷正在努力。

唯一的问题是我们是否要研究规则并按规定去做,还是我们要继续按照自己的意愿工作。

永远不要失去好奇心。
阿尔伯特·爱因斯坦

聚苯乙烯

亲爱的读者们,尽管他们阅读了这篇文章,但我对您的意见和评论以及类似书籍(例如Mike Cohn的书籍)的建议非常感兴趣。

Source: https://habr.com/ru/post/zh-CN460709/


All Articles