Processos de código - Extreme Programming

Depois do fracasso considerável de vários projetos no método Waterfall, várias propostas de metodologias ágeis surgiram, de todas, as três mais conhecidas são Scrum, Kanban e o Extreme Programming (XP para os íntimos).

A proposta do XP consiste em ser um método de desenvolvimento leve em projetos que tem por natureza serem mutáveis e com requisitos duvidosos. Como um dos métodos ágeis, o Xp trabalhará com ciclos de desenvolvimento curtos e com requisitos incrementais, ou seja, tudo pode ser adicionado, incrementado ou substituído de um ciclo para outro. Dada a natureza dos projetos, é necessário que ele seja falível também, adicionando a carga de correção de desenvolvimento dentro de cada ciclo.

O XP é um método abstrato, pode ser adequado a necessidade da equipe, porém possui um conjunto de diretrizes que são divididas em valores, princípios e práticas.

Valores

Dentre todos os valores que o XP traz, 3 se destacam: Comunicação, simplicidade e feedback. Comunicação para se passar adiante aprendizagens entre a equipe, aprender com seus erros e tratar qualquer dúvida de desenvolvimento entre si.

A simplicidade é um meio de enxergar as coisas, para todo sistema complexo existe pequenos subsistemas que são simples. A ideia do XP é sempre desmembrar o problemão em probleminhas que serão resolvidos pela equipe.

O feedback vêm como o controle de danos. Existem riscos em qualquer sistema, porém o risco sempre será maior se não soubermos que ele existe. A ideia do Extreme Programming é incentivar o feedback, seja com erros ou acertos, para que o quanto antes souber do que precisa ser mudado e/ou mantido, melhor seja a decisão e resolução da equipe.

Existem outros valores como qualidade de vida (isso existe pra desenvolvedor?), coragem e respeito, mas são autoexplicativos. Sejam fortes e corajosos como a Ju no BBB, galera!

Princípios

Os princípios do XP são a força que une os valores e as práticas. Muitos engenheiros descrevem como a ponte que liga de lado a lado um rio perigoso que são os requisitos de cliente.

Dentre todos os princípios, o principio inicial é humanidade. Querendo ou não, desenvolvedores são humanos. Quando falamos de humanidade para o XP, não estamos falando sobre a necessidade de um recursos humanos dentro do time, mas sobre a necessidade de gestão de pessoas, responsabilidades, transparência, evolução de carreira e motivação. Nada pior que um time que sofre com problemas de valorização do capital humano, o famoso peopleware. É necessário que o time esteja bem, afinal, quem cria software ainda são os humanos. Ainda.

Depois desse papo meloso, vem a realidade, o principio de economicidade é a parte relacionada a custos de um projeto. O desenvolvimento de um software é caro, os gastos com a equipe, o ferramental, alocação de dados e infra estrutura. Tudo isso tem que estar sendo levado em consideração ao gerir um projeto em XP.

Juntando esses dois fatos, temos a necessidade de um benefício mútuo que agregue o esforço de ter um gasto legal, levando em conta que o pessoal esteja bem. Ou seja, se o seu pessoal tá feliz, vão produzir melhor e consequentemente o produto será melhor. O melhor dos dois mundos.

Mas caso esse benefício mútuo não esteja sendo mantido? Algum problema de gerenciamento, programador ganhando somente um carro popular de salário, ou o cliente esfumando porque o landing page tá feio. Nada disso é problema, pois o XP tem o princípio de melhora contínua. A cada ciclo é necessário utilizar do feedback de ambas as parte do projeto para a melhor resposta a esses problemas nos ciclos futuros.

Para que exista a resposta a problemas, precisa haver o entendimento de que falhas existem, existiram e existirão em um projeto ágil. Não é necessário culpar a parte que falhou, seja o cliente ou desenvolvedor, mas aceitar que há um erro e tratá-lo sem machucar nenhuma parte.

Melhorias precisam acontecer, sejam elas correções de erros ou adições de novidades ao escopo, toda melhoria é uma melhoria. O princípio de baby steps traz a ideia de que para ser mais efetiva a melhoria, que sejam pequenas melhorias em pouco espaço de tempo, e que não comprometa a saúde do projeto. Sem grandes revoluções no produto, caso haja a necessidade de alteração ou adição de algo, que seja aos poucos e mantendo o equilíbrio.

Por fim, o último principio é o de responsabilidade pessoal. Cada desenvolvedor tem que estar ciente das suas responsabilidades com o time, o projeto e o seu desenvolvimento. É um conceito simples mas com toda a certeza tem gente que peca (e muito) neste princípio.

Práticas

Agora, depois de tanta filosofia, entramos no campo da prática. Aqui que o bicho pega e a mãe não vê (Desculpem, não lembro os ditados). Dentro das práticas temos 3 divisões, práticas sobre o processo, práticas de programação e práticas de gerenciamento.

A prática sobre o processo de desenvolvimento é como se dará o dia-a-dia da equipe em processo de desenvolvimento. Começando pelo início do projeto, todo o desenvolvimento precisa de um escopo de produto ao qual o time irá produzir, para isso é necessário a utilização da figura do cliente presente para apresentar as necessidades daquele produto. O cara que vai entregar para os desenvolvedores uma parada chamada histórias de usuários, ou comumente conhecidas como usecases.

As usecases nada mais são que documentos resumidos com um parágrafo de duas ou três frases que apresentem ao desenvolvedor a funcionalidade da maneira que o usuário vê. Vamos a um exemplo de um aplicativo de sinastria astral:

