敏捷项目管理:最佳实践和方法

阅读时间:18分钟

项目管理的艺术

所定义的Gartner,项目管理是“在项目活动中应用知识、技能、工具和技术以满足项目需求“。

作为软件工程过程的一个组成部分,连同业务分析和需求规范、设计、编程和测试,项目管理多年来一直是一个有相当大争议的主题。即使是在公司项目管理实践日趋成熟的今天,根据调查结果,也只有约一半(54%)的人项目管理研究所(PMI),充分认识到这些实践的重要性和价值。

无论哪个行业,项目管理都被证明是公司效率和最终成功的关键因素。事实上,那些使用成熟的项目管理实践的组织浪费的钱更少,而执行的项目也更少2.5倍的成功

项目管理专家得出结论,成功项目的定义不仅是按时和在预算范围内完成的项目,而且是交付预期利益的项目。

项目管理阶段

不管范围是什么,任何项目都应该遵循一系列要控制和管理的行动。根据项目管理研究所(PMI),典型的项目管理流程包括以下阶段:

  1. 引发
  2. 规划
  3. 执行
  4. 性能/监控
  5. 项目关闭

作为完成特定任务的路线图,这些阶段定义了项目管理生命周期。

然而,这种结构太笼统了。一个项目在每个阶段中通常有许多内部阶段。根据工作范围、团队、行业和项目本身的不同,它们可能会有很大的不同。

在寻找管理任何项目的普遍方法中,人类已经开发了大量的PM技术和方法。

传统项目管理方法

基于上述经典框架,传统方法采取循序渐进的方法来执行项目。因此,项目经历了启动、计划、执行、监控直至结束的连续阶段。

通常被称为线性,这种方法包括许多内部阶段,它们以时间顺序顺序和执行。在建筑或制造业中最常应用,每个阶段都需要几乎不需要更改,传统的项目管理也在软件工程中找到了应用。

被称为瀑布模型,它是自20世纪70年代初以来的主导软件开发方法,正式温斯顿·w·罗伊斯描述的:“对于所有计算机程序的开发,不论大小或复杂程度,都有两个共同的基本步骤。首先是分析步骤,其次是编码步骤……这是一种非常简单的实现概念实际上是如果所付出的努力足够小,如果最终产品是由制造它的人来操作——就像通常使用内部使用的计算机程序那样——所有这些都是必需的。

瀑布式项目管理

瀑布模型非常强调规划和规格说明的开发项目时间和预算的40%。该方法的另一个基本原则是项目阶段的严格顺序。一个新的项目阶段只有在前一个阶段完成后才会开始。

这种方法适用于定义清晰、具有单一可交付成果和固定期限的项目。瀑布方法需要全面的计划,广泛的项目文档和对开发过程的严格控制。理论上,这应该导致按时、按预算交付、低项目风险和可预测的最终结果。

然而,当应用到实际的软件工程过程时,瀑布方法往往是缓慢的,昂贵的和不灵活的,由于许多限制。在许多情况下,它无法调整产品以适应不断发展的市场需求,常常导致巨大的资源浪费和最终的项目失败。

敏捷项目管理哲学

与传统方法相反,敏捷项目管理理念已经介绍作为试图使软件工程更加灵活和高效。和94%的组织在2016年练习敏捷,已成为项目管理的行业标准。

敏捷的历史可以追溯到1957当时Bernie Dimsdale, John von Neumann, Herb Jacobs和Gerald Weinberg正在使用增量开发技术(现在被称为敏捷),为IBM和摩托罗拉开发软件。尽管不知道如何对他们所实践的方法进行分类,但他们清楚地意识到它在许多方面与瀑布方法不同。

然而,现代敏捷方法被正式引入2001当一组17个软件开发专业人员开会讨论可选的项目管理方法时。对于灵活的、轻量级的和面向团队的软件开发方法有一个清晰的愿景,他们在敏捷软件开发宣言

宣言旨在“发现更好的软件开发方法”,明确规定了新方法的基本原则:

通过这项工作,我们认识到:

个体和交互过过程和工具

工作软件在全面的文档

