Post

1 Star2 Stars3 Stars4 Stars5 Stars
Loading ... Loading ...

By SaltoNaComputação Leitores do blog, após pesquisas e implantação do Scrum em algumas empresas, segue um post contendo alguns conceitos que julgamos necessário para implantação de práticas ágeis. Boa leitura!A Engenharia de Software constantemente busca a melhoraria do processo de desenvolvimento de software. Mesmo com a constante evolução de técnica, ferramentas e métodos, a entrega de software com custo e prazos preestabelecidos raramente correspondem ao que foi determinado antes do início do projeto. Uma das causas desse problema é o excesso de formalidade nos modelos de processo propostos nos últimos 30 anos (FOWLER, 2003; LARMAN, 2004).Os métodos ágeis de desenvolvimento vêm ganhando atenção na indústria de software, devido à proposta de liberação do produto de forma mais rápida do que os modelos prescritivos de processo (PRESSMAN, 2006). Enquanto outros modelos planejam tudo desde o início até a concepção do produto final, tentando prever riscos durante todo o processo de desenvolvimento, os métodos ágeis pregam o planejamento contínuo, sendo adaptativos e orientados às pessoas e não a processos.Propondo uma nova abordagem para o desenvolvimento, esses métodos possuem alguns princípios, como satisfazer o cliente entregando software de valor em tempo hábil e continuamente, aceitando e se adaptando a mudança de requisitos, a equipe de negócio e do desenvolvimento trabalhando juntas durante o processo, projetos construídos por indivíduos motivados, conversas cara a cara com o time e simplicidade (AGILE ALLIANCE, 2001b ).Agilidade refere-se a atitudes e ambiente, desenvolvimento iterativo, entrega do produto com valor para o negócio, mais rápido e continuamente, garantindo o progresso real. Mudanças são aceitas com naturalidade pelo time, levando em consideração a comunicação entre negócios e TI, preocupando-se com qualidade desde o início do projeto.O Scrum se destaca por ser um framework para gerenciamento de projetos baseado em times pequenos e auto-organizados e por estar sendo utilizado por inúmeras empresas por todo o mundo como case de sucesso.Descrevendo o ScrumComo citado pela (SCRUM ALIANCE, 2011), Scrum é um framework ágil para a conclusão de projetos complexos. Scrum originalmente foi formalizada para projetos de desenvolvimento de software, mas funciona bem para qualquer escopo complexo e inovador de trabalho. As possibilidades são infinitas. O framework Scrum é enganosamente simples.O ciclo do desenvolvimento de um software é considerado complicado e extremamente difícil de prever. Por isso, o Scrum define o desenvolvimento de sistema como uma progressão global, contendo um conjunto flexível de atividades, combinando ferramentas, técnicas viáveis e conhecimentos da equipe para o melhor planejamento para a construção do sistema. Uma vez definidas essas atividades é possível gerenciar o processo e os riscos inerentes utilizados.Os princípios do Scrum norteiam o processo de desenvolvimento de software que tem as seguintes atividades: levantamento de requisitos, análise, projeto, evolução e entrega. (PRESSMAN, 2006)Scrum é um framework iterativo, onde a cada iteração existem adaptações realizadas no produto, é incremental, avalia como foi desenvolvido e melhora, e é orientado a ciclo. É um método ágil para o gerenciamento de projetos baseado em pequenos times, auto-organizados de rápida adaptação e forte visibilidade. Suas características estão sendo utilizadas em diversos projetos desde 1990 em várias organizações por todo o mundo.PAPÉIS E RESPONSABILIDADES Scrum possui três papéis: Product Owner, Scrum Master e o Time.Product Owner (PO)O Product Owner (PO) é o responsável por definir o projeto e garantir o retorno de investimento, o PO demonstra para o time a visão do produto, prioriza e define requisitos.O Product Owner pode alterar as priorizações de tarefas, adicionar ou remover novos requisitos conforme as suas necessidades, porque apenas ele conhece as necessidades do(s) cliente(s). Ele não pode mudar o trabalho que está em codificação pela equipe de desenvolvimento.
Uma das grandes chaves de sucesso do Scrum está no Product Owner, pois ele tem clareza dos objetivos de negócio que o time deve seguir, tem uma visão macro de todo o projeto e caso o projeto tenha possibilidades de atrasar, ele sabe o que mudar.Os requisitos não devem chegar parcialmente definidos para a equipe de desenvolvimento, caso isso ocorra a capacidade de produção da equipe vai diminuir.O Product Owner representa o cliente, já o time de desenvolvimento de software tem que atender as expectativas e orientações do PO.O PO tem o poder de aceitar ou rejeitar um trabalho realizado pelo time de desenvolvimento de software.Scrum Master (SM)O Scrum Master é um integrante do time de desenvolvimento do software que possui algumas atribuições diferentes dos demais. Entre as responsabilidades está a de garantir o processo do Scrum ativo, fazendo com que o projeto seja realizado, seguindo as boas práticas do Scrum.Outra responsabilidade do Scrum Master é identificar todos os impedimentos que estão ocorrendo durante o desenvolvimento do sistema, que fazem com que a capacidade de produção da equipe diminua ou até mesmo não permita que a equipe continue trabalhando. Quando o Scrum Master não tem condições de solucionar o impedimento ele deve buscar a pessoa que pode resolver o problema identificado.A produtividade do time é mais uma responsabilidade do Scrum Master, pois ele deve fazer com que a equipe de desenvolvimento do sistema fique focada ao máximo na sua área de atuação, que é a construção do software. O Scrum Master protege o time de interferências externas e tem também como tarefa treinar o PO e trazê-lo para junto do projeto.Um ponto importante é que o Scrum Master não deve ter controle sobre a equipe.
É importante existir um Scrum Master para substituições eventuais, para caso o Scrum Master do projeto não possa estar presente, logo uma pessoa do time já saiba que ele é a responsável por executar as atribuições de trabalho do Scrum Master.TimeExecuta todo o plano do projeto, sendo protegida pelo Scrum Master e tendo como objetivo atender as necessidades do Product Owner. Um time em Scrum é multi-disciplinar, auto-gerenciado e produz o produto com qualidade e valor para o cliente. A meta estipulada pelo Product Owner é do time, que pode ter no mínimo cinco pessoas e no máximo nove pessoas que fazem o trabalho real (analisar, projetar, desenvolver, testar técnicas de comunicação, documentos, etc.).As equipes são menores para potencializar uma das maiores armas do Scrum, a comunicação entre a equipe. Equipes menores chegam a ter a sua capacidade de produção melhor que equipes grandes.FLUXO DO SCRUM
Conforme mostra a figura:

