Equipe de desenvolvimento de uma sprint de fluxo de trabalho

Se você se importa com pelo menos algumas coisas úteis:

a. disciplina básica
b. a formação de processos acordados de interação entre si e aliados
c. uma explicação sobre o que e como os subcontratados fazem
d) flexibilidade no gerenciamento de processos
Resposta oportuna a problemas emergentes

então eles melhorarão o clima de trabalho na equipe de desenvolvimento.

Se você quiser se desenvolver com calma, precisará se reunir, concordar e escrever regras transparentes para interagir um com o outro. Pelo menos o mais básico.
Quaisquer processos e acordos devem ser elaborados com a participação de todas as partes interessadas e os processos que afetam negativamente devem ser destruídos.

Quero pintar no exemplo do fluxo de trabalho de um sprint quais benefícios seus elementos trazem: quais ações são executadas, quais artefatos estão presentes e por que cada um deles é necessário. Você deve primeiro se familiarizar com as definições de eventos e artefatos de scrum.

Sprint N-1 : Preparatório. O que não é exatamente um sprint.
Antes do início do sprint N do próprio desenvolvimento, parte da equipe está envolvida em trabalhos preparatórios: teste, aprovação, desenvolvimento, visualização etc.
Significado : para que os desenvolvedores possam executar a tarefa de maneira qualitativa, atingir os parâmetros necessários ou resolver o problema de alguém, antes do início do desenvolvimento:

a. faça todo o trabalho preparatório,
b. reduzir discrepâncias,
c. testar usuários ou obter aprovação das partes interessadas,
d) crie uma visualização detalhada.

Saída : um conjunto de artefatos e dados que atendem à lista de verificação Definition Of Ready.

Se você deseja melhorar a interação entre codificadores e todos os outros participantes diretos no processo de desenvolvimento, será útil familiarizar e explicar as funções e processos básicos de todos os participantes. Entre os codificadores, há introvertidos suficientes que não gostam quando interrompem o processo, mas também precisam entender como o resto funciona para que não obtenham o efeito oposto. Começamos:

Início do Sprint N-1 :



OKR, KPI, requisitos das partes interessadas , etc. - Um conjunto de condições externas de entrada que orientam o desenvolvimento.

Objetivo de sprint N.
Dependendo das condições de entrada, para onde o desenvolvimento deve se mover, quais parâmetros precisam ser alcançados, quem e por que ajudar, o objetivo do próximo sprint de desenvolvimento é formado.
Significado : o objetivo do sprint atua como uma motivação para a equipe, uma explicação do significado de suas atividades, estabelecendo indicadores.
Na ausência : codificadores desmotivados são controlados principalmente com chicotes, mantas e multas.

Qualquer equipe precisa de motivação para que o desenvolvimento não se transforme em uma série interminável de tarefas sem sentido, e não está claro se alguém precisa. Especialmente em empresas onde o desenvolvimento não é a base dos negócios, um problema geralmente surge quando o departamento não é apreciado, e é por isso que a auto-estima e a motivação diminuem. Precisamos de um objetivo transparente e compreensível - ajudar alguém a resolver o problema, melhorar alguns parâmetros dos negócios, melhorar a vida de alguém. Mesmo na empresa mais miserável, é bom ter consciência do significado de suas atividades.

Preparação da lista de pendências - reunião ou atividade contínua. Gerenciando o backlog de uma parte limitada da equipe.
Significado : Cada sprint realiza uma reunião com uma composição limitada para limpeza, estudo básico, avaliação inicial de complexidade e viabilidade, decomposição, priorização de tarefas no backlog.
Sair : uma lista de tarefas relevantes e viáveis.
Caso contrário : uma lista enorme de lista de desejos no backlog, que ninguém lê, onde as tarefas ficam esquecidas há anos.

Planejamento de sprint N-1 - uma reunião em que parte da equipe de treinamento, com base no objetivo e escopo do próximo sprint N, seleciona, pré-avalia e prioriza tarefas.
Sentido : a preparação para o sprint também requer alguma ordem. O gerenciamento de recursos é simplificado.
Saída : sprint N. backlog

