Scrum

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:
Papeis Scrum
Os esforços de desenvolvimento no Scrum é composta basicamente de  três papéis:
  1. Product Owner
  2. ScrumMaster
  3. 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:
  1. 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).
  2. O Proprietário do Produto define quais são as funcionalidades do programa que mais importam, criando assim o que chamamos de Product Backlog.
  3. 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.
  4. 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.
  5. 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).
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




Thallita Celeste

Olá! Sou Thallita, fundadora do blog ThallitaCeleste. Sou Analista de segurança, com fome de conhecimento e grande vontade de ajudar as pessoas ao redor. Aqui, tento manter meu histórico sobre diversos temas. Bem, seja Bem Vindo ao meu Blog! Espero que goste. o/

Nenhum comentário:

Postar um comentário