Questions tagged «agile»

我目前正在与我所在大学的一位教授合作，为我学院提供的软件工程和Capstone设计课程开发新课程。 直到最近，这两个课程都只使用瀑布模型，因此，学生们大部分时间都在写冗长的报告。在我施加很大压力之后，我的教授决定在上学期将Scrum纳入软件工程课程。 本学期的前半段仍然是瀑布式的，学生们撰写了40页的设计报告和软件规格文档。学期中，所有团队都必须发布其应用程序演示。那时，课程切换到Scrum，进行了两个为期3周的冲刺。现在，我们正在尝试找出如何完全消除瀑布并创建完全基于Scrum的课程。 不幸的是，我们在Scrum和学生之间遇到了一些不兼容性： 对于学生来说，每天召开Scrum会议几乎是不可能的。即使在上课期间，由于教授通常是在讲课，所以学生召开Scrum会议也不方便。 由于学生缺乏经验，因此无法准确地预测要花费多长时间，因此很难估计积分/小时。 Scrum与全职，位于同一地点的开发人员最适合，但学生都不是。学生最多每周奉献15至20个小时的课程，组织工作会议可能非常困难。团队最多可以有10个学生（并且总是有一两个懒人）。 教授们渴望文档！我还没有听说过Scrum的任何报告，只有积压的工作量和燃尽图（我不确定这是否足以使学者安心）。 学生通常认为敏捷的意思是“立即跳入并开始编码而无需回头”。这导致了一些可以想象的最可怕的代码。因此，我正在寻找一种方法来执行适当的设计，而不需要50页的文档或一堆UML图。 鉴于这些问题，您如何看待我和我的教授如何使Scrum在学术环境中发挥作用（并且我们一开始甚至应该为Scrum烦恼）？此外，教导瀑布模型是否仍然有价值？ 预先感谢您的任何反馈！

15 agile  scrum  documentation 

我向雇主报告进度有问题。我是兼职程序员，为我学校的（非技术）部门处理一个软件项目。 联系人： 1.实际使用该软件并提出功能要求的员工； 2.我的老板（非程序员），她不是软件的用户。 该项目的性质： 它是一种现成的软件，已从第三方购买。我必须修改或添加此软件的功能才能满足部门的需求。这是整个学期需要使用的软件。并非一开始就需要使用所有功能。 因此，我们使用的是敏捷模型：当员工需要某个功能时，他们会提出一个请求，然后我进行更改。在本学期末，我认为所有必需的功能都将得到提高和实现。 问题： 每次老板问我进度如何时，我都无法回答，因为我不知道如何回答。我没有所有必需功能的完整列表。尽管我已经完成了上周提出的功能，但是我仍然不能告诉老板我已经“完成”了，因为新功能也即将推出，我也不知道要增加多少。我不能说“我们有多少完成率”，也不能说“我们要在xxx之前完成”。有时候，在3个请求中，我设法完成2个，我会告诉老板“我已经完成2个，但是其中一项功能尚未完成”。过了很长一段时间，我听起来像是“经过这么长时间，我总是有些事情没有完成”。 无法报告进度使我看起来非常糟糕。这不关我做了多少，而是关乎如何让人们知道。如果我是经理，而我的员工几个月都没有向我报告进度，那么我也会觉得这个人也无能为力。 你们有任何想法如何报告，或回答诸如“软件修改的状态/进度是什么”这样简单的问题吗？ 更新 我的老板没有直接参与开发任务，因此她对我在做什么或程序如何工作一无所知。由于她很忙，我们不定期开会，我觉得这会浪费时间，因为她不是主要用户，她也不知道程序的细节。 我会定期与使用和了解该软件的人员会面。 我很难向老板解释进度。

15 project-management  agile  reporting 

