Questions tagged «agile»

您知道使用基于伪代码的方法设计（即写下）软件的好方法吗？ 我是软件设计的新手，并阅读了一些有关UML的信息。到目前为止，我的谦逊的类层次结构还不错，但是，当事情变得复杂之后，我注意到通过“全面了解”，我可以使用其他结构来实现更高的可扩展性。由于Python可以很好地进行原型制作，所以我刚开始写就可以了，但是还不够。 所以我尝试了UML类图，但是它们似乎并没有太大帮助。我在那里解决的问题在脑海中微不足道。但是，一旦我开始对实际方法进行伪编码，我确实注意到了其他设计要求。 因此，如果您想通过伪代码进行设计，您将如何做？我相信对我来说，一种与代码大致一对一的方法效果最好。但是大多数UML软件甚至都没有显示该方法的代码（与GoF中的图片相反）。 有人声称UML仅用于文档和演示，对设计不是那么好吗？我也有这种感觉。我一直以纯粹的UML和一些简单的白板草图为设计软件的方式，直到谷歌搜索我找到Envision APDT为止。 那么，敏捷开发是我应该关注的东西吗？还是他们会随机称其为敏捷-我认为敏捷仅与计划有关？还是我设计不正确（使用UML）-有人通过伪代码进行设计吗？我如何找到一个好的工具？

9 agile  uml  design 

我们计划采用用户故事，以轻量级方式而不是繁重的SRS（软件需求规范）来捕获利益相关者的“意图”。但是，似乎他们虽然了解故事的价值，但仍然希望将故事“转换”为具有所有属性，优先级，输入，输出，来源，目的地等的SRS式语言。 用户故事从一开始就“消除”了对像正式SRS这样的工件的需求，那么拥有SRS的意义何在？如果我们采用用户案例来捕获系统的功能需求，我应该如何说服我的团队（顺便说一句，他们都是非常合格的CS人才-在教育和实践上都如此），SRS将被“消除”。（也可以捕获NFR等，但这不是问题的意图）。 所以这是我的“工作流程”论点：将初始需求捕获为用户故事，然后将其详细阐述为用例（需要以较低级别进行记录，即描述与UI原型/模型的交互，并且是可交付的文章）部署）。因此，从用户故事转到用例，而不是从用户故事转到SRS到用例。 你们目前如何在工作场所中捕获用户故事（如果有的话），以及您如何建议我为存在用户故事的情况下缺少SRS辩护？

9 agile  requirements  user-story  requirements-management 

我正在评估一些敏捷风格的方法，以可能向我的团队介绍。使用Scrum，是否可以让同一个人扮演多个角色？我们有一个由四个开发人员和一个网页设计师组成的小组。我们实际上没有领导（我要担任这个职位），质量检查测试人员或业务分析师，我们所有的开发任务都来自CIO。自动化测试被视为浪费时间，一切都集中在速度而不是质量上。 首席信息官将提出一个开发任务（无论是功能还是错误），然后将其交给开发人员（而不是整个团队，个人，通常是私下或出乎意料的），然后有望完成。CIO并没有收集超出最初想法的要求（这在以前已经使我们很痛苦，因为我们将实施某些措施只是为了发现最终用户都无法使用该功能，因为没有咨询过他们甚至没有得到有关此功能的信息。在开发它之前，我们会惊慌地被告知要还原更改），但需要对我们所做的一切发表意见/予以批准。 首先，首先要考虑引入Scrum风格来引入一些标准和实践吗？从阅读的角度来看，Scrum似乎更多地依赖于信任和沟通，并且更多地关注项目管理而不是开发，这是我们完全没有的，因为我们目前没有任何项目管理的表象。 其次，如果它可以工作，那么对于某人来说，让我自己充当ScrumMaster和开发人员，是否不合理？还是让开发人员同时担任产品负责人（尽管很有可能这将是CIO，而不是开发人员）？我意识到Scrum Master和产品负责人应该是不同的人，但同时我认为我们没有任何人具有产品负责人的素质（可能会变成“我需要所有这些故事，我不关心如何完成交易”和/或任何冻结都会立即冻结）。 在我看来，我可能需要选择并选择Scrum / XP / Lean来弥补当前的工作方式，因为这种心态很难改变。例如，结对编程永远无法实现（这很浪费（如果浪费，如果您需要两个人，则只能完成一半的任务）），TDD很难卖，但欢迎周期短。

