Este artigo foi escrito por Paul Craig, Desenvolvedor Sênior, Equipe de Plataforma CDS no Canadian Digital Service (CDS). Este artigo foi publicado pela primeira vez como uma postagem no blog do CDS , que colabora com os departamentos federais canadenses para criar serviços digitais mais simples e úteis. Leia o artigo original aqui.

É um ótimo momento para trabalhar na entrega de serviços digitais. As pessoas estão mais conectadas do que nunca esperando ter acesso a serviços digitais modernos. Ao mesmo tempo, o desenvolvimento 'ágil' — construindo e testando protótipos em semanas em vez de gastar anos planejando — ganhou aceitação geral.

Como líder técnico no Canadian Digital Service (CDS), tenho visto muitos dos problemas com que novas equipes se deparam, decorrentes de um conflito cultural entre equipes ágeis que priorizam o código e processos de cascata com muitos papéis. Os departamentos que experimentam equipes ágeis (-ish) ainda querem que eles trabalhem com grupos de aprovações, o que, em última análise, significa encontrar acomodação nas culturas departamentais existentes e obter o trabalho aprovado como qualquer outra equipe.

A metodologia Agile prioriza o envolvimento precoce do usuário. O feedback do usuário não apenas fornece informações para melhorar seu produto, mas também funciona como documentação interna que aumenta sua credibilidade.

Em uma equipe ágil, sua força é sua capacidade de prototipar rapidamente e conversar com os usuários, mas sua fraqueza é a percepção de que essas práticas introduzem riscos indevidos. É crucial encontrar um equilíbrio entre obter rapidamente a liberação de um produto e escrever a documentação exigida pelos processos tradicionais de controle . Equipes ágeis bem-sucedidas precisam se mover rapidamente e estar seguras.

Mova-se rápido: a vantagem ágil

Equipes ágeis são o negócio real. Algumas das maiores empresas de hoje chegaram onde estão porque os fluxos de trabalho ágeis são realmente bons em entregar valor rapidamente, superando empresas mais estabelecidas com modelos de entrega mais lentos.

Em geral, como parte de uma equipe ágil, você deseja definir seu MVP (produto mínimo viável) e testá-lo com os usuários o mais rápido possível. O planejamento em cascata não tem uma boa resposta às 'necessidades do usuário'. A metodologia Agile prioriza o envolvimento precoce do usuário. O feedback do usuário não apenas fornece informações para melhorar seu produto, mas também funciona como documentação interna que aumenta sua credibilidade.

Quando estiver confiante de que seu produto funciona, concentre-se no que você precisa fazer para liberá-lo. É muito melhor ter um serviço 'alfa' lançado do que um protótipo interno altamente polido. Claro, a compensação com 'rápido' é que, convencionalmente entendido, significa comprometer a segurança, então você precisa equilibrar 'agir rápido' com 'estar seguro'.

'Estar seguro' em ágil

Para equipes ágeis, existem 4 maneiras principais pelas quais o desenvolvimento ágil é mais seguro do que o desenvolvimento tradicional de produtos em cascata.

  1. O Agile reduz os erros existenciais no design de um serviço: o envolvimento precoce do usuário reduz o risco de lançar um serviço com desempenho insatisfatório.
  2. O Agile reduz o custo dos erros: iteração frequente significa mudanças menores com mais frequência, o que significa que os erros tendem a ser menores e mais rápidos de reparar.
  3. O Agile reduz a probabilidade de erros por meio do aumento do uso de processos automatizados. Além desses argumentos ágeis ortodoxos, há um ponto final, mais filosófico a ser considerado.
  4. Agile é, acima de tudo, uma abordagem flexível que se adapta rapidamente. As equipes ágeis são pragmáticas na solução de problemas para os usuários.

Já discutimos a primeira resposta em outras postagens (consulte as postagens do blog Aprendendo com as pessoas que desejam usar nosso serviço de relatórios e Teste de validação: uma maneira de desafiar suas suposições ), então vamos analisar as outras.

Ágil reduz o custo dos erros

Tentar evitar problemas colocando camadas em comitês pode criar um ciclo vicioso. Todas essas camadas de governança são criadas para evitar erros dispendiosos, mas os erros geralmente são dispendiosos devido à governança excessiva.

Por outro lado, o desenvolvimento ágil de produtos reduz o custo dos erros . As equipes que lançam diariamente podem corrigir bugs em poucas horas, enquanto você pode estar olhando para 'silos de lançamento' de 3 a 12 meses em equipes mais tradicionais.