我在嵌入式系统中有两个Scrum问题。首先，有许多任务要做，尤其是在早期阶段，这些任务是无法证明的。我们从开发板开始，没有操作系统，没有显示器，没有串行通讯，等等。我们没有六个冲刺的显示器。 前四个冲刺是： 获取RTOS和运行 创建编写网络和串行驱动程序的任务 编写按钮，通讯等中断例程 编写主要的数据库类和方法 编写串行调试菜单 这些任务大多数都不适合用户案例。实际上，进入整个系统的唯一接口是内置在sprint 3中的串行调试菜单，因此在sprint的末尾没有任何内容可以说明。甚至串行菜单也只供内部使用，而不是最终用户。尽管如此，我仍然想通过Scrum跟踪和管理这些开发活动。 我们最终写了“用户故事”这样的词组，例如“作为开发人员...”，我对此并不满意，但是在使用Target Process（www.targetprocess.com）时，没有积压的概念，任务或琐事。 其次，您如何处理发布和测试？对我们来说，这是真正的痛苦，因为测试人员没有硬件调试器，因此我们必须构建代码的闪存版本，并将其刻录到开发板上进行测试。测试人员在技术上不如开发人员那么敏锐，并且通常需要大量支持才能使它们在早期阶段正常工作（重置板子，连接串行通信等），甚至理解输出。 最后，关于完成的定义，只有在所有故事完成之前，冲刺才能完成。在测试人员验证之前，所有故事都是不完整的。无法避免“浪费”开发人员的时间给测试人员。换句话说，如果冲刺中的最后三个用户故事需要五天的时间进行测试，则必须在冲刺结束前五天对它们进行编码和单元测试。开发人员应该做什么？停止工作？ 我正在开玩笑，但尝试遵守规则确实是一个问题。现在，我可以遵循规则了，但是我遇到的问题是，如果在测试之前无法将所有工作标记为已完成，它将使我的所有燃尽指标变糟。 我很想听听其他人如何处理这些情况。

15 agile  scrum  embedded-systems 

大多数敏捷 / XP理论家都拥护的一般想法似乎是，对应该定期交换。例如，每个程序员每天应该交换一次对。一半的人在一天开始时进行交换，一半的人在午餐后进行交换：由于会议，假期之类的外部因素，大多数人倾向于每周交换一次或两次交换时间，以便分配配对配置在整个团队中相当平均。 频繁调换的一个基本原理是，知识在团队中快速而均匀地传播，而不是将特定的技能和知识集中在特定的个人身上-这意味着如果人们离开公司或离开公司，工作就可以顺利进行。另一个原理是围绕结对编程本身的教条的一种推论，即每次有人交换您时，都会得到新的视线审查，因此它只能提高代码质量。 两种说法听起来都合理；从管理的角度来看，这听起来好像您在稳定性和质量上都得到了提高，而这种频繁的交换在我所研究的大多数Agile / XP书籍中几乎都是标准理论。 因此，当实际付诸实践时，人们实际上对从 程序员的观点？ 经理的观点？ 和 当某人从/交换到一对时，应如何确定？

15 agile  pair-programming 

我们最近进入了Scrum流程，并且正在sprint中处理任务和用户故事。我们希望经常进行代码审查，以减轻他们的负担。我们正在考虑在用户故事级别上执行这些操作，但是不确定如何分支我们的代码来解决此问题。 我们使用的是VS和TFS 2010，我们由6人组成。 我们目前为功能分支，但正在努力更改为Scrum分支。 我们目前不使用架子集，如果有其他可用的技术，我们也不想真正实现。 您如何建议我们针对每个用户案例实施代码审查？

15 agile  code-reviews  scrum 

在过去的9年中，我曾在许多小型团队中工作。每个人都有明显的良好做法，例如短期会议，版本控制，持续集成软件，问题跟踪等。 在这9年中，我从未听说过很多开发方法。例如，从来没有过“我们在做Scrum”，“让我们敏捷”，或者是传递引用。所有团队的运作似乎都很好，没有经过很多程序，我们只是自由流动，自然就很好。 有没有其他人长时间进步而没有遇到混乱/敏捷/等问题？ 我唯一接触过这些内容的地方就是通过此类网站。我读过诸如Sprint Meetings之类的问题-谈论什么 ...，所有的讨论似乎都描述了几乎机器人，就像遵循方法论有限状态机的人一样。真的（尽管有些夸张）吗？我想知道在互联网上发布的人们是否只是“最佳实践”的拥护者，具有类似的教科书观点，没有真正反映人们的工作方式吗？或者我遇到过一些团队自然地制定自己的流程。 此外（我在英国，这可能是相关的）...我认为，如果将一种方法论引入我要研究的任何团队中，他们只会拒绝它是愚蠢且不必要的...然后上。我倾向于同意，遵循流程似乎有些不自然。这是典型的还是常见的？

15 development-process  agile  scrum 

