Perguntas e respostas sobre o livro Risk-First Software Development

O livro Risk-First Software Development, de Rob Moffat, exibe todas as atividades de um projeto de software sob a lente do gerenciamento de riscos, introduzindo uma linguagem de padrões para classificar os diferentes riscos, fornecendo sugestões para equilibrá-los e explorar como as metodologias de software as veem.

Os leitores da InfoQ podem baixar uma amostra do Risk-First Software Development.

O InfoQ entrevistou Moffat sobre como os riscos direcionam tudo o que fazemos, o relacionamento entre metodologias e riscos de software, como lidar com riscos de recursos na preparação de pedidos em atraso, atenuando os riscos que podem ocorrer quando usamos bibliotecas de software livre ou software como uma funcionalidade de serviço, lidando com heróis nas equipes, os desafios que vêm com os sistemas operacionais de software no mundo real e como lidar com os riscos operacionais e livros futuros sobre o cenário de riscos.

InfoQ: O que te motivou a escrever o livro?

Rob Moffat: Tudo começou com uma observação no meu livro de registros. A equipe passou muito tempo planejando reuniões tentando decidir o que e como construir. Parecia que estávamos tentando evitar caminhos arriscados que nos levariam ao inferno da dependência, nos deixariam com dívidas técnicas ou nos levariam a construir a coisa errada para os usuários. Embora em certo nível estivéssemos trabalhando em uma equipe Scrum, parecia que, na verdade, o que estávamos tentando era evitar riscos desnecessários.

Entendendo que estávamos evitando riscos nessas reuniões de planejamento, pude perceber que, na verdade, todo o trabalho que fazemos como desenvolvedores tem a ver com riscos. Por exemplo, se estamos trabalhando para tornar as telas de inscrição da nossa aplicação web menos confusas, o que estamos realmente fazendo é tentando reduzir o risco de que os clientes em potencial se afastem. Ou, se estivermos trabalhando na melhoria dos indicadores de integridade da aplicação, na verdade, estamos tentando reduzir o risco dos clientes enfrentarem o tempo de inatividade, o risco de reputação e a potencial perda de receita resultante dele.

Parecia que esse era um conceito além do "ágil" que não havia sido explorado adequadamente, então comecei a escrever alguns artigos no blog, principalmente para mim, para experimentar e entender esse conceito. Isso realmente se tornou um wiki no github (todo o conteúdo do livro também está publicado em riskfirst.org).

Por fim, decidi que seria divertido publicá-lo também em formato de um livro.

InfoQ: Para quem o livro foi destinado?

Moffat: O livro é para pessoas que trabalham em projetos de software. Se temos interesse no que faz o desenvolvimento de software funcionar (ou falhar), provavelmente o livro é útil para nós. Embora agora todos já estejam familiarizados com técnicas como Agile ou DevOps, parece que a Risk-First está tentando ir além disso e explicar em um nível inferior por que esses métodos e práticas funcionam e seus limites.

InfoQ: No livro é comentado que o risco impulsiona tudo o que fazemos. Pode elaborar mais essa afirmação?

Moffat: Claro, vamos discutir alguns exemplos. Uma história de desenvolvimento de melhorias na tela de login do usuário pode ser vista como uma redução do risco de possíveis clientes não se cadastrarem. Ou, quando fazemos algum trabalho para implementar indicadores de integridade, na verdade estamos tentando minimizar o risco de falha da aplicação e de ninguém reagir aos problemas.

Se o software não faz algo que o software do concorrente faz, podemos chamar isso de Risco de Recurso; existe o risco de perder participação de mercado porque não fornecemos algo. Por outro lado, se o software tiver muitas dependências de terceiros, isso poderá levar a um alto nível de risco de dependência. As dependências de terceiros podem conter bugs, falhas de segurança ou ainda, mudar com o tempo de maneiras que não gostaríamos.

Haverá uma troca. Se criarmos o recurso que precisamos, podemos diminuir a quantidade de Risco do Recurso, mas podemos acabar aumentando a quantidade de Risco de Dependência como resultado.

InfoQ: Como podemos enxergar a relação entre metodologias de software e riscos?

Moffat: Uma metodologia de software é um conjunto de ferramentas que nos ajuda a criar o produto certo. O modelo pode nos ajudar a gerenciar o tempo (através de Sprints) ou a equipe (com funções como proprietário de produto ou coach) ou ainda nosso trabalho (talvez através de um quadro Kanban).

A idéia do Risk-First é que todas as ferramentas que temos (sejam metodologias, processos ou ferramentas de software) estão lá para nos ajudar a gerenciar certos tipos de riscos. A parte interessante que é explorada no livro é que diferentes metodologias possuem diferentes ideias sobre quais riscos são importantes para serem gerenciados.

