Engenharia de Software: SCRUM

Princípios, padrões e práticas são importantes, mas são as pessoas que os fazem funcionar. Uma equipe que tem um bom relacionamento é a força de desenvolvimento de software mais poderosa que existe.

Manifesto para o desenvolvimento Ágil de Software

Estamos descobrindo maneiras melhores de desenvolver softwares, fazendo-o nós mesmos e ajudando outros a fazê-lo.

Com esse trabalho passamos a valorizar:

Indivíduos e interações mais que processos e ferramentas

Software em funcionamento mais que documentação abrangente

Colaboração com o cliente mais que negociação de contrato

Resposta a mudanças mais que seguir um plano

Ou seja, mesmo havendo valor nos itens à direita, valorizamos mais os itens à esquerda.

Nós seguimos os seguintes princípios

Nossa maior prioridade é satisfazer o cliente, através da entrega adiantada e contínua de software de valor.

(Quanto mais frequentes são as entregas, maior é a qualidade final)

Aceitar mudanças de requisitos, mesmo no fim do desenvolvimento. Processos ágeis se adequam a mudanças, para que o cliente possa tirar vantagens competitivas.

(Canalizar as mudanças para as vantagem competitivas do cliente. A adaptação as mudanças mostram o quando a equipe entendeu o negócio do cliente)

Entregar software funcionando com frequência, na escala de semanas até meses, com preferência aos períodos mais curtos.

(Nossa atenção está no objetivo de entregar software que atenda as necessidades do cliente)

Pessoas relacionadas à negócios e desenvolvedores devem trabalhar em conjunto e diariamente, durante todo o curso do projeto.

(Clientes, desenvolvedores e interessados devem ter uma interação significativa e frequente)

Construir projetos ao redor de indivíduos motivados. Dando a eles o ambiente e suporte necessário, e confiar que farão seu trabalho.

(As pessoas são o fator de sucesso mais importante)

O Método mais eficiente e eficaz de transmitir informações para, e por dentro de um time de desenvolvimento, é através de uma conversa cara a cara.

(O principal modo de comunicação é a interação humana)

Software funcional é a medida primária de progresso.

(Quantidade de software que está satisfazendo o cliente)

Processos ágeis promovem um ambiente sustentável. Os patrocinadores, desenvolvedores e usuários, devem ser capazes de manter indefinidamente, passos constantes.

(As equipes ágeis tem seu ritmo próprio)

Contínua atenção à excelência técnica e bom design, aumenta a agilidade.

(Alta qualidade é o segredo da alta velocidade)

Simplicidade: a arte de maximizar a quantidade de trabalho que não precisou ser feito.

(Buscamos o caminho mais simples e coerente)

As melhores arquiteturas, requisitos e designs emergem de times auto organizáveis.

(A equipe determina a melhor maneira de cumprir essas responsabilidades)

Em intervalos regulares, o time reflete em como ficar mais efetivo, então, se ajustam e otimizam seu comportamento de acordo.

(A equipe e extremamente flexível)

Fundamentando o Conhecimento

A empresa participante da consultoria utilizava o modelo de gestão proposto pelo PMI e o modelo de desenvolvimento de sistema em Cascata, incompatível com sua velocidade comercial, gerando diversos problemas pelo curto espaço de tempo entre a realização da elicitação dos requisitos e a entrega do produto, dada a velocidade, competitividade do mercado e as exigências do cliente.

Durante a consultoria levei em consideração o perfil da empresa, identificando todos os processos internos apoiado na certificação já existente – ISO 9001, que já contemplava as fases de concepção, planejamento, implementação, estabilização e entrega. Apesar da certificação identifiquei também o desconhecimento e resistência em fazer uso do processo existente na empresa, causada por vícios culturais na organização.

A proposta e adoção das boas práticas do framework Scrum na gestão de projetos de desenvolvimento de sistemas proporcionou a melhoria na qualidade dos processos e gestão do ciclo de vida do produto na organização, contribuindo para diminuição do retrabalho, aumentando a produtividade, racionalizando o uso dos recursos e contabilizando ativos para Fábrica de Software. Mas vou contar essa história ao longo dos textos, objetivando compartilhar conhecimento com a comunidade de TI.

Quanto prestamos uma consultoria, devemos levar em consideração diversos fatores que permeiam um organização, pois trata-se de um organismo vivo e que reponde aos estímulos de forma positiva ou negativa, dependendo da nossa abordagem profissional.