客户协作在合同谈判

响应变化在计划之后。

与之相辅相成敏捷软件的12条原则,这一理念已成为一种普遍而有效的项目管理新方法。

敏捷方法采用迭代方法进行软件开发。与直接的线性瀑布模型不同,敏捷项目由许多较小的周期组成——sprint。它们中的每一个都是一个微型项目:它有一个待办事项列表,由预定义工作范围内的设计、实现、测试和部署阶段组成。

敏捷开发周期

在每个Sprint的末尾,递送潜在可移动的产品增量。因此,随着每次迭代新功能都被添加到产品中,这导致逐步的项目增长。随着在开发的早期验证的功能,提供潜在的产品的机会显着降低。让我们总结主要的敏捷方面:

灵活性:工作范围可能根据新要求而变化。

工作分解:项目由小周期组成(在Scrum中称为sprint)。

团队合作的价值:团队成员紧密合作,对自己的职责有一个清晰的愿景。

迭代的改进:频繁重新评估在一个周期内完成的工作,以使最终产品更好。

与客户合作:客户密切参与开发,可以改变要求或接受团队的建议。

优先考虑灵活性和快速周转敏捷方法提供了以下好处,根据最近的研究:

  • 管理改变优先事项的能力(88%)
  • 通过每日任务分配提高团队生产力(83%)
  • 由于规划系统简单(83%),更好的项目可见性

敏捷框架

敏捷是一个囊括了各种方法论和技术的术语,它们共享上面描述的原则和价值。每一种都有自己的用途和特点。最流行的框架是Scrum、看板、混合、精益、双峰和XP。在更详细地讨论这些框架之前,让我们先看看它们的关键特性。

敏捷框架简短比较

Scrum:角色、sprint和工件

Scrum是一种主导敏捷方法。58%的组织只使用它,而另外18%的公司将它与其他技术结合使用。1986年,Hirotaka Takeuchi和野中郁次郎在新产品开发游戏,

它是在差不多十年之后才被制定出来的。1995年,Ken Schwaber和Jeff Sutherland,两位作者Scrum指南,介绍它Oopsla会议。介绍是基于他们在前几年应用该方法时获得的知识。虽然Scrum早在敏捷宣言之前就被引入了,但它依赖于敏捷原则,并与敏捷宣言中陈述的价值观保持一致。

Scrum的目标是在复杂产品上维持人们之间的强大协作,细节正在被更改或添加。它基于三个主要角色之间的系统互动:Scrum Master、Product Owner和团队。

  • Scrum Master是一个项目中的一个核心人物。他的主要责任是消除可能阻止团队有效工作的所有障碍。
  • 产品负责人(通常是客户或其他涉众)积极参与整个项目,传达产品的全球愿景,并在每次sprint后对完成的工作提供及时反馈。
  • Scrum团队是一个跨职能和自组织的团队,负责产品实施。它应该由多达7名团队成员组成,以保持灵活性和生产力。

sprint和工件

scrum -中的基本工作单位冲刺- 是一种短暂的开发循环,需要生产可流动的产品增量。Sprint通常在1到4周之间:更长的迭代缺乏克拉姆的基本效益的可预测性和灵活性。没有标准持续时间(只要它不到4周),项目中的所有Sprint都应该具有固定长度。这使得更容易计划和跟踪进度。

scrum基础知识

Scrum依赖于三个主要构件用于管理需求和跟踪进度——产品计划安排、Sprint计划安排、Sprint燃尽图。这一过程是通过一些重复的会议而形成的,如Daily Scrum (stand - up), Sprint Planning, Review和Retrospective会议。

产品待办事项列表是项目最终产品中可能需要的功能项的有序列表。它是需求的单一来源。当新的需求、修复、特性和细节被更改或添加时,产品Backlog就会更新。

Sprint Backlog.是团队必须完成的任务列表,以便在每个Sprint的末尾提供功能软件的增量。换句话说,团队成员们同意哪些产品提供并定义如何这样做的计划。

Sprint烧毁图表是Sprint中剩余工作的一个说明。它可以帮助团队和Scrum Master,因为它可以显示每天的进展,并且可以预测Sprint的目标是否会如期实现。

