Como fizemos SCRUM

Um sonho terrível de uma equipe de desenvolvimento é quando você precisa "mergulhar" em uma área desconhecida e "estimar" uma ideia incompleta antes de iniciar o desenvolvimento. Nesse caso, você precisa literalmente " assinar sangue " para o resultado no tempo determinado por uma quantia fixa de dinheiro.

De fato, dar uma avaliação precisa de requisitos imprecisos não é realista. Uma maneira típica no gerenciamento de projetos é elaborar um TOR detalhado antes de iniciar o desenvolvimento. E, em seguida, implemente toda a funcionalidade em uma única peça. Mas essa abordagem em " cascata " ameaça outros riscos: iniciar um projeto no estilo de um " big bang " - quando você obtém o primeiro resultado no final do projeto. E pode estar muito longe dos objetivos reais de negócios e das necessidades dos usuários.

Por que correr esse risco se você pode seguir um caminho completamente diferente?

Porquê SCRUM

Ao nos familiarizarmos com o projeto, existe um entendimento de que "sabemos que não sabemos disso" e até "não sabemos onde os limites do que não sabemos" ajudam o SCRUM



As especificidades do SCRUM podem assustar, se você nunca trabalhou com essa estrutura, pelo fato de que, no início, o comprimento do caminho que você deve percorrer para obter um projeto de trabalho e 100% de satisfação ainda não é conhecido.

É difícil para o cliente - ele NÃO pode preparar um plano estratégico para o desenvolvimento do projeto com datas de lançamento confiáveis. O desconhecido é assustador, especialmente quando você precisa pagar dessa maneira agora.

Mas há vantagens : o cliente no início não deve descrever em detalhes e escrupulosamente todas as funções e recursos de um enorme sistema futuro. E também pode alterar as prioridades a qualquer momento e se ajustar a um mercado externo competitivo.

A propósito, esse também foi o caso , mas em breve você verá como tiramos proveito de uma situação difícil, quando, juntamente com o cliente, descobrimos o que e como implementar já ao longo do caminho.

O SCRUM conta com o conceito de pequenas etapas: lançar versões do software em execução regularmente, sempre que possível e mais cedo. Cada iteração é um micro-estágio de desenvolvimento, imediatamente verificado pela prática.

Isso significa que, após a primeira iteração, o cliente recebe funcionalidades bastante úteis, embora pequenas, mas funcionais, que verificam na prática e dão feedback imediatamente.



Veja como organizamos todo o trabalho: importantes decisões importantes - qual é o próximo valor a ser dado aos negócios - que a equipe toma antes de cada nova iteração; como resultado, o sistema se desenvolve ao longo de um caminho crítico ideal até se tornar o mais apropriado para os negócios. O cliente aqui faz parte da equipe. Tanto o contratado como o cliente são responsáveis ​​pelo sucesso do desenvolvimento. Eles estão de um lado das barricadas.

Esse foi o caso conosco, vamos ver?

Queremos falar sobre nossa maneira de adaptar a estrutura clássica do SCRUM ao trabalhar em um sistema de controle automatizado para a “Academia A + da Educação Moderna” - este é um moderno centro educacional em Kiev, que inclui uma escola, um jardim de infância, um centro de desenvolvimento precoce, música, dança e esportes escolas, estúdios de arte e um centro para o estudo de línguas estrangeiras. No total, mais de mil crianças frequentam quase 150 cursos diferentes na Academia.

O SCRUM é uma estrutura que ajuda a resolver tarefas que mudam durante o processo de trabalho, para entregar produtos de forma eficiente e criativa aos clientes com o maior valor possível

A vantagem do SCRUM e, para alguns, a desvantagem é que é uma estrutura muito leve. Ele não contém respostas para todas as perguntas e instruções detalhadas para os membros da equipe. Scrum - "intencionalmente incompleto", e devido a esse universal.

O SCRUM precisa ser adaptado a cada projeto específico

Como os clientes e prestadores de serviços começam a trabalhar no SCRUM?