A dinâmica do mercado, a necessidade de melhoria no modelo de gestão e dos processos de engenharia de software, o aumento da complexidade dos sistemas, que no passado não demandavam tanta inteligência, as regras de negócio, o mapeamento sofisticado de processos e o conhecimento específico sobre o domínio do negócio, motivou a mudança no modelo de gestão e reavaliação dos processos de Engenharia de Software, resultando na proposta e implantação do framework Scrum na Fábrica de Software.

A empresa em questão fazia uso do modelo de gestão proposto pelo PMI - Project Management Institute e do modelo tradicional de desenvolvimento de software Waterfall[1] (Cascata). Os modelos em uso exigiam um esforço muito grande da equipe de desenvolvimento, em especial dos analistas de requisito, pois a falta de um especialista no negócio dificultava o entendimento do domínio necessário para elaboração da proposta comercial. Para os clientes eram conceitos triviais, pois faziam parte do seu dia-a-dia, mas para os analistas de requisito não eram de fácil entendimento, visto que assim como a socialização com os jargões da profissão levavam tempo considerável, o que dificultava a especificação do projeto do sistema, sem contar com o retrabalho dos analistas de sistema e arquitetos que só participavam do processo após a definição do escopo do projeto e aceite da proposta pelo cliente, precisando validar o escopo com os fornecedores de requisitos antes de iniciar o projeto, passando a impressão de falta de comunicação interna e desorganização.

Limitei a princípio, o escopo da consultoria, ao modelo de gestão de projetos e ao processo de desenvolvimento dos sistemas praticados na empresa, com base na complexidade dos projetos desenvolvidos. Existia a necessidade de desburocratizar os processos de gestão, melhorar os processos de desenvolvimento dos sistemas fazendo uso das boas práticas de Engenharia de Software, e de envolver um especialista no negócio durante o ciclo de vida dos projetos, tornando o processo de gestão e de desenvolvimento compatível com a velocidade comercial da empresa e com o negócio do cliente.
Observei também, no processo existente, uma grande queda de braços. De um lado o cliente querendo colocar o máximo de funcionalidade possível e do outro a empresa desenvolvedora, tentando limitar o escopo para elaboração de uma proposta comercial, com o menor esforço para a equipe de desenvolvimento.

Como implantar um modelo de gestão enxuto e ágil, garantindo prazos, custos e qualidade nos projetos de desenvolvimento de software? Ao longo dos artigos esta pergunta será respondida.

[1] O modelo Waterfall é um modelo de desenvolvimento de software sequencial no qual o desenvolvimento é visto como um fluir constante (como uma cascata) através das fases de análise de requisitos, projeto, implementação, testes (validação), integração, e manutenção de software. A origem do termo cascata é frequentemente citado como sendo um artigo publicado em1970 por W. W. Royce; fonte: http://pt.wikipedia.org/wiki/Modelo_em_cascata.

Objeto da Consultoria

A preocupação com a melhoria do modelo de gestão do ciclo de vida do projeto e do processo de desenvolvimento de sistemas foram os fatores motivadores para a proposta de implantação do framework Scrum na Fábrica de Software, visando o amadurecimento dos processos de engenharia de software, simplificando e agilizando as entregas dentro dos prazos, garantindo a qualidade e custo dos projetos. Esse estudo é um pré-projeto de implantação, é o marco zero na consultoria, e dele dependerá todo o processo de implantação.

Conceituando Engenharia de Software

"A Engenharia de Software é a criação e a utilização de sólidos princípios de engenharia a fim de obter software de maneira econômica, que seja confiável e que trabalhe eficientemente em máquinas reais" (Pressman, 2002). O termo Engenharia de Software já sugere a construção em fases, seguindo um processo bem definido, o que também apoia a implantação do framework ágil.

Fases no Processo de Implantação

Toda proposta de mudança em uma organização precisa ter o apoio da alta direção, responsável pelos objetivos estratégicos, futuro e sobrevivência da empresa no mercado. Com a proposta de implantação do framework Scrum não é diferente, pois a mudança no um processo afeta a empresa como um todo, ou parte da empresa, dependendo do nível de maturidade e vivência nos processos.