Ágil reduz a probabilidade de erros

A governança em cascata tradicional depende de humanos para auditar os produtos antes de serem lançados.

Isso é caro para executar e difícil de dimensionar 1 . Se você quiser se mover duas vezes mais rápido, precisará contratar o dobro da equipe. Em contraste, o desenvolvimento ágil de software procura substituir esse gargalo por testes automatizados que um computador pode realizar, geralmente em questão de segundos. É muito comum que a documentação de segurança esteja desatualizada - uma vez escrita, ela descreve como o sistema costumava funcionar - enquanto os testes automatizados (criados por meio de auditoria conduzida por humanos) eliminam a necessidade de documentação e são atualizados por definição .

Ágil é flexível

O segundo princípio do Manifesto para o Desenvolvimento de Software Ágil é 'software funcionando em vez de documentação abrangente', o que parece uma abordagem muito boa: vamos nos concentrar na construção do produto em vez de escrever longos documentos do Word ou apresentações em PowerPoint. No entanto, o primeiro princípio é 'indivíduos e interações acima de processos e ferramentas' e, infelizmente, a governança atual afirma que essas equipes exigem documentação abrangente. As equipes de supervisão tradicionais solicitam às equipes de produto uma extensa documentação escrita sobre como seu sistema funciona e é administrado. Se você não fornecer, há pouca chance de que seu projeto seja aprovado. Como uma equipe ágil no governo, seu princípio é 'software funcionando' e 'documentação abrangente'.

Movendo-se mais rápido ou sendo mais seguro?

Para recapitular, as duas considerações importantes para equipes ágeis em grandes organizações são:

  1. Entregar valor rapidamente , o que significa colocar algo nas mãos dos usuários rapidamente, sem gastar anos em planejamento.
  2. Gerenciar o risco (percebido) , o que significa se proteger contra erros e preencher a papelada.

As equipes que se movem rapidamente otimizam a velocidade e constroem rapidamente. As equipes seguras levam seu tempo, concentrando-se em testar pipelines e, às vezes, escrevendo documentos grandes.

Esses dois pontos parecem estar em tensão um com o outro. Se você quer velocidade máxima, não escreva nenhum teste. Basta escrever o código, enviá-lo e testá-lo em produção, fazendo com que usuários reais encontrem bugs. Por outro lado, se você deseja a máxima segurança, nunca solte nada. Software que nunca é lançado nunca é hackeado.

Então, onde você deve descer no continuum 'rápido' versus 'seguro'? Para responder a isso, descubra o que você está enfrentando. Se os prazos típicos de desenvolvimento de produtos forem de 2 a 3 anos para o lançamento, veja se você pode obter um serviço alfa lançado em 6 a 9 meses.

Conclusão

Como praticantes ágeis, a oportunidade que existe no governo é clara: os projetos tradicionais de TI do governo geralmente falham em entregar produtos que colocam os usuários em primeiro lugar/que atendem às expectativas dos usuários.

Dados esses problemas sistêmicos, parece uma grande dificuldade mudar para um modelo amplamente bem-sucedido de entrega de projetos que priorize feedback rápido e retorno antecipado do investimento. As equipes ágeis fazem mais com menos sobrecarga e, testando com usuários, elas ficam mais confiantes no que estão construindo.

No entanto, as equipes ágeis do governo canadense operam sob condições bastante difíceis, normalmente tendo que buscar acomodação dentro de uma cultura existente de extrema prevenção de riscos. A força das equipes ágeis é seu foco em enviar antecipadamente e melhorar de forma incremental — mas você precisa entregar algo . Diante disso, é extremamente importante equilibrar o compromisso com a segurança com o desejo de obter rapidamente uma liberação.

A combinação de duas abordagens opostas sempre apresentará desafios, mas é importante manter o foco em fornecer valor real para os cidadãos. No final do dia, você precisa provar que sua abordagem funciona, fazendo-a funcionar. Escolha um produto, controle seu escopo, coloque-o nas mãos dos usuários e conte sua história ao longo do caminho. Mover-se rápido mostra o que é possível, enquanto estar seguro garante que você seja viável.

  1. A prática da Engenharia de Confiabilidade do Sistema define esse trabalho repetitivo e de baixo valor como 'labutar'. [Retorna]

👋 Você pode criar um post como este! Compartilhe seus pensamentos com uma comunidade de servidores públicos. Saber mais

(Crédito da imagem: Unsplash)