问题标签 [agile]

基本步骤是Agile software development什么？
以及如何使用敏捷方法开始一个新项目？

如果有人试图做敏捷，我正在想办法为此使用 JIRA / Greenhopper。我们是一个全球开发团队，因此分布式特性在这里至关重要。

我们最初使用 Scrumworks，但团队抱怨他们在 JIRA 和 scrumworks 中一直有重复的信息，并认为这是多余的。

我们得到了 Greenhopper，并认为这可以解决我们的问题，但我遇到的问题是：

1. JIRA 中没有用户故事概念
2. Greenhopper 过于专注于“任务”而没有在用户故事级别进行聚合。

有没有人在 JIRA 中成功地做到了这一点，或者我们是否应该考虑回到其他工具，如 scrumworks，只使用 JIRA 来解决我们支持团队提出的错误。

我正在为我朋友的业务编写一个小应用程序，并想借此机会复习我在年初进行的一些敏捷项目管理培训。

我（我认为，我现在的组织！）一直在努力以用户故事的形式收集需求，其形式如下：

作为 [用户类型] 我想要 [功能] 以便 [一些好处]

我总是很想错过开始和结束，然后离开这个功能——但这只是变成了收集旧方法的需求！

但我不想让它适合，这样我就可以说“我正在做敏捷”......例如，如果我知道要向用户展示一个项目列表，那么原因不言而喻，不是吗？

例如

作为[商店经理]，我想[查看库存商品列表]，以便...？

省略 [so that] 子句是正常的做法吗？

我是一名刚毕业的大学毕业生，为一家劳动力老龄化的大公司工作。我很好奇人们在处理年龄差距方面的经验，最好是双方。

到目前为止我遇到的示例问题：

• 敏捷实践与瀑布
• 程序员与个性之间的协作
• 早起工作VS深夜工作

我在学校学习的主要是敏捷编程，而我正在从事的项目（大多数开发人员都习惯了瀑布）

我习惯于在项目上与同学和朋友合作，而我倾向于看到年长的程序员喜欢做自己的事情。我觉得我缠着他们问他们问题。

我发现自己更像是一个夜间程序员，但我的大多数年长同事都是清晨（凌晨 5 点）

任何关于技术工作年龄差距的经验都是相关的。

当其中一名参与者在印度（+05:30）而其他人在美国（-06:00 和 -08:00）时，尝试组建 scrum 是否明智？每个人都没有一个舒适的会议时间。

假设我们正在创建 Acme CMS。此 CMS Web 应用程序将允许您创建无限数量的具有子类别（无限深度）的类别，并且每个类别可以有 0+ 个与之关联的内容页面。

所以这个项目，在高层次上将有：

前端 1. 索引页面 2. 带有内容页面列表的类别页面 3. 内容页面

管理控制面板 1. 类别（添加/更新/删除） 2. 页面（添加/更新/删除/）

架构设计 1. 表 2. 存储过程 3. 数据访问层

问题：我正在使用错误跟踪器和 Wiki，那么我应该如何分解这个项目？

我正在考虑将每个部分（前端/管理面板）分解为单独的页面，然后为每个页面（或主题）编写简单的用户故事。

当我完成用户故事后，我将在我的错误跟踪器中创建一个案例列表，代表我必须开发的功能，以及对每个案例的估计。

我是否正确地分解了这个项目？计划中的任何重大差距都会导致该项目失败（理论上无论如何！）

请提供详细的答案，也许是我应该做什么的大致想法，并附有详细的示例来解释它以及原因等。

目前，我们在数据访问对象和大量存储过程和触发器中使用手动 SQL，总计大约 20k 行代码。我们发现，简单的更改会导致几天的工作得以修复，并导致最后期限的推迟。

更改包括修改表以处理额外的数据、基于 QA/用户报告的架构的一般重构等。它是一个非常活跃的系统，正在构建以替换旧的和缓慢的东西。

我们查看了可用的 PHP ORM 解决方案来尝试限制这些更改的影响，但是它们太慢了，无法应对我们的模式；“简单” sql 结果的返回时间比我们的自定义查询要长几个数量级，并导致约 0.5 秒的页面浏览量超过 20 秒。

在一般情况下，我可以研究哪些最佳实践/策略来应对关系数据库的模式演变？

编辑：忘了提及触发器；我们有很多依赖于级联变化的数据，例如。此用户的价格更改会更新该用户的价格等。

我所在的团队在我们的开发过程中使用 scrum。我们目前正在尝试改进我们流程的某些方面，以解决我们最近注意到的一些问题。在这样做的过程中，我们正在探索我们对 Scrum 流程的总体喜欢和不喜欢的地方，以帮助我们确定我们作为一个团队在工作中的价值观。我们认为，如果我们能够确定我们重视什么，那么我们就可以提出围绕这些价值观的实施，以帮助新的解决方案在团队中坚持下去。

话虽如此，我真的很感兴趣其他人如何看待 Scrum 过程。你真正喜欢它的哪一点？什么是令人沮丧的，感觉开销太大或没有生产力？成功和失败的具体例子很好，但我感兴趣的是一个更大的观点，讨论围绕 scrum 的陷阱或 scrum 真正闪耀的地方。

想法？

我签了一份新合同，他们似乎在敏捷方面做得过火了，包括聘请顾问仅仅是为了促进敏捷流程。他正在制定的东西是“核心时间”的概念，我们实际上将一起在同一个房间里。这真的是“核心时间”构成的吗？我问是因为拿起我的笔记本电脑去这个共享位置半天非常不方便；我一直认为“核心时间”意味着你有空，不一定在同一个房间，例如从 9:30 到 4。

我正在启动一个个人项目来开发一些开源软件。我想使用 Scrum 作为 PM 流程（因为我喜欢 Product Backlog、优先级排序，如果我能得到它们，那就是燃尽图），但在我看来，我无法获得全部价值，因为我不能一开始要保证我和我的合作者在给定的冲刺期间能够投入工作的时间。

我知道我仍然可以从使用 Scrum 中获得其他好处，但是是否有我不知道的变化或技巧和技术可以让我获得诸如燃尽图和时间盒迭代之类的东西的价值？还是我太有希望了？

TIA。

注册，安德鲁