Segundo Mike Cohn em uma mudança de cima para baixo, um líder influente compartilha uma visão do futuro e a empresa o segue na materialização dessa visão. A empresa que tentar fazer a transição para o Scrum sem apoio dos níveis mais altos enfrentará uma resistência que não poderá ser superada a partir dos níveis inferiores. (2011, 27)

A mudança pode ser motivada por diversas razões, como:

Insatisfação do cliente.
Problemas na comunicação no ciclo de vida do projeto
Problemas na colaboração dos envolvidos no projeto.
Baixo retorno do investimento em projetos.
Equipe de desenvolvimento desmotivada.
Necessidade de melhoria da qualidade do produto.
Diminuição dos custos de produção.
Aumento de produtividade da equipe de desenvolvimento.
Diminuição no tempo gasto no termino dos projetos.
Diminuição do risco em projetos de desenvolvimento.

Visão do Framework Scrum

Primeiro passo na implantação do framework Scrum, é a realização de uma apresentação/passagem de conhecimento, esclarecendo todas as duvidas da diretoria. Não me refiro às questões técnicas, inerentes ao chão de fábrica, mas a visão gerencial do framework e seus impactos positivos e negativos, com base no modelo organizacional, estudado previamente.

John Kotter, especialista em gerenciamento de mudanças ressalta que “nenhuma pessoa sozinha, até mesmo um CEO de estilo autoritário, consegue desenvolver a visão correta, comunicá-la para uma grande quantidade de pessoas, eliminar todos os obstáculos principais, vencer etapas de curto prazo, liderar e gerenciar dezenas de projetos de mudança e fixar novas abordagens profundamente na cultura da empresa” (1996, 51-52).

Sem o apoio da diretoria que são os grandes responsáveis e os maiores interessados na evolução e continuidade da empresa no mercado, qualquer mudança é utópica.

Tenho identificado muita implantação "teórica" do framework, e não basta implantá-lo teoricamente, é preciso torná-lo um caso de sucesso na empresa contratante.

A visão do framework tem que atender as expectativa do cliente, e sua implantação, a princípio, deve começar com projetos pequenos, porém de relevância considerável para a empresa.

Bala de Prata

Sabemos que o framework Scrum não é a bala de prata que solucionará todos os problemas de gestão de projeto nem tão pouco os problemas identificados nos processos de Engenharia de Software e que nenhum dos processos ágeis descritos por seus criadores é perfeito para as empresas. Diversos fatores, inclusive os culturais e principalmente o nível de maturidade, deverão ser levados em consideração, como levantado no post anterior.

Taiichi Ohno, criador do Sistema Toyota de Produção, escreveu que “há algo chamado trabalho padrão, mas padrões devem ser alterados constantemente. Se você considera o padrão como melhor que pode fazer, não há avanço”. E ainda afirma que se estabelecemos algo como “melhor maneira possível, a motivação do Kaizen [melhoria contínua incremental] deixará de existir” (1982).

Antes da implantação do framework Scrum, realizei a analise das instalações da fábrica, a infraestrutura tecnológica, os processos praticados na empresa, a estrutura organizacional, o modelo organizacional, o sistema de gestão, a existência de planos de capacitação, a garantia da qualidade dos produtos e o nível de maturidade com base nas certificações existentes.

A revisão das áreas que compõem a Fábrica de Software teve como objetivo a identificação do nível de maturidade, fornecendo subsidio para avaliação da possibilidade da institucionalização e prática do framework Scrum, como metodologia padrão de gestão, para projetos de pequeno, médio e grande porte.

Segundo Mike Cohn, "qualquer um deles (processo ágil) pode ser um bom ponto de partida, mas você terá que adaptar o processo para que ele se ajuste mais precisamente as circunstâncias exclusivas de sua empresa, as pessoas e o segmento da indústria. (2011, 28)

A implantação do novo modelo reduziria o risco no projeto, aumentaria o controle de versionamento, o controle de mudanças, aliás, bem-vindo à metodologia, viabilizaria as entregas de releases funcionais em curto espaço de tempo, e estes benefícios seriam garantidos pelos três valores praticados no framework Scrum:

Transparência
Inspeção
Adaptação

Alistair Cockburn concorda com a afirmação acima: "Ter a chance de mudar ou adaptar um processo para aumentar sua conformidade parece ser um fator crucial de sucesso para a equipe que está adotando. É o ato de criação que parece aderir às equipes ao seu próprio processo".

