Questions tagged «agile»

因此，我开始为一家大型公司工作，其中一家公司名称中有3个字母，他们试图成为敏捷公司，但是却有大量流程，我认为这些流程不是敏捷的。 让我最受困扰的是代码审查。我最后的工作是在一家初创公司中工作，我可以说这是我见过，曾经和/或从未听说过的最敏捷的开发团队。 无论如何，我的观点是，代码审查在UX / UI极端/强烈（想想Apple / Steve Jobs完美）的迭代或敏捷开发中浪费时间。也许有人在解雇我之前可以帮助您理解？ 这是我的开发过程，也是我上次启动的过程。非常敏捷。 我们进行早期功能工作以对开发任务/待办事项进行排序。我们将模拟几个版本并将其呈现给用户，团队和市场，以获取反馈。然后，我们进行另一次样机迭代，以从上述相同的涉众获得一轮机会。然后，我们将工作分拆并开始。我们有一些里程碑和日期可以见面，但我们一直在努力。在此期间，我们没有任何代码审查。在我们开发的几周中，我们几次与利益相关者进行讨论，以了解他们是否仍然同意功能/功能/ UX / UI仍然是合适的目标。 随着8周迭代周期即将结束，质量检查人员开始进行测试，然后测试对象为alpha用户，最后是beta用户。但是在Alpha和Beta测试期间，开发人员将研究新功能和旧功能，对UI进行每日或每小时迭代更改，以改善UX。因此，此版本正在开发的功能可能会在过去四周内被更改3次以上，以进行改进和完善，或者添加一些微小的功能（例如，使组件更光滑或更智能）。有时这些更改可能是肤浅的，这意味着没有更改或修改任何CRUD操作，而仅更改所有UI。 因此，使用这种类型的开发过程（极端敏捷），代码审查不会浪费时间吗？这意味着如果我有另一个开发人员或两个开发人员来检查我的代码，但是由于所有UI / UX的改进，代码在发布之前又要更改3次，我们是否不浪费时间来检查代码的前3次？该代码/组件/ UI被废弃了吗？ 我们在此过程中从来没有遇到过很多质量问题，是的，如果开发人员将所有知识都排除在外，但是我们总是找到聪明的开发人员来接管并接管。 是的，我们有很多测试人员，因为他们可能必须重新测试3到4次。另外，请不要挂断询问为什么所有的UI / UX都会发生变化...那就是事情的完成方式...那么那就是为什么该应用程序会赢得大量的UI / UX奖并且用户会因此而丧命应用程式。思考的过程是，如果我可以多花2个小时来改善某件事，那么我可以将其提高2％。用户会更快乐，这意味着更多的$或用户。是的，我们的用户可以继续更改应用程序，因为这是自第一天以来的工作方式，因此他们不会认为它是不好的还是负面的。 希望这篇文章不会那么夸张，但是我看不出代码审查是不是浪费。也许我们所审查的代码中所有代码的2％都有错误。每个版本的代码审查可能会发现3个错误。因此，最终每个开发人员每个版本需要40个小时的代码审查（4 x 40 = 160个小时），才能发现3到5个错误？无论如何，质量保证会发现3到5个错误的可能性是50％。每个开发人员花40个小时来添加新功能或改进现有功能会更好吗？

13 agile  code-reviews 

好吧，问题本身就说明了。在我的工作场所中，会发生这些情况，而且，许多敏捷著作都提倡在同一工作场所工作，并专注于当前项目，以加快工作速度。 也许我对这个话题的了解不够，也许不是那么严格，但这就是为什么我想知道敏捷在此类情况下的建议。 有人吗

13 project-management  agile  team  scrum 

最近我们有一个项目，其中客户忙于巡回演出。随着通常的Scrum团队的成立，管理层决定任命我们的分析师为产品负责人，因为客户将无法积极参与。分析师是与客户紧密合作进行需求分析和规范起草的人。 客户没有时间审查前两个版本。一切进展顺利，直到客户看到了第三个版本。他对某些功能不满意，而这些功能是由临时产品负责人（我们的分析师）介绍的。 我们被告知要等到设计团队完成所有页面的模型化，然后客户检查每一页并批准继续工作。Scrum团队在那里，但没有冲刺-我们完成工作的方式几乎就像经典的瀑布方法一样。 任命Scrum团队成员或管理员为产品所有者是一个好主意吗？在没有客户/产品所有者参与的情况下，我们是否需要关注Scrum？

