Questions tagged «agile»

在敏捷开发过程中，通常主要侧重于用户故事，但是有时一个需求可能跨越多个用户故事。 例如，客户端可以为论坛中的所有用户请求搜索页面，并且在每个用户上可以执行多种操作，例如禁止用户，删除用户，重置密码等。 我们可以将此功能至少分为4个用户故事： 搜索用户 禁止用户 删除用户 重设密码 用户界面设计者将如何实现这样的用户界面？他/她是否应该处理第一个用户故事，然后开始为UI增加更多功能？但是，我认为最终的UI会搞砸了！ 如果他决定使用整个功能（搜索+动作），那么如果这些动作的优先级较低，并且将在搜索功能完成后进行多次迭代，该怎么办？

11 web-development  agile  user-interface  user-story  user-experience 

我已经绘制了我的团队燃尽图及其每次迭代的速度。对我来说，它看起来真的很糟糕（速度波动很大）。我应该寻找什么来诊断这种行为的根本原因？

11 agile  scrum 

已关闭。这个问题需要更加集中。它当前不接受答案。 想改善这个问题吗？更新问题，使其仅通过编辑此帖子来关注一个问题。 6年前关闭。 有人可以向我解释持续集成的概念吗，它如何以一种易于理解的方式工作？公司为什么要在代码交付工作流程中采用CI？我是一名开发人员，而我的公司（主要是构建团队）使用Team City。作为开发人员，我总是签出，更新代码并将其提交到SVN，但总的来说，我从来没有真正担心过TeamCity或CI。所以我想了解CI的用处？CI是敏捷方法论的一部分吗？

11 agile  continuous-integration  jenkins 

像大多数现代开发人员一样，我非常重视敏捷原则，例如客户协作和对变更的响应，但是当产品所有者（或由谁决定需求和优先级的人）过于频繁地改变需求和优先级时会发生什么呢？喜欢一天几次？ 我最近继承了一个很小的代码库，该代码库有错误，不完整，甚至无法处理它应该想到的最简单的情况。我可以处理技术问题，但每天都会收到几封电子邮件，短信或电话，说：“天哪，您现在就必须努力！最重要的事情！这是一个人！”（这只是一点点夸张）更糟糕的是，大多数事情都是次要细节，甚至与该软件实际上应做的事情都不相关，反正要花几天的时间才能实现。我试图解释的是，时间太短了，我们应该首先专注于最重要的事情，但是翻译中似乎会丢失一些东西，因为同一件事会在一两天后发生。 是否有某种产品所有者负责人的角色，深入的研究，隐喻或报价可以帮助我减少浪费的精力或至少解释这种混乱行为的代价？

11 agile  product-owner 

迭代已经开始，新的程序员加入了这个团队，另外一个开发人员估计任务X需要30个小时。 在这种情况下，最佳做法是什么？ 新的开发人员使用给定的估算值运行（想法是在计算速度时会纠正任何差异吗？） 新开发人员重新评估任务？（如果是这样，如果它明显更高并且不再适合迭代，该怎么办？） 举起双手回到瀑布吗？ 还有其他东西吗？

11 agile  estimation 

当我阅读Batic D的Dogsa T的先前工作的摘要时。测试驱动开发的有效性：工业案例研究。软件质量杂志。2011; 19（4）：643-661。令我惊讶的是，围绕TDD进行的许多研究中使用的度量都是基于诸如代码行，缺陷和开发时间所基于的。 是否有研究集中在使用TDD与传统开发或最后测试相比开发的产品的总拥有成本上？ 我对购置和运营总成本特别感兴趣。

11 agile  management  tdd  computer-science 

我有一个团队，所有团队成员之间没有一种共同语言。团队分布在两个位置（尽管地理不是主要问题）。每个地点的所有团队成员都说相同的语言，并且两个地点的成员都可以说两种语言。我想介绍一下Scrum，但是在处理语言问题的后勤工作上很挣扎。 这不是一支离岸团队。所有团队成员均为公司员工，但位于不同国家/地区的两个不同办事处。幸运的是，我们在时区方面没有任何问题。语言是主要障碍。尽管可以将团队分为两个团队，但要考虑到每个地点人员的规模和技能以及其他外部因素，因此更希望将其整合为一个团队。 我认为最好使用视频会议，以便进行更丰富的沟通并帮助团队团结起来，使彼此能够看到对方并采取真正的站立方式。但是，恐怕很难在语言之间进行交流。团队中的双语成员应该口头翻译吗？或者，我们可以使用即时消息，这是我发现的有关分布式Scrum语言问题的唯一参考。我担心沟通不畅，也许对Scrum概念的介绍不佳。 在团队中处理过语言差异的经验丰富的人中，您如何解决该问题以及它对您的工作有多好？