Durante o trabalho de análise, pude identificar que ao longo dos anos em que a empresa atua no mercado, sempre sofreu com as constantes reclamações dos clientes, relacionada aos atrasos nas entregas dos sistemas, por falhas no entendimento do domínio do negócio, participação incipiente dos gestores do projeto e baixa qualidade tanto no produto quanto na documentação gerada para o usuário final.

Após identificar essas pequenas fraquezas, no entanto, ainda ficamos com o problema de como eliminá-las. É difícil (e com frequência impossível) prever exatamente como as pessoas responderão às várias pequenas mudanças que serão necessárias no percurso de se tornar ágil.

Não é possível direcionar um sistema vivo, só perturbá-lo e esperar para ver a resposta... Não temos como conhecer todas as forças que moldam a empresa que queremos mudar, portanto, só podemos provocar o sistema de alguma forma fazendo testes com uma força a qual achemos que possa ter algum impacto e, em seguida, observar para ver o que acontece.

O processo de implantação do framework Scrum passou por várias fases, gerando uma dinâmica diferente na empresa. Dentre elas podemos destacar a fase de seleção dos recursos que mais se identificavam com a metodologia e que após a implantação do framework participaram dos primeiros projetos fazendo uso do Scrum, o que culminou na implantação do novo modelo de gestão em todos os projetos.

Fundamentando Conceitos

Objetivando fundamentar conceitos que foram aplicados na consultoria começo agora a fazer introdução a conceitos relacionados com o framework Scrum. Abordando conceitos relacionados ao valor ao negócio, a origem da abordagem ágil, o framework ágil, o entendimento do manifesto ágil, os doze princípios ágeis, os valores do Scrum, os papeis do Scrum, a contribuição do Scrum, o modelo tradicional Waterfall, o modelo iterativo e incremental, comparação entre o modelo ágil e o tradicional.

Valor ao Negócio

O principal objetivo no desenvolvimento de um sistema é a remoção de uma restrição no negócio do cliente, e podemos entender como restrições todos os impedimentos que impactam no desenvolvimento do negócio de uma organização, e quando automatizados, sistematizados, agregam valor ao negócio. Desta forma um sistema ou software tem como missão ajudar a remover as restrições, os impedimentos, para que o negócio possa obter os resultados esperados.

A Origem do Framework Scrum

O lançamento do livro "The New Product Development Game" (Harvard Business Review, Janeiro-Fevereiro1986), baseado no conceito Lean de desenvolvimento de software, marcou a introdução do conceito do framework Scrum, tendo sua aplicação prática no mercado na Easel Corporation e sob a liderança de Ken Schwaber, Beedlee Sutherland em 1995.

Apesar de identificarmos, ao longo dos vinte anos, a existência de algumas metodologias ágeis, foi o ano de 2001 que marcou a grande disseminação das abordagens ágeis. Um grupo formado por dezessete pessoas que se auto intitularam anarquistas organizacionais, reuniram-se em uma estação de esqui em Utah nos EUA, cujo principal objetivo era discutir sobre as melhores maneiras de gerenciar e desenvolver softwares. Participaram desta reunião os principais responsáveis pelas teorias e aplicações dos diversos métodos de desenvolvimento. Fizeram parte desse encontro: Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas.

Desse encontro nasce o Manifesto Ágil e a formação da Aliança Ágil, uma organização sem fins lucrativos destinados a promover a adoção dos métodos Ágeis.

O Framework Ágil

O Scrum não é um processo ou uma técnica para construir produtos. O framework nos diz o que fazer, mas não como fazer, usando uma sequência lógica de gestão de processos começando com o desenvolvimento da Visão do Produto, onde questionamos: o que vamos fazer e qual o objetivo do sistema?

As respostas às perguntas anteriores nos levam ao segundo passo do framework que é a elaboração do Backlog do Produto, onde listamos todos os requisitos priorizados pelo Dono do Produto[1], ou Product Owner em inglês.

O terceiro passo seria o Planejamento da Sprint que propõe a revisão do Backlog do Produto, acordando com o Dono do Produto a definição do objetivo da Sprint, culminando na formação e estimativa do Backlog da Sprint.

O Backlog da Sprint é composto pelos requisitos selecionados para formação da Sprint, com suas tarefas estimadas pelo time.

O quarto passo proposto pelo framework são as reuniões diárias, onde a equipe responde a três perguntas que ajudam a inspecionar o processo. O gráfico burndown ajuda no acompanhamento da evolução da Sprint, registrando a sua evolução e desvios.

