Olá Pessoal, hoje vamos falar sobre Prática de Desenvolvimento de Software.
De que forma ela influência na qualidade das entregas?
Participo de alguns grupos de debate sobre desenvolvimento, arquitetura, etc… E apesar dos assuntos lá debatidos não iniciarem em volta deste, quase sempre caem no mesmo tema.
Lá está você esperando eu começar a abordar um SCRUM + Kanban, XP ou algum Ágile, pois é, mas a prática a ser abordada hoje é um pouco mais conhecida e muito mais utilizadas que estas:
Apesar da brincadeira, é uma dura e triste realidade.
Empresas ou Departamentos de TI que não possuem estrutura, processos e gestão de tarefas automaticamente tendem a implicitamente utilizar Go Horse!
O objetivo desse post, além da brincadeira é abordar como podemos apesar da triste realidade nos sair melhor mesmo em modo Extreme Go Horse!
Apenas para enfatizar o Go Horse!
Realizar a entrega de um sistema / tarefa de desenvolvimento em um prazo impossível, não pense, apenas faça! Compilou? Sobre no repositório e avisa que está pronto. Testes? Se o cliente encontrar Bug corrigiremos.
Sacou? Nada diferente do que um dia já vivemos ou talvez viveremos.
Apesar da enorme desmotivação que o Go Horse! proporciona, (já que não podemos aplicar tudo aquilo que estudamos e é certo) podemos nos basear em algumas inteligentes regras para tornar nosso trabalho mais assertivo e menos desmotivante, e quem sabe (por que não?) atingirmos com sucesso nossos objetivos:
1- Entenda o propósito.
Procure ter uma visão completa sobre os objetivos que o sistema visa atender. Saiba também o por que o cliente precisa do sistema, como funciona o negócio do cliente.
2- Foco no Domínio.
Um cliente paga para obter valor ao seus negócios, ou seja, foque realmente naquilo que o cliente precisa, se o tempo é curto entregue com uma interface de usuário mais básica porém funcional, encantar o cliente antes de tudo é atingir os objetivos dele, tudo que foi desenvolvido e não foi percebido pelo cliente é investimento jogado fora.
3- Entregue o mais importante antes.
Geralmente a parte mais crítica do sistema é a que fica por último, por ser mais difícil ou por ser a mais trabalhosa, porém é aquela o cliente mais precisa, atenda o desejo dele o quão antes possível. Com o feedback da entrega você saberá se está no caminho certo.
4- O código que você produz reflete que profissional você é.
Não é por que o prazo é curto que o código precisa ser um lixo, escreva códigos simples, comentados, quebre tudo por funcionalidades ao invés de criar uma linguiça com N rotinas aglomeradas. Na próxima manutenção você não terá que jogá-lo no lixo e fazer tudo de novo.
Quanto menos manutenção seu código gerar, mais tempo você terá para pegar aquele projeto bacana que só não iniciou por que a entrega do cliente não está funcionando.
5- Código funcionando é código testado.
Sempre que possível faça os testes unitários de seu código, (ainda falaremos mais sobre isso em breve) Procure testar as rotinas mais críticas, ex: cálculo de juros.
6- Seja prático
Um código que atende claramente o Domínio do cliente é facilmente entendido por outro desenvolvedor, assim você não se torna o eterno pai do sistema.
Investir mais na fase inicial de desenvolvimento para eliminar a possibilidades de manutenções ou mesmo para facilitar possíveis futuras expansões é perca de tempo, não preveja o futuro, tudo muda a toda hora, atenda a necessidade atual da melhor forma possível, o futuro vem depois.
7- Adquira uma organização pessoal para aumento de produtividade.
E-mails, twitters, Facebook, e qualquer tipo de “desviadores de foco” estão presentes na vida de qualquer desenvolvedor. Procure obter momentos de 100% de foco, otimize sua produção com uma quantidade X desses momentos em sua jornada diária, e depois disso nos intervalos você pode Tuitar, ler/responder os e-mails ou até mesmo implementar aquele Pattern que você achou que seria benéfico ao sistema, mas não daria tempo de fazer.
Existe uma técnica interessante para essa gestão de tempo, falaremos futuramente sobre o Pomodoro.
8- Não admita que as coisas são assim e pronto.
Como disse tudo muda a toda hora, se no seu trabalho o dia-a-dia é Go Horse! Você pode mudar isso. Sugira novas idéias, procure sempre aprimorar seu trabalho, não mantenha-se desmotivado, traga novidades para a empresa, procure convencer de forma teórica, didática e prática os seus gestores de que a coisa pode ser melhor.
Tudo mantem-se igual por que ninguém faz o esforço certo e necessário para que as coisas mudem.
Se no final de tudo (de tudo mesmo) a coisa não mudar, mude você! Afinal um bom profissional tem direito a uma boa oportunidade de trabalho.
Resumindo:
Apesar do Go Horse! definitivamente ser um dos grandes males de nossa área algumas inteligentes abordagens podem nos oferecer uma maior oportunidade de melhorar nosso dia-a-dia.
Sim, essa publicação é mais do mesmo, mas para quem principalmente está no início da carreira é importante ter em mente: Não vicie em um ritmo que não é bom, procure melhorar, procure mudar.
Especialmente inspirado:
- Elemar Jr – http://elemarjr.net/2012/06/17/work-in-progress-por-que-eu-ainda-tento-escrever-cdigos-incrveis/
- .Net Architects – https://groups.google.com/forum/?hl=pt-br&fromgroups#!topic/dotnetarchitects/15VbYxC5r5s