9 agile  scrum 

我正在阅读有关一个团队的案例研究，该团队根据完成任务所需的努力来估算任务或“故事要点”。 这些“故事点”的估计单位是什么？我认为“故事点”的概念源于一个称为“敏捷开发”的过程。

9 agile 

团队正在开始他们的第一个资本项目-敏捷项目，该项目似乎将与方法学保持一致（即，我们可能只是拿起一本敏捷书，并像食谱一样遵循它），但会有些混乱： 该项目涉及团队中没有人经验的三件事：与Foo Payroll System集成，能够处理XYZ89文件类型（其中“ XYZ89” =您从未听说过的某些文件类型），并进行转换其他文件，以便可以由Frobnobdicator处理。 据我了解，标准的敏捷实践是为每个事件安排峰值时间，然后我们可以确定它们将需要多长时间（我不确定客户是否有很大的机会会决定不这样做它们，因为它们是项目的基本要求） 所以我的问题是： 我们是否在第一次迭代中预先进行了所有峰值处理，以更好地估计执行峰值处理和/或使“行走骨骼”开始运行所需的时间？ 如果不是这样，总项目进度表是否会受这些尖峰之一的支配，而返回的数据表明这个特定故事所花费的时间比我们制定的时间更长？ 当多个峰值基本上是项目的不可协商需求时，最佳实践是什么？

9 agile 

最近，我对软件开发中的敏捷实践产生了兴趣，从那以后，我已经看到很多文章指出，这些实践可以降低总体成本。 其背后的逻辑通常是这样的：如果您的需求发生变化，则可以在下一个sprint待办事项列表中反映此变化，这将导致成本降低，因为设计新功能并在时间上紧密地实现了新功能，因此根据著名的规则，成本降低了，您越晚需要对需求进行更改，满足该需求的成本就越高。 但是中大型软件项目很复杂。需求的突然变化并不意味着您不必接触系统的其他部分即可满足该需求。在很多情况下，将需要对架构进行非常大的修改，这也意味着您将需要重新实现依赖于较旧架构的所有功能。因此，降低成本的要点在这里已经消失了。当然，如果新的需求需要系统的新的独立部分，那不是问题，旧的体系结构只会不断增长，不需要重新考虑和重新实现。 相反。如果您使用的是瀑布，但突然意识到必须引入新的要求，则可以进行更改。如果需要更改现有体系结构，则可以重新设计它。如果它并没有真正引起混乱，而只是引入了系统的新部分，那么您就去做所有的工作，在这里没有问题。 话虽如此，在我看来，敏捷开发的唯一优势是可以在sprint之间完成功能的完整构建，对于很多人和项目来说，这并不关键。此外，敏捷似乎会导致整个软件体系结构不佳，因为某种功能会相互重叠，因此敏捷团队只关心功能的工作原理，而不是功能的工作原理。看起来，当系统随着时间的推移而变得越来越复杂时，敏捷开发实践实际上会增加整个产品架构的混乱度，从而最终导致更高的成本，因为引入变更的难度越来越大，而瀑布式设计则可以使您完善架构在释放任何东西之前。 有人可以指出我在哪里出问题了吗，因为显然很多人在生产环境中使用敏捷，所以我一定在某个地方错了。

9 project-management  architecture  agile 

首先，我认为由于以下基本原则，敏捷过程可以奏效： 它带来焦点 限制真正带来焦点的噪音 其次，我想知道敏捷流程能否成功需要哪些初始条件？例如我们是否需要： 没有现有的错误 全自动测试过程或至少高度自动化的测试过程 致力于项目的人 更明确定义的新发展 不能使其更快或更稳定的发展 ？ 那么，您需要什么来使其成功？是否有其他敏捷实现可以更好地处理没有某些初始条件的情况？

9 agile 

