Como o Scrum pode ser adaptado a um ambiente de Voluntariado?

Recentemente, ingressei em um jovem hackerspace ainda em processo de criação. Temos sorte porque o espaço possui alguns projetos internos que precisam ser trabalhados e falta de voluntários para trabalhar neles.

Houve algumas discussões sobre como organizar esses projetos. Minha experiência profissional mais recente foi no Scrum, por isso estou pensando em lançar uma abordagem Scrum para nossos projetos de software, mas não tenho certeza de que será uma boa opção.

Embora eu tenha visto o Scrum funcionar bem para pequenas equipes de tempo integral, a natureza desta organização é diferente:

• Os membros são voluntários . Alguns são estudantes em período integral. Outros trabalham empregos em período integral. Não podemos esperar um nível constante de contribuição de ninguém, pois suas vidas reais têm prioridade.
• Embora quase todo mundo tenha anos de experiência na criação de software, poucos membros o fizeram profissionalmente ou em equipes.
• Não há proprietário do produto . Os requisitos para esses projetos são determinados por um comitê. Os membros desse comitê também estarão trabalhando na implementação. Isso significa que não teremos um único e dedicado Product Owner.
• Não temos prazos (flexíveis ou rígidos). Os projetos serão concluídos quando concluídos.

Essas são diferenças bastante significativas, mas não estou convencido de que serão bloqueadores da aplicação do Scrum. Eu acho que alguns pequenos ajustes podem nos superar esse obstáculo:

• Se mudarmos o Sprints para ter um tamanho fixo de história, mas com uma duração fluida (tempo), ainda podemos nos beneficiar de lançamentos iterativos sem colocar pressão de entrega irreal sobre desenvolvedores voluntários.
• Podemos abandonar gráficos de burndown e cálculo de velocidade . Se bem entendi, essas são ferramentas e métricas que funcionam como uma ponte entre a equipe de desenvolvimento e o gerenciamento. Eles servem para relatar o progresso de uma forma que seja significativa para os desenvolvedores e as partes interessadas. Considerando que não temos ninguém com quem reportar (nenhum gerente de projeto, nenhum proprietário do produto e nenhuma parte interessada), acredito que podemos abandonar isso completamente.

As coisas que acho que poderíamos nos beneficiar não exigirão ajustes:

• As reuniões de reunião de requisitos . Onde todos se sentam ao redor de uma mesa e discutem histórias de usuários, esboçam simulações de interface do usuário e constroem um Backlog do produto.
• Retrospectivas da Sprint . Essa será uma maneira interessante de convergir para um processo de desenvolvimento que funcione para nós como uma equipe de voluntários.

Coisas sobre as quais não tenho certeza:

• Como devem ser tratados os Stand-ups diários ? Eu me pergunto se eles teriam muito valor em nosso ambiente. Meu entendimento do ritual de stand-up é que ele ajuda a comunicação naturalmente disseminando informações por toda a equipe. Considerando o fato de que nossos Sprints provavelmente oferecerão muito menos complexidade do que um Sprint médio, pode haver menos necessidade de estar a par dos progressos / desenvolvimentos de todos os outros membros da equipe.
• Devo pressionar para o XP coisas como Integração Contínua, Revisões de Código e TDD? Estou preocupado que isso esteja pedindo muito. Eu ficaria mais tentado a incorporar esses conceitos em projetos futuros quando as pessoas estiverem mais familiarizadas com o Scrum e trabalhando em equipe.

Minhas perguntas:

O Scrum pode ser adaptado a um ambiente voluntário?
E, minha abordagem planejada está indo na direção certa até agora?

Olhe para Kanban. É mais apropriado que o SCRUM para suas restrições.

Edit: SCRUM é (aproximadamente) um backlog ordenado com sprints e cerimônias para garantir que o volume de trabalho 'em andamento' permaneça sob controle e tenha algo sólido no final de cada sprint. Se você abandonar as cerimônias e a cadência dos sprints, acabará com o Kanban: um backlog ordenado e uma forte ênfase em limitar o trabalho 'em andamento' diretamente e garantir que tudo marcado como 'concluído' seja feito, em vez de impor estabilidade no final de cada corrida.

Você ainda obtém os benefícios ágeis: libere a qualquer momento, flexibilidade, alguma medida de previsibilidade - embora o SCRUM possa levar você um pouco mais longe nesse aspecto - e sem as cerimônias ou aspectos do SCRUM que não se encaixam bem em uma equipe distribuída e solta, sem compromisso . A pegada? A retirada das cerimônias exige mais disciplina; portanto, você REALMENTE precisa prestar atenção nos testes, na qualidade do código, no trabalho atual em andamento e garantir que a parte superior da lista de pendências (itens prontos para serem escolhidos pelas pessoas) seja suficientemente elaborada.

Você pode ter uma lista de pendências baseada em votos, embora em um ambiente de voluntariado algumas pessoas trabalhem com o que elas querem.

(E sim, todas as idéias de TDD, CI, revisões e programação por pares são boas).

