Por que usar scrum?

Por que scrum?

     A indústria de desenvolvimento de software evoluiu para se tornar uma das mais importantes instituições de nosso tempo, criando produtos essenciais para o nosso dia a dia. Inúmeros exemplos podem ser citados. Neste ambiente intensamente competitivo, diferenciais devem ser criados para a sobrevivência. A capacidade de criar e de entregar mais rapidamente produtos de software que melhor satisfaçam as necessidades reais do cliente é um deles.

     Segundo PMI Brasil 2006, os problemas mais frequentes em gerenciamento de projetos levantados são:

- não cumprimento de prazos (72%)

- problemas de comunicação (71%)

- mudança de escopo (69%)

- estimativa errada de prazo (66%)

     Analisando os problemas levantados, pode-se constatar que o cerne da questão reside principalmente na comunicação - refletindo nos demais. Quando presentes, mecanismos de comunicação ineficientes são utilizados, contribuindo para a falta de compreensão e colaboração por parte dos envolvidos.

      A figura 1 promove uma comparação entre a efetividade de comunicação e a "riqueza" do canal de comunicação. Dois mecanismos são evidenciados: os que não possuem perguntas e respostas e os que possuem. Este primeiro tipo propõe pouca interação e não permite a colaboração e troca necessária para o alcance do objetivo proposto. A utilização de papel para descrever e comunicar o problema tem importante cunho "documental", além de poder ser compartilhado entre diversas pessoas.

     Por outro lado, mecanismos que promovem e facilitam a comunicação, os mecanismos interativos, são compostos por perguntas e respostas - como duas pessoas falando ao telefone ou discutindo via e-mail são notoriamente mais eficientes. E ainda torna-se mais eficiente se tivermos a presença física na mesma sala dos diversos envolvidos. Para completar, um quadro branco, auxiliando na dinâmica das discussões, pode expandir em muito as possibilidades de entender e se fazer entendido.

Figura 1. Temperatura da comunicação, segundo Alistair Cockburn.

     Comunicação "face-to-face" é uma das formas de se resolver grande parte dos problemas citados e, metodologias ágeis, como o scrum, pregam incessantemente esta prática. O manifesto ágil, criado em 2001, instituiu valores e princípios da escola que corroboram com o descrito acima. Abaixo os quatro valores principais: "nós estamos descobrindo melhores formas de se desenvolver software, fazendo software e ajudando os outros a fazê-lo."

Através deste trabalho nós viemos valorizar:

1. indivíduos e interações primeiro que processos e ferramentas.

2. software funcionando primeiro que documentação compreensiva.

3. colaboração do cliente primeiro que negociação contratual.