我刚刚在大学里担任（唯一的）Web应用程序开发人员。 该学院有许多完全不同但编码很差的遗留系统。它们主要是用PHP内置的，它们处理诸如出勤，考试结果，评分等问题。 我的第一项工作是构建一个包含大量此类数据的系统，该系统目前驻留在各种数据库中，而没有任何友好的API可以将其提取出来（现有系统使用普通PHP编码，没有数据和视图的分离）有了一个新的平台来记录有关学生的牧草信息，并以一种有用的方式将其呈现给教师和高级职员，以便他们可以快速应对学生的问题。 在我们的第一次会议上，有18个人！没有代表多数的明确领导者或声音。没有可识别的客户。这次会议从教师的次要功能的详细实现思想转变为关于是否应使用Excel电子表格进行数据输入的争论！ 可以想象，我的头在最后旋转。我实际上有很多好主意，但是我听不见。在我加入营销机构开发团队之前，这对我来说是一个非常新的角色。我们有明确定义的角色：项目经理，客户，设计师，开发人员。 我想知道是否有经验丰富的开发人员或管理人员可以为我提供一些指导，说明如何将我的同事们带入一个类似于项目团队的项目。是敏捷之路吗？您将如何处理所有不同的声音？显然，某些过程需要非常迅速地落实到位，我只是不确定那是什么。

15 web-development  project-management  agile  development-process  management 

在理想的敏捷世界中，您可以快速构建所需终端系统的一个小而有用的子集，并将其提供给用户。他们很兴奋，因为它很有用，他们开始使用它并提供反馈。然后，您可以计算出要添加的内容，然后进行构建，然后重复进行，直到用完时间。 我最近有几个项目，涉及更换某种工作系统。上面的模型根本不起作用：在您构建了一个包含现有系统几乎所有功能的系统之前，用户完全没有兴趣。他们不会使用它。 当“最小的有用子集”是“全部”时，如何应用敏捷？

15 agile  scrum  users  iterative-development 

我们正在执行一个错误流程。 我们有3个错误级别： P1错误：阻止用户工作的错误。他们必须当场解决。 P2错误：有影响但用户可以使用的错误 P3错误：不会影响用户并可以在其中工作的错误。 P1是强制性的，必须当场处理。但是对于P2和P3，我们将根据具体情况进行判断。 我们拥有3个级别，因此团队倾向于根据客户的要求进行更紧迫的新开发，而不必处理P2和P3，这几乎很紧急。 问题如下： 我是否应该添加另一个优先级，例如拥有P4？ 我是否还应该像本周一样为他们指定处理非紧急票证的目标，当不分配编码任务时，您应至少处理1个P2？ 当前，我们没有像我上面提出的目标，但是我担心的是给他们这样的目标可能是残酷的。可以确定的是，我需要与他们讨论目标，团队喜欢参与讨论，尤其是在设定目标时。 更新： 我从相似性的角度提出了这个问题。但是，它根本不相似。 我的问题是如何让人们处理错误，而又不施加严格的议程却仍要解决它。因此，不，所隐含的问题对我没有帮助。不过还是谢谢你

14 agile  debugging  issue-tracking 

我花了5个小时以上的冲刺计划来进行为期一周的冲刺。似乎太过分了。 由于大多数团队成员都不高级，因此我们将在sprint计划中详细讨论事情。如果我们不这样做，将会在实现过程中导致错误，并在sprint过程中进行重新设计。 我们该如何处理？ 我应该在计划期间讨论多少细节，以使其适合每周冲刺仅2小时的时间？

14 agile  scrum  planning  sprint 

在我们的敏捷过程中，我们有2周的冲刺。每天（每天一次）交付任务，测试团队会在第二天甚至同一天立即完成测试。 我们也有开发人员代码审查，需要一些时间（1-2小时），因此每周安排3次：星期一至星期三至星期五。开发人员聚在一起，建议如何改进/重构代码。 我们的问题是，在代码审查后提出“行动项目”时，大多数任务已经过测试。测试人员不想重新测试已经通过测试的内容。他们不在乎内部开发人员的变更。 我们误解了敏捷过程吗？代码审查是否与每日发布/测试周期不兼容？我们无法每天进行代码审查，因为它们占用了每个人的时间。

14 project-management  agile  teamwork  code-reviews  sdlc 

在一个极端的编程项目中，程序员大部分时间都会进行配对编程。 由于这些对也轮换使用，也就是说，您将程序与不同的人配对，并且具有集体所有权感，因此经常对源代码进行检查和更新。 这样的话，是否需要代码审查？我的意思是，停止编程，实际上只是进行代码审查。

