The Team builds the product that the customer is going to use: the
application or website, for example. The team in Scrum is
“cross-functional” – it includes all the expertise necessary to deliver
the potentially shippable product each Sprint – and it is
“self-organizing” (self-managing), with a very high degree of autonomy
and accountability. In Scrum, teams are self-organizing rather than
being led by a team manager or project manager. The team decides what to
commit to, and how best to accomplish that commitment; in Scrum lore,
the team are known as “Pigs” and everyone else in the organization are
“Chickens” (which comes from a joke about a pig and a chicken deciding
to open a restaurant called “Ham and Eggs,” and the pig having second
thoughts because “he would be truly committed, but the chicken would
only be involved”).
The team in Scrum is seven plus or minus two people, and for a software product the team might include analysts, developers, interface designers, and testers. The team develops the product and provides ideas to the Product Owner about how to make the product great. In
Scrum, the team should be 100 percent dedicated to the work for one product during the Sprint; avoid multitasking across multiple products or projects. Stable teams are associated with higher productivity, so avoid changing team members. Application groups with many people are organized into multiple Scrum teams, each focused on different features for the product, with close coordination of their efforts. Since one team does all the work (planning, analysis, programming, and test) for a complete customer-centric feature, Scrum teams are also known as feature teams.
In Scrum, there are three primary roles: The Product Owner, The Team, and The ScrumMaster.
FT 对于增加响应速度的比如，构建在全职能带给的关系费用的减退上，赋权带动的裁断瓶颈的减少上，静心带来的无谓等待的幸免上，并不直接建构在反映关系上。 假诺您的团伙，赋权必要依附陈说关系来达成，那就足以设计对应的反馈关系。
The Product Owner is responsible for maximizing return on investment (ROI) by identifying product features, translating these into a prioritized feature list, deciding which should be at the top of the list for the next Sprint, and continually re-prioritizing and refining the list.
The Product Owner has profit and loss responsibility for the product, assuming it is a commercial product. In the case of an internal application, the Product Owner is not responsible for ROI in the sense of a commercial product (that will generate revenue), but they are still responsible for maximizing ROI in the sense of choosing – each Sprint – the highest-business-value lowest-cost items. In some cases, the Product Owner and the customer are the same person; this is common for internal applications. In others, the customer might bemillions of people with a variety of needs, in which case the Product Owner role is similar to the Product Manager or Product Marketing Manager position in many product organizations. However, the Product Owner is somewhat different than a traditional Product Manager because they actively and frequently interact with the team, personally offering the priorities and reviewing the results each two- or four-week iteration, rather than delegating development decisions to a project manager. It is important to note that in Scrum there is one and only one person who serves as – and has the final authority of – Product Owner.
The ScrumMaster helps the product group learn and apply Scrum to
achieve business value.
The ScrumMaster does whatever is in their power to help the team be successful. The ScrumMaster is not the manager of the team or a project manager; instead, the ScrumMaster serves the team, protects them from outside interference, and educates and guides the Product Owner and the team in the skillful use of Scrum. The ScrumMaster makes sure everyone on the team (including the Product Owner, and those in management) understands and follows the practices of Scrum, and they help lead the organization through the often difficult change required to achieve success with agile development. Since Scrum makes visible many impediments and threats to the team’s and Product Owner’s effectiveness, it is important to have an engaged ScrumMaster working energetically to help resolve those issues, or the team or Product Owner will find it difficult to succeed. Scrum teams should have a dedicated full-time ScrumMaster, although a smaller team might have a team member play this role (carrying a lighter load of regular work when they do so). Great ScrumMasters can come from any background or discipline: Engineering, Design, Testing, Product Management, Project Management, or Quality Management. The ScrumMaster and the Product Owner cannot be the same individual; at times, the ScrumMaster may be called upon to push back on the Product Owner (for example, if they try to introduce new deliverables in the middle of a Sprint). And unlike a project manager, the ScrumMaster does not tell people what to do or assign tasks – they facilitate the process, supporting the team as it organizes and manages itself. If the ScrumMaster was previously in a position managing the team, they will need to significantly change their mindset and style of interaction for the team to be successful with Scrum. In the case that an ex-manager transitions to the role of ScrumMaster, it is best to serve a team other than the one that previously reported to the manager, otherwise the social or power dynamics are in potential conflict.
Feature teams have been around in large products for a long time, for example, within telecom systems (Ericsson) and compiler development (Microsoft). They always emerged together with daily builds because frequent builds with automated testing is a key enabler for getting feature teams to work well. With the introduction of agile development (and Scrum specifically) feature teams have gained in popularity because they focus more on end-customer requirements and shorter cycle times.
A feature team is “is a long-lived, cross-functional, cross-component team that completes many end-to-end customer features—one by one.” Feature teams are an essential element to scaling up agile development. Without a feature team structure (but instead, a component team organization—based on code ownership, combined with a single-function organization—analyst group, programmer group, testing group, ...) your organization is likely to create numerous wastes and sub-optimizations that lead to a sequential (waterfall, ...) development cycle. Feature teams structure resolves many of these wastes but also introduces change and challenges.
互连网公司与历史观行业公司都以在建筑软件系统， 而升高级程序员程能效都以遥远指标。任何行当都急需快捷响应变化。营造Feature Team, 组织与学识变革会是越来越大的挑衅，进步联系效用，在同生龙活虎的观念意识下统一目的，高效同盟，从上到下都具备便捷学习技艺，那样的协会在几天前市集下才有角逐性。
后天先到此时,希望对您在协会管理, 项目管理,产物管理 有参谋意义 ,
如有想领悟越来越多软件设计与布局, 系统IT,公司新闻化, 团队保管 资源音讯，请关怀自己的Wechat订阅号：
该小说也还要发布在本身的独自博客中-Petter Liu Blog。