Questions tagged «agile»

在某些组织中，采用敏捷可能会失败，我什至在一家公司（瀑布式）是唯一（真正）方法的工作，但这仅仅是因为他们在项目上尝试了敏捷并失败了。 当我问那些仍然记得（我还是大三）的人时，我很难过，就像我提醒他们一场噩梦一样，这确实发生了。 我不知道为什么项目失败了。网上可以找到一些资源，为什么有些公司会导致Agile失败，但原因主要是经济上的。所以我想在此先提出一些反馈。 在某些组织中，敏捷采用失败的原因是什么？或者，另一种表达方式。.要使敏捷成功，您需要做什么？

11 agile  methodology  waterfall  technique 

不幸的是，有人教会了我们的高层管理人员“敏捷”这个词，现在他们希望我们朝着它迈进。我对敏捷有一定的了解（原则上），但从未在实践中使用过。据我所知，这将不适合我们的组织。眼下，事情还很繁琐。这是这样的； 我们是一个非常小的团队-两名开发人员，一名DBA，一名设计师。我工作的公司赚的钱相对于公司规模来说不成比例，其中近95％是纯在线销售。 从开发的角度来看，我们在通常的一天中会遭受很多桌面入侵（我们既是技术支持人员又是开发人员），如果销售团队成员向某人承诺某件事，工作可能会突然间突然消失。我们也承接大型项目，而它们却是不断间断的噩梦。我们中有些人开始把头发扯下来！项目计划是由非技术经理在excel电子表格中制​​定的，他们在其中尝试将任务分解为一口大小的句子，他们可以理解这些句子，并在每个句子旁边放置一个日期。这些日期总是可怕地不切实际，常常被错过，而且我们的会议（大约每周举行一次）经常充满尴尬的时刻，人们问“为什么还没有这样做”。 我很确定敏捷不是我们的理想选择。现在，考虑到（并且我已经尝试过）这家公司不会改变其方式，只有开发团队愿意改变，是否有一种我们可以采用的开发方法，该方法很适合节省一些理智？

11 project-management  agile 

敏捷性的原则之一是您应该测量工作软件： 工作软件是进度的主要衡量标准-敏捷的12条原则 事实是，虽然我可以根据完成的故事，被压缩的错误或缺陷报告的数量减少来衡量我的软件，但我仍然坚持如何衡量我的软件的价值。 如果我以迈克·科恩（Mike Cohn）为例，他帮助SalesForce.com为客户带来的价值比上一年增加了500％*，我该如何衡量这一增长？如何衡量我现在的位置？ 他使用的其他指标是功能数量和每个开发人员的功能数量。如果我的待办事项井井有条，而且故事被“功能”所截断，那么我可以解决这个问题，但是我们只是从敏捷开始，所以我需要一些方法来确定我们现在提供的价值，然后在六个月内使用类似的指标来查看我们是否增加了产量。 我听说过通过增加收入来衡量软件的价值，或者通过提高客户满意度来衡量软件的价值（但是您如何衡量？），但是这些增长可以归因于公司的任何东西（销售，会计，支持），而不是直接涉及我部门正在做的工作。 那么，你们如何衡量软件的价值以及您是如何开始的呢？ * 敏捷的成功 -Mike Cohn

11 agile  scrum 

刚开始一个项目时，您将一无所有--没有UI，没有数据层，之间也没有任何东西。因此，像“用户应该能够查看其foos”这样的单一故事将需要大量工作。一旦有了这个故事，诸如“用户应该能够编辑其foos”这样的故事就更现实了，但是第一个故事将涉及设置UI层，表示逻辑层，域逻辑层和数据访问层。 这与我的“任务”概念不符：对我来说，我宁愿有以下“任务”之类的东西： 在HTML中显示源自JavaScript对象的用户foo的伪数据。 设置表示逻辑层，并将JavaScript对象连接到该逻辑层。 设置域逻辑层，并将表示逻辑层连接到该域。 设置数据访问层，并将域逻辑层连接到该数据访问层。 所有这些都属于上面的单个“故事”吗？如果是这样，我觉得故事在项目的早期并不是一个非常有用的框架。如果是这样，那很好--我只是想确保我没有错过任何东西，因为我真的在尽我所能尝试学习这种敏捷方法。

11 project-management  agile 

DRY原则（不要重复自己）指出：“每条知识都必须在系统中具有单一，明确，权威的表示形式。” 在大多数情况下，这是指代码，但它通常还扩展到文档。 据说每个软件系统都有一个体系结构，无论您是否选择它。换句话说，您构建的软件具有结构，而“已构建”结构就是软件的体系结构。 由于构建的软件系统具有体系结构，因此创建该系统的体系结构描述是否违反DRY原理？ 毕竟，如果您需要了解架构，那么您始终可以只看一下代码...

