"Estás pronto?"
O mais pronto possível, penso eu, enquanto faço a minha lista de verificação mental uma última vez.
Piloto: Atacadores, correias das pernas, correia do peito, luvas, rádio, correia do queixo, verificado.
Linhas: Todas livres e desobstruídas, esquerda sobre a direita para que eu possa virar para o meu lado preferido, verificado.
Asa: O bordo de ataque é aberto e bem distribuído em forma de ferradura, verifique.
Vento: Uma brisa ligeira está a surgir, um pouco fraca demais para um lançamento invertido. Decido esperar por alguns minutos.
"Escolhe o teu momento."
Aceno com a cabeça ao instrutor enquanto observo o cata-vento. Passado mais um minuto, sinto o vento a aumentar um pouco. O cata-vento parece-me bom. Espero alguns segundos para ver se o vento se mantém. E dura.
Vento: verificar.
Espaço aéreo: Não há outros planadores a voar perto do lançamento e não há outros planadores prontos para o lançamento, verificar.
Respiro fundo... "START!", puxo os A-risers na minha direção. A asa infla-se à medida que se eleva. Solto os tirantes e puxo os travões para o fazer parar por cima de mim. A forma da asa parece-me familiar, ótimo. Não há nós visíveis, ótimo. Uma rajada de vento vira ligeiramente a asa. Já não está centrada por cima de mim. Devo abortar? Aplico um pouco de travão para apontar a asa para a frente e dou dois passos para me colocar de novo debaixo da asa. A asa estabiliza-se. Mantenho a asa nesta posição durante um ou dois segundos para verificar se tenho o controlo. Com a asa assente, todos os sinais estão agora verdes. Mantendo uma pressão constante nos travões, giro 180 graus. Após um breve sprint, sinto as correias das pernas apertarem-se enquanto a asa me tira do chão.
Estou a voar.
Adivinhou: tenho um passatempo arriscado. Isso significa que sou uma pessoa que corre riscos, certo? Bem, sim, mais ou menos. E também, não! Como praticante de parapente, gasto uma quantidade significativa de energia na mitigação de riscos. Com uma preparação sólida e mantendo margens saudáveis, reduzo o risco para um nível aceitável. Por isso, um termo melhor é gestor de riscos.
Verificar as nossas vagas
Sem risco, não há negócio
Isto leva-me ao tema em questão, a gestão de riscos no desenvolvimento de software. Mais especificamente, como é que gerimos os nossos riscos de modo a podermos implementar melhorias com confiança e sem stress? Afinal, a implantação de software é semelhante a um lançamento de parapente. Ambos são momentos prováveis para que os riscos se materializem em problemas reais.
Infelizmente, a única forma de eliminar todos os riscos é evitá-los por completo. Parar de voar de parapente ou, equivalentemente, parar a implementação de melhorias de software. A primeira é, de facto, uma escolha válida. Quanto à segunda, bem, alguns riscos terão de ser suportados. Mas ainda podemos reduzir os riscos, por isso, como é que o fazemos no Easy LMS?
Infelizmente, a única forma de eliminar todos os riscos é evitá-los completamente
O que é o risco?
Um risco é um acontecimento com uma probabilidade de ocorrência e um determinado impacto (negativo). A combinação da probabilidade e do impacto determina o nível de um risco. Assim, um evento muito provável de acontecer e com um grande impacto (negativo) é um risco elevado. Um evento que é pouco provável de acontecer e tem um impacto muito limitado é um risco baixo. Se a probabilidade e/ou o impacto forem maiores, o risco aumenta, e vice-versa.
Gestão do risco
Uma vez que o risco é uma combinação de probabilidade e impacto, é possível reduzir um risco:
Por exemplo, como praticante de parapente, consideremos o risco de me despenhar por ter dado um nó feio nas minhas linhas. Entre outras medidas, reduzo este risco
A combinação de todas as medidas dá-me confiança suficiente para correr alegremente em direção à borda da montanha. Confio na minha preparação, nas minhas capacidades, no meu equipamento e nas minhas decisões. O risco ainda existe, mas reduzi-o a um nível que estou disposto a aceitar. No parapente, o lançamento será sempre um momento de tensão para mim. Exige que eu esteja alerta. Mas não estou stressado.
Da mesma forma, temos medidas em vigor no Easy LMS para gerir os riscos e manter-nos calmos. Consideremos o risco de introduzir bugs no sistema ao lançar uma nova funcionalidade. Duas formas de minimizar este risco são:
Temos medidas em vigor no Easy LMS para gerir os riscos e manter-nos calmos
Então, como é que estas medidas nos ajudam no Easy LMS?
Desenvolvimento orientado por testes (TDD)
O Desenvolvimento Orientado por Testes, ou TDD, é a prática de escrever um teste automatizado para o comportamento desejado de uma nova funcionalidade antes de escrever o código para a própria funcionalidade. O TDD ajuda a reduzir o risco de introdução de erros das seguintes formas:
Ao testar o comportamento em testes automáticos é mais provável que os erros sejam detectados durante o desenvolvimento.
Os erros são detectados mais cedo no processo de desenvolvimento ao escrever testes antes de escrever o código.
Escrever testes antes de escrever o código força o programador a pensar em como testar o comportamento desejado independentemente do código final.
Escrever código testável é um pouco como escrever um livro legível. Ele força o desenvolvedor a aplicar estrutura ao código. Como resultado, código testável tende a ser um código de fácil manutenção.
Ao seguir religiosamente o TDD, nós construímos uma suíte de testes ao longo do tempo, compreendendo todos os testes escritos no passado. Antes da implantação, executamos todos esses testes. Se nossa nova funcionalidade causar um problema com a funcionalidade existente, nós saberemos.
Desta forma, o TDD ajuda a reduzir significativamente a probabilidade de introdução de erros no sistema.
Pequenas iterações
No Easy LMS, trabalhamos em pequenas iterações, lançando pequenas alterações com frequência. Muitas vezes realizamos uma ou duas implementações por dia. Fazemo-lo em pequenos passos, mesmo quando introduzimos uma grande parte da funcionalidade. Isto ajuda-nos da seguinte forma:
Recebemos o feedback dos clientes muito mais cedo do que se esperássemos pela implementação até que uma funcionalidade estivesse completamente "terminada". Com base no feedback inicial, podemos facilmente mudar de direção, se necessário.
É muito mais fácil recuperar de um erro se a diferença em relação à última versão estável for pequena.
As iterações curtas são mais fáceis de planear e gerir. Uma equipa não pode simplesmente atrasar-se no calendário durante um período de tempo significativo. Isto leva a menos stress e evita que as equipas sintam a necessidade de cortar nos cantos.
Implantar diariamente cria um forte impulso para um processo de implantação mais simplificado e confiável. Caso contrário, sentiríamos a dor diariamente.
Desta forma, as iterações curtas ajudam a reduzir a probabilidade e o impacto da introdução de erros no sistema.
O TDD e o trabalho em pequenas iterações dão-nos confiança. Fortalecemos a nossa convicção de que o que estamos prestes a implementar funciona. Se houver algum problema, ele será pequeno.
As iterações curtas são mais fáceis de planear e gerir
Os testes de unidade são verdes, verifique.
Movo o ticket para 'Em revisão de QA', o que aciona automaticamente uma implantação em nosso ambiente de preparação.Alguns dias antes, implantamos uma pequena alteração nos status mostrados na visão geral do participante em vários locais do aplicativo. A alteração deveria fazer com que os status refletissem com mais precisão o status de um participante.
Pode ter sido mais exato, mas também foi confuso. Os clientes que olhavam para a nova situação através das lentes antigas tinham a impressão de que os convites não eram enviados.
Agora aqui estava eu, pronto para implantar o remédio. Com base no feedback que recebemos nos dias após o lançamento, agora melhoramos nossa alteração original. Observo o progresso da implantação automatizada em nosso ambiente de preparação, onde realizamos nossos testes finais antes da implantação.
Os testes de aceitação ficam verdes, verifique.
Abri o navegador e naveguei até o ambiente de teste para testar a alteração pela última vez. O ambiente de teste é configurado da mesma forma que nosso aplicativo ativo.
Ele funciona como eu esperava, verifique.
As alterações são pequenas, o que facilita os testes. Os testes de unidade e os testes de aceitação reforçam ainda mais minha confiança de que a funcionalidade existente está funcionando como antes. Todas as luzes estão verdes. Eu aciono a implantação.
Eu tomo um gole do meu café e verifico minhas mensagens enquanto a implantação é executada. Penso em como a mudança deve ajudar nossos clientes. Vamos entrar em contacto com o suporte dentro de um dia. Esperamos que os clientes deixem de contactar o suporte relativamente a este estado. Se recebermos mais feedback, estou confiante de que teremos outra implantação pronta esta semana para melhorar ainda mais nosso aplicativo e atender às necessidades de nossos clientes.
Após alguns minutos, a etapa final da implantação fica verde.
Estamos a voar.
Verificar as nossas vagas
