scrum - 对哲学进行某些修改的 Scrum 的可行性

Question

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center 指导。




9年前关闭。




我更希望回答这个问题的人陈述他们是否有在敏捷环境中开发的经验，或者他们是否从理论的角度说话。

背景故事:

假设有一家机会主义公司开发技术创新产品(多点触控界面、语音识别设备等)，所有这些产品根本不相关。然而，正如人们所看到的，在这些产品上工作的主要优势是可以从产品中创建/提取库并将其出售给其他公司、开发人员等。因此，以增量方式工作是有利的，因为它允许里程碑与最终产品分开。

问题 1:从商业角度来看，这是否有利？你们中的任何人是否遇到过将库分离为贵公司内的单个产品的情况？

问题 2:如果产品确实是以这种增量方式创建的，那么 Scrum 看起来是一种有效的应用方法吗？

让我们假设这个创建组件以拼凑成最终应用程序的增量过程已经准备就绪。开发团队最初很小，只有 6 或 7 人。为了好玩，让我们称这个团队为公会。公司刚刚起步，他们需要做一些有利可图的事情。为了论证起见，假设公会开发了 FaceAPI Library 。所有这些都是在 Scrum 方法中完成的，比如说在一个 sprint 中。现在，该公司有足够的资金再雇佣 7 名员工。这7人新加入了自己的公会，技能和原公会的技能一模一样。

所以现在，这家公司有 2 个公会和 1 个要开发的库。假设一个 Guild 的任务是使用原始库创建 Product1，另一个 Guild 的任务是使用更多功能扩展库。这两个“冲刺”将同时进行，最后更新的库将合并到应用程序中。如您所见，在 Product1 上工作的团队可能需要对库进行一些修改，在这种情况下，合并将非常重要。

无论如何，这是一般的想法。公司会有单独的公会或团队( 问题3:您如何看待这个想法？由于团队较小，他们会希望雇用具有良好协同作用的成员。这是否可能提高整体士气和生产力？ )，它将同时执行冲刺。由于公司提供的服务的性质，团队将使用或多或少相同的组件和应用程序的一部分，但是可以创建他们的冲刺，以便团队始终可以无障碍地开展工作。每个公会都是一个独立的单元，有测试员、设计师和 QA。

最后的问题:

作为开发人员或测试人员，什么是
你对一家公司的看法
以这种方式运行？可以
培养领导技能
开发商？听起来是不是很吸引人？
听起来注定要失败吗？

任何有知识或经验的人
使用 Scrum，它似乎适用
自然在这种
环境？

有没有人工作过
一家功能类似的公司
上面的描述？如果你不
回答一下，叫什么名字？
成功了吗？

最佳答案

首先，到目前为止，我一直在从事 3 个或多或少的 Scrum 项目。

你的故事中有一些不清楚的事情。公司的目标是什么 - 开发库还是最终产品？对我来说，这两者似乎相当矛盾，尤其是对于一家小公司。

另一件事是，在没有任何真正用户的情况下从库本身开始开发对我来说听起来不太灵活。 IMO 敏捷设置将从相反的方式开始:首先开发具体产品，根据具体情况重构设计，可能达到某种分层架构，其中较低的层可以被提取到可重用的库。然后开始开发更具体的产品，寻找在项目之间重用代码的可能性，并演变公共(public)库的设计——同样，根据其客户(产品开发团队)的具体使用和需求。

在某些时候，库开发可能需要自己的团队——一开始，在不同团队之间协调其设计和待办事项可能就足够了。

关于scrum - 对哲学进行某些修改的 Scrum 的可行性，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/3094679/

上一篇：vm-implementation - Parrot VM 对最终用户有什么好处？

下一篇：perl - 如何使用 Tcl 和 TclApp 为 Win32 编写 COM EXE？

相关文章：

agile - 共享代码和界面有哪些社交和技术解决方案？

project-management - 如何管理单人项目的流程

scrum - Scrum适​​合小型组织吗？

debugging - Scrum，如何处理冲刺中的错误以及如何估计错误的时间

tfs - 将字段添加到 TFS 中的工作项会导致权限错误

jira - 在 JIRA 中分离 Sprint 和 Release

tfs - 何时根据功能请求创建 PBI，以及在何处划分它们的界线？

jira - 您如何在Jira/GreenHopper中创建用户案例和任务？

architecture - 在敏捷开发中，您如何处理 "less-well-architected"代码，这些代码源于以 sprint 为中心的心态

Answer 1

首先，到目前为止，我一直在从事 3 个或多或少的 Scrum 项目。

你的故事中有一些不清楚的事情。公司的目标是什么 - 开发库还是最终产品？对我来说，这两者似乎相当矛盾，尤其是对于一家小公司。

另一件事是，在没有任何真正用户的情况下从库本身开始开发对我来说听起来不太灵活。 IMO 敏捷设置将从相反的方式开始:首先开发具体产品，根据具体情况重构设计，可能达到某种分层架构，其中较低的层可以被提取到可重用的库。然后开始开发更具体的产品，寻找在项目之间重用代码的可能性，并演变公共(public)库的设计——同样，根据其客户(产品开发团队)的具体使用和需求。

在某些时候，库开发可能需要自己的团队——一开始，在不同团队之间协调其设计和待办事项可能就足够了。