💆🏼 🐤 🏧 O Scrum pode ser usado na terceirização? 👩🏿‍🌾 👩🏻‍🎓 👨🏻‍🍳

A pergunta é muito controversa, e eu pessoalmente não encontrei uma resposta simples e óbvia para ela, embora a procure há muito tempo e ainda a procure (ainda acredito que encontrarei uma maneira de usar a essência pura do scrum e nada mais no projeto de terceirização). No entanto, a própria estrutura fornece muitos nishtyaks, cujos benefícios são difíceis de negar, se não impossíveis. E, no entanto, na questão pela qual o artigo tem direito, um problema real é lido nas entrelinhas. Permitir a voz.

Problema

Scrum é uma estrutura ágil, que envolve desenvolvimento ágil. O desenvolvimento ágil requer prazos flexíveis e um orçamento semelhante. O desenvolvimento da terceirização, por sua vez, em 95% dos casos (exceto no beco sem saída) envolve prazos apertados e um orçamento apertado. Condicionalmente: “faça de mim um portal corporativo em 3 meses, o orçamento é de 3 milhões. Estou pagando pelo resultado. " E o cliente está certo, ele quer ver o resultado. E o gerente deve liderar a equipe para esse resultado. Mas aqui está como fazer isso usando o scrum?

Essa estrutura pressupõe incertezas no tempo e no orçamento. Ou seja, já na fase inicial do projeto, o próprio scrum diz: "Espere, não posso vir aqui, há prazos claros e um orçamento real, você precisa procurar um caminho crítico, planejar tudo com antecedência, procurar algo em cascata".

Solução para o problema

Etapa 1. Comece com algo em cascata para vender seus serviços.

Desde a infância, meu pai me ensinou: "Não há preto e branco, procure todos os prós e contras". Sim, o waterfall está desatualizado, sim, não é muito adequado para o desenvolvimento ágil, mas fornece entendimento e permite calcular o caminho crítico, levando em consideração todos os riscos. Provavelmente, o caminho crítico será impreciso e até uma avaliação pessimista será muito otimista (se você entende o que quero dizer), mas esta etapa fornecerá um entendimento aproximado da quantidade de trabalho para você e seu cliente.

Você precisará gastar muito tempo avaliando o projeto com os desenvolvedores. Para discussão de recursos. E este é um momento que é uma pena gastar, porque os recursos ainda terão que ser superestimados mais tarde, mas até agora sem ele, em nenhum outro lugar; caso contrário, o projeto não será vendido e o objetivo do desenvolvimento terceirizado não quebrará a cadeia, em busca do próximo osso - não haverá osso.

(!) Esta etapa não significa venda direta, trata-se apenas de determinar o condicional "de" e "para" em dinheiro e em termos.

Passo 2. Viva! Pegamos o projeto, começamos a trabalhar no scrum (à sua imagem e semelhança)

O projeto é realizado. Parece que todos os prazos estão lá. A tarefa é clara, bem, dirigimos a fazer. Alerta! Não seja tão rápido. Provavelmente, muitas coisas mudaram desde a avaliação do projeto pela primeira vez. Poderia, por exemplo, aparecer design ou exibir nova lista de desejos do cliente.

Eu tenho uma sugestão. Tente scrum. Na lista de pendências do produto, selecione a lista de pendências do sprint, noivo. Planeje seu sprint com cuidado e veja como a equipe lida com ele. Faça scrams diários no formato "O que o desenvolvedor fez ontem / O que ele faz hoje". E retro no final do sprint, para resumir os sucessos de cada um e os sucessos da equipe como um todo. Você notará rapidamente como o KPI de cada desenvolvedor cresce de sprint para sprint, como o número de retornos do controle de qualidade diminui e como o backlog do produto diminui.

PS Não se apresse em recusar novos desejos do cliente. Talvez eles façam sentido e possam ser adicionados sem problemas à lista de pendências do produto, em vez de outras funcionalidades que acabaram não sendo mais necessárias para os negócios do seu cliente (e, consequentemente, para o próprio cliente).