Para resolver as diferenças que você observa primeiro:

• O fato de seus membros serem voluntários não significa que você não pode pedir um compromisso. Especialmente com a duração relativamente curta de um sprint no Scrum, deve ser possível para cada um dos membros saber quanto tempo eles podem dedicar ao projeto nas próximas semanas. Ter os membros da equipe disponíveis por um período diferente a cada sprint tornará o planejamento um pouco mais difícil, porque é mais difícil determinar quantos pontos de história são realistas, mas isso não inviabiliza o Scrum.
• O proprietário do produto é responsável por consolidar e comunicar a visão (e os requisitos) que as partes interessadas têm do produto para a equipe de desenvolvimento. A parte de consolidação provavelmente já está coberta pelo comitê 'de direção'. Na parte da comunicação, eles podem apenas delegar um de seus membros como porta-voz principal. Esse será, para todos os efeitos práticos, o proprietário do produto.
• Não ter um prazo externo não é realmente um problema para o Scrum. Apenas se resume mais ao orgulho da equipe no produto para finalizá-lo. O próprio Scrum tem um prazo natural para cada sprint.

Em relação às adaptações propostas, especialmente ao trabalhar com voluntários, eu recomendo fortemente manter o comprimento fixo do sprint. Dessa forma, os voluntários sabem definitivamente por qual período estão se comprometendo.

Eu também não abandonaria os gráficos de burndown imediatamente. Eles também podem ser úteis para a própria equipe, para ver como eles estão se saindo com o compromisso deles. Eu deixaria para a equipe decidir mantê-los ou abandoná-los. O mesmo vale para os cálculos de velocidade. especialmente com a grande variação de horas disponíveis a cada sprint, elas podem ser muito úteis (especialmente se você calcular o número de pontos concluídos por hora) na estimativa de sprints futuros.

Em relação às exibições diárias, elas ainda serão úteis em sua configuração, apenas para informar o que todos estão fazendo ou têm problemas (e isso é independente da complexidade). Mas pode ser mais difícil realizar um stand-up diário, por isso é necessário comprometer-se lá.

As práticas XP mencionadas podem ser introduzidas ou não independentemente do uso do Scrum e também podem ser propostas durante uma retrospectiva.

Surpreende-me que ninguém tenha apontado, mas o seu projeto parece ser a maioria dos projetos de código aberto. Se você conferir alguns projetos de código aberto mais populares, poderá encontrar alguma inspiração. E eu acho que você deve esquecer o SCRUM e pensar sobre isso da perspectiva do agile geral.

Agile é tudo sobre comunicação e colaboração. Há razões pelas quais há 2 pontos em 4 no Manifesto Ágil falando sobre isso.

Indivíduos e interações sobre processos e ferramentas

Colaboração do cliente sobre negociação de contrato

E da maneira que você descreve o seu projeto, seria difícil ter uma comunicação cara a cara com todos que trabalham no projeto, algo que o Agile e o SCRUM incentivam. Então, a primeira coisa que eu focaria seria estabelecer canais de comunicação para toda a equipe (voluntários e comitê de produtos). Coisas como wiki, fóruns, videoconferências e backlog adequado, sistema de rastreamento de tarefas e bugs são ótimas maneiras de garantir que todos saibam o que está acontecendo e o que precisa ser feito.

A segunda coisa que gostaria de observar é não apenas escovar as partes tecnológicas do ágil. Muitos acreditam (inclusive eu) que são eles que fazem o trabalho ágil, não o lado do processo. A revisão de código é importante e a maioria do trabalho de código-fonte aberto, quando alguém que conhece o projeto revisa os commit / push para garantir a manutenção de uma qualidade suficientemente alta. O TDD é praticamente fornecido para qualquer projeto ágil. Ele garante que quaisquer alterações no código não quebrem a funcionalidade anterior, o que é ainda mais importante no seu caso, quando os voluntários não podem se incomodar em corrigir os erros e erros de outras pessoas. Isso também facilita a revisão de código, porque o revisor pode ver nos testes qual funcionalidade foi adicionada e, executando-os, ele garante que a funcionalidade realmente funcione conforme o esperado. A integração contínua é igual ao TDD.

A última coisa é que acredito que você deve ter pelo menos poucas pessoas trabalhando no projeto em tempo integral. Essas pessoas devem ter funções específicas:

• Dono do produto : Embora seja bom que você tenha um comitê inteiro dedicado a isso, deve haver uma pessoa responsável por interpretar as palavras desse comitê em especificações ou histórias de usuários e garantir que elas sejam implementadas adequadamente.
• Coordenador e Scrum Master : Essa pessoa deve ser responsável por todo o processo e garantir que todos saibam sobre as coisas importantes que estão acontecendo no projeto. Além disso, ele mantém o wiki e as ferramentas de rastreamento de tarefas e bugs. Se alguém tiver alguma dúvida sobre o projeto, essa é a primeira pessoa que deve perguntar.
• Desenvolvedor e arquiteto principal : a pessoa que conhece melhor o código. Ele faz a revisão do código e garante que a qualidade do código seja boa o suficiente para o desenvolvimento ágil.

