Agile Development: Problemas e Soluções no Scrum

Scrum é um framework para desenvolvimento de produtos. Nesse artigo, o foco será no desenvolvimento de software. É interessante notar a denominação de Scrum como framework e não processo. Isso porque, essa metodologia diz o que fazer, mas não como.

Por exemplo, as entregas devem ser incrementais e interativas a cada Sprint, provendo real valor ao cliente. Note que não é explicado como se dão essas entregas incrementais, qual o tamanho do incremento por produto, além de não se definir o que é valor para o cliente. Todos esses elementos são deixados em aberto, para que cada Time aplique o que achar mais conveniente para esses conceitos.

Scrum vem como resposta aos problemas que processos em cascata geram. Os processos em cascata focam na definição de processos para o sucesso do desenvolvimento de software. Além disso, a entrega do produto é feita após longas fases de análise e desenvolvimento, tendo-se feedback do cliente meses depois do início do projeto.

Além disso, mudanças são encaradas como problemas, pois qualquer modificação no produto ocasiona onerosa análise e alteração em documentações, até que ela seja efetivamente aplicada ao produto. Finalmente uma ampla documentação vem aliada ao software, pois se acredita que isso gere real valor ao produto.

Por outro lado, Scrum foca estritamente no produto, sendo associado um processo muito leve a ser seguido. Também, entregas são feitas de forma iterativa e contínua. Isso possibilita que o cliente utilize o produto desde o início do desenvolvimento, provendo feedback constante.

Feedback é outro ponto importante: eles são bem vindos e esperados, sendo sempre acomodados no Sprint seguinte, caso necessário. Documentação é outro ponto chave: Scrum não exige documentação e sim, novamente, foco no produto e por isso deve-se produzir o mínimo necessário de artefatos.

Uma questão interessante é a seguinte: “Se o Scrum é tão bom e simples de entender, por que é difícil de ser aplicado?”. Primeiramente, porque seus principais conceitos são quase que opostos ao que o desenvolvedor está acostumado com processos em cascata.

Por exemplo, a ideia de o Time ser responsável pelo produto e não pessoas serem responsáveis individualmente por tarefas vai à contra mão do que desenvolvedores estão acostumados. Também, entregas curtas, interativas, com valor e mesmo assim incompletas ou simplificadas geram bastante discordância, pois isso novamente contraria a metodologia empregada em processos em cascata. Finalmente, Scrum foca em pessoas e não em processos e, como bem se sabe, relações pessoais, mesmo que de trabalho, podem ser bastante complicadas.

A seguir é dada uma breve descrição de cada etapa e papel do Scrum, para que o leitor menos familiarizado com o framework possa entendê-lo um pouco melhor.

Entretanto, o foco do artigo são os conselhos a serem aplicados em cada fase dessa metodologia, discutidos depois da apresentação dos mesmos. Finalmente uma discussão é feita sobre aspectos do Scrum.

Scrum

Nessa seção é feita uma breve descrição de cada etapa do Scrum, bem como os papéis desempenhados, para contextualizar o leitor. Observe a Figura 1: ela representa alguns dos principais conceitos utilizados no Scrum e como eles estão associados.

Sprint

Sprint é o ciclo de desenvolvimento e entregas do Scrum. Nele é feito o planejamento, desenvolvimento, testes, entrega e revisão do processo utilizado. O tamanho do Sprint varia de projeto para projeto, de Time para Time.

Alguns duram uma ou duas semanas, outros um mês. O tamanho dele é descoberto, literalmente por tentativa e erro. O Time deve testar vários tamanhos de Sprint e escolher o ideal. O importante é que, depois de um tempo, ele tenha um tamanho constante, já que o Sprint dita o ritmo de desenvolvimento; e um ritmo constante dá dinamismo ao desenvolvimento.

Reunião Diária

Reunião de duração máxima de quinze minutos onde cada membro do Time deve responder a três perguntas ...