13 agile  scrum  waterfall 

我的团队使用看板系统来跟踪日常进度，并且对于理解功能（捕获为用户故事）的进度非常有效。随着我们开发功能的发展，直到最近，我们在很大程度上允许我们的系统设计出现。在过去的两周中，我们就与性能和可修改性质量属性特别相关的架构取舍进行了多次讨论。 我认为正在发生的事情是在实现功能和设计系统时，我们在隐式地做出有关体系结构的决策，而不是根据我们已知的质量属性要求来考虑这些决策。如果我能够跟踪/捕获/直观地描述这些重要的设计决策是如何做的，那么团队成员将有更好的机会在实施系统时不给系统架构带来额外的压力，这真是太好了。当然，更复杂的是，我们板上的功能并非仅能发挥功能，有时会掩盖架构的复杂性！ 如何在团队看板上直观地跟踪质量属性（或其他与体系结构相关的决策）的进度？

13 agile  tracking  architecture  kanban  quality-attributes 

我的管理层刚刚问了我在组织中（公认的简短）历史中前所未有的问题：“我们能为您提供什么帮助？” 同时，我们正在为一个相当新的客户开展几个大型项目，这些客户能够将需求推向项目中间是传奇。为这些人发展就像在流沙上踢踏舞。 似乎是向更敏捷方法转变的绝好机会。我知道我将要被问到的，而且我对此一无所知的是如何为此类项目报价/出价/开票。你每小时去一次吗？您会出价范围吗？冲刺收费吗？ 更广泛地讲，敏捷宣言中写着“我们重视客户协作而不是合同谈判”的方面正在吓到我的管理层。您如何看待现实世界中渴望大量消费的客户？

13 agile  billing  customer-relations 

一项Scrum测试包含有关定义的问题，该定义最能描述当多个开发团队对同一产品执行工作时的“完成”。 一个正确的答案是，这些开发团队必须对“完成”进行这样的定义，使他们的合并工作有可能被释放。 从这个测验的正确答案中，我不清楚： 团队可以对“完成”有不同的定义吗？在什么程度上？

12 agile  scrum 

关于敏捷的大多数文献似乎偏向于CRUD类型的业务应用程序，在该应用程序中，用户非常了解幕后情况。（这很好，因为所编写的大多数代码可能都属于此类。） 对于这种类型的应用程序，用户故事（需求）和开发任务之间的关系通常很简单：只需将用户故事分成几个任务即可。 但是还有另一种类型的应用程序，其中大多数代码必须处理用户不直接可见的复杂处理。例如： 编译器 自动驾驶汽车图像分析系统 流体模拟系统 在这里，将任务和用户案例联系起来确实非常困难。是否有克服这一问题的技术，或者仅仅是我们必须接受并充分利用的技术？

12 agile  project-management  user-story  task 

我最近看到很多帖子说，使用敏捷的主要原因之一是因为客户经常更改需求。 但是，假设客户不会经常更改需求。实际上，客户的要求虽然严格，但可能有些含糊（但没有任何不合理的含糊），但无论如何，我还是使用敏捷。 我之所以选择敏捷，是因为该软件足够复杂，以至于存在一些细节和问题，直到我真正面对这些问题时我才意识到。我可以像瀑布一样进行全面的繁重计划，但是要花上几个月才能完成所有高级设计和低级代码签名。但是，系统有一个非常具体的固定体系结构设计。 我的问题是：这会被认为是不好的，牛仔编码，反模式等吗？在需求稳定时开始编码之前，我们是否必须采用瀑布式计划并尽可能详细地计划，而不是敏捷中的这种“让我们去做”的心态？ 编辑：这里的主要观点是：我们不能责怪客户改变需求。假设客户向我们指出了一个非常具体的问题，给我们一个非常合理的细节的愿望清单，然后让我们独自一人（即客户有自己的生产性工作要做，别再烦他们了。只向他们演示当您有最低限度的工作原型时结束）。在这种情况下使用敏捷会错吗？