大约一年半以前，我进入一个声称从事敏捷开发的工作场所。我了解到，这个地方采用了几种敏捷实践（例如日常站立，冲刺计划和冲刺审查），但没有一个原则（及时/足够的心态，尽早暴露失败，丰富的沟通）。 现在，我承担了使团队更加敏捷的任务，并向我保证，开发人员和业务团队已完全同意我的要求。作为一个试点计划，他们给了我一个项目，该项目刚刚完成了15个月的需求收集，有110页的“分析与设计”文档（被认为是“一成不变的”），而且我无法找到最终结果。用户（仅限于实际上不会使用该产品的用户经理组成的委员会）。 我从小处着手，为他们提供了前5个冲刺的预期可交付成果的列表（未定义未来的冲刺），第一个冲刺的目标列表，并且剖析了A＆D文档以获取足够的用户案例来满足第一个冲刺的目标。 从那时起，他们就问为什么我们对所有sprint都没有所有要求，为什么我没有开始为第三个sprint（他们认为更重要，但基于第一个sprint的成果） 2个sprint），并要求获得整个IT团队认为繁忙的工作或与我们无关的更多文档（例如，预先编写用户手册，预先记录所有sprint中的所有数据字段等） “前期”工作）。 作为一个新的项目经理，这对我来说是很艰难的，但是我已经有效地实现了一些改进，例如故事管理的scrumban，结对编程，以及让业务预先为我们提供了客户验收测试（作为需求文档的一部分） 。 所以我的问题是： 我该怎么做才能更有效地将变革引入抵制企业？ 我可以在IT方面引入其他实践来帮助向企业展示敏捷的好处吗？ 文档的负担使我们感到窒息-企业仍然将其视为风险管理策略，而不是风险。我们可以采取什么措施来减轻他们对文档的关注和要求（特别是文档的数量及其对所有这些文档的需求）？ 我们与公司位于不同的建筑物中，位于大约3个街区之外，他们拒绝让该项目的人员同居b / c，因为该人员“在他们在我们公司时将无法从事其他项目建造。” 他们希望我们总是走到那里，把我们的问题捆绑在一起，这样我们就可以立即问他们，而不会因为“不断的打扰”而浪费那个人的时间。我们如何做才能与他们进行更丰富的沟通？ 任何其他建议也将不胜感激。 谢谢！

9 project-management  agile  waterfall 

我们是一个由4个开发人员组成的小组，在Scrum中颇为环保。来自全国各地，我们经常请假几天或整周假回家。因此，由于年度休假，我们的团队能力从一次迭代到另一次迭代急剧变化，这导致一次迭代到另一次迭代的速度差异很大。在计划会议上估算速度时，我们如何考虑团队能力？历史数据将反映出截然不同的容量，我们不能等一整年才能得出估计速度的平均值。

9 agile  scrum  estimation 

按照目前的情况，这个问题不适合我们的问答形式。我们希望答案会得到事实，参考或专业知识的支持，但是这个问题可能会引起辩论，争论，民意调查或扩展讨论。如果您认为此问题可以解决并且可以重新提出，请访问帮助中心以获取指导。 8年前关闭。 我不喜欢问题跟踪系统，因为： 描述其中的问题需要花费太多时间。这不鼓励使用。 您创建了一个保存错误的地方。而且如果有他们的地方，人们通常不会太在意修复错误，因为他们可以将其放到那里，以便有一天有人可以（或不可以）对其进行修复。 随着时间的流逝，错误列表变得如此之长，以至于没有人能够处理它，这占用了我们很多时间。 我更喜欢使用白板上的便利贴来处理问题，进行面对面的对话，并在重要的bug出现后立即将其杀死。我不太在乎跟踪错误历史记录，因为我认为这样做不值得。 我一个人在这里吗？是否有关于使用问题跟踪系统的弊端（或巨大优势）的研究（书/文章/任何内容）？

9 project-management  agile  issue-tracking 