Para trabalhar em um paradigma desconhecido, às vezes o cliente precisa mudar o pensamento habitual. Estar no mesmo contexto com o artista. Portanto, antes de desenvolver o sistema para a Academia, organizamos um treinamento conjunto com os caras do Scrum Ukraine . Seus principais objetivos são: conhecer-se, entender a terminologia, elaborar todas as técnicas em forma de jogo, simular as principais atividades, entender por onde começar, distribuir papéis e registrar responsabilidades.









Durante um treinamento conjunto de três dias, nós, usando a chamada visão de helicóptero , formamos o futuro sistema com grandes movimentos e o fixamos em uma linha temporária na forma de Projeto RoadMap.

visão de helicóptero - uma descrição geral ou opinião de uma situação, em vez de uma descrição detalhada


RoadMap de produto global

Quais são as nossas conclusões após esta etapa?

1. O treinamento conjunto ajuda a mudar o pensamento do cliente e da equipe.
2. O RoadMap do produto permite visualizar um plano de desenvolvimento de alto nível e planejar aproximadamente lançamentos. É importante entender que este é um "roteiro ao vivo" que mudará conforme a descoberta de novos detalhes de desenvolvimento
3. O acordo sobre as regras globais do jogo é necessário "on the shore": o proprietário do produto após cada sprint recebe valor - um sistema de trabalho que deve ser usado imediatamente e, em seguida, fornece feedback.

O terceiro parágrafo é obrigatório, sem ele nada funcionará. Uma vez que as esperanças de lançar depois de prontidão abstrata abstrata na final levam a decepções, dos dois lados:

• Por parte do cliente: "É isso que solicitamos, mas não é disso que precisamos".
• Por parte do artista: “Nós claramente fizemos o que você pediu. E agora seus requisitos parecem completamente diferentes para nós. Concordamos em refazer tudo, mas às suas custas. Em geral, há tantas mudanças que a conclusão levará mais seis meses. ”

Dono do produto - o proprietário do produto é responsável por atingir o valor máximo do produto como resultado do trabalho realizado pela equipe de desenvolvimento. A única pessoa responsável pelo desenvolvimento do produto

Todos os nossos arranjos em uma pequena lista.

Etapa 1: Análise de Negócios e Adaptação de Metodologia

Começamos o desenvolvimento de qualquer projeto com uma análise de negócios: você precisa entender os detalhes. Sempre existem muitos processos em qualquer empresa, e nossa tarefa no estudo é descobrir como os participantes do sistema interagem entre si antes de criar o sistema.

Após uma rodada de entrevistas problemáticas e o processamento das informações recebidas, recebemos uma descrição da área de assunto na forma de exemplos de uso.



Embora o SCRUM não exija uma especificação de desenvolvimento, o fato de termos uma descrição da área de assunto pronta foi uma grande vantagem. Este documento formou a base do backlog do produto - a base para o lançamento do SCRUM. Lista de pendências do produto - uma lista de requisitos, histórias, funcionalidades, ordenadas por importância. Com esta lista, tudo começa. Além disso, todos os requisitos são descritos em um idioma compreensível para o cliente. Os elementos desta lista são a história do usuário , "histórias do usuário".

A história do usuário é uma descrição dos cenários mais simples para o usuário usar o sistema, cuja essência pode ser formulada da seguinte maneira: “quem, o que, para quê, quais são os recursos e as limitações”.









Nossa lista de pendências de 203 histórias, convenientemente agrupadas por segmento


Exemplo de história do usuário

Quais são as nossas conclusões após esta etapa?

1. Nossos sprints duram 2 semanas. Porque Sprints curtos são confortáveis. Eles permitem que a equipe seja o mais "flexível" possível: pronta para ajustar seus planos com frequência. Um sprint curto significa um curto ciclo de feedback, levando a lançamentos frequentes. Liberações frequentes = análises rápidas dos clientes = menos tempo para trabalhar na direção errada = treinamento rápido, aprimoramento etc.
2. Sprints longos têm suas vantagens - menos custos indiretos, como planejamento, demonstrações, etc. Mas escolhemos os curtos para serem flexíveis e correr menos riscos.

Sprint - o período durante o qual o "Pronto" é criado, ou seja, um produto adequado para uso e liberação

Etapa 2: planejamento de sprint. Como adaptamos o planejamento da Sprint