O próximo passo proposto no modelo seria a Revisão da Sprint, onde teremos a demo do software e o feedback do dono do produto atestando a qualidade ou não do sistema em desenvolvimento.

Na Retrospectiva da Sprint verificamos o que deu certo durante a Sprint e o que precisamos melhorar. Nesta fase registramos todas as lições apreendidas durante o ciclo de vida do desenvolvimento da Sprint. O Produto gerado no final de cada Sprint é um incremento do software pronto e potencialmente usável.

No framework você pode empregar vários processos ou técnicas de Engenharia de Software. O Scrum deixa clara a eficácia relativa das práticas de gerenciamento e desenvolvimento de produtos, de modo que você possa melhorá-las. Permite tratar e resolver problemas complexos e adaptativos, entregando produtos com o mais alto valor possível para o negócio do cliente.

[1] Dono do produto: durante o desenvolvimento do estudo de caso vamos usar esta denominação em português para o cliente.

Entendendo o Manifesto Ágil

O Manifesto Ágil documentou também os doze princípios orientadores para o desenvolvimento ágil e definiu uma filosofia em torno de um conjunto de metodologias existentes.

O texto original do manifesto diz o seguinte:

“Estamos descobrindo maneiras melhores de desenvolver softwares fazendo-o nós mesmos e ajudando outros a fazê-lo. Através deste trabalho, passamos a valorizar: Indivíduos e interação entre eles mais que processos e ferramentas. Software em funcionamento mais que documentação abrangente. Colaboração com o cliente mais que negociação de contratos. Responder a mudanças mais que seguir um plano. Ou seja, mesmo havendo valor nos itens à direita, valorizamos mais os itens à esquerda.” (http://manifestoagil.com.br)

Indivíduos e interações, mais que processos e ferramentas

Não precisa ser uma equipe formada por gênios, mas por desenvolvedores comuns que façam uso constante da comunicação, este perfil é fundamental na formação de uma equipe ágil. A habilidade dos recursos e a interação entre eles garantirão o sucesso do projeto. Os recursos devem ser capacitados, ter experiência e naturalmente conhecerem os processos da empresa. Porém, também sabemos que os processos não salvam um projeto do fracasso, pessoas capazes sim, por isso, o framework preza mais pelos indivíduos e as interações entre eles. O que não descarta na implementação do Scrum a definição ou correção dos processos existentes na empresa, pois para sermos ágeis precisamos antes sermos organizados e é a organização quem garantirá a agilidade.

O mesmo se dá com frequência na adoção das ferramentas, já que só obtemos os recursos produtivos esperados, se a equipe envolvida tem domínio sobre elas, pois a curva de aprendizagem pode se tornar um risco para o projeto pela falta de capacitação da equipe na ferramenta. Cabe aqui o conceito de simplicidade.

Software em funcionamento mais que documentação abrangente

O Scrum não aboliu a documentação do sistema, muito pelo contrário a tornou mais inteligente com base em seu processo interativo e incremental. Neste modelo a documentação é dividida em dois momentos:

No primeiro organizamos as informações para saber o que fazer e quais os objetivos do sistema orientarão o planejamento do Backlog da Sprint e a formação da Sprint. O segundo momento documenta o que de fato foi implementado, seguindo o processo interativo e incremental, é o que denomino como documentação consequente. A grande vantagem neste modelo é que documentamos o que de fato foi implementado, uma vez que sabemos que a única certeza que temos em um projeto é a mudança.

Temos como premissa não produzir qualquer documento, cuja necessidade não seja imediata e significativa para o projeto.

Colaboração com o cliente, mais que negociação de contrato

Existia aqui uma grande queda de braço entre o time de desenvolvimento e o cliente. Com o objetivo de delinear o escopo na elaboração da proposta o time defendia a ideia de enxugar ao máximo a quantidade de funcionalidades, pois não conhecia os meandros do projeto, os seus riscos e a quantidade de mudanças que poderiam encontrar no tempo de projeto. Do outro lado o cliente forçava para colocar o máximo de funcionalidades, pois uma vez fechado o contrato não haveria mais alteração no escopo, sem a geração de custos para o projeto.

Os softwares inteligentes variam de acordo com o negócio do cliente, e são únicos. Um projeto com domínio de negócio complexo não podem seguir um cronograma rígido e cuja participação do cliente só aconteça no final.

A framework ágil tem como fundamento o envolvimento do cliente em todas as fases do projeto, para nós denominado “coautor do sistema”. Nada mais inteligente, pois é ele quem conhece o domínio do negócio e é o feedback regular e frequente do cliente que nos garantirá o sucesso do projeto.

Em um contrato não conseguimos especificar todas as complexidades dos requisitos, e refletir em um cronograma fixo os meandros, as particularidades que o domínio do negócio nos imputará ao logo do ciclo de vida do sistema, pois não somos os especialistas no negócio. Os contratos devem regular as relações entre cliente e fornecedores, norteando o modo como a equipe de desenvolvimento e o cliente trabalharão juntos, e esse foi o nosso diferencial.

Colaboração com o cliente, mais que negociação de contrato

Resposta a mudanças, mais que seguir um plano

Toda mudança é bem-vinda. A equipe Scrum reconhece que a única certeza que temos em um projeto são as mudanças. Mesmo porque, não somos especialistas em todos os domínios de negócio existente, e o conceito de unicidade dos projetos nos torna flexíveis, pois ao logo do desenvolvimento podem existir divergências no entendimento, por não conhecermos a fundo o seu domínio. É durante o ciclo de vida do projeto que o time de desenvolvimento aprende sobre o domínio do negócio, em contato constante com o especialista do negócio, representante legal da empresa. Essa flexibilidade, característica fundamental das equipes ágeis, possibilita que o time responda rápido as mudanças.

Os 12 Princípios Ágeis

Nossa maior prioridade é satisfazer o cliente, por meio da entrega adiantada e continua de software de valor.
Aceitar mudanças de requisitos, mesmo no fim do desenvolvimento. Processos ágeis se adequam às mudanças, para que o cliente possa obter vantagens competitivas.
Entregar software funcionando com frequência, na escala de semanas até meses, com preferência aos períodos mais curtos.
Pessoas relacionadas à negócios e desenvolvedores devem trabalhar em conjunto e diariamente, durante todo o curso do projeto.
Construir projetos ao redor de indivíduos motivados. Dando a eles o ambiente e suporte necessário, e confiar que farão seu trabalho.
Contínua atenção à excelência técnica e com design, aumenta a agilidade.
O método mais eficiente e eficaz de transmitir informações para e por dentro de um time de desenvolvimento é através de uma conversa cara a cara.
Software funcional é a medida primária de progresso.
Processos ágeis promovem um ambiente sustentável. Os patrocinadores, desenvolvedores e usuários, devem ser capazes de manter indefinidamente, passos constantes.
Simplicidade: a arte de maximizar a quantidade de trabalho que não precisou ser feito.
As melhores arquiteturas, requisitos e designs emergem de times auto organizáveis.
Em intervalos regulares, o time reflete em como ficar efetivo, então, se ajustam e otimizam seu comportamento de acordo.

(http://manifestoagil.com.br)

Os Valores do SCRUM

Os valores do Scrum têm como base a transparência, a inspeção e a adaptação.

O valor transparência exige que todos os envolvidos no projeto conheçam os aspectos significativos do processo e do projeto. A visibilidade é fundamental para comunicação da equipe, colocando todos na mesma página. A clareza nas informações possibilita que todos tenham o mesmo entendimento, pois todos envolvidos tem que falar a mesma linguagem independente de para quem a pergunta foi formulada, a resposta tem que ser a mesma.

O valor inspeção garante o bom andamento do projeto e viabiliza a adaptação, o terceiro valor do Scrum. Os processos, as práticas e atividades devem ser inspecionadas constantemente para mantermos o projeto dentro do planejado nas Sprints, detectando os desvios o mais cedo o possível. A inspeção também garante que o sistema atenderá os requisitos do negócio, garantindo assim a qualidade do sistema.

O valor adaptação garante as correções dos desvios ao longo do ciclo de vida do desenvolvimento da Sprint, e serve como lição aprendida nas reuniões de retrospectivas do Scrum, evitando que erros detectados nas Sprints anteriores ocorram novamente ao longo do ciclo de vida das demais Sprints. Fazem parte do valor Adaptação quatro eventos formais que são utilizados para inspeção e adaptação:

Reunião de planejamento da Sprint.
Reunião diária
Revisão da Sprint
Retrospectiva da Sprint

A Adaptação depende da Inspeção e a Inspeção depende da Transparência.

Os Papeis do Scrum
Podemos identificar no Scrum três papeis bem definidos, o Dono do Produto ou PO – Product Owner, o Scrum Master e o Time de Desenvolvimento.
O Dono do Produto tem como função principal garantir o ROI - Return on Investment do produto, conhecendo as reais necessidades dos usuários e stakeholders. Dentre as suas habilidades podemos destacar a necessidade da visão estratégica e entendimento do que é valor para o cliente por ele representado, a capacidade de comunicação para conseguir trabalhar em conjunto com os stakeholders capturando as necessidades do cliente e usuários, a facilidade para estabelecer e comunicar a visão do produto para todos os envolvidos, autoridade para exercer suas responsabilidades, o comprometimento com o projeto, as habilidades de negociação, o bom relacionamento interpessoal e o conhecimento sobre o Scrum.
O Scrum Master deve ser um profundo conhecedor da metodologia, tendo domínio sobre suas regras, papéis, eventos e artefatos. Ele atua como mentor, auxiliando o Time de Desenvolvimento e o Dono do Produto a trabalhar melhor com o Scrum. É um facilitador, e deve também, possuir habilidades de comunicação e negociação, além de ter algum conhecimento técnico, saber blindar a equipe contra interferências externas e dar suporte para que o Time de Desenvolvimento seja funcional e produtivo.
O Time de Desenvolvimento, da mesma forma que o Scrum Master, precisa conhecer o framework Scrum, como as suas regras, papéis, cerimônias e artefatos, trabalhar sempre de forma colaborativa, atuando com transparência e sempre buscando entregar o máximo de valor ao negócio. Suas atividades devem estar pautadas pelo conceito de melhoria continua, trabalhando com qualidade e produtividade e principalmente, dado ao número reduzido de papeis, o time deve ser auto organizável.

A Contribuição do Scrum

Oposto ao período de participação do cliente no modelo tradicional cascata, a framework Scrum propõe a participação ativa dos interessados em todas as fases ou Sprints do projeto, mudando o cenário anterior, permitindo a construção e entrega do software por partes ou releases.
O cliente tem a liberdade, com base no domínio do negócio, de solicitar o que ele desejar e quando desejar. As mudanças são facilitadas e fazem parte do processo de desenvolvimento.
No framework ágil o desenvolvimento de um projeto de software não pode ser planejado com muita antecedência, mesmo porque o domínio do negócio pode sofrer mudanças, fazendo com que os requisitos mudem também. Projetos longos com entregas previstas no final e sem a participação de stakeholders ao longo do desenvolvimento aumentam o risco do projeto. A grande vantagem da metodologia são as entregas parciais que geram conforto e confiabilidade para os stakeholders, pois eles começam a ver o sistema funcionar ao longo do seu ciclo de vida.
As pequenas releases que agregam valor ao negócio do cliente seguem planejamentos detalhados para as primeiras semanas de desenvolvimento, são flexíveis para a próxima Sprint, aproximados para os próximos três meses e extremamente rudimentares para além dos três meses, ou seja, devemos saber quais tarefas individuais estaremos trabalhando na próxima semana, conhecer em linhas gerais os requisitos nos quais estaremos trabalhando nos próximos três meses e ter apenas uma vaga ideia do que o sistema fará depois de um ano.
Mike Cohn relata em seu livro que “uma razão pela qual os stakeholders estão tão satisfeitos é o time-to-market reduzido com o uso de um processo ágil como o Scrum. Esse time-to-market[1] mais veloz é gerado pela produtividade mais alta das equipes de desenvolvimento ágil, que, por sua vez, é resultado da qualidade mais alta em projetos de desenvolvimento ágil, já que, os funcionários ficam livres para fazer um trabalho de alta qualidade, e veem seu trabalho sendo entregue mais cedo para os usuários que estão esperando. Desta forma, a satisfação no trabalho aumenta. Com uma satisfação no trabalho mais alta vem um maior engajamento dos funcionários, o que leva a um maior ganho de produtividade, iniciando um eficiente ciclo de melhoria contínua”.

[1] É o tempo de colocação do produto no mercado, sem que afete o nível de demanda e oferta do mesmo.

Engenharia de Software

Páginas

SCRUM

Software em funcionamento mais que documentação abrangente

Nenhum comentário :

Postar um comentário