Você não pode adaptá-lo da maneira que está descrevendo e ainda o chama SCRUM. mas na minha opinião, você pode usar o Scrum como a seguir para a configuração que você descreveu.

1. Ter iteração fixa. Para que você possa medir seu progresso. Isso não é apenas para a gerência, mas também para a equipe "saber" como eles estão se saindo.
2. Peça aos voluntários que compartilhem capacidades no início da iteração. Toda a equipe precisa do que os membros estão comprometendo, caso contrário, determinado membro pode deixar a equipe pelo trabalho mais profissionalmente realizado.
3. Não ter prazo é bom. O Scrum não força que, no entanto, o que você faz no final de cada iteração deve ser potencialmente entregável. Isso permitirá que você decida o que fazer a seguir com base no que você fez até então (que está funcionando).
4. Não ter um proprietário do produto também pode funcionar. Você pode ter algum tipo de sistema de votação para empilhar a lista de pendências e aceitar / rejeitar o trabalho realizado.
5. A coleta de requisitos não faz parte do Scrum. Você pode fazer o que quiser. Mas não inclua isso como parte do escopo da iteração. Tem capacidade separada para isso. Portanto, para uma iteração, planeje apenas o trabalho para o qual os requisitos são claros, por exemplo, a equipe conhece os critérios de aceitação.
6. Retrospectiva são boas. Portanto, inicie o Scrum como ele, mas usando retrospectivamente, veja o que está funcionando e o que não está, por exemplo, você pode precisar alterar o tamanho da iteração, pode precisar se livrar de alguns voluntários que estão arrastando todos os outros.
7. O status diário é obrigatório. Isso dá oportunidade à equipe de sincronizar entre si, ou seja, alinhará seus esforços para que nenhuma tarefa seja bloqueada desnecessariamente devido à indisponibilidade da entrega de outro membro.
8. XP é bom. Tenha uma definição estrita de feito com base no XP, por exemplo, nenhum código será inserido, a menos que seja revisado. Faça menos para fazer mais ..

Eu poderia sugerir uma abordagem diferente. Como você está lidando com voluntários, você precisa considerar algumas coisas. Sua equipe provavelmente terá uma alta rotatividade, a vida ficará no caminho e as pessoas se distrairão. Dos que sobraram, alguns contribuirão consistentemente, mas não muito, e por fim, você terá aquele grupo de hardcore que realmente afunda no projeto. Estou fazendo muitas suposições sobre sua força de trabalho aqui e, se você sentir que minha avaliação não reflete as pessoas com quem está trabalhando, fique à vontade para ignorar o restante.

Agora você precisa de uma estratégia que permita que as pessoas que não trabalham muito possam trabalhar de maneira autônoma, elas só têm muito tempo para se dedicar a isso e não deseja fazê-las gastar a maior parte disso em comunicação. As pessoas mais envolvidas devem ser responsáveis ​​pela integração e liberação de algumas das idéias mais complexas.

Isso me leva a pensar em um processo de desenvolvimento mais focado em estruturas e protótipos de arame.

Você pode ter um conjunto de itens de trabalho disponíveis e incentivar as pessoas a escrever armações de arame para eles. Você pode usá-los como Tracer Bullets (terminologia emprestada do programador Pragmatic) para aprimorar a ideia e fornecer inspiração para as pessoas desenvolverem. A partir daí, você pode graduar as idéias bem-sucedidas em protótipos; novamente, esses são projetos muito pequenos, projetados para ajudar as pessoas a aprender mais sobre os projetos. Depois disso, agora você tem uma seção menor de idéias sólidas que foram criadas por uma multidão de pessoas que você pode entregar a uma equipe um pouco mais ativa e que pode trabalhar para integrar essas idéias ao seu sistema.

Eu acho que Kanban se encaixaria melhor nessa situação.

O Scrum tem algumas coisas que não se encaixam. As medidas de tempo ou escopo não são necessárias e todo mundo que desenvolve tem a mesma visão do produto das reuniões. A responsabilidade e o cumprimento de um plano curto com consistência são objetivos de negócios.

O Kanban oferece muitas das mesmas vantagens que o Scrum, sem suas desvantagens. Pode fornecer prototipagem rápida. Os protótipos podem ser executados antes das reuniões. Também fornece TDD para testes de código e regressão variáveis. A programação em pares pode facilitar os recém-chegados e não-regulares à base de código, transferindo conhecimento.

O Kanban também tem vantagens únicas. Se a visão do que os usuários fazem estiver sendo desenvolvida em paralelo, o Kanban funcionará bem. Prova disso é o sucesso de programas para pequenas empresas. Além disso, nos dias com poucos voluntários, como três pessoas, Kanban ainda funcionaria bem. Scrum, apesar de ser leve, seria muita fita amarela.