Nosso primeiro valor comercial foi uma revista eletrônica. Para os desenvolvedores mais experientes, isso parecerá utópico: temos uma planilha em branco, não há um único diretório, interface do usuário, sistema de autorização ou uma única entidade comercial, e estamos comprometidos em fornecer uma das funções mais complexas do sistema.



Como foi isso? Para nós, era necessário obter duas coisas: o objetivo declarado do sprint e o backlog aprovado do sprint.

Nosso proprietário do produto sempre começou o planejamento de sprint com uma descrição do que precisa ser feito primeiro, as histórias mais significativas. Depois disso, a equipe avaliou os custos de mão-de-obra para todas as histórias de usuários, começando pela mais importante. No processo, a equipe teve muitas perguntas sobre como isso deveria funcionar.

O planejamento da sprint é uma atividade muito importante do SCRUM. Todos estão cientes da responsabilidade de uma avaliação correta, porque:

• isso permite que a empresa entenda qual funcionalidade pode esperar no final do sprint. Vamos ser uma equipe previsível e estar "na mesma página" com o cliente
• o valor de uma meia história realizada é zero; portanto, todas as histórias planejadas no âmbito de um sprint precisam ser decididas.
• qualquer alteração na pontuação durante o sprint é ignorada;

O objetivo do sprint é o objetivo do sprint . Mais importante, o objetivo deve ser indicado em termos de negócios, e não técnico. Ou seja, em um idioma compreensível até para pessoas de fora da equipe, e o backlog da Sprint é uma seleção de histórias do backlog do produto . É uma lista de histórias que a equipe identificou como as mais importantes nesta fase e se comprometeu a concluir durante o sprint.


Exemplo de lista de pendências do Sprint

Revista eletrônica após o primeiro sprint

Simplificações e suposições para o primeiro sprint . No sistema - 2 usuários: professor e pai; uma classe - 5 "A"; a composição real da classe, inserida manualmente diretamente por meio de consultas SQL; a programação atual para 5 "A", também formada diretamente através da entrada na tabela.

História do usuário nº 1 : o professor efetua login no sistema e dá classificações para qualquer disciplina do horário das aulas do dia. Um sistema com uma função simples, mas já funcionando. Já na demonstração do sprint, o professor disse o que usar de forma conveniente e o que não, para que, nos próximos sprints, a equipe possa planejar as correções e fornecer uma ferramenta atualizada.

Qual é o valor real: desempenho digitalizado da classe real, avaliações atuais, perspectiva de preparação automática de relatórios mensais, semestrais e trimestrais.

História do usuário nº 2 : um relatório semanal para os pais sobre o desempenho no correio.

Qual o valor agregado: informar os pais sobre o desempenho atual; comentários de professores sobre trabalhos de casa; análise mínima, mas real.

Após várias corridas, decidi que havia funcionalidade suficiente para os professores trabalharem com um diário eletrônico. Portanto, pausamos o desenvolvimento dessa ferramenta e mudamos o foco para o designer de cronograma. Isso é normal para o SCRUM. Voltei à revista eletrônica o foco do desenvolvimento após uma dúzia de sprints e, tendo descartado parcialmente a funcionalidade simplificada, levamos a revista eletrônica ao estado necessário para a análise do desempenho anual. Precisávamos dessa funcionalidade naquele momento. Ganhamos valor suficiente e mudamos o desenvolvimento ativo para partes de maior prioridade do sistema.

Svyatoslav, Proprietário do produto

Para referência : para corrigir a versão final (ideal), tivemos que retornar ao diário eletrônico para vários sprints.


É assim que a revista era após o primeiro sprint, mas já era possível trabalhar com ele.


Esta versão da revista eletrônica foi recebida após 12 sprints e pôde ser exibida aos pais.

Outro exemplo vívido de uma abordagem iterativa do SCRUM é o construtor de cronogramas.

O cliente recebeu o primeiro designer de cronograma 2 meses após o início do projeto. Foi um "editor brutal" para um usuário muito avançado. Mas ele nos permitiu apresentar uma programação para todas as quinta séries e testar o sistema em uma programação ao vivo real.