Scrum会议

该过程通过许多经常性会议形式形式化,如每日scrum(screatup),sprint计划,审查和回顾性会议(Sprint回顾性)。

每日例会是一个有时间框的会议,在此期间开发团队协调其工作并为接下来的24小时制定计划。活动时间为15分钟,每天在同一地点、同一时间举行。

要完成的工作计划于Sprint计划。Sprint中的每个人(一个产品负责人,一个Scrum管理员,一个开发团队)都参加了这个活动。它们回答了两个关键问题:哪些工作可以做,以及如何做。Sprint计划在一个月的Sprint中持续时间不超过8小时。对于更短的sprint,会议通常需要更少的时间。

在每个Sprint结束时,团队和产品负责人在冲刺评审。在这个非正式会议中,团队展示完成的工作,并回答关于产品增量的问题。所有的参与者就下一步该做什么来增加产品的价值进行合作。Sprint Review是一个为期一个月的Sprint的四小时会议。

整个队伍去回顾性会议在Sprint期间反思他们的工作。与会者讨论进展顺利或错误,找到改进方法,并计划如何实施这些积极的变化。Sprint追溯在审查后和下一个Sprint规划之前举行。事件的持续时间为为期三小时,为一个月的冲刺。

什么时候使用scrum

Scrum适​​用于需要利益相关者反馈的长期复杂项目,这可能会影响项目要求。因此,当无法估计确切的工作量,并且不固定发布日期时,Scrum可能是最佳选择。

通过将客户需求和按时/按预算交付作为最高优先级,Scrum获得了89%敏捷用户的信任。因此,使用这种方法的公司名单令人印象深刻。事实上,有一个公共电子表格与微软、IBM、雅虎和谷歌等组织合作。

最新的Scrum Anliance的研究表明Scrum超越了IT。金融、咨询、教育、零售、媒体、娱乐等领域的公司都选择这种方式来组织工作流程,加强与客户的合作。2016年,大多数Scrum Report的受访者(98%)表示,他们将使用这个框架向前发展。

看板:处理进度工作的综合解决方案

另一个常见的项目管理框架是看板。43%的公司有规定他们使用看板作为项目管理框架之一。起源于卡片的视觉系统丰田制造作为一种生产控制方法,看板是一种简单但功能强大的软件产品开发方法。

Kanban董事会

翻译为视觉信号从日语来看,看板关注工作流的可视化和优先级正在进行中的工作(WIP),限制其范围以有效地匹配团队的能力。一旦任务完成,团队就可以从管道中获取下一个项目。因此,开发过程提供了更灵活的计划、更快的周转、清晰的目标和透明度。

与Scrum相反,看板中不需要流程中的标准过程,也不需要固定的迭代。项目开发是基于工作流可视化通过看板,通常由粘滞便笺和白板或在线工具代表,如trello。

trello看

Trello实现了看板的自动化和数字化。由于每个看板包含关于工作项的简洁信息,团队中的每个人都知道谁对该项负责,每个人的任务是什么,什么时候应该完成,等等。团队成员还可以留下评论、附加截图、文档或链接,以提供更多细节。

使用看板工具的团队以协作的方式工作。跟踪进度的能力可以帮助同事了解每个人在实现共同目标时的个人投入,从而专注于按时、好地完成任务。

何时使用看板

使用看板,团队可以做小的发布并适应不断变化的优先级。与Scrum不同的是,没有预设目标的sprint。看板关注的是出现的小块工作。例如,如果测试人员在产品中发现了错误,开发人员试图立即修复它们。例如,看板在产品的主版本发布后工作得很好。

Spotify和Wooga(领先的移动游戏开发公司)等公司已经在多年来一直在使用这种方法。然而,8%的组织将Scrum与Kanban技术相结合,使用所谓的scrumban.而不是原来的框架。

混合:瀑布式开发和敏捷(灵活的开发和全面的项目计划)的混合

