Índice:
Ser uma equipe ágil de desenvolvimento de software certamente significa coisas diferentes para pessoas diferentes. Existem graus de adoção em um espectro muito amplo, aparentemente com muito poucas organizações que pensam que o fazem bem. De acordo com a Pesquisa State of Agile da VersionOne (lançada em abril de 2017), 80% dos entrevistados dizem que estão "no nível ou abaixo de um nível de maturação". Infelizmente, as equipes de desenvolvimento geralmente não colocam muito esforço na parte “aprender” da iteração. Queremos nos apressar e encerrar as cerimônias do Scrum para que possamos voltar a escrever o código. Afinal, há muito trabalho a ser feito! Mas será que o tempo de codificação insuficiente é realmente o problema?
Para muitos de nós, o combate a incêndios também pode ser listado especificamente em nossa descrição de trabalho. Vamos trabalhar todos os dias sabendo que precisamos estar prontos para deslizar pelo poste a qualquer momento, pegar nossos chapéus e pular no caminhão. Aceitamos como as coisas são e assumimos que não há nada que possamos fazer a respeito. Mas, e se a causa raiz de nossas lutas for uma grave falta de eficiência? Todo mundo sabe o quanto é importante fazer isso melhor do que aquela outra empresa. Simplesmente não conseguimos chegar lá - parece que não temos a largura de banda. Os gerentes adicionam mais pessoas e aumentam o tamanho de suas organizações e ainda enfrentam as mesmas dificuldades. Parece que você não consegue superar o obstáculo porque suas equipes não estão desenvolvendo software com eficiência (e você não está sozinho).
Princípios de Desenvolvimento Eficiente
Pixabay
Então, o que nos torna ineficientes? Para a maioria de nós, a primeira coisa que vem à mente é a falta de automação (compilações automatizadas, implantações, testes). “Assim que tivermos automação suficiente, a vida ficará melhor.” Infelizmente, isso é apenas parte da solução. Considere o efeito do retrabalho em seu projeto. A maneira mais eficiente de construir um recurso é criá-lo uma vez corretamente e nunca voltar e tocá-lo novamente. Bugs, refatoração e outras atividades semelhantes estão essencialmente reabrindo o paciente depois que ele sai da sala de cirurgia e há risco inerente associado a isso. Não podemos eliminar o retrabalho, mas certamente devemos nos esforçar para minimizá-lo.
“Mas o Agile não envolve o retrabalho (ex. Refatoração)?” Na verdade, de certa forma, porque os criadores do Agile entenderam que duas causas principais de retrabalho são circunstâncias imprevistas e mudanças nos requisitos de negócios. Acontece que os humanos são terríveis em prever o futuro. Os criadores do Agile também entenderam que um grande contribuidor para a ineficiência é o que os desenvolvedores chamam de “gold-plating” - pacote de funcionalidades que achamos que alguém usará, embora os usuários finais nunca tenham realmente solicitado. É como carne de porco para o seu produto de software - uma completa perda de tempo. "Não construa uma estação espacial quando tudo o que eles estão pedindo é um Volvo." Portanto, as empresas sabiamente começaram a deixar de lado o porco e a abraçar a refatoração, adicionando funcionalidade apenas quando há uma necessidade clara. Mas a imprevisibilidade da vida não é o único fator para retrabalho, certo?
Detalhes perdidos em qualquer estágio de desenvolvimento de recursos acabarão por desperdiçar tempo e dinheiro. Colaborar com eficácia desde o início irá, com o tempo, economizar uma tonelada de retrabalho (lidar com requisitos não atendidos, um projeto míope, etc.). Todos nós temos pontos cegos e todos precisamos de pares extras de olhos. Muitas equipes de desenvolvimento adotam isso no back-end durante a revisão do código, mas colocam muito menos energia na colaboração desde o início, quando os problemas podem ser resolvidos de forma barata e com investimento mínimo.
Quantas vezes você implementou um recurso e encontrou falhas significativas perto do final que deveriam ter sido detectadas durante as discussões de requisitos / design? É como tentar dirigir de Atlanta a Montgomery e perceber várias horas de viagem que você acidentalmente dirigiu para Birmingham. Quanto tempo foi gasto tentando obter o código correto apenas para abrir o paciente novamente mais tarde porque requisitos importantes foram perdidos? Aproveitar a inteligência coletiva certamente economizaria tempo e dinheiro, mas, em vez disso, os desenvolvedores costumam trabalhar em recursos isolados.
Swarming Tradicional
Pixabay
O swarming tradicional significa que a equipe trabalha de forma colaborativa em histórias com várias pessoas trabalhando em um pequeno recurso ao mesmo tempo, encurtando o ciclo de feedback e reduzindo o tempo de conclusão geral do recurso (ou seja, dividir para conquistar). Isso é essencialmente um enxame dentro de cada disciplina (desenvolvedores de back-end, desenvolvedores de IU, etc.). Antes do início do desenvolvimento, os desenvolvedores de UI trabalham para identificar tarefas independentes que podem ser executadas simultaneamente. Eles discutem pontos de interface para que cada pessoa saiba como sua peça se encaixa no todo. Os membros da equipe, então, podem prosseguir para a conclusão de suas tarefas atribuídas e reunir tudo no final durante a integração. Confirmações frequentes e revisões de código periódicas ajudam a garantir que tudo permaneça nos trilhos. Esta abordagem requer colaboração entre os desenvolvedores,o que ajuda a produzir um resultado final melhor de qualquer maneira. Freqüentemente, priorizamos o tempo gasto escrevendo código (qualquer código) em vez do tempo gasto para nos certificarmos de não escrever o código errado. Quando você considera o tempo potencialmente economizado, o valor se torna claro.
Sendo desbloqueado
Pixabay
Outra abordagem valiosa para enxamear é focar a equipe desde o início na mitigação da dependência para facilitar o desenvolvimento simultâneo entre as disciplinas. Considere o fluxo natural de desenvolvimento de um recurso de IU. Os testadores de automação (SDETs) dependem de uma IU funcional para testar, os desenvolvedores de IU dependem de uma API de back-end em funcionamento e os desenvolvedores de back-end dependem de configuração, atualizações de banco de dados e compilações / implantações automatizadas. Portanto, os desenvolvedores de IU podem não iniciar seu trabalho até que as APIs sejam concluídas e os SDETs podem não iniciar seu trabalho até que o recurso seja concluído. Cada disciplina está trabalhando isoladamente, o que dificulta a colaboração porque as pessoas com as quais você precisa interagir estão ocupadas trabalhando em outras coisas.Mas e se você pudesse mitigar as dependências mais cedo e permitir que todas as disciplinas trabalhassem simultaneamente no mesmo recurso?
aqui estão alguns exemplos:
1. IU funcional implantada com stubs
Para desbloquear SDETs, os desenvolvedores de IU podem fornecer a eles uma IU funcional que funcione apenas o suficiente para permitir que escrevam testes. A integração da API de back-end e os estilos CSS ainda podem estar pendentes, já que frameworks de teste automatizados como o Selenium não se importam se essas coisas estiverem inacabadas. Tudo pode ser fumaça e espelhos. Embora possam ocorrer alterações que causem algum retrabalho, o benefício de iniciar os testes antecipadamente supera esse risco.
2. APIs de back-end implantadas (dados stubbed, hard-coded)
Fornecer APIs de back-end que os desenvolvedores de IU podem testar permite a detecção antecipada de problemas de integração entre o front-end e as API (s). Às vezes, você descobre que a API fornecida não atende às necessidades dos desenvolvedores de front end. Chamadas inteiras podem estar faltando, a assinatura pode estar errada ou a estrutura dos dados pode ter problemas. Se houver uma desconexão, você também pode descobrir mais cedo, antes que qualquer coisa tenha se consolidado.
3. Crie uma versão HelloWorld de novos aplicativos e serviços.
Se um novo serviço for necessário (por exemplo, um microsserviço), crie o repo e construa uma versão “hello world” do serviço. Isso permite que os recursos dev-ops sejam iniciados nos jobs e scripts de implantação do Jenkins antes que o serviço seja realmente desenvolvido.
Essas otimizações facilitam um ciclo de feedback inicial, onde alguém pode dizer “Eu preciso de algo diferente” antes que o desenvolvimento seja concluído no componente que requer a mudança.
Embrulhando-o
É extremamente importante descobrirmos como reduzir o tempo de lançamento no mercado dos recursos em que estamos trabalhando. O negócio não obtém valor por ter um monte de recursos em andamento, e os desenvolvedores precisam desesperadamente de recursos a serem implementados rapidamente para que os defeitos possam ser resolvidos o mais próximo possível do ponto de injeção. Os desenvolvedores também precisam desesperadamente interagir uns com os outros, embora tudo o que realmente queiram fazer seja escrever código. É melhor para todos os envolvidos, incluindo o usuário final que deseja apenas um produto melhor. Se você não der a eles, eles irão a outro lugar para encontrar.
O swarming é uma ferramenta extremamente valiosa na caixa de ferramentas de sua organização, se as pessoas dedicam um tempo para aprender como fazê-lo. Não é uma estrutura ou mesmo uma atividade - é uma mentalidade. Para cada história de usuário, os membros da equipe se fazem duas perguntas:
- Como organizamos as tarefas desta história para que várias pessoas contribuam ao mesmo tempo?
- Qual é o mínimo que preciso fazer para desbloquear alguém que está esperando por mim?
E se sua equipe construísse rapidamente recursos juntos, em vez de construir lentamente um monte de recursos de forma independente? Eles podem realmente responder aos requisitos de negócios em constante mudança e atender às necessidades dos negócios quando os negócios precisam que eles sejam atendidos. Os concorrentes têm medo de você - os clientes vão adorar você. Essa é a receita para um negócio de sucesso.
© 2017 Mike Shoemake