Por exemplo, o Método Cascata é herdado da indústria da construção. Portanto, gerenciamos os riscos com os quais nos importaríamos em um projeto de construção. Por exemplo, o Risk-First minimiza o risco de retrabalho e o risco de custos em espiral durante a fase física do projeto. Esse é um risco importante para gerenciamento na construção, porque jogar concreto em algo é significativamente mais fácil do que removê-lo depois que endurece.

A Metodologia XP tem uma idéia diferente sobre quais são os riscos importantes em um projeto de software (por exemplo, coisas como Risco de Pessoa Chave). Como resultado, as práticas são muito diferentes daquelas em um projeto Cascata (por exemplo, Programação em pares).

Portanto, a escolha da metodologia e das ferramentas que usamos para controlar o projeto depende dos riscos que o projeto enfrenta. Precisamos ajustar a metodologia e as práticas ao perfil dos riscos no projeto.

InfoQ: Quais são os riscos dos recursos e como podemos lidar com eles na preparação da lista de pendências?

Moffat: Riscos de recursos são uma família de riscos associados aos recursos do software que estamos criando para nossos clientes. Um já mencionado é o risco de faltar recursos e os clientes estarem insatisfeitos quanto a isso. Mas também precisamos considerar que os recursos estão com problemas, são difíceis de encontrar ou não funcionam da maneira como os usuários gostariam, e o Risco de Aderência do Recurso, é quando os clientes têm uma expectativa sobre o que o produto deve fazer, mas, na verdade, é ofertado outra coisa.

Esses são conceitos úteis para se ter em mente, porque quando estamos tentando organizar a lista de pendências, o que realmente estamos tentando fazer é diminuir os riscos do projeto. Os itens na parte superior da lista de pendências devem ser os de maior risco. Na parte inferior da lista de pendências, temos itens que apresentam baixo risco de recurso e podemos removê-los, pois estão apenas causando carga cognitiva desnecessária e são um desperdício de tempo na lista (o que representa o tipo de Risco de Agendamento).

InfoQ: Quais riscos podem ocorrer quando usamos bibliotecas de software livre ou o software como serviço de funcionalidade? Como podemos mitigar esses riscos?

Moffat: Estamos falando aqui sobre diferentes tipos de dependências, e inevitavelmente captamos o Risco de Dependência ao usar o software ou serviço de terceiros. Geralmente, quando escolhemos uma dependência (seja de código aberto, comercial, SaaS ou qualquer outro tipo), acabamos com algum tipo de compromisso, e geralmente é mais difícil desistir do que aceitá-lo.

Há muitos indicadores que podemos observar ao escolher dependências, como popularidade do produto, tamanho da organização, quantidade de documentação e assim por diante, mas o que realmente estamos tentando avaliar é o nível de risco de confiabilidade e se a dependência fornece ou não os recursos necessários (Risco de ajuste de recurso, novamente).

InfoQ: Foi mencionado no livro que ter um ou mais heróis em uma equipe pode representar certos riscos. Quais são as sugestões para lidar com esses heróis?

Moffat: Sempre que houver uma equipe de pessoas envolvidas em um projeto, inevitavelmente trarão ao projeto, não apenas os próprios talentos e habilidades, mas também os objetivos e agendas. O Risk-First considera esse conflito entre o objetivo da equipe e um dos membros, como um exemplo de "Risco da agência", e isso inclui comportamentos como a criação de CV e a promoção de "Projetos para animais de estimação".

O heroísmo é geralmente mais benigno. Embora muitas vezes os heróis estejam motivando a equipe, em certas ocasiões tentam tornar-se indispensáveis (criando o risco da pessoa-chave) ou tentando afirmar a própria visão sobre o projeto. Nesses casos, os objetivos do projeto não coincidem com os objetivos do herói.

Como líderes de equipe, há algumas coisas que podemos fazer sobre isso. Podemos optar por não fazer nada, se acreditarmos que os riscos criados por ter um herói são um preço pequeno a pagar pela quantidade de outros riscos do projeto que estão mitigando. Como alternativa, e provavelmente a resposta mais humana, é tentar examinar por que os objetivos do herói não se alinham ao projeto e ver o que pode ser feito para melhor alinhar os objetivos. Talvez o herói esteja tentando se tornar indispensável porque sente que seu trabalho está em risco? Como líderes de equipe, provavelmente podemos fazer algo sobre isso.

InfoQ: Quais são os desafios dos sistemas operacionais de software no mundo real?

Moffat: Muitas vezes, os riscos que enfrentamos no nosso pequeno sistema são os mesmos dos grandes. Um módulo de software não confiável pode ser uma fonte de risco de dependência, assim como um fornecedor ou um funcionário não confiável. Da mesma forma, podemos construir um software que tenha muito risco de complexidade e precise ser simplificado, mas às vezes, organizações inteiras são muito complexas e precisam ser simplificadas.

