Como Transição da cachoeira para Scrum

1. Introdução: Olá, bem-vindo a este curso sobre como fazer a transição da cachoeira para o Scrum. Meu nome é faz a origem. Que 25 anos de experiência em desenvolvimento de produtos de software e gerenciamento de projetos. Se você já conhece o básico do Scrum, esta aula ensinará um processo passo a passo sobre como fazer a transição bem-sucedida do scrum em cascata. Cada transição tem seus próprios desafios. Da mesma forma, a transição para o scrum também tem seus próprios desafios. No final desta aula, você terá um bom entendimento tanto do processo de transição quanto dos desafios que o ajudarão a desempenhar um papel efetivo na equipe do Scrum. Obrigado por assistir a este vídeo, e estou ansioso para vê-lo em breve. 2. Como fazer transição de aquarela para a Scrum: Se a sua organização acompanha o modelo tradicional em cascata há acompanha o modelo tradicional em cascata algum tempo, mudar da cachoeira para o Scrum não é uma tarefa fácil. Essa transição, porque você está drasticamente mudando mentalidade e leva seu tempo juramentado, esforço e dinheiro. Neste vídeo, vou apresentar sim. Processo de dez etapas que você pode seguir para fazer a transição bem-sucedida da água para essas contagens. Etapa número um, entenda a natureza dos produtos. Compreender os produtos naturais e o desenvolvimento e fazer uma avaliação realista desse agora é uma das principais etapas determinar se a escória será ou não a escolha certa para o seu organização. O projeto é considerado bem-sucedido se os requisitos fornecidos forem concluídos para a satisfação do cliente no prazo e dentro do orçamento. Como você deve saber, cada produto é gerenciado mantendo três restrições em mente, ou seja, escopo, tempo e custo. Essas são chamadas de restrições triplas no gerenciamento de projetos. Você precisa que as alterações feitas em qualquer uma dessas restrições tenham impacto em outras restrições. Dê-me uma abordagem tradicional. O escopo geralmente é corrigido com o trade-off entre variáveis de custo e cronograma. Mas no Scrum, o cronograma e custo do escopo fixo se tornam a variável à medida que o escopo é retribuir nosso gosto com cada sprint ou lançamento. Portanto, a fraude é mais adequada para entregar regularmente com escopo variável. duração do projeto é curta. Nossos requisitos são simples e fixos, então a escória pode não trazer muitos benefícios para essa equipe. Por outro lado, se os requisitos do produto forem complexos, improvável que mudem durante o custo de desenvolvimento, duração do produto for longa e lançamentos frequentes são necessários, então o a implementação eficaz do Scrum oferecerá muitos benefícios a essa equipe. Etapa número dois, maior ou consulte o treinador scrum. Depois de identificar a massa Scrum, a estrutura ITIL para o desenvolvimento do seu produto, o próximo passo é contratar ou consultar, sim, scum coach. Com a ajuda do scrum coach, você pode criar uma proposta para sua equipe de gerenciamento. Essa proposta deve abranger problemas existentes, resposta a falhas de produtos e como o Scrum pode ajudar as PMs do projeto a concluírem o projeto com sucesso. Essa proposta também deve falar sobre novos processos de desenvolvimento, métodos, ferramentas, mudanças organizacionais, recursos, escalas, funções, responsabilidades e requisitos de treinamento que são necessário para implementar com sucesso o Scrum. treinadores Scrum ajudam equipes e empresas a se transformarem do trabalho focado em produtos, também, do trabalho focado no produto. As equipes de ajuda e as empresas criar um backlog de produtos que impulsiona o trabalho em vez de criar um plano de projeto maior. Os treinadores de varredura trabalharam com o proprietário do produto, passaram a dominar e ajudá-los a criar backlog de sprint, auxiliar as equipes a realizar eventos de sprint de forma eficaz, compartilhar algumas práticas recomendadas na medida de desempenho e o propósito das equipes. Os treinadores do Scrum são responsáveis por orientar as equipes durante o processo de implementação e fornecer todo o suporte necessário às equipes do Scrum. Etapa número três, busque o compromisso da gerência. Quando estiver pronto com sua proposta, equipe de gerenciamento de boas-vindas através da proposta destacando todos os benefícios e desafios. Buscar a caneta de confirmação do seu gerenciamento é extremamente importante porque a implementação do scrum exige uma mentalidade completamente diferente. Porque muito tempo, esforço e dinheiro da organização. Implementando o Scrum em uma organização que é nova desenvolvimento de produtos e não tem nenhuma experiência prévia. É mais fácil do que fazer o mesmo em uma organização onde as pessoas estão bastante acostumadas a desenvolver produtos em um modelo tradicional , como cachoeira. Educar nossa equipe de gerenciamento conforme necessário e aborde seus consentimentos. Obter esse compromisso, suporte e aprovação é muito importante. Você não poderá colher os benefícios do Scrum sem envolver a gerência e a equipe. Etapa número quatro, identifique um produto-piloto e aloque recursos. implementação do scrum de forma faseada é altamente recomendada. A primeira fase seria a fase piloto, onde você pode identificar um produto ou um módulo dentro de um produto que pode ser desenvolvido, testado e entregue de forma independente. Se o produto, nosso módulo já estiver em cronograma apertado ou restrições de custo, talvez não seja um bom candidato. Em vez disso, escolha o produto, mantendo o código de aprendizado em mente. A duração do projeto não deve ser muito curta ou muito longa. Pode levar pelo menos quatro a seis semanas para avaliar como a pele funciona. Escolha indivíduos que já saibam que o Scrum é, pode ser treinado de acordo com seus princípios antes de implementar seu projeto. A equipe do Scrum precisa de um indivíduo de cada departamento ou áreas especializadas para que eles tenham todos os registros, conhecimento de casos, suporte e capacidade de tomada de decisão. Embora sua equipe scrum possa ter de três a nove desenvolvedores. Ter uma equipe pequena para começar seria ótimo. A equipe de phi seria uma venda ideal. Certifique-se de que todos esses recursos sejam totalmente dedicados a este produto e eles não estão trabalhando em nenhum outro projeto. Construindo a fase piloto, a equipe pode ramificar ideias de produtos fortes, planejar como implementar seu projeto-piloto e identificar os requisitos de treinamento necessários. Quanto mais eles trabalharem juntos, mais fácil será o projeto. Etapa número cinco, treine todos os recursos no Scrum. Um extenso treinamento de scram é extremamente importante para todos os membros da equipe Scrum, como proprietário do produto, scrum master , desenvolvedores e outras partes interessadas que fazem parte da Equipe Scrum. Este treinamento deve ser conduzido pelo treinador Es kommt, que tem experiência prática na implementação de escória a partir do zero. Muitas organizações pensam que já estão usando o Scrum, mas estão praticamente fazendo o que estavam fazendo antes do scrum. Continuando a usar o modelo tradicional onde os membros são solicitados a trabalhar em vários projetos com prioridades e prazos conflitantes. Basta adicionar sua reunião diária de stand-up e usar termos como sprints só pode Watson o processo existente. Em muitas organizações, gerentes de produtos que estão acostumados a gerenciar produtos em sua baía tradicional ou esperam desempenhar o papel de Scrum master com algum conhecimento superficial sobre Scrum, tem sido observou que Scrum Masters e gerentes de projeto desempenham papéis diferentes. Etapa número seis, use ferramentas de automação como um dos objetivos do Scrum é melhorar a produtividade. É altamente recomendável que você use ferramentas de automação o máximo possível. Por exemplo, para gerenciar o alicerce e acompanhar o progresso de todas as histórias de usuários, você decidiu recomendar que use seu software comercial em vez usar e distribuir muitas planilhas. Da mesma forma, é altamente recomendável usar ferramentas para projetar codificação, versão, controlar, verificar a qualidade do código, testar e liberar. uso de todas essas ferramentas melhora a produtividade da equipe de água reduzindo o retrabalho e melhorando a qualidade. Certifique-se de que o membro da equipe e outras partes interessadas sejam treinados conforme necessário em todas essas ferramentas e processos estabelecidos dentro da organização. O primeiro e mais importante escrito para automação nos testes Scrum é o curto ciclo de desenvolvimento. As equipes Scrum têm apenas algumas semanas para fazer testes frios e integrar recursos recém-adicionados. Se todos testarem o que manualmente, levará mais tempo do que o tempo real de desenvolvimento. Em muitas ocasiões, algumas histórias de usuários podem não ser concluídas dentro de um determinado sprint devido à falta de tempo para testes. Por outro lado, testes inadequados levam a problemas de qualidade. Venha sempre estágios de boas-vindas ou mudanças frequentes precisam ser cuidadosamente testadas. Além disso, em uma alteração que você implementa não deve afetar a funcionalidade existente, isso é chamado de teste de regressão. Manualmente. Fazer esses testes é chato, demorado e propenso a erros humanos. Capturar outras pessoas rapidamente por meio da automação permite que os desenvolvedores verifiquem a estabilidade de um código. Problemas corrigidos, conclua histórias no prazo e cumpra a meta do Sprint. automação não deve se limitar apenas a testes. Ele também deve abranger outras atividades, como compilação, implantação e lançamento. Processos e ferramentas de automação podem reduzir significativamente o tempo de lançamento no mercado. Etapa número sete, você implementa o Scrum. Tendo obtido a aprovação da gerência, identificou um projeto-piloto, alocado recursos, identificou ferramentas e concluído todo o treinamento necessário. O próximo passo seria implementar o SCOM. Suave. No entanto, duas semanas de sprint é preferido. O que, o que ele tinha mais tempo sprint scrum equipe é esperado para seguir os princípios da agenda, viver pelos valores da escória. Participe de todas as escórias, mesmo a tempo, e desempenhe seus papéis e responsabilidades em todo o potencial para atender o bom sprint. A equipe de fraude pode criar um roteiro para o trabalho piloto. E a equipe deve sempre ficar de olho no roteiro para definir prioridades, entender as expectativas e se alinhar com os outros. No entanto, a equipe de fraude é autogerenciada, eles não podem fazer o que quiserem. Em vez disso, eles entregáveis simultâneos em cada sprint. A falta de comunicação pode afetar significativamente essas iniciativas e, em última análise, levará ao seu produto que não atenda plenamente aos requisitos das partes interessadas. Ao estabelecer uma clara ln de equipes de compartilhamento de conhecimento, você poderá acompanhar todas as mudanças e ajustes. Todos os membros da equipe, independentemente das regras, são igualmente responsáveis pela entrega bem-sucedida de histórias e tarefas concluídas. Em cada sprint, espera-se que cada membro ajude e apoie outros membros em todas as possibilidades para completar o sprint com sucesso e atingir essa meta de sprint. Comece pequeno, faça mudanças como mais doentes e defina metas e expectativas realistas. Comemore os sucessos, marcos e conquistas ao longo do caminho. Etapa número oito, avalie o desempenho periodicamente para fazer uma comparação precisa antes e depois, você precisa ter uma visão clara de como as coisas estão funcionando hoje usando algumas métricas importantes. Métricas ou medidas de avaliação quantitativa. Se os dados não estiverem disponíveis, é importante examinar alguns projetos recentes e um pouco e obter alguns dados de linha de base do ponto de partida SES. Você pode usar exatamente as mesmas métricas para comparar e avaliar a eficácia da transição. O evento Perspective é uma ótima oportunidade para todos os membros da equipe Scrum discutirem todos os pontos positivos e áreas para melhoria. Todas essas áreas identificadas e aceitas para melhoria devem ser implementadas nos Sprints e CLS subsequentes possíveis. Além disso, buscar feedback periódico de clientes e outras partes interessadas que não participam do evento retrospectivo seria útil escolher sua matriz com sabedoria. Você não quer tomar uma decisão com base em apenas uma métrica. Nem você quer coletar e medir muitas métricas. Aqui estão algumas das métricas que você pode considerar. Burndown de Sprint. O gráfico Sprint Burndown mostra quanto trabalho foi concluído até um determinado dia e quanto tempo está disponível para concluir o trabalho restante. Ao examinar este gráfico em seu negócio diário, normalmente antes do Daily Scrum, você pode verificar se a equipe está cronograma para completar a meta de sprint. Sucesso na meta da Sprint. Sprint Goal é o único objeto para o sprint. Essa meta de sprint é criada durante o planejamento de sprint e adicionada ao backlog de sprint definindo metas de sprint e, em seguida medindo quantos sprints atingiram a meta, você pode medir como os objetivos do negócio são atendidos. Os defeitos escapados são a métrica crucial que mostra quantos bugs foram experimentados pelos usos na produção para uma determinada versão. Idealmente, sim, a equipe do Scrum deve testar completamente as histórias e entregar o outro produto gratuito. Mas, na realidade, isso raramente acontece. Os defeitos escapados refletem a qualidade do produto. Velocity mostra o número médio de pontos da história que a equipe concluiu nos sprints anteriores. Também é indicado de pontos de história comunista que a equipe pode cometer no próximo sprint. Além disso, ele capta o progresso da equipe em toda a despesa. Tempo de entrada no mercado. tempo de entrada no mercado é o período de tempo desde o consumo do seu produto até que ele comece fornecer variados os clientes são, ele é lançado para o mercado. retorno sobre o gasto com anúncios deste projeto é a receita total gerada a partir de um produto relação ao custo dos sprints necessários para desenvolvê-lo. Satisfação do cliente Há muitas maneiras de o Connect Service, feedback dos presos e quantificar a satisfação do cliente. Pontuação de satisfação do cliente, pontuação de esforço e uma pontuação líquida do promotor, ou algumas das formas de obter satisfação do cliente. Escolha o que melhor funciona para sua organização, dê satisfação. Conduta periódica em serviço, pode ver o quão satisfeitas as equipes do Scrum estão. Etapa número nove, compartilhou o sucesso e construiu mais equipes. Quando a fase piloto estiver concluída, compartilhe a história de sucesso e as lições aprendidas com gerência e outros membros da 11ª organização. Compartilhar histórias de sucesso com outras pessoas traz os seguintes benefícios que tive é obtido quanto à forma como projetamos uma aparência diferente antes de implementar o scrum. E como as equipes agora são capazes de fornecer produtos serviços e resultados por meio de uma implementação eficaz de uma varredura, demonstrando o sucesso, você prova, a reputação, a credibilidade, a simplicidade e a confiança das equipes Scrum compartilham desafios enfrentados e lições aprendidas pelo show e ele está no trabalho realizado pela equipe e expressando sua gratidão. Eles se sentem valorizados e motivados. Além disso, eles confiam em você e o apoiarão em todas as situações. Um pouco mais contém para adicionar mais valor à sua organização. E clientes. Pisionado por dez, faz o treinamento vem como parte do programa de indução. Tornar o treinamento scram obrigatório para todos os seus funcionários tornaria uma organização totalmente adj. E eles permitem que os funcionários da cidade aprendam e adotem o Scrum desde o início. Aqui está a lista de todas as etapas que acabamos de ver. 3. Principais desafios na transição: transição de um modelo tradicional, como cachoeira, a escória tem muitos desafios. Neste vídeo que analisou dez principais desafios. Número um, resistência à mudança. Essa instância para mudar geralmente é vista como um dos principais desafios. Você ou a gerência podem não estar interessados em fazer algo novo, o que exige uma mentalidade diferente. Mudanças organizacionais, novas funções e responsabilidades, muito tempo e esforço, dinheiro, etc. Gerentes que preferem ter boa autoridade, comando e controle. O que as equipes podem não estar dispostas a ir? Uma estrutura sugere escória onde delta Posada capacitou e o autogerenciamento. Seus funcionários que não estão dispostos a aprender e atualizar suas habilidades podem ajudar na implementação do Scrum. Falta de conhecimento. Quando as pessoas não entendem por que um determinado Scrum Practices necessariamente, os resultados podem ser imprevisíveis e ineficazes. Por exemplo, se a equipe de TI começar, entendo o propósito do seu scrum diário. Eles geralmente acabam fornecendo sua atualização de status típica para a maioria das pessoas sênior que participa do evento. Antipatia geral da mudança. Algumas pessoas, esta é a implementação do Scrum simplesmente porque elas não gostam de mudanças. Número para desenvolver a equipe verdadeiramente capacitada e autogerenciada. Scrum. É que espera-se que o trabalho em equipe que traz sucesso aos membros da equipe Scrum exiba as seguintes características. Vindo pintar, foco, abertura, coragem e respeito. Além disso, cada equipe deve ser multifuncional e autogerenciada. Desenvolver essa equipe não é fácil, especialmente quando os membros, eles só estão acostumados a trabalhar e a direção e controle completos dos gerentes de produtos em sua cachoeira anterior produtos. Muitas pessoas, quão pouca ou nenhuma experiência com comunicação e colaboração abertas. Eles estão muito hesitantes em compartilhar seus pontos de vista e consentimentos e os não participam ativamente de todos esses eventos Scrum. Para colher os benefícios do Scrum, os membros da equipe precisam de alguma liberdade e espaço para construir coisas que desejam. Isso pode ser um desafio em uma organização onde a microgestão continua a existir. Número três, falta de disciplina. Em uma equipe Scrum. Espera-se que todos os membros sejam altamente disciplinados em termos de desempenhar o papel de forma eficaz, assumir responsabilidade competitiva, ter comunicações abertas com outros membros, trabalhar em equipe e participando de todas as reuniões a tempo. Você precisa de falta de disciplina não ajudará a equipe a atingir o Objetivo do Sprint com sucesso. Número de histórias incompletas no final de um sprint. Há situações em que os desenvolvedores em um determinado sprint não conseguem completar as histórias de usuários a tempo. E eles solicitam que o scrum master estenda a duração desse sprint em particular. Isso pode ser muitas razões pelas quais as histórias de usuários não são concluídas a tempo. Alguns deles são mal-entendidos sobre histórias de usuários. A falta de domínio são tecnicamente escalas, estimativas imprecisas, falta de BAM e problemas de qualidade. Estender a duração de um sprint específico pode não motivar os membros da equipe. O completo há histórias sobre dez. Em segundo lugar, a velocidade da equipe ficará distorcida. Número cinco, eventos Scrum não realizados em dez. Scrum não recomenda a muitas reuniões desnecessárias. É importante que todos os eventos scrum, sugira refinamento de backlog, Sprint Planning, Daily Scrum, revisão da Sprint e retrospectivas de sprint sejam conduzidos a tempo. E todos os membros da equipe participam ativamente deles com base na regra. Por exemplo, espera-se que o evento de refinamento de backlog seja conduzido no meio de um sprint em andamento. Então isso usa os alunos para o próximo sprint pode ser mantido pronto se enganado ele atrasa esta reunião. E os desenvolvedores estão muito ocupados trabalhando em histórias de usuários atuais. O backlog do produto pode não ter número suficiente de histórias de usuários. Para o próximo sprint, e isso afetará o planejamento do sprint e o progresso dos próximos sprints. Número seis, mistura, cachoeira e Scrum. Sem treinamento adequado, dê aos membros que afirmaram ter alguma experiência prévia em um DJ de outras organizações tentem trazer suas experiências e fazer com que outros os sigam. Na realidade, que experimenta a maior parte do tempo, combinação de Scrum, cachoeira. E isso não permite que a organização atual colha os benefícios da pedra. Número sete, membros da equipe trabalhando em várias equipes. Embora os lipídios, procurando em uma equipe do Scrum ou espere que sejam completamente dedicados, e não é aconselhável que eles trabalhem em várias equipes, a menos que estejam ociosos e não tenham histórias de usuários para trabalhar ligado. Se os desenvolvedores estiverem trabalhando em várias equipes, talvez eles não consigam se concentrar em uma coisa e geralmente tendem a ser menos produtos. Além disso, será difícil cumprir o Meta da Sprint devido à sua não disponibilidade e várias outras prioridades. Número oito, esperando células rápidas, implementando o Scrum para os primeiros dez em uma organização, nos leva desgastados. Envolve muitas mudanças organizacionais, dedicação, compromisso, foco, treinamento, aprendizado e continuidade a implementar. Todas essas coisas não podem acontecer da noite para o dia. Pode levar de alguns meses a vários meses, dependendo de quão efetivamente golpe é implementado e praticado. Esperar rapidamente com as células só levará à decepção. Número nove, fazendo com que as plantas entendam Scrum. Quando você desenvolve seu produto em colaboração com seu cliente que é novo no Scrum, é sempre bom fazê-los entender os benefícios do Scrum e como ele o ajudará a entregar com sucesso o produto. As latas tendem a gostar de processos reais porque conseguem revisar os pequenos pedaços e fornecer feedback no final de cada sprint. No entanto, educá-los para gerenciar processos mais colaborativos no início pode ser um desafio. Número dez, falta de gerenciamento de riscos. No entanto, o próprio Scrum mitiga muitos deles no desenvolvimento de produtos ou gerenciamento de produtos, apenas seguir o scrum não garante sucesso. Existem muitos riscos inerentes aos quais cada produto está associado. É importante que todas as organizações ainda tenham um bom plano de gerenciamento de riscos e todos os riscos potenciais sejam tratados de forma muito proativa. Por exemplo, a alta rotatividade de funcionários é uma das tarefas comuns com as quais as mini organizações lidam. Poderia haver razões como grande demanda do mercado , salário, novas tecnologias , melhores benefícios para funcionários, etc. A menos que tais riscos sejam atenuados, isso terá um impacto na finalidade solicitada do produto em desenvolvimento.