11 agile  scrum  team  spoken-languages  distributed-development 

我有点支持“行为驱动开发”方法论（又名BDD）。我已经使用BDD已有两年了，并且在开发DotNet应用程序时采用StoryQ作为我的首选框架。即使我已经进行了多年的单元测试，并且以前已经转向测试优先的方法，但我发现使用BDD框架会带来更多的价值，因为我的测试抓住了相对而言需求的意图。在我的代码中清除英语，并且因为我的测试可以执行多个断言而无需在测试进行到一半时结束测试-这意味着我可以一目了然地查看哪些特定断言通过/失败，而无需进行调试即可证明。 对于我来说，这确实是冰山一角，因为我还注意到，我能够以更有针对性的方式调试测试和实现代码，从而提高了我的生产力，并且我可以如果由于输出进入构建日志而导致问题一直困扰到集成构建，则可以轻松确定发生故障的位置。此外，StoryQ api具有很好的流利语法，易于学习，并且可以以多种方式应用，不需要外部依赖就可以使用它。 因此，有了所有这些好处，您会认为很容易将概念引入团队其他成员。不幸的是，其他团队成员甚至都不愿看StoryStorQ来对其进行正确评估（更不用说应用BDD的想法了），并说服彼此尝试从我们自己的核心测试框架中删除许多StoryQ元素，甚至尽管他们最初支持使用StoryQ，但是即使他们希望删除的代码也不会影响我们测试系统的任何其他部分。这样做将最终导致整体上显着增加我的工作量，并且确实与实际情况背道而驰，因为我通过实践经验深信，这是在特定的工作环境中以“测试优先”的方式工作的更好方法，只会导致更大的工作量。鉴于以下情况，我们的软件质量得到了改善 我们发现更容易坚持使用BDD进行测试。为了进一步澄清，我们大多数的单元测试往往都很脆弱且难以维护，多年来由于应用程序测试不佳而导致的结果是，由于不愿坚持测试驱动的流程，开发人员退回到了旧习惯，在项目结束时进行所有测试（这些人声称自己是敏捷的！）。 因此，问题实际上归结为以下几点： 我可以使用哪些论点来真正说明这个团队使用StoryQ或至少采用BDD方法会更好？ 您能否指出我能用来支持我的论点以采用BDD作为我们的标准选择方法的任何轶事证据？ 您能想到什么相反的论点，这可能表明我希望鼓励团队采用BDD的想法可能是错误的？是的，只要论据是合理的，我很高兴被证明是错误的。 注意：我并不是在主张我们全面重写测试，而只是为了以后的所有测试工作而以不同的方式开始工作，最好以与客户互动的方式开始。 对于希望进一步了解BDD的人来说，以下链接可能会有用： http://dannorth.net/introducing-bdd/ http://en.wikipedia.org/wiki/Behaviour_driven_development http://behaviour-driven.org/简介 对于那些对更多细节感兴趣的人，我们是一个由4人组成的小型团队，致力于大约5个大型项目。BDD的“试验”最初进行了大约2个月，随后又进行了大约4个月。团队接受了我应该继续以这种方式工作并进行自己的尝试。自试验结束以来，我一直从事BDD工作约两年，而其他人则非常擅长回避问题。我不是在问题上施加“对抗”，而是在寻找一种方法来温和地说服团队摆脱集体的落后，并抽出时间来做好自己的工作。

11 productivity  agile  unit-testing  bdd 

敏捷的宗旨之一是... 客户合作而非合同谈判 ...另一个是... 个人与流程和工具之间的互动 但是从我的角度来看，至少在与客户互动方面，存在一个基本问题： 客户的想法与软件工程师的想法不同 是的，这可能有点概括。可以说，在某些业务领域中，这不一定是正确的，尽管这些领域很少而且相去甚远。但是，在许多领域中，典型的客户是： 对日常运营问题感兴趣-短期策略...不一定是策略； 可以理解，仅关注即时解决方案； 实际的思想家，而不是抽象的思想家； 与考虑解决方案将如何支持未来的问题相比，对“完成工作”更感兴趣。 另一方面，理想情况下，实践敏捷的软件工程师是： 大量考虑质量的人； 欣赏一些前期工作可以节省大量精力的个人； 经验丰富的分析思想家。 因此，似乎存在文化差异，倾向于抑制“客户合作”。 解决此问题的最佳方法是什么？

11 agile 