敏捷和瀑布是软件开发管理的两个不同愿景。前者是关于迭代的发展和灵活性,而后者促进逐步开发,需要仔细规划,并拒绝沿途做出改变。

二十三家公司意识到,使用两种方法的原则可能比选择两者中的一个更有利。传统瀑布项目管理方法和敏捷的组合称为混合动力车。

专家利用敏捷哲学的优势进行软件开发。当涉及预算、计划和硬件设置时,瀑布方法非常有效。另一方面,通过将敏捷实践嵌入到传统的瀑布式工作过程中,公司可以增加实现成功项目的机会。例如,项目计划可以在sprint中完成,测试可以在开发中合并,反馈可以定期收集。修改瀑布模型的其他方法包括使用看板和组织回顾。

应该指出的是,混合框架的特征的选择可能取决于项目。混合框架不仅意味着使用两种方法,具体取决于项目阶段,还包括将敏捷实践注入瀑布过程的选项。

何时使用Hybrid

混合动力车是一种有效的解决方案,当产品交付依赖于硬件和软件操作时。但是,还有另一个理由选择混合动力车。客户对未指明的时间范围和预算不满意的情况,以及缺乏规划,并不罕见。这种不确定性是敏捷的典型。在这种情况下,规划,要求规范和应用设计可以在瀑布中完成。敏捷是为了软件开发和测试。

双峰:传统瀑布与敏捷相结合

双模方法非常受欢迎:据估计,有16%的公司选择它。术语“双峰IT”介绍了Gartner2014年。Bimodal是管理两个独立但一致的工作方式的做法:一个专注于可预测性和其他敏捷性。

模式1是传统;因此,它可以在很好理解和可预测的领域完美地工作。据Gartner称,该公司专注于开发已知资源,同时将传统环境转变为适合数字世界的状态。

模式2涉及快速应用开发。它是探索性的、非线性的、为解决新问题而优化的。模式2对于需要尽快完成的项目特别有用。

两种模式都需要不同的技能,技术和工具。因此,需要两个单独的工作组。这些团队有两个独特的目标 - 确保采用创新的同时稳定。团队成员侧重于适合其模式的项目。

Mode 1团队开发和维护应用程序和核心系统,以支持长期业务需求。一个公司的技术能力直接依赖于这个团队所做的工作。

Mode 2团队经常交付创新的应用程序,以吸引新客户并满足短期业务需求。该团队可能会在收到反馈并分析市场后改变产品的功能。

该团队使用不同的交付机制并通过不同的组织结构报告。尽管如此,他们需要互相沟通以交换想法和分享结果。

作为桑迪Kemsley,模式2依赖于模式1提供的信息和服务基础设施,而模式1依赖于模式2测试新产品理念和新开发方法,这些新产品理念和新开发方法最终可能回退到模式1中。

何时使用双峰

如果公司专门从事需要不同发展和管理方法的长期和短期项目,双模可能是正确的选择。该框架是关于保持IT系统基础设施与推动创新之间的平衡。成功实施时,BimoDal帮助组织快速提供用户需要保持竞争力的解决方案。

瘦:消除软件工程中的废物

据最新估计,17%的组织采用了这种方法瘦且健康的。它的受欢迎程度从2015年到2016年下降。然而,这一框架仍然是5个最广泛使用的敏捷框架之一。具有同样的起源作为Kanban,该方法开始作为应用于物理制造的技术。它源于丰田生产系统作为旨在的管理方法“以最快、最高效的方式为客户定制车辆,以最快的速度交付车辆。

精益原则在软件开发中的应用最初是由Mary和Tom Poppendieck在他们的书中介绍的精益软件开发:一个敏捷的工具包。它包括这一点7基本原则:

  • 消除浪费
  • 扩大学习,创造知识
  • 尽可能晚做决定
  • 尽快交付
  • 赋予团队
  • 构建诚信/品质
  • 看到整个

现在让我们仔细看看这些原则。

消除浪费。就项目而言,术语“废物”是指未将价值添加到项目的任何内容,因此应该被淘汰。在软件工程中,这可以是空闲时间,不必要的功能或缺陷。