Foram necessários três sprints para refiná-lo ao "editor visual". O foco do desenvolvimento foi alterado várias vezes, mas no início do ano letivo, o cliente recebeu um designer de cronograma totalmente funcional, com a ajuda do qual ele introduziu o cronograma do primeiro (A, B, C, D) ao oitavo ano em apenas uma hora.

Vamos seguir a rota "editor brutal para um administrador real" - "editor visual" - "designer de programação"

E como você fez a programação antes?

A programação foi elaborada em folhas coladas de papel Whatman A1 manualmente: pintadas, realçadas com marcadores coloridos, coladas. O diretor levou semanas e meses para fazer isso.


A primeira versão do editor: "Editor brutal para o administrador" - que fez o cronograma para 2018


A segunda versão melhorada, com a ajuda da qual o cronograma 2018/2019 foi feito


Criador de cronogramas - versão final

Quais são as nossas conclusões após esta etapa?

1. Cada sprint deve ter uma meta claramente definida.
2. Simplificar a funcionalidade e desenvolvê-la é normal. Por que o SCRUM é tão bom: não há um caminho certo no desenvolvimento de produtos. Este não é um tutorial com atribuições e respostas corretas no final. Você sempre pode considerar muitas opções alternativas e executá-las em diferentes seqüências. Se, no final do sprint, o cliente receber um valor completo com o qual ele pode trabalhar, testar, inserir novos dados e isso avançar para a tarefa final global, esse é o caminho certo.
3. A principal filosofia do SCRUM: não perseguir um código bonito no início, mas concentrar-se em fornecer ao cliente uma ferramenta de trabalho. Portanto, você pode tolerar erros no decorrer do trabalho, mas precisa entender: a melhor maneira de identificar esses erros é parar de pensar no código ideal no nível da arquitetura e do design e, primeiro, dar à empresa um protótipo funcional.
4. É importante durante a discussão fazer alterações na história do usuário e salvar e anexar todos os artefatos aos cartões.

Como fazer uma equipe avaliar a história do usuário de forma realista

A equipe sempre avaliará adequadamente a história do usuário se as condições forem atendidas: o comportamento do usuário real é descrito em detalhes, os limites de uso e as premissas são indicados, os critérios de aceitação são listados. Ou seja, a equipe entende o "o que" precisa ser feito e sugere aproximadamente o "como".

Por que é importante formular “critérios de aceitação” e “limites de uso” - isso fornece o mesmo entendimento do escopo do trabalho de histórias do proprietário do produto e da equipe.

Escala de classificação ou SCRUM-poker

No SCRUM, a avaliação da história ocorre não em horas ou dias, mas em pontos da história. Essa é uma mistura de complexidade, risco e esforço que uma equipe deve gastar para concluir uma história. Para cada equipe, 1 ponto de história é um valor empírico individual, mas cada membro da equipe sente isso.

Observe que a sequência de valores nos cartões não é linear. Por exemplo, não há nada entre 13 e 21. Porque



Em primeiro lugar, isso é necessário para evitar a aparência de um falso senso de precisão para grandes classificações. Se a história é estimada em cerca de 17 pontos, não faz sentido discutir se deve ser 15, 18 ou 21. Tudo o que precisamos saber é história, é difícil avaliar. Portanto, atribuímos a ela uma classificação de 21. Aproximadamente.

Em segundo lugar, as pessoas tendem a exagerar suas capacidades, e a escala não permite que muita coisa esteja errada na avaliação de tempo e recursos. Por exemplo, a equipe concordou que 6 pontos da história são suficientes para uma das tarefas. Mas se você não tiver certeza de que 5 é suficiente, é melhor escolher 8. Isso permite definir termos reais nos quais a equipe se encaixará exatamente. Além disso, ajuda a iniciar um diálogo entre os participantes, compartilhar sua visão da implementação da história , expor os riscos e chegar a um consenso.

Muito importante : cada membro da equipe deve fazer uma avaliação. Porque

• Para uma avaliação fundamentada, cada participante deve entender perfeitamente qual é a essência dessa história. Ao receber uma avaliação de cada membro da equipe, garantimos que todos saibam o que está em jogo. Isso aumenta a probabilidade de assistência mútua durante o sprint. E o mais importante: as perguntas mais importantes dessa história surgirão o mais cedo possível.
• Uma visão abrangente do problema leva a uma ampla variedade de avaliações. Tais desacordos são melhor identificados e discutidos o mais cedo possível. Após discussão de desacordos - reavaliação, votação. Geralmente, alguns ciclos de avaliação são suficientes para esclarecer os pontos principais e criar um entendimento comum.

