问题标签 [development-process]

这是一篇关于使用眼动追踪软件生成“热图”的有趣文章，显示用户大部分时间在屏幕上的位置。

任何关于这样做的好包的线索，而不是花钱请人进来为你进行评估？

http://www.useit.com/eyetracking

作为软件行业的新手，我遇到了一个关于截止日期执行的问题：

回到学术界的田园诗般的时代，截止日期是学期末，惩罚是明确定义的“F”（或当地同等学历）。在现实世界中，我们需要编写我们当前和未来的同行可以使用的代码，我面临截止日期到来，截止日期过去，项目仍未完成的情况。

怎么办？在一个极端，我们可以解雇所有相关人员，另一方面，我们可以丰厚奖励所有相关人员。

1. 您看到哪些操作被用作错过最后期限的“惩罚”，哪些操作最终会产生更好的代码？

2. 哪些项目管理响应导致项目彻底失败，

3. 哪些响应恢复了工作秩序并导致之后可以维护的代码？

4. 哪些响应导致更糟糕的代码？

诸如“将服务器从 v1 升级到 v2”或“提高启动性能”或“重构登录模块以降低代码复杂性”之类的技术项目是否应该进入产品 backlog，如果是这样，非技术产品所有者应该如何确定它们的优先级与其他功能更强大的积压项目相比？

是否应该有单独的技术资料积压？我们是否应该与两个可以在产品待办列表中优先考虑功能和技术内容的人共同担任 PO 角色？

今天在大学里我们有一个 Scrum 练习练习（模拟创建软件解决方案的整个过程），我想出了一个不太理解的问题。

假设我们已经定义了我们的故事并给它们一个适当的优先级。还有一个故事没有什么优先级……也许会在最后的冲刺中完成。

问题是，如果这个故事给我们的解决方案设计带来了巨大的架构变化怎么办？例如，从独立应用程序中，您将不得不选择客户端-服务器架构，仅因为这个故事。

在我看来：以某种方式标记哪些故事肯定会完成（在某个特定的时间），那些是关键的要完成的故事不是很自然，但它并不重要，所以团队有他们牢记并做出更好的决定来设计他的解决方案。或者你是如何处理这个问题的？如果有问题。

提前致谢！请原谅我可能很蹩脚的问题。

我们有一个大型企业应用程序，其中项目的范围设计并最终使用正式的瀑布流程进行编码。仅仅因为它们在同一段代码中，我经常会为不相关的计划进行代码更改。所有倡议必须同时上交。开发团队对范围或交付时间线也几乎没有发言权。我们无法与用户交谈，我们必须通过一组不了解业务的需求收集。

有没有人对如何在这样一个根深蒂固的环境中实施即使是最小的敏捷技术有任何建议。

我正在为大约 15 名员工的团队寻找应用程序生命周期管理工具。它应该提供以下功能：

一般的

• 多用户网络系统
• 每个用户的仪表板
• 应该适合Scrum
• 多个项目

问题跟踪器

• 分离错误、增强功能和新功能
• 问题应具有：类别、严重性、状态、描述、文件附件、受让人、预计时间、所需时间、进度
• 问题之间的依赖关系
• 按优先顺序排列
• 问题和项目的层级结构，累积的关键绩效指标取决于层级（例如子项目的进度）

产品/发布管理

• 可能这可以简单地视为一个项目

资源

• 具有访问控制的用户管理
• 每位员工的工作时间，假期
• 每位员工的时薪

测试管理

• 创建测试用例
• 跟踪测试结果（手动测试）

报告

• 概述所有项目的进度和成本等。
• 资源监控

更换管理层

有什么建议吗？

好吧，我知道 UML 图有助于构建程序，但是什么时候使用它们呢？在开始编码之前需要它们吗？你需要它们，所以你知道你必须编码什么吗？还是在编写程序后使用它们？

Team Foundation Server 2008 允许每个签入都与一个工作项相关联，但是如果您正在开发一些跨越多个团队项目的功能，您会怎么做？

例如，您正在为客户开发特定产品，并且该产品有其自己的团队项目，但也使用您在另一个团队项目中独立维护的一些其他组件或工具。

您在哪里为涉及两个项目更改的需求创建工作项？

1. 分开，每个工作项在其自己的团队项目中
2. 客户团队项目中的所有工作项，无论关联的源代码如何

后者似乎更易于维护和控制，但它涉及将一个团队项目的签到与另一个团队项目中的工作项相关联。

我在哪里可以找到有关如何使用错误、风险、场景、任务和服务质量要求工作项的实际示例？

在 MSDN 文档中，我发现了这个主题： http: //msdn.microsoft.com/en-us/library/bb668962.aspx，但我还不足以深入了解何时使用其中一个。

谢谢！

我们团队中的一位程序员正前往更绿色的牧场。我们将从 6 到 5。我们应该采取哪些步骤来确保我们的开发过程继续顺利进行，可能同时融入新的血液。

我们目前正在通过迭代开发进行较短的发布周期。设计 - 代码 - 审查。离开的人是团队中最资深的开发人员，并且经常会向团队的其他成员提供大量反馈，尤其是在设计阶段。