我在一个中等规模的公司的一个小团队中工作，其中大多数不参与软件开发。我是最新的，经验最少的开发人员，在开始之前没有软件方面的专业或学术背景，但是我对自己的投入受到尊重感到非常满意，并感谢在职业生涯的这么早就被认真对待。 尽管如此，我觉得我应该在如此充裕的通话时间内做更多的事情。作为一个团队，我们似乎很难完成工作。我希望能够提出一些建议来改善这种情况，并且我想如果这是个好主意，我会听取的，但是我对所提建议不知所措。 我可以确定为问题的事情包括： 对当前任务的说明很少。部分原因是管理是瓶颈，而我们没有钱或人来承担我们想要的尽可能多的详细需求。这也部分是因为我们正在开发的软件正在调查中，确切的方法尚待证明并用于确定其有效性之前尚不清楚。 首席开发人员非常喜欢他所说的“原型”，以至于他最近开始坚持认为所有东西都是“原型”，对我们其他人来说，这就像在编写不良代码并将其交给建模者一起玩。在许多情况下，尚不清楚他期望从这项练习中得到什么。然后，由于他坚持认为良好实践会花太多时间来制作原型，因此“实际”实现会遭受损失。我什至没有开始能够解开这种扭曲的逻辑，而且我不确定是否要尝试。 建模人员应该精确地告诉我们有关所需方法的所有信息，并且绝对相信他们提出的理论上是完美的。这几乎是不可能的，但是没有采取任何纠正措施。建模方面的任何人都不会以可能采取行动的结构化方式提出任何问题，也不会寻求应用最佳实践的指导。他们的被动性也没有做。 我以前曾尝试将TDD推入团队，但由于它对我来说是新事物，因此发现它很困难，尽管那些对我的工作负责的人愿意容忍它，但其他任何人都没有热情。我无法证明我花了很多时间去完成功能而不花时间，所以这个想法暂时被放弃了。我担心它不会再被捡起，因为没人喜欢被告知如何做他们的工作。 现在，我们有一个持续集成服务器，但它主要仅用于运行多个小时的回归测试。它应该也应该运行完整覆盖的单元和集成测试，但目前还没有人编写它们。 每次我与首席开发人员提出质量问题时，都会得到以下答案：“测试功能A很简单，功能B对用户来说更重要，但测试却太难了，因此我们不应该测试功能一个'。我再一次没有尝试解开这种逻辑。 .... phe 当我这样说时，它看起来比我想的要糟得多。事实证明，我想这是在寻求帮助。

9 productivity  agile  testing  teamwork 

我对PO的职责感到困惑。我是游戏功能团队的开发人员，也是PO。开发人员的日常工作几乎是全职的，因此我必须加班工作以履行我的PO职责，而PO的职责似乎违背了开发人员的想法。 作为采购订单，我将在下一个冲刺中选择更多功能。否则，我会告诉自己不要这样做，因为我是开发这些功能的团队成员。这种情况使我感到困惑，所以我想听听你们的一些想法。 我是Scrum和Game Dev的新手（大约一年半），也是这里和英语的新手。

9 agile  scrum  game-development 

在决定下一个版本要做什么时，并估计每个用户故事的时间（以及给定故事的子任务）时，你们是在小组中还是在经理中这样做？ 对于10人的团队来说，这可行吗？ 多久时间？

9 agile 

看完这个，我看到对于在具有不同能力的一组开发人员（又称几乎所有团队）中如何构建敏捷团队似乎存在很多分歧。是否应该将所有最好的开发人员放在自己的团队中，并给予最高优先级的工作？这几乎可以确保完成最重要的任务。同时，您剩下的地方是“不够完美”的团队，他们承担着技术债务，即使只是在低优先级任务上。另一方面，分布均匀的团队可以使落后的开发人员更好一些，但有可能挫败最沉重的打击者。另外，如果您将一堆好的设计模式与一堆糟糕的反模式混合在一起，那么您最终可能会得到一堆反模式。

9 agile  team  teamwork 

我们目前使用JIRA来跟踪我们的开发工作。我的管理层希望将所有内容格式化并归类为“用户故事”，包括与非软件开发相关的任务。例如： “作为测试经理，我可以仅使用自动测试而不进行手动测试来对应用程序进行测试，以便可以尽可能高效地测试应用程序吗？ 验收标准：1.将50个现有的手动测试转换为全自动测试。2.测试必须在不到1小时的时间内执行” 如果要在支持软件开发过程的工作中使用“用户故事”，而不是由程序员来做，并且不会直接产生可交付的代码，那么我想从社区中了解。还是应该对它进行不同的处理/分类（例如，在JIRA中）？ 2011年6月7日更新-措辞更正的问题集中在“用户故事”一词。

9 agile  stories