放大学习并创造知识。在精益中,软件开发被认为是一个持续的学习过程。开发人员通常不会在第一次尝试时就写出清晰的代码。在检测和修复错误之后,他们会编写对之前代码的改进版本。工程师在开发过程中通过解决问题和产生代码变化来获得知识。因此,改善软件开发环境的最好方法是扩大学习。

尽可能晚做决定。迟做的决定更明智,因为它们是基于事实的。记住,技术过时的速度越来越快,推迟一个不可逆转的设计决策是一个明智的举动。迟迟作出承诺的一个主要战略是为系统的变革保留能力。

尽快交付。第四个原则是关于快速软件开发的优点。较短的开发周期允许开发人员通过获得反馈了解更多信息。它们还允许客户推迟对设计的最终决定,直到他们了解更多。因此,快速交付有助于减少浪费。

授权团队。开发人员应该有做出技术决策的权利,因为他们比其他人更了解他们工作的细节。他们可以创建一个路线图并遵循它。

建立在诚信/品质。用户对软件及其特性的看法必须重合。如果客户认为软件拥有所有所需的功能并且易于使用,那么该系统具有感知的完整性。概念完整意味着该软件具有相干的架构,并且可用性和目标的适应性高。它可以维护,调整和扩展。

看到整个。工程师应该对系统的整体效率负责,而不是只关注他们的一小部分。如果专家们坚持这一原则,他们可以创建一个完整的系统。

这些基本原理完美地描述了精益哲学:它的目标是通过更少的努力、投资和时间交付更多的价值。

精益软件开发是一种迭代和增量框架。因此,与其他敏捷方法一样,工作产品增量是在开发的早期阶段交付的。进一步的进展很大程度上取决于产品负责人的反馈。

精益方法的区别在于,团队不局限于使用任何正式的过程,如重复的会议或彻底的任务优先级。

何时使用精益

精益允许公司遵循最小可行产品(MVP)开发技术。它包括一个产品的部署,该产品拥有满足早期用户的最少的、足够的特性集。最有价值产品策略的理念是收集和分析客户的反馈,以知道他们是否喜欢这个产品,想要购买它。了解客户的习惯、品味和需求是生产商业成功产品的关键。开发人员使用反馈来创建未来开发的路线图。

由于小型短期项目的生命周期较短,所以精益很适合它们。如果客户能够参与到项目实现中来,这种方法也是合适的,因为精益需要持续的反馈。采用精益的另一个重要条件是整个团队应该在一个办公室工作,以实现沟通。

由于耐克,福特和英特尔,精益原则被广泛用于其他行业的大量制造公司得到了有效采用。初创公司和成功的公司,例如Corbis,患者和Xerox,将精益软件工程实践应用于他们的流程。

极限编程:写好代码的工程实践

极端编程(XP)与上述框架不同,专注于软件开发的技术方面。XP以9%的公司使用。

它结合了最基本的,为敏捷团队提供了许多工具来优化工程过程。极限编程是一套应用于软件工程以提高其质量和适应需求变化的能力的实践。

XP要求开发人员在最高的、几乎是极限的级别上执行少量的工程实践,因此得名。

XP是在20世纪90年代引入的。Kent Beck是敏捷宣言的最初签名者之一,他在开发一个克莱斯勒综合薪酬体系项目。他旨在找到尽可能迅速完成复杂任务的方法。1999年,他记录了书中的XP实践极限编程解释:拥抱变革。最常用的XP实践是:

  • 测试驱动开发(TDD)
  • 重构
  • 持续集成
  • 对编程

测试驱动的发展是一种先进的工程技术,使用自动单元测试来推动软件设计过程。与常规开发周期相反,在代码(或根本没有写入)后写入的情况下,TDD具有测试首先方法。这意味着单元测试是在代码本身之前写的。

根据这种方法,当没有代码来完成功能时,测试应该先失败。之后,工程师编写代码,重点关注使测试通过的功能。一旦完成,源代码应该进行改进以通过所有测试。这三个步骤通常被称为Redgreen-Refactor循环

