Scrum 对理念进行某些修改后的可行性
我希望回答这个问题的人能够说明他们是否有在敏捷环境中开发的经验，或者他们是否是从理论角度发言。
背景故事：
假设有一家机会主义公司开发技术创新产品（多点触控界面、语音识别设备等），所有这些产品根本上是不相关的。然而，正如人们所看到的，开发此类产品的关键优势在于可以从产品中创建/提取库并将其出售给其他公司、开发人员等。因此，以增量方式工作是有利的，因为它允许里程碑与最终产品分开。
问题1：从商业角度来看这是否有利？你们中有人遇到过将库分离为公司内的单独产品的情况吗？
问题2：如果产品确实以这种增量方式创建，那么 Scrum 似乎是一种有效的方法论？
让我们假设创建组件以拼凑成最终应用程序的增量过程已就位。开发团队最初很小，只有六七个人。为了好玩，我们将这个团队称为“公会”。公司刚刚起步，他们需要盈利。为了便于讨论，假设 Guild 开发了 FaceAPI 库。所有这些都是在 Scrum 方法中完成的，比方说在一次冲刺中。现在，该公司有足够的资金再雇用 7 名员工。这7个人被放入了自己的公会，他们的技能与原来的公会的技能相同。
现在，该公司有 2 个公会和 1 个库可供开发。假设一个 Guild 的任务是使用原始库创建 Product1，而另一个 Guild 的任务是使用更多功能扩展库。这两个“冲刺”将同时进行，最后更新的库将合并到应用程序中。正如您所看到的，处理 Product1 的团队可能需要对库进行一些修改，在这种情况下，合并将非常重要。
无论如何，这是总体思路。公司会有单独的公会，或者团队（问题3：你觉得这个想法怎么样？由于团队规模较小，他们会希望聘用具有良好协同作用的成员。这是否有可能提高整体士气和生产力？），这将同时进行冲刺。由于公司提供的服务的性质，团队将使用或多或少相同的组件和应用程序的一部分，但是可以创建他们的冲刺，以便团队始终可以无障碍地开展工作。每个公会都是一个自我封闭的单位，有测试人员、设计师和质量保证人员。
最终问题：
- 作为开发人员或测试人员，什么是 您对一家公司的看法 以这种方式发挥作用？是吗 培养领导技能 开发商？听起来很吸引人吗？ 听起来是不是注定会失败？
- 任何有知识或经验的人 对于 Scrum，它似乎适用吗 自然地在这种 环境？
- 有没有人工作过 一家功能类似的公司 上面的描述？如果你不这样做 介意回答一下，那叫什么？ 成功了吗？
I would prefer if those who answer this question state whether or not they have experience developing in an Agile Environment or if they are speaking from a theoretical standpoint.
Backstory:
Let's say there is an opportunistic company that develops technologically innovative products (multi-touch interfaces, speech recognition devices, etc, etc) all of which are fundamentally unrelated. However, as one may see, the key advantage of working on products like these are that libraries can be created / extracted from the product and sold to other companies, developers, etc. Thus, working in an incremental fashion is advantageous as it allows the milestones to be separated from the final product.
Question1 : Is this advantageous from a business standpoint? Have any of you encountered the separating of libraries into individual products within your company?
Question2 : If products are indeed created in such an incremental manner, does Scrum seem like a valid methodology to apply?
Let's assume that this incremental process of creating components to piece together into a final application is set in place. The development team is initially very small, 6 or 7 people. For the fun of it, let's call this team a Guild. The company is just starting out, and they need to make something profitable. For argument's sake, let's say the Guild developed the FaceAPI Library. All of this was done within the Scrum methodology, let's say in one sprint. Now, the company has enough funding to employ 7 more people. These new 7 people are put into their own Guild, and their skills mirror the skills of the original Guild.
So now, this company has 2 Guilds, and 1 library off which to develop. Let's say that the one Guild is tasked with creating Product1 using the original library, and the other Guild is tasked with extending the library with more features. These two "sprints" would be carried out concurrently, and at the end the updated library would be merged into the application. As you can see, it is possible that some modifications might need to be made to the library by the team working on Product1, in which case the merge will be non-trivial.
In any case, this is the general idea. The company would have individual Guilds, or teams of people (Question 3: What do you think of this idea? Since teams are smaller, they would want to hire members that have good synergy. Is this likely to increase overall morale and productivity?), which would carry out sprints concurrently. Because of the nature of the service the company offers, the teams would work with more or less the same components, and parts of the applications, however their sprints could be created so that the teams could always carry out work without impediments. Each Guild would be a self-enclosed unit, having testers, designers, and QA's.
Final Questions:
- As developers or testers, what are
your opinions on a company that
functions in this manner? Does it
foster leadership skills in
developers? Does it sound appealing?
Does it sound destined to fail? - Anyone with knowledge or experience
with Scrum, does it seem to apply
naturally in this kind of
environment? - Has anyone worked for
a company that functions similarly to
the above description? If you don't
mind answering, what was it called?
Was it successful?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
首先，到目前为止我已经参与了 3 个或多或少的 Scrum 项目。
你的故事中有一些不清楚的地方。公司的目标是什么——开发库还是最终产品？对我来说，这两者似乎相当矛盾，尤其是对于一家小公司而言。
另一件事是，在没有任何真正用户的情况下从库本身开始开发对我来说听起来不太敏捷。在我看来，敏捷设置将以相反的方式开始：首先开发一个具体的产品，根据具体情况重构设计，可能达到某种分层架构，其中较低层可以提取到一个可重用的库。然后开始开发更具体的产品，寻找在项目之间重用代码的可能性，并改进公共库的设计——同样，根据客户（产品开发团队）的具体使用和需求所决定。
在某些时候，库开发可能需要自己的团队 - 一开始，在不同团队之间协调其设计和积压工作可能就足够了。
To start with, I have been working on 3 more or less Scrum projects so far.
There are a couple of unclear things in your story. What is the company aiming for - developing libraries or final products? To me the two seems fairly conflicting, especially for a small company.
Another thing is, starting development with a library itself without any real users doesn't sound very agile to me. IMO an agile setup would start the other way around: develop a concrete product first, refactoring the design as dictated by the concrete situation, to possibly arrive to some sort of layered architecture, in which the lower layer(s) could be extracted into a reusable library. Then start developing more concrete products, looking for possibilities to reuse code between the projects, and evolving the design of the common library - again, as dictated by the concrete usage and needs of its clients (the product development teams).
At some point, library development would probably require its own team - in the beginning, it might suffice to have its design and its backlog coordinated between the different teams.
关于您关于团队互相踩踏代码的问题 - 这就是源代码控制的用途。分叉新东西，然后在下一个冲刺中重新整合并稳定下来。
关于 q2，scrum 是一种增量方法，因此如果设计适合增量工作部分，那么它当然是合适的。
关于第三个问题，雇用“能够在他们内部很好地工作并且他们愿意与之合作的人”怎么可能是一件坏事呢？
Regarding your question about teams treading on each other's code - this is what source control is for. Fork for the new stuff, then in the next sprint reintegrate and stabilise.
Regarding q2, scrum is an incremental approach so if the design lends itself to incremental segments of work then of course it's appropriate.
Regarding q3, how could it ever be a bad thing to hire "people that would work well within them and that they would want to work with"?
团队组织和体系结构具有很强的依赖性。 请参阅康威定律
这意味着您可以让两个独立的团队处理两个独立的代码模块（库团队和产品团队），您需要在团队之间有一个明确定义的沟通渠道，因此，开发的代码将在设计中反映这些渠道。传统上，这意味着您最终为库定义一个 API 或接口，它就像每个团队可以开发的合同一样。敏捷实践通常采用更紧急的设计理念，因此很难创建有意义的 API。
大多数敏捷团队解决这个问题的方法是将开发时间限制为可管理的增量。因此，虽然设计整个 API 可能不现实，但产品团队和库团队可能会在 2 周的工作时间内就 API 设计达成一致。编写代码、部署、设计下一次迭代，然后重复。通过这种方式，建立了团队和代码模块之间的通信路径，因此两个团队可以独立工作，而不会互相干扰。
我最近看到的另一个选择是使用看板/有限 WIP 流程来管理更大的团队。让每个人都在同一个团队中并由看板管理，可以实现更有机、更灵活的自组织，这意味着您的系统将能够更轻松地发展。通过保持正在进行的工作高度可见，可以增加沟通；通过限制正在进行的工作，可以防止系统在任何一个方向发展得太远，从而限制开发人员互相破坏。结合可靠的 VCS，您应该可以顺利使用了。
最后，另一种选择是在投入开发之前花一些时间来真正考虑您的架构。在有限的“范围内使用软件架构设计流程，例如以架构为中心的设计方法 (ACDM)” “spike 0”类型的角色可以帮助您解决允许紧急设计时常见的许多问题。在设计冲刺结束时，您将能够制定一个对您需要做的事情更有意义的计划。请记住，仅仅因为这是一个设计阶段并不意味着您不编写代码 - 恰恰相反。 ACDM 强烈提倡实验。
Team organization and system structure are highly dependent. See Conway's Law
This means that for you to have two separate teams working on two separate code modules (the Library team and the product team) you will need to have a clearly defined communication channel between the teams and thus, the code developed will reflect those channels in the design. Traditionally what this means is you end up defining an API or interface for the library which acts like a contract to which each team can develop. Agile practices normally adopt a more emergent design philosophy so it can be difficult to create an API that makes sense.
The way most agile teams get around this is by time boxing development to manageable increments. So while it might be unrealistic to design the entire API, the product team and library team could probably agree on an API design enough for 2 weeks of work. Write the code, deploy, design for the next iteration, and repeat. This way communication paths between the teams and code modules are established so the two teams can work independently without stepping on one another's toes.
Another option I've seen used recently is to have larger teams managed with a Kanban/Limited WIP process. Having everyone on the same team managed by a Kanban allows for more organic and flexible self-organization which means your system will be able to evolve more easily. By keeping work-in-progress highly visible it increases communication and by limiting work-in-progress you constrain developers from clobbering each other by keeping the system from evolving too far in any one direction. Combined with a solid VCS you should be good to go.
Finally, another option is that you take some time to really think about your architecture before diving into development. Using a software architecture design process such as the Architecture Centric Design Methodology (ACDM) in a limited "spike 0" kind of role could help you resolve many of the issues commonly encountered when allowing emergent design. By the end of the design sprint, you'll be able to lay out a plan that makes much more sense for what you need to do. And remember, just because it's a design phase doesn't mean you don't write code - quite the opposite. ACDM advocates strongly for experimentation.