Mostramos isso pelo exemplo de uma grande variação na estimativa de uma das histórias. A história se chamava Buzz .

Importante : durante o planejamento, geralmente não sabemos quem fará essa ou aquela parte. A implementação da história do usuário requer a participação de especialistas para diferentes tipos de trabalho: arquitetura, front-end, back-end, testes, preparação de dados reais. Separadamente, existe um grupo de trabalhos como design e design de interface do usuário.

Caso brilhante: Buzz

No sistema de gestão escolar, muitos eventos de diferentes graus de significância surgem. Por exemplo, um aluno recebeu uma nota; ocorreu uma substituição e, em vez de matemática, haverá biologia com outro professor; Um incidente irritante ocorreu com o aluno e os pais devem ser informados imediatamente; O professor escreveu um comentário importante sobre a DZ.

É inconveniente que os usuários enviem esses dados por métodos padrão para mensageiros instantâneos ou por correio e até ontem. Além disso, as mensagens podem se relacionar com várias pessoas ao mesmo tempo: o professor precisa enviar aos pais que o aluno deixou a escola durante a aula. No documento original, essas regras são coletadas em 10 páginas


Buzz na implementação final

Caso brilhante: Buzz

Estamos discutindo entre os desenvolvedores o quanto estimamos a quantidade de trabalho na história do Buzz.



Todo mundo fala quantos pontos da história são necessários. Descobrimos que temos grandes diferenças de opinião e chamamos a atenção para opiniões extremas: por que alguém classificou 50 e seu colega confia em cinco pontos da história. Então, imediatamente descobrimos requisitos não detectados que foram notados por um desenvolvedor mais cauteloso. Além disso, tarefas globais relacionadas à personalização foram reveladas. Este é um ótimo exemplo de como uma equipe pode antecipar dificuldades.

Que conclusões tiramos em relação à metodologia de avaliação

1. Sim, é normal que o designer de QA e UX faça uma avaliação do histórico técnico.
2. story points, «» . , , story points.
3. 2-3 , — 1 story point

story point — , , .

№3: . sprint execution SCRUM

A reunião diária do SCRUM, ou stand-up, e todo o SCRUM é uma história sobre comunicações eficazes que ajudam a economizar tempo e esforço da equipe. Estas não são apenas "reuniões" e "conversas". Eles não gastam tempo que poderia ser gasto no trabalho, mas ajudam a otimizar os esforços. Um dos princípios do SCRUM é: "Pessoas e interação são mais importantes que processos e ferramentas".



Cada membro da equipe relata brevemente, de acordo com uma lista de verificação especialmente projetada, o que ele fez, quais problemas encontrou, o que fará em seguida. Uma pessoa não é deixada sozinha com um problema, ela é rapidamente ajudada a resolvê-lo da maneira mais eficaz. Portanto, um engenheiro não gasta tempo com tentativas malsucedidas, após as quais você pode ter que refazê-lo do zero, economizando os recursos de toda a equipe.

Funcionalidade cruzada: a equipe está pronta para executar qualquer tarefa de lançamento do produto.Na

formação da equipe, selecionamos especialistas em T que são versados ​​em muitas áreas e pelo menos um é especialista. Graças a essa versatilidade, todos os engenheiros conhecem o sistema muito bem.

A experiência de todos é valiosa para encontrar a solução mais eficaz.

Em uma equipe, uma pessoa pode não ter a experiência necessária para uma tarefa específica, mas com uma alta probabilidade de ter seus colegas. O mesmo por parte do cliente: uma pessoa pode não conhecer alguns detalhes, mas outra pessoa os conhece.

, : , , sprint backlog , , , , . , , , , . .

, Scrum Master

sprint running

1. , , , .
2. É necessário mudar a ênfase e entender que um SCRUM diário é necessário para a comunicação e não para a administração.
3. Cada sprint subsequente deve levar em conta a experiência dos anteriores.

Como conduzir uma reunião diária do SCRUM