• Um usuário, quando logado no meu aplicativo tem que ser capaz de calcular o mapa astral através da data de nascimento e local de nascimento

• Um usuário, quando logado, deve ver se o mapa astral calculado é compatível com o seu mapa astral. Caso seja, mostrar publicidade de aliança de casamento, caso não seja, mostrar publicidade de apps de namoro

Após definido o usecase, haverá um momento de reunião com o time que transformará usecases em tarefas técnicas e levará em consideração a complexidade de desenvolvimento. Para quantificar a complexidade de desenvolvimento, é utilizado pontos, que os valores variam na faixa da sequência de Fibonacci (1, 2, 3, 5, 8, 13...). Esses pontos são chamados de Story points, o valor 1 é o mínimo esforço e o máximo esforço só Deus sabe quando parar de contar. Normalmente esses valores servem para delimitar como a equipe vai trabalhar. Desenvolvedores juniores começam pegando pontos 1, 2 ou 3, enquanto plenos e seniores pegam valores 5, 8 e 13. Nada impede que um júnior pegue uma tarefa de 13 pontos mas vai ser por conta e risco. Confie sempre no seu potencial.

O desempenho de uma equipe vai ser levado em conta a quantidade de pontos executados por ciclo. Não há um valor x ou y que demostre que uma equipe é boa ou ruim, mas o histórico daquela equipe conta como aprendizagem. Por exemplo, se em vários ciclos o valor de story points fica entre 30 ou 40 pontos, um ciclo que somente 20 pontos foram entregues liga um pisca alerta na cabeça do gestor de que algo de errado não está certo. Se a equipe começa a entregar 50 pontos, por outro lado, pode mostrar que há uma evolução entre os desenvolvedores. Bom, é um problema para gestores, eu sou uma mera desenvolvedora. Não sei muito o que fazer com esses valores.

Enquanto ao tempo de cada ciclo, há uma sugestão de tempo e de processo que o Extreme programming irá utilizar, abaixo uma imagem com faixas de tempos de cada ciclo, a nomenclatura e um exemplo de atividade realizada. Importante saber que a cada final de ciclo, há a necessidade de receber feedback.

Finalizamos a parte ritualística da coisa e adentramos a prática de programação. O nome extreme programming se dá pela oferta de uma programação melhorada ao extremo para os seus desenvolvedores. Se você acha que toda aquela parte de definição de usecases e story points foram um lenga lenga sem fim, o método waterfall era muito mais burocrático, com definições infinitas de requisitos de usuários, laudas e laudas de documentos com definições e exigências dos clientes, divisões de trabalhos infinitas... um inferno. A parte boa do negócio ficava para o final. O desenvolvimento ficava meio apagado dentro de toda essa história.

O XP vem com a ideia de que devemos começar a desenvolver dentro do projeto o quanto antes. Se tivermos somente a definição do que vai ser apresentado em uma tela, iremos desenvolver aquela tela o mais rápido possível e utilizando métodos para aquele desenvolvimento seja conciso. A frase de comando é faça a coisa mais simples que possa funcionar. É claro que todo o produto não será apenas aquela coisinha desenvolvida com o mínimo de requisito do cliente, mas tudo o que vem depois será adicionado, então o desenvolvimento de todo o produto tem que ter um design incremental. Que ele seja capaz de receber sempre mais requisitos (e que seja capaz de remover também).

Outro conceito de programação que foi adotado no XP foi o conceito pair programming, que consiste em desenvolver uma funcionalidade ou tarefa técnica por dois desenvolvedores. Um desenvolvedor principal, o driver e um desenvolvedor auxiliar, chamado de navegador. O conceito é tirado das provas automobilísticas antigas que pilotos menos experientes possuíam um ajudante com um mapa apontando para ele os caminhos do percurso. Essa técnica é perfeita para o auxílio ao aprendizado de um desenvolvedor novato ou que esteja enfrentando problemas dentro do desenvolvimento de algo do projeto.

Além desse conceitos, há também especificações de qualidade como: Testes automáticos, Desenvolvimento dirigido por testes (o famoso TDD) e as práticas de controles de versão.

As práticas de desenvolvimento, como os outros pontos do XP vai depender muito do escopo do projeto, já as práticas de gerenciamento não vão ter várias mudanças de projeto em projeto.

Começamos com as especificações do ambiente de trabalho, o Extreme programming indica que todo time seja pequeno, com menos de 10 desenvolvedores e que todos eles estejam dedicados a um mesmo projeto. Outro ponto é que se evite a utilização de longas jornadas de trabalho. Caso exista a necessidade, que as horas sejam repostas em outro momento para descanso. Sempre pondo em cheque a necessidade de cuidado com a humanidade do projeto. Se os desenvolvedores não vão bem, com certeza o projeto também não irá.

A necessidade de desenvolver em XP vai variar de cada projeto, de cada time e até de cada cliente. Caso seja necessário, o XP vai se adaptar as demandas e a rotina dos seus desenvolvedores. Mesmo sendo um dos métodos menos burocráticos, ainda existe um certo nível de maturidade para aplicar. Abrir mão de certas definições, iniciar o desenvolvimento rapidamente, trabalhar com um escopo aberto sempre serão pontos de atenção em qualquer projeto.

Bom, esse foi um resumo do meu estudo no desafio de 100 dias de código. Eu estudei pelo livro Engenharia de software moderna do Professor Marco Tulio Valente. É um ótimo livro introdutório para assuntos corriqueiros no dia-a-dia de desenvolvimento de software.

[2/100] dias de código