11 agile  documentation  architecture  dry 

文章“混杂配对和初学者的思想”（PDF）建议您将一对对代码库的特定领域了解最少的人放在这个配对中。这也表明，你换了一对，每90分钟左右的高级成员。新手不仅会了解代码的这一领域，而且与已经知道该领域的人相比，他们的想法也会有所不同。 有人对此策略有经验吗？它与现实有关系吗？ 我发现了有关何时使用配对编程以及是否需要进行配对编程的工作的其他问题，但是我没有发现专门涉及混杂配对和这种“初学者”策略的问题。 如果您不熟悉结对编程，请参阅Wikipedia和c2.com上的有趣文章。

11 agile  pair-programming 

我们有一个概念，即向主请求请求中的所有代码都应准备好生产。这是有道理的，我认为这是一个公正的声明。 这里的想法是，一旦创建了PR，就说明您已经将它放到了主控器中，但是希望某些审稿人仅与您“同意”，并发现您碰巧遇到的任何问题。 由于我们只是人，所以我们会犯错，并希望其他审阅者可以找到单元测试找不到的项目-拼写错误，不正确的javadocs等。 但是，“拉取请求”是我们应该向开发人员提供某种程度的帮助/培训的地方，如果需要，应该达到什么程度？ 每次您推送新更改时，审阅者都必须重新审阅您的更改，这要花费他们的开发时间，并导致重新审阅更改。 因此，在请求请求中应该允许接受多少培训？我的一部分感到，这从大三到大四。但是，我也觉得这里不应该是发现大量问题的地方-即使对于初中生也是如此。 是否还有其他人在努力使开发人员实现“我的拉取请求应该准备好生产”的目标？

11 agile  pull-requests 

我对Scrum管理员的职责的理解如下： 执行过程 消除障碍（开发人员无法消除自己） 防止外界干扰 促进Scrum会议（站起来，回顾等） 如果团队中的开发人员受到纪律处分，则他们将遵循该过程而无需他人指导。他们也可以毫无困难地举行回顾会议和其他Scrum会议。如果组织的其他成员了解sprint的界限，则已经将需要Scrum管理员的外部中断和障碍已最小化。 随着团队绩效的提高和组织对sprint界限的理解，似乎对Scrum Master的需求似乎减少了。团队是否有可能最终达到不再需要Scrum Master的地步？

11 project-management  agile  scrum  team 

我们正在为项目使用Pivotal Tracker，这使我们可以从以下三个点比例中进行选择： 0,1,2,3 0,2,4,8 0,1,3,5,8 我正在寻找一种资源来指导我们的决策。（在使用0、1、2、3进行两次迭代后，我们可以看到其中一个更有用或更有意义。）

10 agile  scrum 

如今，每个人都希望变得敏捷。在与我合作的每个团队中，敏捷的形式都不同。有些事情很常见-例如日常站立或计划，但其他部分则有很大差异。 在我目前的团队中，有一个细节令我感到困扰。缺乏功能要求。不仅没有书面形式的期望，而且在任务中模糊地定义了需要完成的工作。 该项目的目标是使用新技术重写旧系统。旧系统也没有任何合理的文档。当然，最新的不存在。企业主对需求的描述是-让我们在新实现中以与旧实现相同的方式进行。似乎合理，但事实并非如此。旧系统是一种意大利面条式代码，从中提取业务需求非常昂贵。看来情况对计划产生了负面影响。当然，在新的实现中容易出错和出错（省略一些细节）。 因此，我在想-在重写旧系统的情况下，没有业务需求真的很敏捷吗？

10 agile  legacy-code  rewrite 

我刚刚开始阅读Craig Larman的《 Applying UML and Patterns》。我觉得这很有趣，因为它挑战了我在工作中遇到的许多问题。我读到，并不是一次就可以完全收集需求，并且需要很多次迭代才能完成需求收集。如果是这样，考虑到明天可能会有一些新的突破性要求（或伪装成要求的变更请求），我是否必须设定一个硬性规定的截止日期，这是我在工作中必须做的，非常敏捷。

10 agile  requirements  release  iterative-development 

