* Scrum Master
* Product Owner
* Equipe
The people who fill these roles work together on a daily basis, to ensure the smooth flow of information and rapid adaptation to changes.
Scrum Master
The Scrum Master is the guardian of the process. He is responsible for making sure the process goes well by removing obstacles that hinder the team’s productivity by organizing meetings.
The Scrum Master responsibilities include:
• Remove the barriers between the team and Product Owne.
• Teach the PO how to maximize the return on investment (ROI) and meet their objectives through Scrum.
• Facilitate the work of the team by removing obstacles that prevent staff from working.
• Improve productivity of staff as soon as possible after an issuel.
• Improve the engineering practices and tools so each increment of functionality is potentially shippable.
• Keep the information about the team's progress visible to everyone in a clear and organized fashion.
In simple terms, the Scrum Master needs to understand Scrum concepts to train and mentor people in other roles, and to educate and help other stakeholders that are involved in the process. He must pay constant attention to the status of the project and compare it to the expected progress. He should investigate and facilitate the resolution of any issues that hold back progress, and generally be flexible enough to identify and deal with any problems that might arise. He must also protect the team from outside disturbances.
The Scrum Master does not assign tasks to team members, this is a team responsibility. His general approach is to encourage his staff and to facilitate the process of making decisions and solving problems related to development, so that they can work more efficiently without the need for supervision. His goal is to have a self-organized team.
Product Owner
The Product Owner owns the product. It provides the business knowledge in the form of different tasks required in order for the application to work as well as the order they should be done in. In practice, the Product Owner is the link between the company and customers.
He gives the team requirements and corrections requested by various sources. He is the point of contact for clarification of doubts about the team's product requirements.
He works in conjunction with the team defining user needs, technical requirements, documenting them as needed, and determining the order of their execution. He manages the product backlog (which is where of all this information is located), keeping it at the level of detail and quality that the team needs.
The Product Owner also defines the schedule for release of releases, and makes the final validation to see if the implementations have the features and quality necessary for release.
Development Team
The Development Team should be self-organized and multidisciplinary, composed of people who do the development work and product testing.
Once the team is responsible for product development, it must also have the autonomy to make decisions about how to perform their work. The team is self organized: Members decide how to divide the work into tasks, and along the sprint decides the execution order of tasks according to the story being developed, making certain stories a priority.
If possible, the team size should be kept to a maximum of nine people. A larger number can hamper communication and affect productivity.
Fonte: http://www.cprime.com/about/scrum_faq.html
Em um projeto SCRUM, como um profissional que tenha apenas habilidades de análise de REQUISITOS, atua estando em um time de desenvolvimento ? Uma vez que as necessidades do cliente são captadas pelo Dono do Produto e explicadas pelo mesmo…. Existe espaço dentro do SCUM para esse profissional exercer funções de análise REQUISITOS? Se sim, como seria? (se tiverem exemplos práticos eu agradeceria :))
Oi Felipe,
Boa pergunta. Em primeiro lugar, é bom lembrar que o Scrum é um framework. Ou seja, queremos dizer com isso que ele é flexível e sempre permite adaptações. Nesse caso, certamente você precisará adaptar. Existem algumas possibilidades. Uma seria esse Analista de Requisitos fazer parte do grupo do P.O., ou seja, colocá-lo para apoiar o P.O., ajudando-o a preparar as histórias. Outro caminho é colocá-lo trabalhando na especificação das histórias na Sprint “S-1”. Nesse caso, as histórias definidas pelo P.O. são primeiramente trabalhadas pelo Analista de Requisitos em uma Sprint para serem trabalhadas pelo time de desenvolvimento na Sprint posterior. Outra possibilidade ainda, que é a que menos gostamos, é mantê-lo no time de desenvolvimento e separar histórias que só ele pode mexer (especificação) de outras que ele não pode mexer (codificação).
Logicamente, tudo depende das características do projeto, incluindo aí a organização atendida, o P.O., o time, etc. Esperemos tê-lo ajudado.
Obrigado pela sua participação.
Obrigado pela resposta e os exemplos !
Ajudou bastante ! Ótima resposta!