12 agile  development-process 

我在一家大公司工作，这规定了敏捷过程的使用。例如，对于我们的项目，我们使用专门针对管理敏捷开发的基于云的服务。 我所服务的特定工程团队没有传统开发的软件（相反，我们从更鸟瞰的角度帮助推动项目），但是这种情况正在发生变化。我们有大量即将到来/计划中的软件项目，这些项目大多以数据为中心-例如，我们将进行数据监控，收集，汇总和一些报告。其他任务包括使用专用硬件和各种类型的客户端/服务器（多层）体系结构进行自动化。我将协助雇用多个人，并制定我们前进的许多计划。 我的问题是进行快速原型设计（一次性代码）是否适合敏捷哲学。例如，我喜欢Python及其广泛的软件包。我看到使用基于Python的工作流非常快地实现我们的许多想法的可能性。但是，我认为会有很多人认为Python不是“企业质量”的，并且许多工作都需要用Java或C ++重写。 但是，创建Python原型将使我们在快速实现真实结果方面付出巨大的努力。 您是否能够在企业环境中将快速原型制作（希望在Python中）整合到可靠的敏捷工作流程中？

12 python  agile  design  prototyping  product-management 

在我的公司中，单个任务永远不可能由一个人完成。将有单独的人进行质量检查和代码审查每个任务。这意味着每个人将针对每个任务给出完成所需时间的估计。 问题是，我应该如何处理掉？如果我将小时数汇总在一起，请假设以下估计： 10小时-开发时间 4小时-质量检查 4小时-代码审查。 任务估计= 18小时 在每天结束时，我要求用“剩下多少时间才能完成”来更新任务。但是，每个人通常只考虑自己的部分。他们应该标记剩余的工作量，然后再添加工作量估计吗？你们好吗？ 更新 为了澄清一些事情，在我的组织中，一个故事中的每个任务都需要3个人。 有人来制定任务。（进行单元测试等） 负责审核任务的质量检查专家（他们主要进行集成和回归测试） 技术负责人进行代码审查。 我认为没有错误的方法或正确的方法，但这是我们的方法……而且这种情况不会改变。我们会以团队的形式尽可能地完成故事的最小层面。在开发完成之前，您实际上无法测试某些项目是否可行，并且您也无法查看代码的质量……因此，您可以做的最好的事情就是将这些内容分解为较小的逻辑切片，以便可以测试最基本的功能。尽可能早地进行审查。 我对以这种方式工作的人的问题是，当以这种方式设置他们时，如何烧掉“任务”。除非一个任务有它自己的子任务（JIRA不允许）...我不确定每天完成跟踪“剩下的事情”的最佳方法。

12 agile  scrum 

从我读到的内容来看，敏捷开发通常涉及到将重构或反向工程代码重构为图表。当然还有很多，但是如果我们考虑依赖这两种方法的实践，动态类型的语言是否处于不利地位？ 看来静态类型的语言会使重构和逆向工程容易得多。 如果在动态类型语言中并非不可能，那么重构或（自动化）逆向工程难吗？现实世界中的项目说明了如何将动态类型的语言用于敏捷方法？

12 agile  dynamic-typing  static-typing 