Desenvolvimento de teste
Depende do estilo de desenvolvimento e da presença de testadores na equipe.
Significado : vale a pena ter planos prontos para verificar a integridade do código.
Sugiro considerar duas opções:
Na ausência de testadores, há uma opção para transferir a criação de testes para a equipe de desenvolvimento. Nesse caso, essa atividade é executada como parte do desenvolvimento de tarefas no sprint N. De acordo com algumas revisões, essa abordagem melhora a qualidade do código escrito pelos desenvolvedores.
Se você tiver testadores, poderá usar a abordagem quando os testes forem escritos antes do código. Uma das utilidades é que o desenvolvimento da tarefa termina no desenvolvedor e reduz a chance de retornar a tarefa finalizada dos testadores quando o desenvolvedor já tiver alternado para outra tarefa.

Estudo de Caso de Uso - estudo detalhado de cenários de interação e resultados dentro da tarefa.
Significado : uma descrição dos cenários de interação da tarefa com texto ou diagramas melhora a compreensão do problema por todas as partes interessadas. A solução de baixo custo pode ser usada para criar casos de teste e prototipagem.
Na ausência : baixa elaboração leva a uma divergência de entendimento do que é realmente necessário para a tarefa, a perda de casos de uso alternativos é possível.

Wireframing, mockuping e prototipagem são, em geral, um processo iterativo de desenvolvimento da visualização da interface, com detalhes cada vez maiores. Começando com a opção mais simples e barata, os usuários / partes interessadas são testados para verificar se a opção proposta atende à expectativa de resolver o problema. O teste visual é tão útil na redução da inconsistência das descrições de texto e é muito barato comparado à codificação que nas empresas com um forte design e lobby de produtos, eles começaram a separá-lo em uma metodologia separada com seus processos, artefatos e cronograma.

Wireframing - esboço aproximado de elementos da interface. Uma caneta em um pedaço de papel ou em software sem frescuras.
Sentido : teste / aprovação rápida e barata pelas partes interessadas da tarefa. Uma demonstração adicional de visualização melhora drasticamente a percepção do que apenas texto descritivo.
Na ausência : uma divergência de entendimento sobre o que realmente está sendo criado. Aumento dos custos de desenvolvimento.
Na ausência de aprovação : obtenha aprovação documental ao desenvolver para uma parte interessada, para minimizar a chance de "eu não pedi isso".
Saída : wireframe de rascunho aprovado / testado.

Maquete é o segundo passo para visualizar sua interface. O aumento em detalhes.
Significado e ausência : semelhante ao wireframing. Preparação de conteúdo para layout.
Saída : maquete e layout aprovados / testados.

A prototipagem é a terceira etapa no desenvolvimento da visualização da sua interface. Para visualização com alto detalhe, é adicionada uma demonstração de imitação da interação do usuário com o produto.
Significado e ausência : semelhante a wireframing e mockuping.
Saída : temos um protótipo detalhado do produto e visualização da interação. Além da aprovação documental das partes interessadas ou do resultado de testes nos usuários.

DoReady = Definição de Pronto - a lista de verificação das condições acordadas pela equipe de desenvolvimento e pré-treinamento de acordo com as quais serão verificadas: o estudo das tarefas tem um nível suficiente, a presença de todos os artefatos necessários, para que a tarefa possa ser aceita no desenvolvimento.
Significado : Ter uma lista de verificação formal acordada por todas as partes interessadas melhora a compreensão e a interação dentro da equipe. Todo mundo sabe o que e como passar. Você pode enfiar o nariz na lista de verificação e enviar para terminar os trabalhadores negligentes.
Na ausência : “Ah, quase terminei, está 95% pronto.” e ... nunca será concluído.

IMHO, este é o artefato mais importante para resolver conflitos básicos entre codificadores e todos os outros. Fica imediatamente claro quem e como não finalizaram o trabalho, o que violaram e como isso afetará os outros. É muito mais difícil argumentar com as regras estabelecidas do que quando há uma disputa baseada em opiniões ou pressão por autoridade / posição. Embora o moderador do PM que cutuca o item desejado ainda seja útil.

Passou ainda mais:

Sprint N. Começamos o desenvolvimento.

Sprint Start N :



Definição de Pronto, Objetivo do Sprint, Lista de tarefas inicialmente avaliadas - as condições (e artefatos) necessários para iniciar o sprint.