Etapa número 4: como realizamos uma demonstração dos resultados. Nossa adaptação da sprint demo

Os desenvolvedores se revezam demonstrando novas funcionalidades ao vivo com dados reais. O foco está no que fizemos e não em como fizemos. Em geral, nos esforçamos constantemente para tornar nossa demonstração orientada para os negócios, sem mencionar os detalhes técnicos.

Como descobrir se uma solução atende ao cliente

Aqui, novamente, o objetivo do sprint vem à tona . Nossas demonstrações eram frequentemente assistidas por professores especialmente convidados e diretores que não estavam planejando. Eles sabiam sobre o produto apenas em termos gerais. Sempre recebemos com satisfação que, após cada história demonstrada, os próprios clientes tentavam fazer algo no sistema. Em seguida, o usuário final verifica cada item do critério de aceitação. Ele diz o que combina e o que não combina, que aspectos podem ser aprimorados. E assim - para cada história de usuário que foi planejada para este sprint.





Que conclusões tiramos da metodologia para demonstrar os resultados

1. Composição obrigatória para a demonstração: proprietário do produto, scrum master, representantes de clientes e usuários finais que trabalharão com a ferramenta, equipe.
2. , .
3. , . -.
4. , . .
5. . , ,

—

№5: retrospective

Para nós, a retrospectiva é um evento importante logo após a demonstração do sprint. Retrospectivas são úteis, especialmente quando algo dá errado. Sem retrospectivas, pode acontecer que a equipe pise no mesmo rake repetidamente.



Como garantir a repetição de erros

O rake mais comum é quando o desempenho real da equipe é muito diferente do previsto. O desempenho real é calculado com base em uma avaliação inicial de cada história. E quando, no meio do sprint, percebemos que a história, estimada em 5 pontos, é feita tanto quanto a tarefa geralmente leva 13 pontos da história e está longe de ser concluída, e se também é uma história bloqueadora, outras não podem ser iniciadas porque insegurança problemática. Quando as metas de sprint estão em jogo - a retrospectiva é inevitável.

Nossas retrospectivas têm uma estrutura e objetivos absolutamente claros: a equipe se reúne. O Scrum Master lê o backlog do sprint, pede a cada membro da equipe que fale e avalie os resultados do sprint do seu ponto de vista. Cada membro da equipe expressa sua opinião de que era possível fazer bem, o que deu errado e - o mais importante - por quê. O que continuar a fazer e o que recusar. No entanto, ninguém o interrompe. Ele coloca suas conclusões registradas no adesivo em uma das colunas:

• ok
• poderia ser melhor
• precisa consertar

Um exemplo de nossas melhorias com base em uma retrospectiva

• Quando um desenvolvedor faz um front-end e começamos a implementá-lo, é necessário que os designers estejam 100% acessíveis.
• Discuta com o PO a inclusão de horas metodológicas.
• Em ergonomia, é importante obter o máximo de documentação.
• A dívida técnica não deve ser acumulada: alinhe 10% para as histórias técnicas com a OP.
• Deve haver um especialista que resolverá problemas técnicos à medida que surgirem.
• Antes de cada planejamento do sprint, é imprescindível realizar a preparação do sprint.

“Depois que a equipe fizer um brainstorming sobre todos os adesivos problemáticos, realizarei uma“ votação no local ”: cada membro da equipe terá três votos (três pontos marcadores nos adesivos). Ele pode dar todos os seus votos de uma só vez para um problema ou pode distribuir de maneira diferente. Com base nesta votação da equipe, selecionamos 2-3 aprimoramentos nos quais focamos no próximo sprint. E no início da próxima retrospectiva, verificaremos o que aconteceu. Por assim dizer, "verificando a lição de casa" :) "

Pavel Kamyshov , treinador ágil

Sim, o SCRUM requer a inclusão ativa de todos os membros da equipe. Para atividades como limpeza, planejamento e SCRUM diário, levamos cerca de 12% do tempo pago - esse é um tipo de preço para transparência, previsibilidade e redução de riscos.

Uma semana de trabalho pode economizar uma hora de planejamento.

Pavel Kamyshov , treinador ágil da Scrum Ucrânia