重要提示：我们有没有问题，有任何的源代码文件。这属于常规代码审核，并且是最新的。我们的问题是开发人员文档（如果愿意，也可以是“外部”），从程序员到程序员的类似博客的小技巧，这些技巧往往一经编写，经常被抛在后面。 我们使用类似Wiki的系统来生成程序员文档 - 程序员为程序员编写的文章，详细描述了特定代码的工作方式。这些维基页面通常包括： API部分设计决策背后的动机（例如；我们做这件丑陋的事是因为这个特定的第三方库希望以这种方式完成工作，因为另一个库...是因为...） 解释我们如何处理特定的常见任务（例如，显示琐碎的弹出窗口，该弹出窗口需要引用适当的应用程序样式，在注册表组件中注册自己，并实现一些接口以便被其他组件自动“扫描”） 良好做法（实际上是主观的，我们确实将这些内容记下来了） 环境配置，所需的工具及其设置 通常，主要与编写代码有关的内容由于其大小和博客文章/类文章的性质而与常规代码文档不符。 问题 就几个月前引入这个系统而言，似乎是个好主意，如今，我觉得它引起的问题比解决的问题多。例如： 人们确实写文章...但是一旦代码更改，Wiki更新就很少跟进 很多草稿文章，是某人匆忙写的，像这样离开 即使文章请求通常来自项目负责人，也几乎从未对其正确性/组成进行过验证-有时会导致质量不佳 通常降解。代码已更改，Wiki保持不变。下次有人寻找信息时，他通常会发现一堆过时，质量低下的东西-并且想知道正在发生什么，他发现的东西是准确的还是（甚至更糟）其中的哪些部分。而本该提供帮助的结果却相反。 目前看来，人们已经意识到了这个问题，包括项目负责人，但是显然没有人愿意为此做任何事情（或者要做更多有趣的事情）。 我最初的想法是将其全部遗忘（在我连续几次被过时的“小费”咬伤之后），但是我想那可能太极端了。一些信息值得注意，有时会读得很好，但是问题仍然存在：如何处理其“最新信息”？它是否以某种方式链接到源代码（因此，当检入文件的更新版本时，文章作者会收到通知，他可能需要修改代码/文章）？有指定人员在日常基础上“监视”它吗？定期清理吗？

12 project-management  agile  documentation 

完成分配给冲刺的故事的态度应该是什么？显然，您想优先考虑在sprint中完成它们，但是对我而言，敏捷的全部要点是动态的：您不想故意拖延或使其“错过”在sprint中完成用户故事的机会，但是在当出现意外情况，而那些故事没有完成并被推送到下一个冲刺的同时，您也不希望感觉自己做错了什么。那不应该是令人恐惧或消极的经历，对吗？ 缺少冲刺承诺是否可以接受负面/恐怖经历？当出现必须处理的意外任务（例如生产支持）时，开发人员是否应该对错过的冲刺承诺负责？

12 agile  sprint 

我们的团队有7个开发人员，需要在短时间内（大约一个月）将开发速度提高一倍。我知道有一个常识性规则，即“如果雇用更多开发人员，则只会在头几个月损失生产力”。该项目是一个电子商务Web服务，大约有27万行代码。 我现在的想法是将项目分为大约两个独立的子项目，让新团队在两个子项目中的较小者上工作，而当前团队在主项目上工作。即，新团队将致力于结帐功能，最终将成为独立的Web服务，以减少耦合。这样，新团队就可以在只有10万行代码的项目上工作。 我的问题是：这种方法是否可以帮助新手开发人员轻松适应新项目？还有什么其他方法可以快速扩展开发团队，而不必等两个月，直到新手开始生产更多的软件，然后再开发bug。 ======= 更新 这家企业完全失败了，但并不是因为你们提到的原因。首先，我对新团队的规模和能力不了解。我本应该对它们进行评估。其次，在该站点招聘人才是一项艰巨的工作。在总公司所在地，招聘要容易得多，但是在第二团队的城市中，显然缺少具有所需资格的开发商。结果，工作时间从原来的1.5个月延长到了4.5个月左右，并被高层管理人员取消。 我犯的另一个错误（Alex D曾警告过）是我试图将重构出售给高层管理人员。您从不出售重构，而仅出售功能。 事实证明该启动是成功的。从未发生过的重构变成了技术债务：系统变得更加单一且难以维护，开发人员的生产力逐渐下降。我现在不在团队中，但是我希望他们能在不久的将来完成它。否则，我不会为该项目的成败做出任何贡献。

12 productivity  agile  team 

开发人员成为“ scrum master”是否有益？ 这是官方认证还是专业的人？ 成为一体的步骤是什么？

12 agile  scrum  scrum-master