Etapa 2.1 Introduzir o proprietário do produto no projeto

Na maioria das vezes, as empresas de terceirização têm apenas um gerente de projeto. Sem se dividir em mestres de scrum e proprietários de produtos, mas esse não é um problema tão grande quanto parece à primeira vista.

Por exemplo, eu tenho um testador bacana no projeto, para quem delegou 90% das responsabilidades do proprietário do produto (os 10% restantes são o que vem do cliente e eu já o passo ao meu colega). Além do fato de ele estar envolvido em testes (e ele faz isso perfeitamente), ele também mantém e reabastece o backlog, escreve um dock, constrói tabelas de fluxo e de entidades: ele faz um ótimo trabalho (não em detrimento de seu núcleo), pelo qual eu simplesmente não tenho tempo, devido ao emprego em outros projetos.

Nesta abordagem, há outra grande vantagem. Para um testador experiente (e somente isso pode ser confiado à propriedade do produto), é uma ótima chance de não se cansar e se divertir com novas tarefas + para sentir o seu valor. Não esqueça de mostrar confiança nos membros de sua equipe, pelo menos porque é assim que você aumenta sua autoridade também.

PS Agora, eu trabalho nesse modelo, não em todos os meus projetos. Em algum lugar, um scrum simplesmente não é necessário, porque complica. Estes são principalmente pequenos projetos por um período de um mês ou menos.

Etapa 2.2 Converter a classificação do relógio em pontos da história

Não é o passo mais importante, você pode trabalhar sem ele, mas mais difícil. O fato é que, quando você avalia a tarefa em horas, o relógio é diferente para todos, leva 6 horas para alguém criar uma entidade de domínio (tarefa condicional), alguém tem 7, alguém tem 8. Em histórias todos terão o mesmo = 8.

De acordo com os pontos da história, será mais conveniente calcular o KPI de cada desenvolvedor, compilar uma revisão de desempenho e acompanhar o sucesso do projeto, em geral.

Organize com os desenvolvedores 8 pontos de história por dia (mb 5 de junho), planeje com base nisso e veja como as tarefas são fechadas e o projeto está sendo implementado.

Se um desenvolvedor fechar repentinamente 8 pontos de história em 4 horas (5 pontos de história, de acordo com os números de Fibonacci), não o carregue com novas alças. Aprecie seu acordo, respeite o trabalho dele. Parte do seu tempo "livre" restante ainda será gasto no estudo do próximo recurso, na preparação para o amanhã e em parte no autodesenvolvimento ou mesmo no lazer. Bom lazer também motiva o trabalho bem.

Etapa 3. Trabalhar com calma

Não faça tudo como está escrito nos guias scrum ou em qualquer outro padronizador do PM-sky. Tome decisões com flexibilidade e aproveite a situação. Selecione cuidadosamente as ferramentas oferecidas por diferentes estruturas e não hesite em tentar uma nova.

Não há necessidade de trabalhar em cascata ou scrum para gerenciar projetos com sucesso. Precisa trabalhar bem. Isso é tudo.

Conclusão

O Scrum pode ser usado, e será muito útil: uma excelente estrutura que oferece várias ferramentas legais para estar constantemente atualizado, desenvolver-se e fornecer a base para o crescimento da equipe, monitorar o progresso do projeto e considerar os membros do KPI da sua equipe.

No entanto, o scrum não é uma panacéia e, por exemplo, dizer ao cliente que inicialmente não sabemos quanto o projeto chegará a você e quanto tempo levará em termos de desenvolvimento terceirizado provavelmente falhará. É tudo a mesma coisa sem elementos em cascata.

Sinta-se livre para combinar as estruturas e usar as ferramentas de que você e sua equipe gostam, mesmo que não devam ser scrum. Faça com que funcione de maneira conveniente, porque esse é o objetivo principal de cada estrutura. E como ligar para ele é com você.

PS Eu tenho HMS - scrum geneticamente modificado.

O Scrum pode ser usado na terceirização?