Questions tagged «agile»

敏捷软件开发是基于迭代和增量开发的一组软件开发方法，其中需求和解决方案通过自组织，跨职能团队之间的协作来发展。

9
确定元素的交货日期是否是“敏捷”的工作方式？
我们一直被告知，我们将由高级管理层以敏捷的方式开展新项目。他们设置了站立式，冲刺计划，回顾展等。但是，他们现在想出了一个计划，详细说明了他们希望我们针对每个要素提供的所有工作，并再次展示了日期，并在每个要素中进行了演示。一。该计划将于2017年第二季度发布。 在我看来，这似乎是最糟糕的瀑布，一个没有技术团队投入的计划已经草拟，其中计划中的某些故事还不清楚，开发团队也没有估计。 但是，我知道他们的论点是“高级利益相关者必须有日期并且必须有计划，我们不能仅仅从积压的工作中进行。” 在我看来，似乎高级利益相关者还没有购买敏捷，因此我们注定无法在较低的水平上实施它。 这是公平的判断还是我对这个计划反应过度了？
9
敏捷开发方法是否有可行的替代方案？
两种主要的软件开发方法是瀑布式和敏捷式。在讨论这两者时，通常会着重于将它们区分开的特定实践（结对编程，TDD等与功能规范，大型前期设计等）。 但是真正的差异要深得多，因为这些实践来自一种哲学。 Waterfall说： 更改成本很高，因此应将其最小化。 敏捷说： 改变是不可避免的，所以要使改变便宜。 我的问题是，不管您如何看待TDD或功能规格，瀑布式开发方法真的可行吗？ 真的有人认为对于希望交付有价值的软件的人来说，最小化软件更改是一个可行的选择吗？还是真正的问题是，哪种方式在我们的情况下最能应对不可避免的变化？
1
是否有关于敏捷的经典书籍？
作为一个单独的开发人员，我认为我正在使用类似敏捷的流程，但是我想将自己在做的事情与真正的敏捷进行比较，看看我是否可以改进自己的流程。 是否有一本书是事实上的标准，用于描述有关敏捷的最佳实践，方法和其他有用信息？那本书使它与众不同吗？
45 agile  books 
10
在没有要求的情况下编写软件是应该具备的技能还是应该避免的情况？
我发现一些软件开发人员非常擅长此事，并且经常以其提供具有抽象要求的有效概念的能力而倍受赞誉。坦白说，这让我发疯，而且我不喜欢随便“弥补”。我曾经以为这是有问题的，但是我已经开始感觉到了转变，而且我想知道在很少给与指导的情况下是否需要调整我的思想（和编程）过程。我应该开始学习这种技能吗？还是坚持将需求的收集和业务规则放在首位的想法？
7
Scrum与公开招标不兼容吗？
一个公共组织要求我举办一个有关敏捷开发101的非正式研讨会，解释Scrum，看板等的术语和概念。我已经在敏捷环境中工作了大约五年，但是我不认为我是Scrum的传播者。 研讨会结束后，他们喜欢这个主意。但是，他们解释说，这种方法可能不适用于他们，因为他们需要委托外部软件公司为他们开发软件（他们自己只有很少的开发人员）。这项活动需要在公开招标过程中完成，描述结果，价格和时间范围。这是为该组织（公共研究机构）申请预算的法律要求。 这些约束似乎与敏捷开发的基本原理矛盾，不是吗？ 在这种环境下Scrum只是不兼容吗？ 您对这个组织有什么建议？
7
您如何处理每个Sprint的多个分支/开发人员的集成代码？
刚接到一个电话，开发人员对每个sprint中将其故事集成到master分支表示担忧。开发人员所有代码都在自己的分支中，并且在冲刺结束时，他们都合并到一个主分支中。 然后，让一名开发人员（通常是同一位开发人员）负责确保所有内容都与其他开发人员的代码很好地集成在一起（大多数更改都在同一页面上。例如，数据显示故事，数据过滤故事和SLA指标）。 我们如何减轻这种负担并使我们的代码更容易合并在一起？从我的角度来看，让PO或SM以更有效的方式对故事进行优先级排序，以便我们在同一sprint中没有此类依赖关系可能会解决某些问题。其他人如何解决呢？还是这只是过程的一部分？
6
首席开发人员在敏捷团队中的作用是什么？
在非敏捷开发团队中，首席开发人员通常： 设置标准（编码等） 为团队研究新技术 为团队设定技术方向 对事情有最终决定权 设计系统架构 但是，敏捷团队的工作方式有所不同： 敏捷团队将依靠紧急设计，而不是预先设计 敏捷团队一起设计，而不是由一个人决定设计 敏捷团队决定自己的技术方向，这是交付项目的最佳选择 这将使敏捷开发团队中的首席开发人员离开哪里？在敏捷团队中是否可能有首席开发人员？敏捷团队是否需要与领导不同的职责？
4
什么是“群居”？
我听说过在敏捷或极限编程中提到的蜂拥而至。它似乎是配对的补充。 到底是什么 什么时候应该使用？你怎么做得好？
6
为什么我们使用“冲刺”一词？
敏捷宣言的创始原则之一是 敏捷过程促进可持续发展。赞助者，开发者和用户应该能够无限期地保持恒定的步伐。 Scrum团队使用术语sprint来指工作周期（也称为迭代）。 但这对我来说没有意义。根据谷歌的冲刺是： 在短距离内全速运行。 换句话说，这是不可持续的。为什么Scrum团队使用sprint这个词？在我看来，这与敏捷的基本原则之一相抵触。
5
其他人会觉得Scrum不敏捷吗？
我是敏捷开发的忠实拥护者，几年前在一个非常成功的项目中使用了XP。我喜欢它的所有内容，迭代开发方法，围绕测试编写代码，配对编程，让客户在现场运行。那是一个高产的工作环境，我从没有感到自己受到压力。 但是我工作的最后几个地方使用/使用了Scrum。我知道这几天是敏捷开发的榜样，但我不是100％相信它是敏捷的。以下是它对我不敏捷的两个主要原因。 项目经理喜欢它 从本质上讲，他们迷恋时间表的项目经理似乎都喜欢Scrum。以我的经验，他们似乎将Sprint Backlog用作跟踪时间要求并记录在给定任务上花费了多少时间的方法。他们都没有使用白板，而是使用一张excel表格，每个开发人员都必须认真地填写该表格。 在我看来，这对于敏捷过程来说是太多的文档/时间跟踪。当我可以继续进行任务本身时，为什么我会浪费时间估计一项任务要花多长时间。或类似地，为什么我会浪费时间记录任务可以花多长时间才能转到下一个任务。 站立会议 我以前工作过的站立会议是一场噩梦。每天我们都必须解释昨天的工作以及当天的工作。如果我们按照时间“完成”一项任务，那么项目经理会发臭，并参考“ Sprint待办事项列表”，以表明您不称职不称职。 现在，我了解了交流的必要性，但可以肯定的是，日常会议的气氛应该轻松愉快，并专注于知识共享。我认为这不应该成为您家庭作业风格的诱人之处。同样可以肯定的是，敏捷的漏洞在于时间线会发生变化，它们不应该一成不变。 结论 敏捷的想法是通过使开发人员的生活更轻松来使软件更好。因此，在我看来，团队使用的任何敏捷过程都应由开发人员领导。我不认为让项目经理使用他们标记为“敏捷”的流程来跟踪项目与敏捷开发有关。 有人在想吗？
41 agile  scrum 
3
如何协调Scrum中两个不同项目之间的开发人员时间？
我成为一个新成立的团队的Scrum Master，负责创建软件和维护其他已部署的应用程序。因此，基本上每个团队成员都有开发和运营任务。 在过去的几周中，我一直在观察他们的工作方式，我注意到团队在协调这些任务时遇到了麻烦。当开发人员专注于编码时，他会被打扰以解决生产中出现的问题，这使他很难再次专注于先前的任务。 我尝试分配％的开发人员时间用于操作工作，但是显然，这不能解决问题。我很想听听曾经遇到过这种情况的Scrum管理员的来信，您如何处理这种情况以及您有什么建议？
17
每日站立-是或否？[关闭]
您认为每日站立会议有多有价值（或没有）？ 如果您不熟悉它，则指的是Scrum拥护者（以及其他一些敏捷方法论）中的日常会议。这个想法是，您每天召开一次会议，时间限制为15分钟，每个人都必须参加会议（以鼓励人们直截了当）。 在会议上，您到处走走，每个人都说：-昨天您做了什么-您今天打算做什么-任何阻碍或阻碍您前进的障碍。 您认为这种做法有价值吗？有没有人在一个做过的地方工作，您觉得呢？
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.