敏捷问题：敏捷是否相信以“快速而肮脏的方式”启动并运行事物？还是敏捷更喜欢从头开始进行牢固构建？还是这不是方法论问题，而是您逐案评估的问题？ 从技术上说，我是在“重造”系统的基础之后，我已经构建了很多结构本身……这不是一项艰巨的工作……会敏捷地希望我首先确定整个流程，对其进行分析，进行调整，然后构建？我觉得从某种意义上说这是更好的方法……一旦建立了一个凌乱的系统，我就会更好地了解它是如何完成的……另一方面，它并没有那么有条理……只是好奇什么才是最好的发展实践就是在这方面。 我认为这个问题与敏捷和原型设计有些不同，因为我不是在问原型设计和一次性代码。我对敏捷的生产级代码感兴趣。

10 agile 

《Scrum指南》定义了一个由产品所有者，3至9个成员的开发团队以及1个介于5至11个成员之间的Scrum Master组成的单个单元。我见过产品负责人可能有支持人员，或者团队可能没有专门的Scrum Master来稍微改变这个数字的情况，但似乎最多只能有十几个人。 的的Nexus指南介绍了Scrum的缩放处理3-9 Scrum团队单一产品工作的一种方法。它增加了一个新的Nexus集成团队，该团队可以是专门成员，也可以由来自各个Scrum团队的人员组成。根据该指南，它将扩展到大约20-120个人。 纪律严明的团队可以从一个团队扩展到N个团队。一个标准的个人团队规模将与Scrum中的团队规模相同-3-9个成员，加上来自各种专家，独立测试团队，领域专家等的支持角色。此框架中的考虑不仅是扩展规模，而是应用敏捷方法在大型组织中，受监管的环境具有强制性的合规性，外包，全球分布的团队。似乎限制是每个产品或产品线只能有一个DA实例。 在不同程度上，我一直参与使用Scrum，Nexus和DAD进行工作或实施流程，因此我对它们有扎实的了解。除了我在阅读别人说的以外，我还没有LeSS和SAFe的工作知识。 LeSS似乎很简单。它是Nexus的替代产品，具有更大的扩展能力。LeSS的规则规定，LeSS是为2-8个团队设计的，而LeSS Huge是为8个以上团队设计的，我估计LeSS的开发组织规模约为15-80，LeSS Huge的开发组织规模约为80+。根据您的组织，您可能会在LeSS的产品组织中寻找20-110人，在LeSS Huge中寻找100+人，其中包括管理，独立质量检查，运营等等。两种形式的LeSS似乎都针对单个产品，或者针对一组紧密相关的产品（例如一条产品线或一组微服务）。每个产品都有自己的LeSS（或LeSS Huge）实例。 SAFe似乎涵盖了整个组织-运营，用户体验，企业架构师和系统工程师，产品经理，质量保证，开发人员等。它具有两个模型-3级组织和4级组织。3级组织标识团队，计划和项目组合。四个级别的组织在计划和项目组合之间添加了一个价值流​​级别。根据确定的角色数量，这似乎是针对具有多种产品和并发程序的大型企业组织。阅读他们的实施指南，他们似乎希望实施组织会培训高管和管理层，然后再培训至少50名开发团队成员。最小的组织规模似乎是在所有确定的组中只有数百人，并且有多种产品使实施有意义。 我认为LeSS是Nexus在目标受众方面的“竞争者”，而SAFe的目标是拥有大量产品或产品线的大型组织，远远超过其他规模化的敏捷框架吗？

10 agile  large-scale-scrum  scaled-agile-framework 

我知道Scrum在日常站立比赛中的规则说，团队应该只谈论他们昨天所做的事情，他们今天所做的事情以及任何阻碍他们前进的事情。没有其他的。但是问题是，有时开发人员会花费自己的时间从事与任务无关的工作，然后在独立讨论中谈论它。这就是他们昨天所做的！ 根据我的经验，我发现谈论董事会上的任务，保持站立状态，使每个人专注于他们的任务，复查他们的估计并每天跟踪他们的记录更为有效。 将讨论限制在董事会的任务上是否有效？

10 agile  scrum  meetings 

假设我进行了14天的sprint迭代，其中有多个新功能，改进和缺陷修复的故事。当更改准备就绪时，我也将对其进行部署，而不是等待sprint结束。 我的问题是-如何跟踪这样开发和维护的产品的语义版本控制？如果每14天发布一次，这将很容易，我将增加版本号并记下changelog中的所有更改。但是，如果不断部署变更怎么办？每次部署某些东西时都应该增加版本吗？还是我应该等到sprint结束，然后再进行“恢复”操作，并根据实际部署在每次迭代中单独增加一次版本号？敏捷中语义版本控制的最佳实践是什么？ 编辑：为了更好地解释我的需求，我想首先为利益相关者提供变更日志。我认为他们在部署每次更改后都不会对changelog中的新记录感兴趣。

10 agile  scrum  versioning