O que podemos encontrar em diferentes escalas é que o equilíbrio dos riscos que enfrentamos pode mudar. Quando estamos começando a criar um novo software, pode ser que estejamos preocupados principalmente com o Risco de Recursos, ou seja, tememos disponibilizar um software apenas útil para os clientes em potencial. Mas quando estamos operando um sistema de software do tamanho do Facebook, as preocupações podem ser voltadas para o Risco de Reputação. Na verdade, o Facebook é um bom exemplo disso, porque quando começaram o lema era: "Mova-se rápido e quebre as coisas", entretanto mudaram em 2014 para algo mais relacionado sobre confiabilidade: "Mova-se rapidamente com infraestrutura estável".

Então, acho que a resposta é "depende", mas ao tentar nomear e classificar diferentes tipos de risco, podemos pelo menos falar sobre qual é a coisa mais importante a ser tratada e podemos ver como os diferentes riscos "rimam" em diferentes escalas e em diferentes contextos.

InfoQ: Como podemos nos preparar para lidar com os riscos operacionais?

Moffat: Um conceito que acho útil é a idéia do "Modelo Interno". Ou seja, as coisas que uma pessoa, uma equipe ou uma operação inteira pensa que sabem sobre o mundo. Este Modelo Interno, contém uma visão sobre os riscos conhecidos e a gravidade deles, entretanto, existem riscos ocultos que não estão lá e geralmente são os que causam mais problemas.

Existe muita literatura boa e preexistente sobre gerenciamento de operações que não quero examinar, mas de um modo geral, desejamos testar e melhorar nosso Modelo Interno o mais rápido possível. O Risk-First chama isso de "Conhecendo a realidade" e acontece toda vez que tentamos fazer algo, porque nesse momento descobriremos se o modelo interno foi bom o suficiente ou não.

Se estivermos executando uma operação, convém tentar criar loops de feedback, para garantir que estejamos "encontrando a realidade" com a maior frequência e profundidade possível. Se pensarmos sobre isso, seja executando compilações automatizadas, testes beta ou executando um cenário de recuperação de desastre, em todos os casos estamos testando para garantir que nosso Modelo Interno corresponda à realidade.

InfoQ: No primeiro livro da série, foi abordado o cenário de risco. O que podemos esperar ver nos próximos livros?

Moffat: o cenário de risco é a ideia de que sempre que fazemos algo para lidar com um risco, o que realmente está acontecendo é que estamos assumindo outros riscos como resultado. Por exemplo, contratar novos desenvolvedores para uma equipe, pode eliminar mais Riscos de Recursos (criando recursos de que os clientes precisam), mas também significa que vamos escolher Riscos de Coordenação e Agência, devido à equipe maior. Então, estamos seguindo um cenário de riscos, esperando encontrar uma boa posição em que os riscos sejam melhores para nós.

Este primeiro volume do Risk-First Software Development era sobre esse cenário e os tipos de riscos que encontraremos nele. Estou planejando um segundo volume, que novamente estará disponível para leitura em riskfirst.org. Este se concentrará mais nas ferramentas e técnicas que podemos usar para navegar no cenário de riscos.

Por exemplo, se tivermos uma equipe distribuída, podemos enfrentar muitos riscos de coordenação, onde o trabalho é duplicado ou as pessoas passam por cima das outras. Quais são as técnicas que podemos usar para resolver isso? Poderíamos introduzir uma ferramenta de bate-papo como o Slack, mas isso pode acabar desperdiçando tempo do desenvolvedor e causando mais riscos de agendamento. Ou poderíamos tentar subdividir o sistema para que diferentes desenvolvedores tenham responsabilidades diferentes, mas isso pode implicar que o software não seja fatorado corretamente e é uma fonte maior de risco de complexidade ou risco de pessoa-chave.

O volume 2 também analisará mais de perto as metodologias como coleções de práticas que gerenciam riscos, esmiuçará as práticas de Scrum, XP, DevOps, Lean, SAFe e assim por diante, e tentará examinar exatamente quais riscos tratam e como o fazem.

Mas ainda é cedo para isso. Se desejarmos nos informar sobre como isso se desenvolverá, podemos favoritar o projeto no GitHub para ser convidado a participar da equipe Risk-First. Enviarei uma mensagem com as atualizações a cada duas semanas para dizer como estamos progredindo, e haverá alguns softwares interessantes em andamento para interagir e visualizar os diagramas do Risk-First, em breve.

Sobre o autor do livro

Rob Moffat é um desenvolvedor de software que deveria saber melhor quando desistir. Está aprendendo a criar software desde que usava calças curtas e, honestamente, não consegue ver nenhum cenário futuro em que esteja vivo e não continue a aprender. Mora no Reino Unido, perto de Londres, e criou o riskfirst.org, um esforço para descobrir os padrões subjacentes à maneira como os projetos de software funcionam.