Engenharia de Software | Gerenciamento de Projetos de Software | Lean, Kanban e eXtreme Programming
Desenvolvimento de software enxuto
O Lean não é especificamente uma metodologia ágil, porém muitos de seus valores estão presentes em valores ágeis e sua adoção pode agregar muitos valores em diversas outras metodologias e boas práticas. Baseado na metodologia desenvolvida pela Toyota conhecida como Lean Manufacturing.
O Lean está diretamente ligado à redução do desperdício. Para o Lean, desperdício é tudo que não é feito para o cliente, e no caso dos softwares podemos ter: espera (tempo de desenvolvimento parado por falta de informações), documentação excessiva, funcionalidades e rotinas não solicitadas pelo cliente.
Conceitos do Lean
O Lean Software Development identifica sete conceitos principais, são eles:
1 – Eliminar o desperdício: Para maximizar o valor, precisamos minimizar o desperdício. O Lean classifica o desperdício em 3 categorias:
MURA: Desperdício gerado por antecipar possíveis necessidades do cliente (desenvolver o que não foi solicitado pelo cliente acreditando que um dia poderá ser útil. Esse conceito está muito próximo ao de Gold Plating, do gerenciamento de projetos). Podemos diminuir a MURA evitando desenvolver o que não foi solicitado e evitando paradas em trabalhos ainda não terminados;
MURI: Desperdício gerado pela falta de planejamento (ou planejamento malfeito). Na MURI também classificamos o desperdício causado pelo excesso de burocracia;
MUDA: Desperdício gerado pela cultura de trabalho, desperdícios do dia a dia, como: espera, superprocessamento, defeitos, locomoção, inventário, transporte desnecessário e superprodução.
2 – “Empoderar o time“: Em vez da abordagem de microgestão, devemos respeitar o conhecimento superior dos membros do time e deixar que eles sejam responsáveis pelas decisões técnicas (locais) necessárias, para tornarem-se mais produtivos e bem-sucedidos, aumentando as chances de sucesso do projeto.
3 – Entregar rapidamente: Podemos aumentar o Retorno sobre Investimento (return on investment) – ROI com entregas de valor rápidas. Com entregas rápidas e frequentes o cliente já pode iniciar o uso do software (das funcionalidades já desenvolvidas) gerando valor mais rapidamente para o investimento realizado no desenvolvimento. Como o cliente prioriza o que deve ser feito primeiro, funcionalidades mais importantes (e as de maior risco, assunto que será tratado mais adiante) geralmente são produzidas mais cedo, e consequentemente, entram em uso mais cedo, gerando maior retorno.
4 – Otimizar o todo: Para o Lean o sistema não é apenas a soma de suas partes, devemos observar além de cada parte e como todas estão alinhadas aos interesses de negócio da empresa e como otimizá-las da melhor forma possível.
5 – Construir com qualidade: O Lean não testa a qualidade no final do processo. A qualidade do produto final deve ser assegurada com a qualidade de cada etapa/parte do processo utilizando técnicas como refatoração, integração contínua e muitas outras que veremos mais adiante.
6 – Adiar decisões: Parece estranho esse conceito mas a mensagem aqui é equilibrar o planejamento antecipado com a tomada de decisões e decidir o mais tarde possível. Veja que não se está defendendo a procrastinação, mas sim esperar o máximo possível antes de decidir. Em muitos projetos na fase inicial estamos decidindo baseado em várias premissas (lembrando, premissa – eventos incertos que para fins de planejamento consideramos como verdadeiros, o que na execução do projeto não necessariamente será verdadeira), o que sempre traz riscos ao projeto, como estar restrito a uma solução limitada por uma tecnologia disponível até o momento.
7 – Amplificar aprendizagem: Esse conceito envolve facilitar a comunicação cedo e sempre, promovendo o feedback o mais rápido possível, e aprendizado contínuo com base no que aprendemos sobre projetos, softwares e negócios.
Kanban
Antes de iniciarmos o tópico sobre o KanBan, conheça uma história sobre os jardins do palácio imperial Japonês. Em Abril, centenas de visitantes vão aos jardins do palácio para apreciarem as flores de Sakura (flor de cerejeira). Como os jardins, apesar de grandes, são limitados fisicamente, existe um controle de cartões de entrada e saída. Um visitante, para entrar nos jardins, precisa de um cartão, esse cartão é retirado na entrada e devolvido na saída. Um novo visitante só entra se tiver cartões disponíveis. O que esse cartão controla? O número de atividades (pessoas) que os jardins são capazes de atender. Um controle simples e eficiente garante o atendimento sem prejudicar a qualidade do serviço.
O KanBan possui a mesma filosofia dos cartões, é uma ferramenta visual que auxilia o acompanhamento do fluxo de trabalho e controle do WIP (Work in progress, “Trabalho em progresso”).
O quadro KanBan permite visualizar o trabalho que está em andamento e limitar o WIP. Tradicionalmente (mas não é uma regra), o quadro KanBan é dividido em quadros ou status como Do (A Fazer) – Doing (Fazendo) – Done (Feito), as tarefas que precisão ser realizadas são listadas (ou “coladas“) na parte A Fazer, quando elas começam a ser feitas, elas mudam para o status Fazendo e quando estão (totalmente) prontas, vão para o status Feito. Os status podem ser completamente diferentes, por exemplo, no caso de desenvolvimento de software poderíamos ter Modelado, Em Desenvolvimento, Desenvolvido, Em Implantação, Pronto. Ou qualquer outro estado que faça sentido para o trabalho e para a equipe.
Utilidades do quadro Kanban
O Quadro KanBan possui quatro características que se agregam à execução do trabalho. Observe:
Visualizar o fluxo de trabalho
O quadro KanBan é uma excelente ferramenta “Low-Tech, High Touch”. Quando inserimos a tarefa (ou funcionalidade) no quadro, tornamos o trabalho tangível, o que é um desafio para gerentes de projetos de softwares e serviços. A visualização nos permite identificar onde estão ocorrendo os gargalos no fluxo de trabalho e assim melhorar os processos redesenhando-os ou redimensionando a equipe em cada tarefa.
Limitar o WIP (trabalho em progresso)
O trabalho, até estar pronto para o uso, é custo, por exemplo, uma funcionalidade em desenvolvimento que ainda não é utilizada agrega algum valor para a empresa? Um serviço que está sendo desenhado, agrega ? NÃO ! Só temos valor quando a funcionalidade ou serviço podem ser utilizados pela empresa. Uma das regras mais importantes para qualquer metodologia ou framework ágil é “entregar mais que iniciar“.
Tornar regras e processos explícitos
Com o quadro é mais fácil discutir os trabalhos que estão em andamento, que precisarão ser feitos e como um trabalho em andamento poderá impactar outro.
Colaboração
A percepção visual do trabalho facilita o debate aberto do time sobre como resolver atividades que estão ”engarrafando” o fluxo, além de dar a percepção do todo (do conjunto de atividades feitas, fazendo e a fazer).
eXtreming Programming
Para entendermos o XP, inicialmente devemos compreender seus valores. Esses são conceitos não tangíveis que acredita-se fazer uma grande diferença na qualidade final do produto e na motivação dos times. O primeiro deles é a Comunicação. O valor da comunicação é visto dentro do time, entre seus membros, e entre o time e o cliente. Ambos têm igual importância.
A comunicação deve ser:
- Direta;
- Eficaz;
- Esclarecedora.
Feedback
É um valor que engloba as relações interpessoais, mas também se refere ao feedback que o próprio código do projeto devolve aos membros do time. Para que o feedback do código funcione bem, são necessários testes automatizados de unidade e um servidor de integração contínua para que os testes mais longos sejam rodados com frequência e, se quebrarem, sinalizem uma inconsistência.
Com o feedback o cliente pode:
- Identificar erros rapidamente;
- Definir prioridades.
Coragem
O XP prega que os desenvolvedores precisam ter coragem para refatorar o código em prol de melhorias em clareza e design – e nada melhor para dar coragem do que testes automatizados.
Coragem é também apagar o código, mesmo funcionalidades inteiras, não importa o trabalho que tenha sido empregado para desenvolvê-la.
Coragem para não tentar prever o futuro, mas sim focar no que é realmente necessário no momento. XP associa a essa ideia a sigla YAGNI (you ain’t gonna need it – você não vai precisar disso).
Simplicidade e propriedade coletiva do código
Considere que, na média, o tempo de construção de um software é cerca de 30% do tempo investido nele. Os outros 70% são dedicados a manutenção do sistema. Neste tipo de cenário, a simplicidade é essencial para tornar esse período maior muito agradável.
Além disso, é comum que desenvolvedores trabalhem em partes independentes do código. A consequência dessa abordagem é que cada desenvolvedor se sente responsável apenas por sua parte. O ideal é o sentimento de time onde todos são responsáveis pelo código. Assim, um desenvolvedor é livre para interferir em qualquer parte do código sem irritar o “dono” do código.
Programação pareada
A programação em par é uma forma eficaz de reduzir a incidência de bugs em um sistema. Quem trabalha continuamente com programação em par se habitua a corrigir e ter seu trabalho corrigido dezenas de vezes ao dia.
A incidência de erros identificados pelo colega costuma ser tão elevada que surpreende quem não está acostumado ao uso da técnica e as equipes que trabalham em par conseguem reduzir drasticamente a inserção de defeitos em seus códigos.
A programação em par ajuda os desenvolvedores a criarem soluções mais simples, mais rápidas de implementar e mais fáceis de manter. A programação em par também é uma forma de fazer com que o desenvolvedor tenha mais confiança no código que produz. Observe que todas essas características fazem com que a programação em par acelere o desenvolvimento significativamente, embora à primeira vista pareça o contrário.
Programar em par exige que as pessoas envolvidas sejam receptivas, compreensivas umas com as outras, engajadas e, sobretudo, humildes. É necessário aceitar que somos falíveis para que possamos programar em par. Jerry Weinberg, no livro The Psychology of Computer Programming, apresenta o termo egoless programming, ou seja, programação sem ego.
Testes automatizados e refatoração
Um dos grandes desafios é trabalhar em códigos antigos. O XP prega a refatoração constante. Mas, quanto maior o projeto, maior é a quantidade de código não escrita por nós ou antigo, o que aumenta a insegurança de refatorar o código, impedindo a evolução do projeto.
Com o aumento do projeto é comum que pequenas partes de código mal escrito se acumulem e, quando menos se esperar, compromete todo o projeto. Esse conceito foi nomeado por Joe Yoder como “Big Ball of Mud”. A melhor forma de evitar esse problema é através de pequenas refatorações constantes.
O autor Martin Fowler define refatoração como uma técnica controlada para reestruturar um trecho de código existente, alterando sua estrutura interna sem modificar seu comportamento externo.
Funções dos testes automatizados
O XP prega o uso extensivo de testes automatizados que descrevem o comportamento de uma funcionalidade, preferencialmente escritos antes mesmo do código que eles testam, prática que recebe o nome de desenvolvimento dirigido por testes (test Driven Development – TDD). Os testes automatizados tem duas funções importantes:
Permitir refatoração: Podemos refatorar o código com mais segurança. Isto é, podemos alterar o código e verificar automaticamente se o software continua funcionando.
Documentar: Os testes devem ter nomes que explicam quais funcionalidades eles testam, assim, ao executar o código, o desenvolvedor sabe quais funcionalidades foram implementadas e qual o comportamento esperado pelo código.
RIBEIRO, Rafael Dias; CUNHA, Horácio da; RIBEIRO, Sousa. Gerenciamento de Projetos com Métodos Ágeis. Rio de Janeiro: [s.n.], 2015. ISBN:9788591910212. Disponível em: <http://www.saraiva.com.br/gerenciamento-de-projetos-com-metodos-ageis-8890292.html>
Outros:
Lean para desenvolvimento de Software. Afinal, o que é isto?
https://www.lean.org.br/artigos.aspx
Engenharia de Software | Gerenciamento de Projetos de Software | Lean, Kanban e eXtreme Programming