4. resposta a mudanças primeiro que conformidade com planejamento.

     É importante destacar que não há ruptura entre os itens da esquerda e os da direita, e sim de ênfase. A comunicação irá auxiliar em cada um dos itens da esquerda e será o grande facilitador desse processo.

     O interessante deste tipo de abordagem é que não se tem a procura por um culpado. Todos estão imbuídos na busca da melhor solução para a organização, seja o analista, desenvolvedor, gerente de projeto ou o cliente. 

     E cada um tem o seu papel claramente determinado frente ao processo de desenvolvimento. Em metodologias ágeis, uma das premissas básicas é ter o cliente sempre por perto e fazê-lo um participante ativo. É importante que ele entenda suas responsabilidades e sua grande parcela de contribuição para o sucesso do projeto.

     Algumas questões diferenciam metodologias ágeis no planejamento do projeto. Nas metodologias ágeis, o planejamento é feito continuamente, durante todo o projeto, e baseado em um goal (objetivo), no qual são definidas as tarefas necessárias para se iniciar o mesmo. Este objetivo serve como um guia para todos os envolvidos e é a meta a ser perseguida. 

     Normalmente, é um parágrafo que resume, em três ou quatro frases, o foco maior que o projeto deve ter. Seu estabelecimento visa delegar à equipe do projeto um espaço de agilidade que a permita tomar decisões rápidas ao longo do projeto, norteando-o quanto a alterações de prioridades, de requisitos, práticas ou outras quaisquer.

      Se todo o planejamento fosse feito no início do projeto, após as primeiras semanas, o longo planejamento feito poderia estar defasado, pois as mudanças ocorreriam e o forçariam a esta situação. Requisitos não devem ser intensamente esgotados no início do projeto, eles sim, são incrementados a cada iteração, experimentados pelos envolvidos, colocados a prova, avaliados e refinados.

   É importante construir o todo aos poucos, refinando os requisitos, equalizando o entendimento sobre eles e corrigindo o rumo sempre que uma mudança provoque alterações significativas.

   Planejar detalhadamente é ir contra a natureza do processo de desenvolvimento de software. As tarefas que constituem este tipo de abordagem fazem parte de um processo criativo, não linear e não palpável, fazendo com que modelos ágeis se apresentem como uma alternativa interessante. Por isso, planos menos detalhados e feitos em frequência maior mostram-se mais adequados.

    A forte presença de iterações curtas também contribui para o planejamento contínuo citado. Elas garantem ritmo a todos os envolvidos e levam ao feedback real e imediato dado pelo cliente. Como resultado, auxiliam nos possíveis ajustes - que não acontecem mais tardiamente - e ajudam na entrega de software de valor. Cada uma das iterações é composta de todas as tarefas necessárias a esta entrega: levantamento de dados, análise, projeto, implementação, testes e integração à versão anterior.

     Outro ponto interessante é a maneira pela qual o monitoramento e a medição do projeto são executados em metodologias ágeis. Cada tarefa definida é verificada quanto ao seu percentual de andamento (o mais usual) e também quanto à sua qualidade através de testes e entregas que são feitas com maior frequência. O progresso do projeto não é medido levando em consideração o plano inicial feito, como em metodologias tradicionais, ou seja, não é traçado um quadro comparativo entre o que foi planejado no início e o que foi executado até o momento. Mudanças são aceitas e algumas "linhas de bases" farão parte do projeto. Dessa forma, o atendimento ao goal definido deve ser a principal medida de progresso sendo verificado, constantemente, para garantir o máximo de retorno para o negócio.

     A identificação e o gerenciamento dos riscos em metodologias ágeis são feitos em taxas diárias (através de reuniões curtas e diárias), e, durante toda a iteração, o controle da qualidade dos trabalhos é avaliado. Esta tarefa pode ser executada através de testes, revisão por pares, inspeção contínua e acompanhamento pelo cliente, que seguem o mesmo processo. Impedimentos são levantados e devem ser resolvidos no prazo máximo de 24 horas para garantir que ações de resolução rápidas sejam executadas e para que todos conheçam os impedimentos que podem se tornar potenciais riscos para o projeto.

     Além disso, mudanças no projeto são bem aceitas, pois elas existem e irão acontecer. É por isso que o comprometimento de todos os envolvidos é tão importante em um projeto. Caso o cliente queira mudar uma solicitação ou adequar-se a uma mudança de mercado, pode-se alterar o rumo rapidamente, sem afetar todo o projeto, pois o planejamento é refeito a todo o momento. E ainda, caso uma iteração não corra conforme o esperado pelo cliente, pode-se mudar a abordagem de levantamento de dados, os recursos envolvidos, a forma de troca de informações e corrigir o rumo a tempo do final do projeto.

     Pode ser (e na maioria das vezes é) que o plano inicial não represente mais a necessidade real de nosso cliente. Ele deixa de pedir alterações, pois o contrato já foi assinado; ele não tem mais horas adicionais para pagar; o prazo está curto e ele necessita do produto e, então... ele "evita" solicitar mudanças. Pergunta: o que ele ganha? De que adianta entregar um software que o cliente não irá usar? E o quê o fornecedor do serviço ganha? Ok, entrega-se o produto, o cliente usa poucas funcionalidades, reclama das funcionalidades prioritárias que ele não recebeu e, em contrapartida, recebeu várias outras que não vai utilizar. E isso pode ser considerado um projeto de sucesso?

     O sucesso de um projeto de software utilizando metodologias ágeis não é somente medido comparando projeções iniciais de prazo, custo e escopo, e sim, através de entrega de software de valor ao cliente. Estes três pilares - prazo, custo e escopo - devem ter seus pesos definidos. É claro que todos nós desejaríamos que nossos projetos terminassem dentro do prazo previsto, com o custo dentro da margem determinada e com todo o escopo entregue. Todos nós já passamos por fases posteriores de manutenções e correções que consomem grande esforço de recursos e também trazem desgaste no relacionamento das pessoas envolvidas.

Estraido da web aula unopar 2013