14 agile  code-reviews  pair-programming  extreme-programming 

在短期内，敏捷项目的需求管理对我来说似乎是一个已解决的问题。 从Scrum角度，新需求或对现有需求的更改是通过用户故事交付的。并且，按Epic或Feature分组的User Stories有助于交付更大，更复杂的需求。 当然，从技术上讲，用户故事不是要求文档。这是一个可管理的工作分组，映射到通常称为功能的垂直切片的内容。这些故事的范围可以通过使用接受标准（AC）来明确定义。 因此，尽管用户故事不是正式的要求，但浏览它们可以使您对他们的基本要求有一个清晰的认识。在短期内。 我之所以说是短期的，是因为随着项目的进展，用户故事的数量会增加。因此，随着时间的流逝，浏览不断增加的故事列表以找到需求的效率越来越低。 当您考虑扩展，取代甚至否定先前故事的用户故事时，此问题会更加复杂。 现在，假设一个项目的开发迭代（生产稳定）之间存在2年的差距。最初的团队消失了，他们所有的知识也消失了。 如果原始团队知道这将要发生（例如，这是企业的性质），那么他们可以采取哪些措施来帮助后续团队？ 当然，待办事项将提供一些信息，但是它几乎不容易浏览。 那么，可以做些什么来帮助后续团队了解项目的状态，包括为什么以及如何到达那里？ 以我的经验，以下几项无效： 积压整理以删除或更新以前的用户故事，以便可以将积压阅读为需求文档。 文档冲刺团队成员的任务是记录系统的当前状态。 通过行为测试的文件。这种方法是我所见过的唯一接近可行的方法。不幸的是，编码行为测试是命名问题的受害者。尽管这些测试可能正确记录了该系统，但要使变动的开发人员团队按照相同的Domain术语，措辞和样式编写测试几乎是不可能的。 因此，重申一下： 长期如何管理敏捷项目需求？

14 agile  requirements  requirements-management 

实际上，我正在帮助一家小型软件商店进行Scrum实施。最近的Scrum Master那里告了我，他有一个问题，因为该小组正在随时间实现范围（承诺积压）。因此它们具有虚幻的速度。 我的正式问题是： 除了在回顾会议上发表讲话外；您认为实施一些硬块以避免超时是一个好主意吗？ 如果是这样，您建议使用哪些技术/工具？ 修订控制系统（SVN，GIT，HG等），按小时（8到5）划分 工作站按小时数（8到5）还是累计小时数（每天最多8个小时）进行分组？ 其他）... 或者，也许不要硬阻这类事情；但是在不合理的加班时间内实施“罚款制度”？ 第一：感谢您的快速响应。 @Baqueta（以及其他有类似问题的人）：不，他们没有被收取加班费。我对他们的第一个建议是审查他们的估计，因为他们可能低估了他们的估计。这是我最喜欢的建议： 如果他们有兴趣加班，将其删除。开发不是您每周可以工作60个小时并保持高效的东西，并且有大量研究证明了这一点。如果加班费是问题，那就摆脱它，提高他们的基本工资，使他们得到自己所需要的。 另外，我认为（对于该团队）根本问题是以下各项的组合： 告诉开发人员他们在冲刺中必须实现的目标/未就可实现的目标进行咨询/在说太多工作时被忽略。 开发人员始终低估了任务将花费多少时间/每个任务涉及多少个工作单元。 简介：我将与团队讨论评估他们的估算，并与采购订单进行沟通，因为正如您提到的那样，我认为没有就范围进行咨询。

14 agile  scrum 

我们已经开始由4个开发人员组成的团队使用Agile / Scrum。我们进行了故事估算，并在产品积压订单中订购了故事Primed故事。 我们从对复杂度从1到5的基于点的估计开始，而不是通常的1,2,3,5,8,13 ....等 在处理了几个故事之后，我们觉得一些估计为4点的故事应该只有2个，而其他估计为2点的故事要复杂得多，应该估计为5个。我想知道： 在迭代过程中更改我们的故事估算值可以吗？ 是否可以使用当前估计点从1到5，而不是通常的1,2,3,5,8,13 ....等 尽管我个人认为这两种情况都不应该，但是由于我自己的理解还不是很清楚，我需要支持自己（尽管任何好的参考资料都会很好！）

14 project-management  agile  estimation