O PO cria e prioriza sua lista de desejos chamada Product Backlog;Durante o planejamento da Sprint o Time seleciona as tarefas do topo da lista para de desejos e decide como as tarefas serão executadas;O time tem um certo tempo para executar essas tarefas que vão de duas a quatro semanas, com reuniões diárias a cada dia para acompanhar seu progresso;Ao longo do caminho, o Scrum Master mantém a equipe focada em seu objetivo;No final da Sprint o trabalho deve estar pronto para entregar ao cliente;A corrida termina com uma revisão de Sprint e com a retrospectiva.Um projeto no Scrum se inicia com uma visão do produto que será desenvolvido (SCHWABER, 2004). A visão do produto é definida pelo Product Owner representando assim a necessidade dele. É o que deve ser realizado e entregue ao fim do projeto. Para ter essa visão o Product Owner colhe informações como características do produto, algumas premissas e restrições com todos os envolvidos no projeto como stakeholders, clientes, time, gerentes, usuários, dentre outros.De acordo com Schwaber(2004), o Scrum introduz os seguintes artefatos principais usados ao longo do seu fluxo de desenvolvimento: Product Backlog, Sprint Backlog e incremento de funcionalidade do produto.Product BacklogO PO cria uma lista de requisitos conhecidos que precisam ser implementados e que recebe o nome de Product Backlog. Esses requisitos são priorizados de acordo com o valor de negócio para o cliente e podem ser alterados durante o projeto, ou seja, o Product Backlog nunca está completo, ele evolui à medida que o produto é desenvolvido.Sprint Planning MeetingÉ uma reunião de planejamento realizada pelo o Product Owner e o Time para planejar e decidirem juntos o que deverá ser implementado na iteração, selecionando itens do backlog que farão parte da Sprint. Essa reunião é divida em duas partes. Na primeira parte o PO descreve em aproximadamente quatro horas os itens de maior

valor e prioriza aqueles que devem ser entregues durante a Sprint. Considerando a capacidade de produção, o time decide em conjunto o que poderá entrar para o desenvolvimento. Na segunda parte, o time irá se planejar e definir o Sprint Backlog com as tarefas necessárias para implementar as funcionalidades de acordo com a priorização. As tarefas podem sofrer modificações e variações.SprintSprint consiste na produção de parte do produto definida pelo cliente, dentro do prazo determinado que pode durar de duas a quatro semanas. Os membros do time são os responsáveis por estimar um conjunto de atividades que irão compor o desejo do cliente, informando o que será possível ser desenvolvido naquele prazo. O conceito de Sprint nos remete a necessidade de entregarmos algo de valor ao cliente.Durante a execução da Sprint valem as práticas de engenharia definidas para o projeto. O Scrum Master lidera e colabora com o time, facilitando o trabalho e removendo impedimentos encontrados, garantindo assim a aplicação do Scrum.Durante a Sprint, o time pode sentir necessidade de consultar membros do time ou até mesmo o Product Owner, por isso a importância da equipe multi-disciplinar com não mais que nove membros.O tamanho ideal das Sprints deve ser o tamanho que o time e o cliente achem ideal. Vale salientar, que para projetos com mudanças no topo do Product Backlog, para times com a síndrome do estudante, que significa adiar o trabalho até o último momento possível, e para times com dificuldades de entregar valor para o cliente ao final das Sprints, o ideal é trabalhar com Sprints curtos. Porém quando o time e/ou cliente estão exaustos com loops tão curtos o ideal é trabalhar com Sprints longos.O que o time e o cliente definiram para entrega na iteração corrente é o que deve ser entregue. Se o conteúdo da Sprint mudar se torna regra:
O cliente deixar de fazer um planejamento de qualidade, bem como de estar atento às priorizações do Product Backlog, afinal se tudo muda sempre para que se preocupar com esses deveres?
O Time ignora a meta, pois ele sempre irá mudar;
O Time perde foco e se desmotiva;
E podem ocorrer inúmeras situações que desgastam o relacionamento do time com o Scrum Master e Product Owner.
Pode acontecer da Sprint finalizar antes do previsto nas seguintes situações:
O Time não conseguirá atingir a meta;
O PO observa que mudanças em fatores externos influenciarão diretamente no valor da meta da Sprint.

