Fui convidado por uma organização pública a dar um workshop informal sobre os 101 do desenvolvimento ágil, explicando os termos e conceitos de Scrum, Kanban e similares. Trabalho em ambientes ágeis há cerca de cinco anos, mas não me considero evangelista do Scrum.

Após o workshop, eles gostaram da ideia. No entanto, eles explicaram que a abordagem provavelmente não se aplicaria a eles, pois eles precisam contratar empresas de software externas para desenvolver software para elas (elas têm apenas alguns desenvolvedores). Essa atividade precisa ser realizada em um processo de licitação pública que descreva o resultado, preço e prazo. Este é um requisito legal para solicitar um orçamento para esta organização (um instituto público de pesquisa).

Essas restrições parecem um tanto contraditórias aos princípios fundamentais do desenvolvimento ágil, não são?

Scrum é apenas incompatível em tal ambiente?

O que você recomendaria para esta organização?

Provavelmente, o Scrum não é apropriado para esta organização.

No Guia Scrum, "Scrum é uma estrutura para o desenvolvimento, fornecimento e manutenção de produtos complexos". Também foi desenvolvido para uma equipe de 3 a 9 membros de uma Equipe de Desenvolvimento que trabalha no produto, um Dono do Produto e um Scrum Master (que podem ou não estar na Equipe de Desenvolvimento), totalizando de 4 a 11 pessoas.

Com relação ao desenvolvimento interno, você menciona que eles têm apenas alguns desenvolvedores. Se não houver uma equipe grande o suficiente para formar uma equipe Scrum, não faz sentido usar todo o Scrum. No entanto, algumas práticas do Scrum podem ser úteis para a organização.

Para o desenvolvimento contratado, é possível que uma das partes externas use o Scrum. Nesse caso, é útil que o instituto de pesquisa conheça as práticas do Scrum e compreenda os papéis e como ele funciona. Eles ainda podem precisar entender as especificidades de como a organização de desenvolvimento externa usa as práticas do Scrum, bem como outras práticas, mas isso pode ajudá-los a entender como funciona. Por exemplo, entendendo a necessidade de participar das Revisões da Sprint ou de trabalhar com a organização (provavelmente o Dono do Produto) no pedido do Backlog do Produto.

A 18F, uma agência de serviços digitais do governo dos EUA, trabalhou muito em como o governo pode escrever contratos para permitir o uso de metodologias ágeis de maneira consistente com a lei, especificando resultados gerais e não requisitos detalhados de como o trabalho deve ser feito. Alguns de seus recursos incluem:

• Melhorando os resultados do governo por meio de um formato de contrato ágil
• Contrato de compra geral ágil
• Contratação Modular (dividindo projetos grandes em projetos modulares menores com desenvolvimento ágil)
• Seu projeto está usando "agilefall"?

Uma vantagem dos métodos de trabalho ágeis é que eles se concentram na descoberta de uma solução para um problema após a adjudicação do contrato, ou seja, durante a execução pós-adjudicação, em vez de especificar a solução detalhada antecipadamente, como na Parte 15. Um contrato ágil tenta: especifique problemas que exijam soluções detalhadas, geralmente como Itens do Backlog do Produto que descrevem áreas de entrega de contratos de alto nível.

Entendendo esse problema, o Escritório de Gerenciamento e Orçamento e o Escritório de Política Federal de Compras determinaram que as agências parassem de usar SOWs e passassem a usar uma Declaração de Trabalho de Desempenho (PWS) para a aquisição de serviços. Um PWS “deve declarar requisitos em termos gerais do que (resultado) deve ser feito, e não como (método) é feito”. Os bons contratantes aconselham as agências que, ao comprar serviços especializados, isso implica que você não é o mais conhecedor. em "como" o trabalho é feito. Como proprietário da missão, você é o especialista em "o quê", deve ser cumprido, mas a fusão das duas coloca sua missão em risco e dificulta o fornecimento de valor por um contrato.

Fundamentalmente, a abordagem é mais como contratar um provedor de serviços para trabalhar com você para projetar uma solução, em vez de listar antecipadamente páginas de especificações detalhadas. A instituição não contrataria um arquiteto para projetar um novo edifício listando "o projeto deve ser de quatro andares, com uma inclinação de 37º. O terceiro andar deve ter uma cozinha de 237 pés quadrados contendo quatro luminárias fluorescentes, controladas por um movimento sensível à luz, em um teto suspenso. " Em vez disso, eles teriam um contrato para o arquiteto fornecer serviços de design em consulta com o cliente, e confiariam em seu fornecedor, um especialista na área, para produzir os resultados resultantes.

Embora os detalhes dependam da instituição e das políticas e leis de compras aplicáveis, ele mostra que, em meio a todas as falhas de grandes projetos de TI do governo, há grupos trabalhando para mover licitações públicas para desenvolvimento de software para metodologias ágeis mais modernas, dada vontade política suficiente e parceiros de desenvolvimento confiáveis. É preciso uma grande mudança na maneira como esses projetos são concebidos e gerenciados (incluindo muito tempo em andamento, fornecendo feedback do usuário ao longo do processo), que a organização pode ou não ter interesse em prosseguir.

Parece típico. Uma vez redigida a proposta, as ofertas são recebidas e um dos concorrentes recebe o contrato ... no que diz respeito aos representantes da organização pública, o projeto está concluído.

É por isso que muitos desses projetos falham. Depois que eles ultrapassaram o orçamento.

O ponto que eles estão perdendo (ou pelo menos não sentem que é da sua preocupação) é que eles são partes interessadas que deveriam estar participando de reuniões e demonstrações.

