Scrum
História:
A primeira referência ao assunto foi no artigo “The New New Product Development Game” em 1986 na Harvard Business Review produzido por Takeuchi e Nonaka, o artigo apresentou iterações, valor, times pequenos, multifuncionais e auto-organizados.
Em 1995, Jeff Sutherland e Ken Schwaber publicaram este método e chamaram de “Scrum” no artigo “Scrum and the Perfect Storm”, Jeff era vice-presidente na Easel e Ken da Advanced Development Methods.
Scrum é uma metodologia ágil para gestão e planejamento de projetos de software. Um framework de desenvolvimento iterativo e incremental utilizado no gerenciamento de projetos e desenvolvimento de software ágil. Estas boas práticas que em conjunto permitem ganhos no gerenciamento de projetos de desenvolvimento de software, com papéis, eventos, artefatos e regras.
Características Scrum
- Clientes se tornam parte da equipe de desenvolvimento (os clientes devem estar genuinamente interessados na saída);
- Entregas frequentes e intermediárias de funcionalidades 100% desenvolvidas;
- Scrum é um processo ágil para gerenciar e controlar o desenvolvimento de projetos.
- Scrum é um processo que controla o caos resultante de necessidades e interesses conflitantes.
- Discussões diárias de status com a equipe;
- Scrum é uma forma de aumentar a comunicação e maximizar a cooperação·
- Scrum é uma forma de detectar e remover qualquer impedimento que atrapalhe o desenvolvimento de um produto.
- Planos frequentes de mitigação de riscos desenvolvidos pela equipe;
- Scrum é escalável desde projetos pequenos até grandes projetos em toda empresa.
Pilares Scrum:
Papéis Fundamentais Scrum:
Os esforços de desenvolvimento no Scrum é composta basicamente de três papéis:
- Product Owner
- ScrumMaster
- Time de Desenvolvimento
Product Owner
Product Owner é o ponto central com poderes de liderança sobre o produto. Ele é o único responsável por decidir quais recursos e funcionalidades serão construídos e qual a ordem que devem ser feitos.
É responsabilidade dele manter e comunicar a todos os outros participantes uma visão clara do que a equipe Scrum está buscando alcançar no projeto. Como tal, ele é responsável pelo sucesso global da solução.
Para garantir que a equipe construa rapidamente o Product Owner deve colaborar ativamente com o ScrumMaster e equipe de desenvolvimento e deve estar disponível para responder às perguntas tão logo estas são feitas.
Scrum Master
O ScrumMaster é responsável por ajudar a todos os envolvidos a entender e abraçar os valores, princípios e práticas do Scrum.
Ele age como um Coach, executando a liderança do processo e ajudando a equipe Scrum (e o resto da organização) a desenvolver sua própria abordagem do Scrum, que tenha a melhor performance, respeitando as particularidades da organização.
O ScrumMaster também tem um papel de facilitador. Ele deve ajudar a equipe a resolver problemas e fazer melhorias no uso do Scrum. Ele também é responsável por proteger a equipe contra interferências externas e assume um papel de liderança na remoção de impedimentos que podem atrapalhar a produtividade.
Time Scrum
No desenvolvimento tradicional de software são abordados vários tipos de trabalho, tais como: arquiteto, programador, testador, administrador de banco de dados, Designer e etc.
No Scrum é definido o papel do Time de Desenvolvimento, que seria a junção de todas essas pessoas em uma equipe multidisciplinar, e que são responsáveis pela concepção, construção e testes do produto.
A idéia principal é que a equipe de desenvolvimento se auto-organiza para determinar a melhor maneira de realizar o trabalho para atingir a meta estabelecida pelo Product Owner.
Em geral e de forma reduzida, esta metodologia funciona da seguinte forma:
- O produto é definido: quais são os seus requisitos? O que realmente o cliente quer? O responsável por esta tarefa é o que chamamos de Proprietário do Produto (Product Owner, em inglês).
- O Proprietário do Produto define quais são as funcionalidades do programa que mais importam, criando assim o que chamamos de Product Backlog.
- Com as prioridades definidas, uma pessoa é definida para ser o ScrumMaster, uma espécie de coordenador do projeto. O ScrumMaster, junto com o Proprietário do Produto e o Time de desenvolvimento definem o que chamamos de Sprints.
- Cada Sprint possui uma parte de todo o Product Backlog, e devem ser trabalhados de acordo com as prioridades definidas no Product Backlog. Os Sprints devem ser preparados de uma forma de que durem de 2 a 4 semanas, e que no final de cada período tenham um produto apresentável para o cliente.
- Os Sprints vão sendo feitos até o Product Backlog acabar e o Proprietário do Produto definir que o projeto está pronto. Mas isso não quer dizer que novas funcionalidades não podem ser incluídas: basta ir adicionando no Product Backlog e realizando outros Sprints.
Seguindo estas etapas:
Seguido este processo:
Mas como funciona cada etapa do processo?!
Product Backlog
É basicamente uma lista com requisitos e suas prioridades definidas pelo Product Owner. No product backlog são definidas as funcionalidades a serem entregues ao cliente, este documento pode ser alterado a qualquer momento, está é outra característica importante do Scrum, neste processo a equipe tem que ter ciência da natureza mutável do software, ou seja, as necessidades dos clientes podem e muito provavelmente vão mudar a qualquer momento e um processo de desenvolvimento ágil tem de ser flexível neste ponto. Quando se tem o Product Backlog pronto pode-se partir para a próxima etapa o Sprint Backlog.
Sprint Backlog
Consiste em uma lista de itens selecionados do Product Backog que serão realizados no próximo Sprint, esta lista é definida durante uma reunião chamada Sprint Planning Meeting na qual a equipe decide o que vai ser realizado em determinado Sprint, onde as reuniões são um dos pontos centrais do Scrum.
Sprint
O sprint é o desenvolvimento de um incremento de um software a ser entregue em determinado prazo, mas esse processo envolve algumas nuances a mais que veremos a seguir. A duração de um sprint pode variar de (7 e 30 dias).
O sprint é o desenvolvimento de um incremento de um software a ser entregue em determinado prazo, mas esse processo envolve algumas nuances a mais que veremos a seguir. A duração de um sprint pode variar de (7 e 30 dias).
Daily Scrum
É uma reunião diária realizada a cada dia de um sprint, está reunião tem um conjunto de regras bem definido:
- A reunião começa precisamente no horário marcado.
- Todos são bem-vindos, mas apenas "poucos" podem falar.
- O encontro tem duração determinada (Time-Box) e dura 15 minutos.
- A reunião deve acontecer no mesmo local e mesma hora todos os dias
- Durante a reunião, cada membro da equipe responde a três perguntas:
- O que você tem feito desde ontem?
- O que você está planejando fazer hoje?
- Você tem algum problema impedindo você de realizar seu objetivo?
Uma das vantagens das reuniões curtas é que evitam o cansaço causado por reuniões muito longas e que muitas vezes acabam sendo pouco produtivas, também é importante destacar que desta forma também se garante que todos os membros da equipe estarão a par de cada progresso feito durante o projeto.
Reunião de Revisão da Sprint (Sprint Review)
Esta reunião tem dois objetivos principais: rever o trabalho concluído e o não concluído e apresentar uma demo ao cliente. Dessa forma a cada sprint o cliente poderá ver uma parte do produto funcionando e participar do processo fazendo sugestões de melhorias.
Retrospectiva da Sprint (Sprint Retrospective)
Está reunião tem o objetivo de rever os erros e acertos no sprint realizado. Está é uma das partes mais importantes do processo, já que nela é possível aprender com os erros e tentar aprimorar o produto. Com isso é possível obter o que se procura não só quando se está desenvolvendo software, mas em qualquer outro produto: a melhoria continua.
Bem pessoal eu espero que tenham gostado. Continuem acompanhando os lançamentos e até a próxima! \o
0 comments:
Postar um comentário