12% é muito, mas vale a pena, pois na clássica "cascata" o preço do uso da metodologia é um papel separado para o gerente de projetos. Em média, cerca de 15% do custo de desenvolvimento são gastos na administração de nosso segmento de mercado.

Que conclusões tiramos da metodologia retrospectiva

1. Para nós, a retrospectiva é o segundo evento mais importante no SCRUM após o planejamento do sprint.
2. Cada membro da equipe se manifesta para que todos estejam no mesmo campo de informações.
3. Cada mudança tem um preço. Você deve concordar com a PO para incluir histórias técnicas e horas metodológicas no backlog do sprint.
4. As horas metodológicas são pagas pelo cliente.

A retrospectiva da Sprint é uma oportunidade para uma equipe realizar uma inspeção destinada a si mesma e criar um plano para melhorar o trabalho em equipe na próxima Sprint.

Etapa número 6: como adaptamos o refinamento da lista de pendências do produto ou Grooming

Muitos colegas familiarizados com as especificidades da TI duvidam: como isso pode ser tão claro para uma equipe durante o planejamento do sprint que ela está pronta para avaliar todas as histórias de usuários.



Sim, de fato, sem a preparação de tal coerência não funcionará. Para que isso funcione dessa maneira, há uma atividade especial do SCRUM: refinamento da lista de pendências do produto. Para realizá-lo, você precisa solicitar ao proprietário do produto um horizonte de planejamento: descreva quais histórias podem ser candidatas ao próximo sprint. Se houver histórias entre elas que exijam estudo aprofundado ou competências especiais que a equipe não possui, uma reunião é chamada - preparação / pré-planejamento.


Resultados de higiene

Nosso proprietário do produto era muito competente; portanto, sempre tínhamos um horizonte de visão suficiente de como o sistema se desenvolveria e realizamos regularmente refinamentos. De fato, a transparência é um dos princípios fundamentais do SCRUM.


Parece um plano de higiene

Que conclusões tiramos sobre a metodologia de refinamento

1. Este é um evento importante que nos permite esclarecer o que não sabemos, que competências nos faltam. Assim, uma vez que foi decidido atrair um consultor desenvolvedor / desenvolvedor de terceiros em questões específicas, cuja solução não tínhamos na época.
2. Essas discussões foram muito eficazes conosco, consideramos muitas alternativas e opções, o que nos permitiu manter o problema em mente e, para o planejamento de sprints, a história mais complicada já foi “apresentada”.
3. Problemas complexos e aparentemente insolúveis encontram soluções claras. Às vezes, basta comprar uma biblioteca do que desenvolver você mesmo um site complexo.

O refinamento é a base para estar pronto para dar uma avaliação da complexidade das histórias em diferentes condições de implementação durante o planejamento do sprint, porque precisamos entender seu volume e complexidade.

Falha

Sim, estamos sinceramente encantados com o desenvolvimento da metodologia SCRUM, mas isso não significa que tudo correu bem. Aqui estão três pontos em que colocaríamos canudos se soubéssemos de antemão que seria assim.

Trabalhe em padrões familiares

Em uma das retrospectivas, analisamos detalhadamente o motivo do desvio anormal da "produtividade real" da equipe em todas as histórias envolvendo designers. O desempenho real é geralmente calculado usando a fórmula: desempenho projetado / desempenho real.

Descobrimos por hábito que eles se organizavam na familiar cascata seqüencial.

Como resultado: as tarefas foram executadas seqüencialmente, os desenvolvedores passaram um tempo ligando sequencialmente em diferentes estágios, com atrasos causados ​​pela necessidade de concluir as tarefas já iniciadas.

Conclusão: Talvez a história mais dolorosa para nós, que causou mais danos e não foi revelada imediatamente. É necessário verificar regularmente se todos os membros da equipe passaram a trabalhar de acordo com os novos padrões.

Trabalho extra em funcionalidades desnecessárias

No segundo sprint, o proprietário do produto sucumbiu à opinião de um dos diretores, que acreditava que o “diário do curador” era uma funcionalidade extremamente importante. Pegamos essa história em um sprint, gastamos o esforço nela.

Por que um erro: essa ferramenta só pôde ser testada nas etapas posteriores, pois precisava de dados acumulados, que na época não estavam lá.