Portanto, não há conflito com o Agile ou o Scrum. São pessoas que não assumem seus papéis. É a maneira como o governo trabalha que causa isso.

Não é como "gostaríamos de ter esse sistema e estamos dispostos a colocar algum esforço nele e ver até onde podemos levá-lo".

Não. É como "nossa democracia decidiu que teremos esse sistema até então". O que não deixa espaço entre 100% de sucesso, por um lado, e 100% de falha, por outro. Condenado desde o início.

Também é um convite ao mercado para solicitar taxas ridículas. Não fazer o projeto porque é muito caro não é uma opção, a decisão de fazê-lo já foi tomada antes da redação do concurso.

Justo, mesmo que as partes interessadas assumissem seus papéis, elas seriam totalmente impotentes. Nenhum deles teria um bastão credível para levar a essas demos pelo mesmo motivo.

Não, o SCRUM não é incompatível com os concursos públicos. Você precisa declarar explicitamente o que está comprando em um concurso público.

"O comprador deseja comprar 10 sprints de desenvolvimento de duas semanas, de uma equipe experiente do SCRUM, com 5 desenvolvedores e um mestre certificado do SCRUM (o comprador assumirá o papel de partes interessadas). Os sprints serão executados de março de 2018 a julho de 2018" é bastante razoável início do concurso. Você precisará listar as habilidades de equipe necessárias, é claro, e dar uma idéia sobre o projeto em que trabalharão, mas é perfeitamente aceitável ter uma proposta para contratar uma equipe.

Claro, você está desistindo do "escopo fixo" aqui. Isso é típico para o SCRUM, afinal. Com um pouco mais de redação no concurso (mas estamos entrando em território legal aqui), você pode permitir uma pequena extensão de escopo, ou seja, um pequeno número de sprints adicionais. Mas se você decidir que deseja 10 corridas adicionais após as 10 corridas iniciais, provavelmente precisará repetir o concurso.

É difícil.

Obviamente, você não pode oferecer o trabalho com um orçamento em aberto. Portanto, você precisa analisar o que precisará ser feito e quanto esforço é necessário para fazer isso.

Agora, a razão pela qual muitos projetos de software falham se deve ao fato de que a fixação, o tempo, o esforço e o escopo são muito propensos a erros. Por exemplo, uma especificação apresentada em uma proposta quase sempre terá alguma ambiguidade.

Portanto, há uma questão fundamental não apenas com o ágil, mas com o conceito de concursos abertos para o desenvolvimento de software. As chances de alguém sair e criar exatamente o que você queria, no tempo especificado, são baixas.

Se você permitir alguma flexibilidade, poderá melhorar isso.

Parece que o processo de abertura de concurso público não é flexível. No entanto, uma vez que o contrato seja vencido, você poderá descobrir que há espaço para se esquivar. Você poderia, por exemplo, permitir um trabalho ágil, mas precisaria aceitar (e obter autorização legal) que isso poderia afetar o escopo.

Agora, acredito que isso resultaria em um produto melhor, pois você poderá ver o que está acontecendo cedo e fazer alterações antes de serem inseridas no produto. Loops de feedback apertados e desenvolvimento iterativo podem tornar os produtos mais adequados aos requisitos reais (que podem ou não ser o que foi licitado).

Depende, mas provavelmente sim.

Estou disposto a apostar dinheiro para que todos os que já trabalharam com qualquer governo em qualquer projeto relacionado à TI saibam que, na prática, os 'limites rígidos' descritos no concurso nunca são cumpridos. As coisas tendem a exceder o orçamento, atrasam e / ou o escopo é alterado. Geralmente vários deles. Se os governos estiverem dispostos a admitir que essa é a verdade e a tratá-los como as diretrizes, então o scrum pode funcionar muito bem.

Por experiência pessoal (tanto na minha rede quanto na minha profissional), sei que os requisitos mudam frequentemente na maioria dos projetos do governo. Os comitês responsáveis ​​também tendem a receber muito feedback quando finalmente se envolvem no final de um projeto. Esses são problemas para os quais o Scrum é adequado.

No entanto, isso exigiria uma mudança fundamental de mentalidade por parte dos governos e de suas agências. Na maioria dos países, é muito improvável que essa mudança ocorra. Até esse momento, os concursos públicos continuarão sendo incompatíveis com o trabalho com o Scrum. (Na verdade, na minha opinião pessoal, os concursos públicos continuarão sendo incompatíveis com qualquer prática sustentável de desenvolvimento de software, mas isso é outra questão por outro tempo ...)

O que você recomendaria para esta organização?

Neste ponto nada.

O que falta aqui é a história de quais problemas o processo atual deles está causando. Scrum não é algo que se recomenda cegamente. Isso tem razão. Não é um tamanho único.

Pergunte a eles que problemas o processo atual lhes causou. Ouço. Apenas recomende métodos que resolvam seus problemas reais. Eles serão direcionados para o processo atual. Os Tinders podem parecer que ditam um processo de desenvolvimento, mas não o fazem. Eles ditam um processo de entrega. Mas essa é uma distinção que essa equipe provavelmente nunca teve que fazer antes.

O Agile funciona melhor quando os requisitos mudam mais de 3% ao longo da vida útil do projeto. Caso contrário, a cachoeira ainda é muito eficaz. Ainda é usado em muitos lugares hoje. E, é claro, muitos desenvolvedores de sucesso nunca formalizam seu processo de qualquer maneira. Informal funciona bem quando os problemas difíceis são técnicos, não sobre as pessoas.

Portanto, converse com eles sobre o processo atual e os problemas que ele tem. Diga a eles sobre o que esses métodos ajudam. Mas se não estiver quebrado, não conserte.