Qual é o principal problema no desenvolvimento de software (ou talvez em qualquer trabalho)? Quando fiz uma pergunta a meus colegas, recebi respostas diferentes: alterações nos requisitos, incompatibilidade de expectativas, qualidade do código, interação com outras equipes ... resumindo por mim mesmo - a comunicação é um dos problemas mais importantes.
Durante a comunicação, todos entendem tudo à sua maneira, interpretam de maneira diferente do que foi dito. O cliente mantém em sua mente uma certa imagem que ele está tentando converter em palavras e imagens, o desenvolvedor, ouvindo essas palavras, as converte em sua cabeça em algum tipo de sua própria imagem. E nessa cadeia pode haver muitos links.
Tentando resolver esse problema, as pessoas escrevem um ToR detalhado. Mas isso resolve o problema? As mesmas perguntas, a meu ver, foram feitas por Bob Martin e Martin Fowler junto com seus colegas quando eles escreveram o Agile Manifest em fevereiro de 2001. Vamos tentar descobrir isso juntos sobre esse assunto e no próprio Agile.
A história
No inverno de 2000, houve uma reunião dos líderes da chamada Programação Extrema, eles discutiram metodologias de desenvolvimento e, como resultado, começaram a oferecer algumas metodologias Light. Poucas pessoas estavam interessadas (eu não quero ofender ninguém), provavelmente elas fizeram mais piadas sobre esse tópico. No entanto, vários participantes dessa reunião organizaram a sua própria um ano depois. Tudo começou com o fato de Bob Martin (ele escreveu o famoso livro sobre a qualidade do código), ter feito um boletim aos líderes da última reunião - vamos nos reunir e conversar. Na verdade, nada de concreto. Por algum tempo eles discutiram sobre o local e a hora. Como resultado, eles se reuniram em 11 de fevereiro de 2001, em Utah, em uma estação de esqui. 17 pessoas do setor de desenvolvimento, incluindo Bob Martin, Martin Fowler e outros. Beberam, Fowler foi esquiar e, após discussões, o
Manifesto Ágil surgiu.
Em princípio, tudo o mais importante pode ser transmitido literalmente por uma página de texto, que pode ser lida
aqui .
Mas, como tudo que foi curto e meticulosamente pensado, entender isso simplesmente lendo não foi fácil para mim pessoalmente. Portanto, vamos considerar em detalhes o que aquelas pessoas que assinaram o manifesto Agile tinham em mente.
Princípios Ágeis
Ou seja, sem negar a importância do que é certo,
no entanto, valorizamos mais o que está à esquerda.
Esse é um aspecto muito importante que sempre deve ser lembrado ao ler um manifesto e, na verdade, todos os dias no trabalho. Vamos discutir as principais declarações do manifesto.
Pessoas e interação são mais importantes que processos e ferramentas
À primeira vista, isso pode parecer uma tentativa de jogar fora todos os projetos Jira, rastreadores de bugs, registradores de horas e outras ferramentas e todos os processos configurados. O que poderia ser mais fácil é discutir verbalmente com os colegas o que alguém está fazendo. Se ao menos todos estivessem felizes. Mas parece um pouco utópico, certo?
Esse princípio sugere que, ao construir o processo de desenvolvimento de qualquer coisa, é importante lembrar por que isso é feito, para quem e com que finalidade. Não faz sentido criar um processo para o próprio processo. Como o trabalho será finalmente realizado por pessoas, você e eu. O que acontecerá se toda a centelha, todo o interesse em nossos olhos for substituído pela tarefa no yutrek ou pelos insetos no jir? É inútil para um processo bem organizado que fornece segurança completa perante o cliente, mas não resolve problemas reais de desenvolvimento. Detalhes burocráticos (formais) podem facilmente levar à perda de pessoas em um projeto. Costumo pensar que o mesmo vale para o planejamento. Quando foi a última vez que você fez o planejamento, que, no final, pelo menos 60 a 70% se mostrou preciso?
Na minha opinião, esse princípio do manifesto poderia soar assim:
Processos para pessoas, não pessoas para processos
Como o manifesto sugere que nos aproximemos da implementação desse princípio?
- Profissionais motivados devem trabalhar no projeto.
- A comunicação direta é a mais prática e eficaz.
- Os melhores requisitos e soluções de arquitetura vêm de equipes auto-organizadas.
- A equipe deve analisar constantemente seu trabalho e otimizar o processo.
O que a equipe desenvolve em geral? Produto para o cliente.
Um produto de trabalho é mais importante que a documentação abrangente
Se interpretado como está, na testa, acho que muitos concordarão. Mas o que mais você vê aqui? Pessoalmente, vejo aqui que um produto que funciona e funciona dentro do
prazo é mais importante que o código perfeitamente escrito. Essas são palavras cruéis e assustadoras em muitos aspectos, então não devo dizer isso. Mas toda a minha carreira, aprendendo com pessoas diferentes, fiquei cada vez mais convencida do pensamento - se eu escolher entre um projeto ideal em termos de código e arquitetura e um projeto que não seja muito bonito por dentro, mas que beneficie o mundo, escolherei o segundo. E sim, vou melhorá-lo da melhor maneira possível.
E aqui você deve pensar por um momento. Mas o que pode ser feito para tornar esses problemas menos comuns? Para que não tenhamos de escolher entre refatorar um módulo e desenvolver um novo recurso?
- Um produto de trabalho deve ser lançado o mais rápido possível.
- Um produto de trabalho é um indicador chave do progresso.
- A atenção contínua à excelência técnica e qualidade aumenta a flexibilidade do projeto.
- Simplicidade e minimização são necessárias.
Preste atenção ao ponto sobre excelência técnica. Mantendo o código em qualidade boa (necessária) e suficiente, é muito mais fácil tolerar alterações nos requisitos e, consequentemente, alterações no código.
Todos os princípios, lembro a você, não são negativos. Um não exclui o outro. Isso é sobre priorização. Tudo é importante - o produto, a qualidade do código e a documentação. Mas o que escolher, quando escolher? Trabalhando em um certo equilíbrio entre qualidade e produto, é mais fácil priorizar o produto, sem negar a qualidade.
Como exemplo da minha vida, lembro-me do trabalho em um projeto bancário para um cliente russo. O trabalho foi realizado com a participação de analistas e estritamente na CT volumétrica. A cada seis meses, o gerente ia à sede do cliente e mostrava os resultados do trabalho. É fácil adivinhar que, em regra, os resultados foram significativamente diferentes das expectativas do cliente. O contador do cliente, que viu o novo sistema pela primeira vez e geralmente sabia que ele estava sendo criado, estava horrorizado - não havia nada como o processo de trabalho habitual no novo sistema. O que nos leva ao próximo tópico.
A colaboração com o cliente é mais importante do que negociar os termos do contrato
Você deve ter muito cuidado com esta afirmação. E, novamente, lembre-se de que o lado direito da declaração não é negado. Pelo contrário, dizemos que o contrato é importante. Apenas quando ponderamos os termos do contrato e da cooperação, as parcerias corretas de longo prazo, o relacionamento será mais importante. Sem negar o segundo. Chamo tanta atenção para isso porque vivemos no mundo real e, às vezes, temos que trabalhar com clientes muito diferentes. Há casos em que o cliente, para seus próprios fins egoístas, pode tirar proveito da ingenuidade e, às custas do contrato, vencer condições inaceitáveis para os desenvolvedores.
No entanto, se falarmos sobre um certo bom cliente abstrato
no vácuo , é mais importante manter um relacionamento de longo prazo que levará a novos projetos.
Como alcançar o entendimento e o cumprimento das expectativas ao longo do projeto?
- Durante o projeto, desenvolvedores e representantes do negócio personalizado devem trabalhar juntos diariamente.
- A comunicação direta é a mais prática e eficaz.
Ao mesmo tempo, certamente não se deve esquecer a confirmação dos acordos para sua própria segurança. A propósito (felizmente raramente) existem clientes que geralmente se recusam a pagar após os acordos.
Qualquer que seja o cliente, a atividade do desenvolvedor é sempre útil.
Eu também acrescentaria que isso deve funcionar nos dois sentidos.
Isso nos leva a uma continuação lógica - mudanças no trabalho e nos planos. Poucas pessoas gostam de fazer mudanças, é da natureza do homem, se você pensar sobre isso. Qualquer sistema busca um certo ponto de equilíbrio e imutabilidade. Mas é o desenvolvimento que está sempre associado ao movimento e mudança.
A preparação para a mudança é mais importante do que seguir o plano original.
A existência de um plano como tal não é negada. Pelo contrário, o plano é importante. Mas é ainda mais importante estar preparado para alterá-lo, se em algum momento percebermos que esse plano não funciona mais no ambiente atual.
Um exemplo da prática de meus colegas é um projeto de inspeção fiscal de um dos países da CEI. O projeto estadual, em essência, TK, legislação, não se falava em nenhum ágil. Mas a equipe teve que mostrar flexibilidade no momento em que o estado no país do cliente alterou sua legislação tributária para que o projeto não fizesse sentido na forma em que foi planejado. Tive que alterar as especificações técnicas e refazer o projeto quase concluído para que o cliente pudesse usá-lo. Caso contrário, não haveria sentido no trabalho, bem, exceto talvez pelos ganhos enquanto tais.
Talvez este não seja o exemplo mais revelador, pois as mudanças foram provocadas por fatores externos. Por outro lado, o cliente pode, novamente devido a fatores externos, apenas chegar à necessidade de alterar os requisitos. Caso contrário, ele não terá uma vantagem competitiva.
Tudo isso toca em um tópico um pouco doloroso para mim. Mas e se estivermos fazendo um projeto por um ano inteiro e, um ano depois, o cliente disser - ok, você é ótimo, e agora colocaremos tudo isso no arquivo, não o usaremos e iniciaremos um novo projeto. Eu sou bastante doloroso em relação a isso, tive uma experiência semelhante. Mas realmente - o que aconteceu? O trabalho realizado ajudou o cliente a entender que o caminho escolhido está incorreto. Ou ineficaz. Para obter uma vantagem competitiva, você precisa trabalhar de maneira diferente, realizar outro projeto. E ele recebeu esse conhecimento com a nossa ajuda.
Quais aspectos do nosso trabalho ajudarão a suavizar esses cantos e tornar a flexibilidade menos assustadora?
- Entrega regular e antecipada de software.
- As mudanças são bem-vindas, mesmo nas etapas posteriores.
- As mudanças ajudam a fornecer ao cliente uma vantagem competitiva.
Ao mesmo tempo, vivemos no mundo real, com pessoas reais, onde nenhum julgamento, incluindo este, deve ser elevado ao absoluto. Sim, as alterações são bem-vindas quando geram valor agregado ao produto final. Mas é importante manter o equilíbrio. Se fizermos alterações sem fim, nunca lançaremos um produto em produção. Portanto, em algum momento você deve dizer - pare, lançamos o produto, verificamos tudo na prática e começamos a fazer a versão dois, que conterá essas alterações. Sempre esclarecendo com o cliente - que valor ele vê nessa ou naquela mudança.
Li recentemente a frase no Facebook,
se você não tem vergonha do seu produto, entra no mercado tarde demais
Com bastante precisão reflete a essência do exposto acima. Precisamos procurar um certo ponto de equilíbrio, no qual o produto esteja pronto o suficiente para o próximo lançamento em termos de mudanças, e no qual ainda não começamos a gastar muito esforço em pequenas mudanças.
Em vez de resumir
Os criadores do manifesto Agile não prescrevem nenhuma regra e até vice-versa. Mas eles levantam questões importantes em nosso trabalho - a interação de pessoas, desenvolvedores e clientes, prontidão para mudanças. Esses princípios são importantes por natureza. Com a inegável importância da documentação, contratos, processos e planejamento, interação humana, prontidão para mudanças valiosas e trazer algo útil ao mundo são ainda mais importantes.