Como resultado: não foi testado, não utilizado, não desenvolvido. As funções necessárias foram resolvidas de maneira diferente e não da maneira que o diretor pensava, por meio de ferramentas completamente diferentes. Conclusão: leve ao trabalho apenas o que você começará a usar imediatamente.

Igual a usuários avançados

Em um estágio, levamos a história com o “editor de substituição” para o desenvolvimento, no desenvolvimento do qual um professor, um usuário de computador muito experiente, participou. Como resultado, obtivemos uma ótima ferramenta, mas não poderia ser usada por professores comuns que não eram tão avançados.

Conclusão: confirme a história em clientes regulares.

Conclusões gerais

Conclusão número 1

Pro flexibilidade: SCRUM permite que você seja uma equipe eficaz

Os resultados de cada sprint dependem das tarefas introdutórias, eficiência, coordenação, responsabilidade da equipe e feedback de qualidade.

A entrada é fornecida pelo proprietário do produto. Ele também é responsável pelo contexto em que a funcionalidade será usada, a qualidade da formulação dos requisitos, fornece uma profundidade de detalhes suficiente.

O SCRUM exige que a equipe conclua uma peça de trabalho completamente tangível, que permita obter valor, ou seja, uma ferramenta que pode ser fornecida ao usuário no final de cada iteração. Isso ajuda a ver a solução em funcionamento e nos estágios iniciais para entender o que precisa ser alterado para seguir em frente.

Conclusão número 2

Sobre o uso mais eficiente dos recursos

SCRUM - uma forma de organização do trabalho que é benéfica para o cliente e o contratado. O que?
Trabalhar com iterações já nos estágios iniciais permite entender o que está acontecendo de errado, o que significa que você precisa fazer ajustes no tempo. A preparação para cada sprint e as especificidades de sua organização ajudam a cada vez fazer apenas o que o cliente precisa e não se afastar. E fornece enorme EFICIÊNCIA dos recursos gastos, tempo e esforços.
Nos estágios iniciais, o cliente recebe uma seção de trabalho do sistema: após os primeiros sprints, ele pega a funcionalidade que executou e a testa na prática.

SCRUM - quando ambas as partes estão seguradas contra riscos

Veja como a responsabilidade é compartilhada entre o cliente e o contratado
A barricada desaparece, nos dois lados em que o contratante e o cliente estão no gerenciamento clássico de projetos. Em princípio, as posições do cliente e do contratante desaparecem, a equipe permanece. E não há condições para um possível confronto.

CLIENTE

O cliente paga apenas se todas as metas do sprint foram atingidas. Se não for desenvolvida uma ferramenta que o cliente possa executar na prática amanhã, o sprint não conta.

O cliente paga uma quantia fixa por cada sprint e torna seus negócios um passo mais eficientes

Artista

O contratado está interessado em preparar uma nova ferramenta, um novo valor para o cliente durante cada sprint, porque isso dará uma nova rodada de feedback e informações / experiências. Que pode ser usado para desenvolvimento adicional de produtos.

Cada sprint aumenta o nível de competência do performer, acelera-o na implementação do projeto.

No total, em apenas 7 meses, fizemos um sistema que funcionou e foi completamente satisfatório para o cliente, testado por ele na prática e refletindo todos os desejos, e não emitimos um sistema teoricamente projetado de acordo com as especificações técnicas, que precisaria ser concluído mais alguns meses, pois a prática inevitavelmente faria suas próprias correções.

Globalmente, este caso trata de uma técnica de gerenciamento de projeto selecionada corretamente, sob condições de alto grau de incerteza e tempo limitado antes do lançamento.

Com um cliente tão exigente, com altos padrões de qualidade, às vezes era muito difícil para nós, mas ao mesmo tempo muito interessante. Os desafios que superamos, os erros cometidos, no entanto, com o tempo, conscientes e corrigidos, as conclusões feitas, mudaram para sempre a cultura em nossa equipe

Provavelmente, durante muito tempo, todo mundo ficou interessado em saber sobre o produto em si, que acabou.

O cliente recebeu um excelente produto: um conjunto de ferramentas para uma escola moderna que pode transformá-lo rapidamente em uma escola do futuro