-
Notifications
You must be signed in to change notification settings - Fork 2
Estado Desejado
O modelo utilizado como base para o projeto será o Scrum que é um framework para metodologias ágeis, com alguns aspectos do Kanban e do eXtreme Programming(XP). A escolha do Scrum como base foi feita pelo motivo de que boa parte dos integrantes do projeto já estão familiarizados com ele, facilitando a execução do processo da empresa Go-Horse+.
Scrum é um framework para desenvolver, entregar e manter produtos complexos. Este guia contém a definição do Scrum. Esta definição consiste em papéis, eventos, artefatos e as regras do Scrum que unem os demais e os mantém integrados. Ken Schwaber e Jeff Sutherland desenvolveram o Scrum.
O XP é um método de desenvolvimento de software criado em 1997 considerado leve, não prescritivo, e que procura fundamentar as suas práticas por um conjunto de valores. Para o trabalho vamos trazer algumas dessas práticas:
O Kanban é uma estrutura popular usada para implementar o desenvolvimento ágil de software. Ele requer uma capacidade de comunicação em tempo real e transparência total de trabalho. Os itens de trabalho são representados visualmente em um quadro do kanban, permitindo que os membros da equipe vejam o estado de cada parte do trabalho a qualquer momento. Dessa forma, além de trazer grande visibilidade do fluxo de desenvolvimento para a equipe, é um ótimo complemento para o Scrum, que também foi eleito como modelo para o processo desejado, auxiliando em tarefas relacionadas a planejamento, monitoramento e controle.
As atividades do processo devem ser baseadas no Scrum. Portanto, é necessário que existam sprints, que a entrega seja incremental feitas em espaços de tempo definidos (time-boxed) que tenham os eventos de planejamento de sprint, reunião diária, revisão e retrospectiva mapeadas para as atividades do processo da empresa Go-Horse+. Os eventos do Scrum são definidos abaixo:
Planejamento da Sprint: (Planejamento) O Time de Desenvolvimento trabalha para prever as funcionalidades que serão desenvolvidasdurante a Sprint. O Product Owner debate o objetivo que a Sprint deve realizar e os itens de Backlog do Produto que, se completados na Sprint, atingirão o objetivo da Sprint. Todo o Time Scrum colabora com o entendimento do trabalho da Sprint. O planejamento é time-boxed - máximo 8 horas para uma sprint com duração de um mês. Tendo definido o objetivo da Sprint e selecionado os itens de Backlog do Produto da Sprint, o Time de Desenvolvimento decide como irá construir essas funcionalidades durante a Sprint e transformá-las em um incremento de produto “Pronto”. Os itens de Backlog do Produto selecionados para a Sprint, junto com o plano de entrega destes itens é chamado de Backlog da Sprint. Durante o planejamento da Sprint é definido a meta da sprint que fornece uma direção para o Time de Desenvolvimento sobre o porquê de estar construindo o incremento.
Reunião diária: (Monitoramento e Controle) É um evento time-boxed de 15 minutos no máximo com foco no time de desenvolvimento. Ela é mantida todo dia no mesmo horário e local para reduzir complexidade. Ela é utilizada para inspecionar o progresso em direção ao objetivo da Sprint e para inspecionar se o progresso tende na direção de completar o trabalho do Backlog da Sprint. O Scrum Master assegura que o Time de Desenvolvimento tenha a reunião, mas o Time de Desenvolvimento é responsável por conduzir a Reunião Diária. O Scrum Master ensina o Time de Desenvolvimento a manter a Reunião Diária dentro do time-box de 15 minutos.
Revisão da Sprint: (Monitoramento e Controle) A Revisão da Sprint é realizada no final da Sprint para inspecionar o incremento e adaptar o Backlog do Produto se necessário. Durante a Revisão da Sprint o Time Scrum e as partes interessadas colaboram sobre o que foi feito na Sprint. Com base nisso e em qualquer mudança no Backlog do Produto durante a Sprint, os participantes colaboram nas próximas coisas que podem ser feitas para otimizar valor. Esta é uma reunião informal, não uma reunião de status, e a apresentação do incremento destina-se a motivar e obter feedback e promover a colaboração. É um evento time-boxed de 4 horas para sprints com duração de um mês. O resultado da Revisão da Sprint é um Backlog do Produto revisado que define os prováveis Itens de Backlog do Produto para a próxima Sprint. O Backlog do Produto pode também ser ajustado completamente para atender novas oportunidades. O objetivo principal desse evento é demonstrar o que foi feito para as partes envolvidas no projeto.
Retrospectiva da Sprint: (Monitoramento e Controle) A Retrospectiva da Sprint é uma oportunidade para o Time Scrum inspecionar a si próprio e criar um plano para melhorias a serem aplicadas na próxima Sprint. Ao final da Retrospectiva da Sprint, o Time Scrum deverá ter identificado melhorias que serão implementadas na próxima Sprint. A implementação destas melhorias na próxima Sprint é a forma de adaptação à inspeção que o Time Scrum faz a si próprio. Apesar de que melhorias podem ser implementadas a qualquer momento, a Retrospectiva da Sprint fornece uma oportunidade formal focada em inspeção e adaptação. É um evento time-boxed de 3 horas para sprints com duração de um mês. Portanto, o objetivo desse evento é demonstrar os pontos positvos, os negativos e propor melhorias para os pontos negativos encontrados.
A utilização do KanBan pode estar explícita no processo desejado, mais especificamente, em atividades relacionadas aos seguintes eventos do Scrum: Planejamento da Sprint, Reunião Diária e na Própria Sprint (Time-Box de Desenvolvimento). Uma forma de mapear o uso desse modelo no processo, é a menção deste nas descrição das atividades, exigindo a utilização dos quadros e movimentação dos cartões caso seja necessário na atividade da qual a descrição diz respeito.
Assim como nas atividades, os papeis devem ter como base o framework scrum e devem estar explícitos no processo. Os papéis do Scrum são product owner, time de desenvolvimento e scrum master. As responsábilidades de cada um dos papeis se encontram abaixo.
Product Owner: O Product Owner, ou dono do produto, é o responsável por maximizar o valor do produto resultado do trabalho do Time de Desenvolvimento. Como isso é feito pode variar amplamente através das organizações, Times Scrum e indivíduos.O Product Owner é a única pessoa responsável por gerenciar o Backlog do Produto.
Time de Desenvolvimento: O Time de Desenvolvimento consiste de profissionais que realizam o trabalho de entregar um incremento potencialmente liberável do produto “Pronto” ao final de cada Sprint. Um incremento “Pronto” é requerido na Revisão da Sprint. Somente integrantes do Time de Desenvolvimento criam incrementos.
Características dos times de desenvolvimeto:
- Auto-organizados;
- Times de Desenvolvimento são multifuncionais;
- O Scrum não reconhece títulos para os integrantes do Time;
- O Scrum não reconhece sub-times no Time de Desenvolvimento;
- Individualmente os integrantes do Time de Desenvolvimento podem ter habilidades especializadas e área de especialização, mas a responsabilidade pertence ao Time de Desenvolvimento como um todo
Scrum Master: O Scrum Master é responsável por promover e suportar o Scrum como definido no Guia Scrum. O Scrum Master faz isso ajudando todos a entenderem a teoria, as práticas, as regras e os valores do Scrum. O Scrum Master é um servo-líder para o Time Scrum. O Scrum Master ajuda aqueles que estão fora do Time Scrum a entender quais as suas interações com o Time Scrum são úteis e quais não são. O Scrum Master ajuda todos a mudarem estas interações para maximizar o valor criado pelo Time Scrum.
As boas práticas devem ser definidas com base na metodologia de desenvolvimento eXtreme Programming(XP) e devem estar explícitas no processo de desenvolvimento (descrição das atividades) e/ou nas políticas adotadas pela empresa Go-Horse+. As boas práticas que devem ser seguidas são a programação pareada, execução de testes, integração contínuas e padronização do código. O Scrum não explicita como deve ser o desenvolvimento, por este motivo foi necessário o apoio do XP, portanto, é ideal que as boas práticas estejam inclusas na execução da sprint, seja como políticas ou como descrição da atividade de desenvolvolvimento. As práticas adotadas são descritas abaixo:
Trata-se de duas pessoas trabalhando com UMA máquina onde um codifica, e o outro critica ou dá sugestões. Os pares trocam de lugar periodicamente. Essa prática é excelente e favorece comunicação e aprendizado. Com essa troca constante de ideias temos como resultado um Projeto de maior qualidade e como estudos comprovam temos maior produtividade e maior qualidade (com padrão de codificação e entendimento do código e partes do código que não eram entendidos). Essa prática também facilita aprendizado dos novos integrantes.
Evidente que essa prática requer ambiente de trabalho apropriado como, por exemplo, um ambiente que provê mobilidade, e pessoas que devem concordar com o barulho que será causado.
A prática de teste no XP é bastante técnica, e envolve a presença do cliente no desenvolvimento e na validação de testes. O cliente compartilha com o desenvolvedor sobre o funcionamento do sistema. Os testes também se tornam as especificações da programação, visto que o teste diz o que deve estar de acordo e o que não deve estar de acordo, é como uma especificação.Os testes são escritos antes da funcionalidade, o que também é conhecido como TDD (Test-Driven Design) onde intercala-se a função de testar um pouco e codificar um pouco. Além disso, o TDD impõe o programador à saber o que deve ser verdadeiro no programa e o que não deve ser para que ele funcione corretamente, portanto, pensa-se primeiramente no problema e depois na solução. Dessa forma, os testes são automatizados, diferente de anteriormente onde o desenvolvedor fazia a implementação e entregava para alguém testar. Com os testes automatizados podemos executá-los a qualquer momento, e dessa forma, novas funcionalidade ou alterações podem ser imediatamente testadas para ver se essas mexidas não acarretaram outros problemas. Dessa forma, o teste impõem também confiança ao sistema e dão coragem para altera-lo, pois podemos saber imediatamente se algo introduziu um bug no sistema.
Entre os tipos de testes temos o Teste Unitário que automatiza o teste da funcionalidade e tipicamente testa uma classe, ou pequeno grupo de classes. Se um bug é descoberto, acrescenta-se imediatamente um caso de teste para ele. Assim garantimos que ele não se repetirá. Outro tipo de teste é o Teste de Aceitação (Teste funcional) que é especificado pelo cliente para testar que o sistema funciona conforme especificado por ele. Quando todos os seus testes de aceitação passam, a história é considerada completa.
Teste automatizado é a prática que sustenta e viabiliza muitas outras práticas como Integração contínua, Projeto Simples, Versão Pequena, Refatoração, e Propriedade Coletiva.
Para o contexto da matéria, não será feito o TDD tendo assim a adoção apenas dos testes automatizados.
Todo código deve ser integrado diariamente e todos testes devem passar antes e depois da integração. Se algum problema é encontra do ele deve ser corrigido imediatamente.
Todos mexem em todos os códigos, todos refatoram e todos trabalham em pares. Assim é interessante mantermos um padrão para termos algo solidificado. Por isso a melhor forma é a equipe definir um padrão de codificação sempre no inicio dos projetos.
Os artefatos do processo desejado devem ser, também, baseados no Scrum e devem estar explicitos no processo utilizado. O backloog do produto, backlog da sprint e o incremento são elementos fundamentais do Scrum e estes são descritos abaixo.
O Backlog do Produto é uma lista ordenada de tudo que é conhecido ser necessário no produto. É a única origem dos requisitos para qualquer mudança a ser feita no produto. O Product Owner é responsável pelo Backlog do Produto, incluindo seu conteúdo, disponibilidade e ordenação.
O Backlog da Sprint é um conjunto de itens do Backlog do Produto selecionados para a Sprint, juntamente com o plano para entregar o incremento do produto e atingir o objetivo da Sprint. O Backlog da Sprint é a previsão do Time de Desenvolvimento sobre qual funcionalidade estará no próximo incremento e sobre o trabalho necessário para entregar essa funcionalidade em um incremento “Pronto”.
O incremento é a soma de todos os itens do Backlog do Produto completados durante a Sprint e o valor dos incrementos de todas as Sprints anteriores. Ao final da Sprint um novo incremento deve estar “Pronto”, o que significa que deve estar na condição de ser utilizado e atender a definição de “Pronto” do Time Scrum. Um incremento é uma parte principal inspecionável de trabalho pronto que suporta empirismo no final da sprint. O incremento é um passo na direção de uma visão ou de um objetivo. O incremento deve estar na condição de ser utilizado independente do Product Owner decidir por liberá-lo ou não.
SCHWABER, Ken. SUTHERLAND, Jeff. The Scrum Guide The Definitive Guide to Scrum: The Rules of the Game. 2017 < https://www.scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-US.pdf >
Como a metodologia Kanban é aplicada ao desenvolvimento de software https://br.atlassian.com/agile/kanban
- Template do Plano de Medição
- Template para Resultado de Métricas Coletadas por Sprint
- Diretrizes e template para Objetivos GQM