TDD已经证明可以提供以下功能好处:

  1. 测试用于捕获代码中的任何缺陷或错误,从而提供对每个软件组件的状态的恒定反馈。因此,最终产品的质量越来越高。
  2. 单位测试可以用作始终是最新的项目文档,随着项目的发展而变化。
  3. 深入地参与产品开发,团队需要能够批判性地分析它,并预见计划的结果,以便正确地测试它。这可以保持团队的积极性和参与性,为产品质量做出贡献。
  4. 通过彻底的初始测试,调试时间可以最小化。

除了在TDD周期内使用外,代码重构是敏捷软件开发的常见做法。基本上,通过简化和澄清,这是一个恒定的代码改进的过程。该过程完全是技术性的,也不呼吁软件行为的任何变化。

使用每次迭代扩展源代码,敏捷团队使用重构作为杂草杂散杂乱和重复的方式。这有助于防止软件ROT,保持易于维护和扩展的代码。

持续集成(CI)是敏捷团队用来管理共享代码和软件测试的另一个实践。我们相信CI是敏捷原则的进化发展。开发人员可以每天多次提交新编写的代码部分,而不是进行简短的迭代。通过这种方式,他们不断地向用户传递价值。

要验证软件的质量 - 通过测试 - 并自动化其部署,团队通常使用像CruiseControl,亚斯西亚竹,队伍或詹金斯等工具。

此外,CI还有助于维护共享代码,从而消除集成问题。因此,产品的主线是强大而干净的,可以快速部署。

对编程,或“配对”,被认为是一个非常有争议的敏捷实践。这种技术需要两个工程师一起工作。当其中一个实际编写代码时,另一个作为观察者积极参与,提出建议并导航整个过程。

由于专注于代码和更抽象的技术任务,这个由两个人组成的团队有望更高效,创建更好的软件设计,犯更少的错误。这种方法的另一个好处在于在团队成员之间传播项目知识。

然而,这种做法经常被指控对球队的短期生产力产生负面影响。该研究表明,每个任务通常都需要15-60%的时间,这是一种方法的主要缺点。然而,有些人意见从长期来看,额外的时间很容易通过软件的整体高质量得到补偿。

何时使用XP

XP提供了在开发新系统时降低风险的工具,特别是当开发人员必须在严格的时间框架内编写代码时。必须知道XP实践是为不超过12人的小团队设计的。如果能够确保开发人员、客户和管理人员能够在项目中共同工作,那么就应该选择这个框架。

XP也建议进行单元测试。如果程序员有足够的创建功能测试的经验,那么可以使用XP。

极限编程提供了帮助开发团队适应不断变化的需求的工程实践和思想。该框架的关键特性是高用户参与度和不超过一周的短迭代周期。此外,XP建议开发人员尽可能进行最简单的设计,并对任务进行优先级排序。

虽然XP可以作为一个独立的框架使用,但它的一些技术实践已经成为其他敏捷方法的一部分。10%的公司选择Scrum / XP.杂交种框架,XP工程实践与Scrum Management方法共存。例如,混合动力包括Scrum事件和工件。客户的角色发展:它定义了一个产品积压,并与办公室的开发团队一起工作,直到项目结束。

结论

敏捷方法常常被错误地认为是单一的方法。然而,还有许多方法和实践在本研究中没有被提及。

不管他们使用的是什么方法和技术,敏捷团队都有证明提高利润37%,增加30%的收入比非敏捷的公司。通过这些方法实现更高的速度、灵活性和生产力,是促使越来越多的组织转向敏捷的关键驱动因素。

软件工程是一个非常快节奏的行业,在项目开发的每个方面都要求灵活性和响应性。敏捷方法允许交付尖端产品并培养创新体验,同时保持产品与市场趋势和用户需求同步。

但是,总有一个多样性的地方。根据您的业务需求和目标,您仍可能从使用瀑布模型或两者的组合中受益。