Caso umas das situações ocorra e a Sprint seja cancelada é aconselhável iniciar imediatamente o planejamento da próxima Sprint.O conceito de pronto ao final de uma Sprint leva em consideração que o projeto foi bem codificado, refatorado, que tenha passado por testes unitários, que o build tenha sido gerado e que tenha passado por testes de aceitação. Ou seja, ao final de cada Sprint o Time deverá ter produzido um incremento do produto com alta qualidade, testado e completo.Daily MeetingSegundo Pressman (Pressman, 2006), Daily Meeting (DM) são ciclos de reuniões diárias de 15 minutos em média, com características particulares, elas são realizadas “em pé” (Standup Meeting) pela manhã, onde cada membro da equipe do projeto deve responder a três perguntas:1. O que fez para o projeto desde a última reunião? 2. O que fará para o projeto até a próxima reunião? 3. Há algum obstáculo para conseguir seu objetivo? Precisa de ajuda? O intuito dessa reunião é que o time ganhe visibilidade de como está caminhando para a meta e planeje o dia seguinte de trabalho. O Scrum Master atua como facilitador, conduzindo a reunião e levantando os impedimentos para ajudar o Time a não ter problema com atraso na entrega do produto.Sprint ReviewÉ uma reunião de apresentação do resultado da iteração para os clientes onde todos os envolvidos no projeto participam. A Sprint Review é realizada no final da Sprint. É uma reunião que dura aproximadamente 4 horas para Sprints de um mês, ou seja, essa reunião não deve ultrapassar 5% do Sprint total.
Essa reunião deve contemplar a inspeção por parte do Product Owner identificando o que foi feito e o que não foi feito. Já o Time identifica os problemas que ocorreram durante a Sprint, como esses problemas foram resolvidos, demonstrando o que foi feito, e respondendo questionamentos do Product Owner.O Product Owner discute sobre o andamento do Product Backlog, faz projeções de datas para entregas, sempre acompanhando a velocidade do Time. Todos os envolvidos colaboram entre si, fornecendo inputs para a Sprint Planning Meeting seguinte.As possíveis consequências dessa reunião são:
Devolver ao Product Backlog funcionalidades não terminadas e repriorizá-las;
Remover do Product Backlog funcionalidades que foram finalizadasantecipadamente;
Trabalhar com o Scrum Master para reformular a equipe;
Repriorizar o Product Backlog;
Solicitar o fechamento de um Release com as funcionalidades demonstradas, sozinhas ou com o incremento de Sprints anteriores;
Escolher não avançar mais com o projeto e não autorizar outra Sprint;
Solicitar que o progresso do projeto seja acelerado autorizando a inclusão de times adicionais para trabalhar no Product Backlog.

RetrospectiveÚltima reunião da Sprint e representa o espírito de inspeção-adaptação no Scrum. Tem duração de aproximadamente três horas. O Scrum Master revisa com o Time todo o processo de trabalho da Sprint com a finalidade de inspecionar como ocorreu a última Sprint analisando processos, relações entre os membros do time e ferramentas. A inspeção identifica e prioriza os principais itens que ocorreram bem e aqueles que se feitos de modo diferente, poderiam ter deixado o resultado ainda melhor.Os membros do Time são convidados a escrever os pontos que acreditam que foram bons na Sprint corrente e quais ainda devem ser melhorados. Esse trabalho deve ser feito individualmente e não deve ser levado para o lado pessoal, ou seja, deve-se focar em falar do problema, melhorias e qualidade, e não apontar um responsável.
Perguntas utilizadas na reunião:
O que foi bom na Sprint?
O que deve ser melhorado para próxima Sprint?
Ao final dessa reunião o Time terá identificado medidas de melhoria que implementará no próximo Sprint. Essas mudanças se tornam a adaptação para a inspeção empírica.Por Liliana Carrha

Source: http://www.saltonacomputacao.com/2014/01/praticas-ageis-e-conceitos-necessarios.html

Category: Agile, DM, Metodologias, Scrum

Você também pode querer ler

Comments are off for this post.