问题标签 [development-process]

高质量的错误报告对于有效的错误跟踪至关重要 - 在理想情况下，所有错误报告都将包含基本信息，例如它影响的软件版本以及如何重现错误的分步描述。

但实际上，报告的错误质量可能有很大差异。他们可能是在线的（“功能 X 不起作用，修复它！”）、功能请求、PEBKAC 或无法理解。

您如何执行或维护错误跟踪器中错误报告的质量以保持有效性？

我爸爸总是说“没有权威的责任是没有意义的”。

但是，我发现作为开发人员，我们总是陷入以下情况：

• 负责确保软件“无错误”，但无权实施错误跟踪系统
• 负责按时完成项目，但不能影响需求、质量或团队资源（项目管理的三个部分）
• 等等

当然，你可以说很多事情来解决这个问题——找一份新工作，和老板打架，等等......

但是这个问题的技术解决方案呢？也就是说，你可以自己做什么样的编码事情，而不必说服团队纠正其中的一些问题——或者你可以使用什么样的工具来证明为什么未跟踪的错误会伤害你，错过最后期限是因为质量问题，你如何利用这些工具获得更多的“权威”，而不必当老板？

***举个例子——老板来找你说“为什么有这么多虫子！！？！？” - 我们中的大多数人会说“我们没有一个好的系统来跟踪他们！”，但根据我的经验，这通常被视为一个借口。那么，如果您可以指向一些报告（经理喜欢报告）并说“看，这就是为什么”？

想象一下，您正在实现包含各种新功能并增加代码库复杂性的用户故事。现有代码已经很好地覆盖了，您刚刚决定了接口。您开始实现从测试开始的功能。

现在，您有基于需求的相当复杂的测试用例，但是当您能够提交 SCM 完全工作的代码并且许多测试失败（应该如此）时，实现还远远不够。

假设在持续集成中，如果可能，所有构建都应该是绿色的，因此您不应该提交，因为您会破坏构建。但是你也不应该“变暗”并为自己保留这么多的代码......

在这种情况下建议的程序是什么？

我知道有一些事情，比如进行手动检查，以确保提交的代码基本上是正确的。但除此之外呢？我问的原因是因为一个大项目每天都有很多提交。

一个初学者的问题，请耐心等待：我只是想知道在什么情况下应该使用像 nant 或 msbuild 这样的构建工具？我正在开发一个中型应用程序（.net 3.0），每个开发人员都在做他的工作，并在他的机器上构建，检查他的代码更改到存储库中。一旦我们都完成了，我将从存储库中获取所有代码，在我的机器上进行干净的构建，然后部署二进制文件。只是出于好奇，构建工具在哪里？

You must have heard the archetypical story of a failing/failed project:

1. A team of inexperienced programmers work 24x7
2. Bugs are fixed only to introduce new bugs
3. Customer is screaming that he could not even do the basic stuff (Saving/Querying) etc.
4. Programmers used to having the spec handed down struggle to improvise
5. No automated unit tests aggravate the situation
6. Architecture document that looked nice on paper was not followed in practice
7. Third party components used become bottlenecks not having been tested for fitness in the first place
8. Milestone after milestone missed
9. The team is not able to come up with a delivery date as nobody agrees as to the quantum of work actually needs to be done
10. No technical leadership / or a Cowboy Coder that can take on the technical issues

Now, If you were to be brought in as #10 what would be your first steps?

Update: First of all: Thanks to you all for chipping in. Well... I'm being brought in as #10. I was the original Architect anchoring the solution when we made the proposal to the client. Then, unfortunately, I couldn't take on the delivery responsibilities as I was assigned somewhere else. :)

Let's say it's a webification of an existing desktop application. I'm now being brought in as #10. Running away, sadly, is not an option. I'm sure this can still be reversed by following agile best practices and just wanted to tap the community for ideas.

The larger question perhaps is this: If the development team does not have specs but only the (baselined) code for a running application, the original solution called for looking at the code and extracting business rules on the fly. Now, the inexperienced programmers are reluctant to look at VB 6.0 code and want documents! So how do you fight this if you were to instate Agile processes?

我过去使用持续集成服务器取得了巨大成功，并且不需要在源代码控制系统上执行代码冻结。

然而，最近似乎在我所见的任何地方，大多数商店在准备发布时使用代码冻结的概念，甚至是他们产品的新测试版本。这个想法甚至在我当前的项目中运行。

当您提前且经常签入，并使用单元测试、集成测试、验收测试等时，是否还需要冻结代码？

在使用 ASP.NET 开发 Web 应用程序时，您是否有任何关于如何将内容/功能的开发与设计分开，从而使两者可以分别并行开发的提示？

情况是：

• 客户已就他们想要的功能达成一致
• 客户正在改变他们对页面外观（样式和布局）的看法
• 网页设计师不是专家：
  • 不是从头开始开发干净的基于 CSS 的布局
  • 正在从 3rd 方站点获取各种基于表格的布局（使用 CSS），用作布局的示例/原型以与客户讨论

鉴于此，如何在基于表格的布局最终确定之前开始编码功能？

我认为一种方法可能是：

• 编码功能（包括在每个页面上创建活动元素）而不关心（指定）它们的布局和样式
• 然后，最后，在设计师和客户就设计达成一致后，将活动元素剪切并粘贴到设计师的原型页面中。

这是唯一的还是最好的方法？还有哪些其他方法？有任何提示、提示或技巧可以使这更容易吗？

我希望对此进行一些健康的讨论，而不是specific解决方案，因此我将在社区 Wiki 上讨论它，因为它是一个相当主观的话题。感谢它是否可以作为有用的资源保持开放。

最近，我接任了一个小型技术团队的开发经理。

业务/营销/设计团队与技术团队的比例大约为 4:1，因此您可以想象，尝试将技术团队与一连串的需求隔离开来需要做很多工作。

为此，我们制定了一些适当的流程，使用 SCRUM 进行项目开发，要求业务团队成员填写适当的需求文档、用例等......

在我们第一个主要版本发布后的几周内，我们将向业务团队介绍正确的 UAT 流程、问题报告和变更请求流程以及我们自己改进我们的问题分类和错误修复程序。但正如您可以想象的那样，对于所有相关人员来说，这是一个非常陡峭的学习曲线和思维方式的转变。

只是从技术社区（开发人员、团队领导和开发经理）那里寻找一些一般性的反馈，他们经历过类似的事情以及他们如何处理任何特定的障碍。

我在一家很小的初创公司工作，我们开始使用 Scrum/Agile 开发周期的一种形式。

在很多方面我都喜欢 Scrum。我们的冲刺相对较短（2 周），我喜欢用燃尽图来跟踪团队的进度。我也喜欢功能板，所以我总是知道下一步我应该做什么。从板上取下功能的卡片，完成它然后将其放入烧毁堆中感觉很好。

然而，我们现在进入了第 18 个 Sprint 发布周期，我开始感到有些疲惫。并不是我不喜欢工作或我的同事，只是这些冲刺是……嗯，冲刺。从头到尾，我真的觉得我在与时间赛跑以保持我们的开发速度。当我们完成 sprint 后，我​​们会花一天时间计划下一个 sprint 的功能集和估计，然后再继续。

对于在成熟的敏捷/Scrum 开发过程中工作的人来说，这正常吗？还是我们错过了什么？在未分配/未跟踪的 Scrum 环境中，通常是否有时间来完成一些小事情并让你头脑清醒？