Scrum最适合具有通才成员的团队，即，至少2人可以完成相同任务的团队。我的主要关注点是为由专家组建的团队找到合适的解决方案以适应混乱（保持什么，删除什么，改进什么）？ 假设您有一个由5个开发人员组成的团队（不是真正的，仅作为示例）： 一位在C语言方面很强的数学家； 一名数据库开发人员； 一名Web开发人员； 一位UX / GUI开发人员； 一位软件架构师； 在这里，所有人都是专家，没有人可以替代其他人（我不在乎建立这样一个团队的风险，我想专注于Scrum）。因此，在混乱的情况下，这是我的想法： 毫无用处的春季计划：的确，当数学家说某项特定任务的价值为2分时，没人会投票反对他。 无用的团队速度指标：由于每个人都可以为自己的任务分配任意数量的点，因此计算速度是没有意义的； 用每周一次（较长）的Scrum会议代替每天的Scrum会议：由于团队中的每个成员都在按自己的任务进行工作，因此，每天的Scrum会议对于保持“团队合作精神”非常重要。但是，每天的Scrum会议应该持续15分钟左右。显然这不足以了解其他人正在做和将要做的事情。而且，数学家在大多数时候会回答相同的问题：“我仍在做％＆Lo（+？$$ ++＆）” ...每周的会议会花更多的时间。为了在“初始” Scrum会议和“每周” Scrum会议之间保持相同的会议时间，每个每周的Scrum会议应持续（每周5天，有4个星期的冲刺，其中Sprint会议持续4个小时，每日会议持续15分钟）： （4 * 60 + 20 * 15）/ 4 => 还是Scrum仍然可用？也许应该使用另一种敏捷技术？

11 agile  scrum 

关闭。这个问题是题外话。它当前不接受答案。 想改善这个问题吗？ 更新问题，以使它成为软件工程堆栈交换的主题。 8年前关闭。 我想知道保存项目日志或日记有多困难/有用。我担心跟踪自己所做的事情会占用太多时间...

11 project-management  agile 

最近，我与一位开发人员进行了讨论，该开发人员提到在程序开发过程中，他们会定期创建和删除表和列，同时使用新功能和合理的工作，并说使用敏捷开发过程是正常的。 由于我的大部分背景都是在瀑布式开发环境中进行的，所以我想知道这在敏捷开发中是否被认为是正确的，或者这可能是潜在问题的征兆，无论是程序体系结构还是遵循敏捷过程。

11 architecture  agile  database 

我是一个相对较新的开发团队的成员Scrum，假设在sprint结束时，一些大的故事是由PO决定in progress还是不是accepted。 首先，这些用户故事会发生什么？您是否只是将它们带入下一个冲刺？ 如果是这样，是否应该重新估计它们？在我看来，这些用户故事上剩下的工作可能很少或很多？如果没有，为什么不呢？ 编辑：在我的特定情况下，故事没有完成是因为存在几天的障碍，而不是因为用户故事被低估了。对于可能对您有用的人，我们正在使用VersionOne

11 agile  scrum 

我正在按照Scrum模型松散地进行一个项目。我们正在做两个星期的冲刺。我尚不清楚的东西（也没有书可以参考）正是冲刺之间应该发生的事情：应该有一些“包装”过程，产品在这里生产和交付，但是： 这通常需要多长时间？ 整个团队都应该参与吗？ 在开发人员开始处理下一个冲刺项目之前，它是否必须严格完成？ 进行代码审查和测试时，这是什么？ 一共有三个开发人员，总共约有1个FTE。因此，冲刺确实非常短。

11 agile  scrum  sprint 

当我阅读马丁·福勒（Martin Fowler）著名的博客文章《设计死了吗？，我得到的惊人印象之一是，鉴于在敏捷方法论和极限编程中，设计和编程都是进化的，总有一些地方需要重构。 当程序员的水平很好并且他们了解设计的含义并且没有犯严重错误时，代码可能会继续发展。但是，在正常情况下，在这种情况下的地面现实是什么？ 通常情况下，产品会进行重大开发，而当需求发生重大变化时，这是否不是我们想要多大的期望就不能修改基本设计方面的约束呢？（而不会丢弃大部分代码）。在设计和要求方面的任何进一步改进方面，人们不太可能走到尽头吗？ 我不是在这里提倡任何非敏捷实践，但我想向实践敏捷，迭代或进化发展方法的人们了解他们的真实经验。 你有没有遇到这样的死胡同？您如何避免或逃脱了它？还是有措施确保设计在发展过程中保持清洁和灵活？

11 design  agile