Planejamento do Sprint N - uma reunião em que a equipe de desenvolvimento, com base no objetivo e no escopo do sprint N, seleciona, avalia, prioriza e decompõe tarefas. Dependendo da velocidade média da equipe, uma certa quantidade de tarefas é obtida.
Sentido : a principal reunião em que a equipe verifica se as tarefas foram realizadas satisfatoriamente. Eles entendem corretamente as tarefas definidas, os critérios de aceitação. Os desenvolvedores finalmente avaliam o custo das tarefas.
Na ausência de : caos, as tarefas serão definidas a qualquer momento, por qualquer pessoa incompreensível, mesmo no meio da realização de outras tarefas.
Saída : sprint N. backlog
Nota: dependendo da velocidade da equipe, os sprints geralmente levam de 70 a 80% das tarefas para o objetivo do sprint e 20 a 30% das tarefas para bugs, dívidas técnicas ou tarefas críticas súbitas.

A decomposição e a atribuição de tarefas geralmente são uma mini-reunião para uma equipe de desenvolvimento sem pessoas extras.
Significado : uma equipe com um líder de equipe decompõe as tarefas de sprint em subtarefas por um período não superior a 1 dia (borda 2). As subtarefas são atribuídas pelos desenvolvedores, dependendo de sua especialização ou preferência.
Na ausência : depende da participação da equipe no processo se os desenvolvedores receberão tarefas interessantes que contribuem para o seu desenvolvimento.
Saída : detalhando as subtarefas de N a 1 dia da lista de pendências do sprint.

Reunião diária - reunião curta diária da equipe de desenvolvimento.
Significado : todos os dias, os desenvolvedores devem sincronizar-se entre si: quem fez o que e o que no dia anterior, o que planeja realizar no dia atual e quais problemas interferem na tarefa.
Na ausência : ninguém sabe no que os outros estão trabalhando, seus problemas de implementação. Os prazos de desenvolvimento estão sendo interrompidos.
Saída : o progresso é registrado no gráfico de queima - o agendamento das tarefas.

Minha opinião é que um dos principais significados da existência de comícios diários é a introdução da disciplina. Os programadores têm muitos introvertidos que não querem se comunicar, não querem saber o que os outros estão fazendo, não querem gastar tempo em comícios. Daí as regras para executar em pé, brevemente.
De fato, se a equipe trabalhou bem em conjunto, se comunica bem em um bate-papo e compartilha imediatamente qualquer problema, o número de reuniões pode ser reduzido pela reestruturação das reuniões em um processo contínuo. Mas você não deve cortá-lo completamente.

Discussão e resolução de interferência é uma continuação direta da reunião diária.
Significado : depois que os desenvolvedores expressam problemas com a implementação de tarefas, é realizada uma discussão sobre as tarefas que a equipe pode resolver internamente, depois é direcionada aos participantes e a interferência na solução externa é direcionada à PM.
Caso contrário : os problemas de implementação devem ser resolvidos juntos, o mais rápido possível, para que ninguém prejudique artificialmente o progresso.

Quando os introvertidos fugiram, aqui você já pode discutir os problemas e suas soluções.

Confirmação / Revisão de Código - verificação de código por outros membros da equipe.
Significado : 1-2 outros membros da equipe devem examinar o novo código e aprovar a qualidade, o estilo etc.
Caso contrário : aumente o número de erros no código, baixa qualidade e estilo.

Eles se oferecem para realizar a revisão de código 2 por outros desenvolvedores com níveis diferentes, mesmo para os juniores, essa é uma boa maneira de aprender. De uma forma ou de outra, a equipe obtém um estilo aceitável, quem sabe quando e quem precisará retornar ao código de trabalho.

Implantar no servidor / pré-demonstração de desenvolvimento - faça upload do código no ambiente / servidor de desenvolvimento.
Significado : qualquer implementação da tarefa pode ser carregada no ambiente de desenvolvimento e convidar as pessoas interessadas para teste e aprovação preliminar do trabalho realizado.
Caso contrário : no sprint de demonstração final, você pode ficar em uma posição desconfortável demonstrando uma implementação quebrada ou incorreta.
Saída : aprovação informal da tarefa.

