敏捷（Scrum）的采用-情况如何？ [英] Agile (Scrum) adoption - how did it go?
问题描述
对于那些在组织中实施Scrum的人来说，最大的障碍是什么，如果克服了这些障碍，怎么办？
背景：2006年，我与一家大公司签约，该公司在我到达前几个月就采用了Scrum冷火鸡。该公司希望Agile / Scrum可以保存他们庞大的企业软件产品。在那里的数百名或更多程序员中，我与一支大约十二名的团队密切合作，观察并参与了他们的敏捷实验。
摘要：我相信敏捷的帮助远不止于此。到今年年底，该团队可以持续估算和生产特征，而以前他们的生产力相当不稳定。
实施：自此以来是一个大型组织和大型产品，该项目以混乱的混乱的形式运行。大约每15-20个开发人员就有一个Scrum管理员，这些团队通常被分成规模较小，工作紧密的Scrum，大约6-8个人进行迭代。团队在很大程度上是独立的，可以调整自己的迭代频率（从1个月降低到1周），并拥有最大的灵活性来实施他们认为最好的敏捷。该公司定期引进敏捷教练（例如Object Mentor）来帮助培训Scrum管理员，团队和管理人员。
障碍物：大量。其中有些与敏捷有关，有些与敏捷无关。
产品积压订单一开始就被频繁地修改。最终，团队和管理层花了几天的时间来研究所有功能，进行估计并确定优先级。这是一个很大的成功，但是却大有帮助。获得的经验教训：及早订购您的产品积压并保持维护。产品负责人必须对自己想要的东西有个清晰的认识。
我们浪费了时间进行尝试以及与时尚和炒作打交道。开始时，您将无法知道自己做的是否正确。总是不断地在敏捷过程中摆弄一些诱惑，以将注意力从产品上移开。获得的经验：拥有经验丰富的敏捷教练确实有助于减少这种学习曲线。总是应该有人阻止任何实验。限制峰值的数量。
一个好的Scrum管理员是非常宝贵的。当然，一开始它是一个全职职位。
这需要时间。团队花了几个月的时间才开始熟悉这个过程。
挑起战斗。可以理解，有些程序员会持怀疑态度，而另一些程序员会完全不喜欢并逃避更改。留出一定的灵活性。例如，强制使用产品积压和迭代计划，但不要求每个人都使用记录卡。对引入诸如配对编程或测试优先开发之类的工具和编程方法特别敏感。
最后，保持沟通畅通并管理期望。
祝你好运！
For those of you who have implemented Scrum in your organizations, what were your biggest obstacles and if you did overcome them, how?
Background: In 2006 I contracted with a large company which had adopted Scrum cold turkey just months before I arrived. The company hoped Agile/Scrum would save their huge enterprise software product. Of the hundred or more programmers there, I worked closely with a team of about a dozen for a year, observing and participating in their Agile experiment.
Summary: I believe Agile helped more than it hurt. By the end of the year, the team could consistently estimate and produce features, whereas previously their productivity was rather erratic.
Implementation: Since this was a large organization and a large product, the project ran as a "scrum of scrums." There was one scrum master for about every 15-20 developers and these teams were often divided into smaller, closely working scrums of about 6-8 people for an iteration. Teams were largely independent, could adjust their own iteration frequency (1 month down to 1 week) and were given lots of flexibility to implement agile as they saw best. The company regularly brought in Agile coaches (such as Object Mentor) to help train the scrum masters, teams, and management.
Obstacles: Plenty. Some of them related to Agile, some not. In no particular order, here are some lessons learned:
The product backlog was revised way too often in the beginning. Eventually, the team and management took several days to go over all the features, estimate them, and prioritize them. It was a big hit, but it helped tremendously. Lesson learned: get your product backlog in order early and keep it maintained. Product owners must have a clear idea of what they want.
We lost time experimenting and dealing with fads and hype. When you start, you have no way of knowing if you're doing things correctly. There's temptation to constantly fiddle with the agile process taking the focus away from the product. Lesson learned: having an experienced Agile coach does help reduce this learning curve. There should always be someone pushing back on any experimentation. Limit the number of "spikes".
A good scrum master is invaluable. Certainly in the beginning, it's a full-time position.
It takes time. It took several months before the team started to be comfortable with the process.
Pick your battles. Some programmers will be understandably skeptical and others will outright dislike and flight the change. Allow for some flexibility. For example, enforce the use of a product backlog and iteration schedule, but don't require everyone use note cards. Be particularly sensitive to introducing tools and programming methodologies such as pair programming or test first development.
Finally, keep communication open and manage expectations.
Good luck!
这篇关于敏捷（Scrum）的采用-情况如何？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