参考

  1. 职业脉搏2017 -http://www.pmi.org/-/media/pmi/documents/public/pdf/learning/thought-leadership/pulse/pulse-of-the-profession-2017.pdf?sc_lang_temp=en
  2. Gartner术语表:项目管理https://blogs.gartner.com/it-glossary/project-management/
  3. 管理大型软件系统的开发 -http://www-scf.usc.edu/~csci201/lectures/lecture11/royce1970.pdf.
  4. 第11届年度敏捷报告 -https://explore.versionone.com/state-of-agile/versionone-11th-annual-state-of-agile-report2.
  5. 新产品开发游戏https://hbr.org/1986/01/the-new-new-product-development-game.
  6. 迭代和增量开发:简史https://www.cs.umd.edu/~basili/publications/journals/J90.pdf
  7. 敏捷软件开发的宣言 -http://www.agilemanifesto.org/
  8. Scrum指南-http://www.scrumguides.org/docs/scrumguide/v2016/2016-Scrum-Guide-US.pdf#zoom=100
  9. 面向对象程序设计,系统,语言和应用http://www.sigplan.org/Conferences/OOPSLA/
  10. 2017年Scrum报告的状态https://www.scrumalliance.org/scrum/media/ScrumAllianceMedia/Files%20and%20PDFs/State%20of%20Scrum/State0fScrum_2016_FINAL.pdf?aliId=261272923
  11. 丰田生产系统-http://www.toyota-global.com/company/vision_philosophy/toyota_production_system/
  12. 高德纳术语表:双峰-https://www.gartner.com/it-glossary/bimodal/
  13. 双峰,http://www1.softwareag.com/corporate/images/SAG_Bimodal_IT_8PG_WP_Aug16-Web_tcm16-143391.pdf
  14. poppendieck -http://www.poppendieck.com/
  15. 精益软件开发:敏捷工具包 -http://ptgmedia.pearsoncmg.com/images/9780321150783/samplepages/0321150783.pdf.
  16. 测试驱动开发指南https://msdn.microsoft.com/en-us/library/aa730844(v=vs.80).aspx.
  17. 加强结对编程的案例-http://www.cs.utah.edu/~lwilliam/papers/ieeesoftware.pdf.
  18. 编程成对:如何开始-https://www.ibm.com/devops/method/content/code/practice_pair_programming
  19. 极限编程:一个温和的介绍-http://www.extremeprogramming.org/index.html.
7点评论

评论

头像
排序方式: 最新的 | 最古老的 | 最票
家伙Strelitz
3月30日,2020年
家伙Strelitz

这里描述的“混合”并不敏捷。它是一个与纯粹的瀑布框架中的敏捷语言(特别是Scrum语言)的共同合作,具有增量贴面。这也许是一个非常瀑布的断言,即敏捷==增量。不是。

值得注意的是,在20世纪70年代,温斯顿罗伊斯没有“正式描述”瀑布。在标题为“管理大型软件系统的开发”的文件中,他介绍了一个类似于上面的图表,并解释了它为什么“是有风险和邀请失败”。

vwin.co0m
3月30日,2020年
vwin.co0m

盖伊,谢谢你的反馈。

拉里沃特金斯
3月2日,2020年
拉里沃特金斯

你们有很多关于scrum、看板和许多其他主题的讨论,但没有一个人提到文档,更不用说一个例子了,而这正是我想要看到的。

桑德拉史密斯
2020年2月27日

谢谢你的文章,很有用。我个人认为看板方法对管理我的项目非常有帮助。我使用kanbatool.com来帮助我完成我的项目,结果非常好。

保罗·安德鲁斯
2月26日,2020年2月26日

这是一个很好的阅读,谢谢分享!我们通常在要求不稳定的情况下使用敏捷方法。它基本上取决于情况。干杯!

- Paul, HUSH Project Management & Consulting Ltd。

大卫里沃德
2019年4月25日

这是我到目前为止见过的敏捷项目管理最有用的文章。实践真的很棒,易于理解和遵循。这是我第一次领导团队,我不知道如何正确做到。感谢上帝,我在做一些研究时看到这篇文章。我现在有一个关于如何在Smoothstack敏捷中正确管理我的团队的参考。我很高兴。

vwin.co0m
2019年4月26日
vwin.co0m

大卫,谢谢你的评论!我们很乐意帮忙。