De qualquer forma, interpretações incorretas da tarefa, ou os critérios de leitura da tarefa obliquamente, às vezes chegam a esse estágio. Quanto mais cedo a tarefa for verificada e testada, menos frequentemente será necessário retornar a ela.

Definição de Concluído - Semelhante à Definição de Pronto, esta é uma lista de verificação dos princípios pelos quais o PM / PO aceita tarefas concluídas.
Sentido : criado pela equipe de desenvolvimento em conjunto com PM / PO para previsibilidade dos parâmetros de aceitação do trabalho. Todo mundo sabe qual é o critério da tarefa e o que não é.
Na ausência : sem critérios claros, o "refinamento" das tarefas aparece após tentativas de aprovação. Ou as tarefas permanecem inacabadas até os requisitos finais.

Um contrato documental pelo qual o PM / PO aceita a tarefa e seus critérios, aprovados por ambas as partes. Bem reduz a quantidade de pontos controversos.
Impede o PM / PO esmagando insolentemente o poste. Corta as tarefas "concluídas" em 95%. Os desenvolvedores não devem concluir as tarefas concluídas após o sprint, se a tarefa claramente não atender à lista de verificação, ela não deverá ser considerada aceita e seguirá para o sprint futuro.

Revisão e demonstração do incremento do produto - uma manifestação na qual os desenvolvedores demonstram às partes interessadas a implementação do objetivo do sprint.
Significado : os próprios desenvolvedores demonstram um incremento viável de novos produtos. O PM / PO verifica formalmente os critérios de desempenho da tarefa e a conformidade com o Departamento de Defesa. As partes interessadas decidem se o novo incremento do produto corresponde aos Objetivos da Sprint.
Na ausência : a ausência de uma demonstração formal e aceitação do trabalho realizado reduz o valor dos critérios de aceitação, a qualidade do trabalho realizado.
Saída : o trabalho da equipe está concluído. As partes interessadas decidem se o próximo sprint será de todo.

A demonstração pelo desenvolvedor da tarefa concluída é mais útil e compreensível do que o fornecimento impessoal de novas funcionalidades a uma parte interessada para auto-análise. E a parte interessada vê quem fez o trabalho para ele e os desenvolvedores veem para quem eles estão resolvendo o problema.

Recolha de críticas - continuação Revisão da manifestação.
Significado : a presença em um local de todas as partes interessadas, a equipe e o próprio produto permite a comunicação informal, a coleta de idéias, sugestões, etc. Obtenha feedback sobre a qualidade da equipe.
Na ausência : o tempo formal alocado reduz contatos desnecessários entre a equipe e as partes interessadas durante outras horas de trabalho.
Saída : novos dados, feedback.

O feedback geralmente é útil, até o feedback das partes interessadas sobre sua experiência com os desenvolvedores. Razão para modificar os processos de interação com atores externos. A melhoria das relações com as partes interessadas atuais e futuras sempre pode ser explorada - pedidos, orçamento, concessões etc.

Retrospectiva da Sprint N - Um rally para a equipe de desenvolvimento e PM / PO.
Significado : discussão dos processos e problemas da equipe durante o último sprint, uma tentativa de mudar os processos de trabalho para melhorar a equipe. Quais processos foram bem-sucedidos, que não trouxeram benefícios ou danificaram, que novos problemas surgiram e como eles podem ser corrigidos.
Saída : o plano da experiência do processo. Os processos são modificados no próximo sprint para avaliar quais modificações são úteis e quais devem ser descartadas.
Na ausência : plantar os processos de desenvolvimento da equipe a partir de cima ou a falta deles reduz a usabilidade, a produtividade e a previsibilidade do desenvolvimento.

Além da discussão banal dos problemas e como eles devem ser resolvidos, quero prestar atenção ao "Plano do experimento do processo". Não trate os processos registrados como esculpidos em pedra - imutáveis ​​e constantes. Adicione novo - teste, não gostou - interrompa.

Fim do Sprint N


Sprint N + 1 . Despeje um novo incremento na produção
Significado : devido à conclusão frequente do sprint no final da semana de trabalho, a implantação no servidor de produção e o acesso aos usuários já ocorrem no próximo sprint, para que problemas potenciais não ocorram no fim de semana.

O incremento foi para monitorar os parâmetros.

Source: https://habr.com/ru/post/pt465189/


All Articles