Guia completo de Agile, Scrum Master e Kanban *E-book gratuito*

1. Introdução ao curso: Ei, pessoal, bem-vindos à primeira palestra real do curso. Vamos falar sobre agile scrum Cambon. O que? Nós vamos cobrir isso. O que você deve esperar e dar a vocês um cara sólido tem que entregar mudança de valor dentro de sua organização. Você não precisa necessariamente ter uma compreensão básica do gerenciamento de projetos. Se você vai ser bem-sucedido, ágil, particionamento ou scrum master, você tem que tomar decisões diárias sobre velocidades do projeto para nomear com sua equipe e executar retrospectivas para ajudar a equipe a ir. Você verá que o curso toca em tudo o que tem a ver com mudança e agilidade, pois é uma filosofia que está no centro de tudo o que fazemos. Independentemente de usarmos combate de limpeza durante a vida, você também ouvirá vídeos e verá que as demonstrações estão construindo sua primeira geração. Como pode os homens é uma luta dentro de sua organização, mas também os diferentes papéis que uma equipe scrum consiste em, Mas suas responsabilidades como um produto mestre scrum, mesmo um membro que é uma parte do desenvolvimento. Este curso é também para as pessoas gostariam de atualizar o seu conhecimento de agile rolar me Cambon como ele oferece um grande interior. É como trabalhamos diariamente. Usar este curso também inclui folhas de trabalho prontas para você pegar e começar a trabalhar . Ele inclui um modelo de ponto de história, queimar modelos e até mesmo uma história de usuário. Difícil guiá-lo através do seu primeiro ano de histórias de partição. Se você tiver alguma dúvida durante o curso, se você precisar de mais alguma orientação se você tiver algum feedback ou sugestões do mesmo, por favor me avise, porque este curso sempre vai melhorar com os pés para trás. Nossos caras, então, espero que você esteja animado porque eu estou animado para ensinar este curso Solis pulá-lo. 2. Introdução ao curso Ático: não importa a indústria de tamanhos da empresa. Há sempre pelo menos uma pessoa falando sobre tornar as coisas mais ágeis. Mas o que isso significa exatamente? E como você pode colocar em prática e se tornar mais do que um palavrão? Bem, primeiro lugar, a agilidade do contexto de negócios é anonimamente usada para dizer que algo é flexível, proativo e características rápidas que são úteis em um mundo acelerado e transformador . Mas, além disso, significado descritivo permanece toda uma mentalidade em uma maneira filosofia de olhar para os desafios e fazer coisas que vão muito mais fundo, simplesmente colocando etiquetas ágeis tudo o que difere de um processo de cachoeira tradicional . Em suma, ser verdadeiramente ágil é uma questão de cultura corporativa. Perspectiva. Tornar-se ágil ajuda a dar uma olhada em um exemplo brilhante. Uma indústria que é caracterizada pela agilidade mais do que qualquer outra e tem estado tão longe da última década é o desenvolvimento de software. Pode servir como um modelo para qualquer outra indústria que queira ser ágil. Enquanto muitas áreas estão apenas agora percebendo o impacto total da transformação digital, desenvolvimento de software tem sido o cerne deste desenvolvimento desde o início , a forma como compreendeu a necessidade de novas abordagens no mundo em rápida evolução pode ser o melhor no manifesto ágil. Foi publicado em 2001 após 17 figuras líderes na indústria de software admitir montanhas Utah . Um objetivo comum era encontrar os melhores fluxos de trabalho possíveis para o desenvolvimento de software durante a sua estadia. Eles conseguiram identificar e as crenças anteriormente comuns são definidas no manifesto ágil. Hoje, quase duas décadas depois, é mais relevante do que nunca, especialmente para outras indústrias. Os princípios orientadores formulados no manifesto pela essência da capacidade das indústrias de software para acompanhar um mundo digitalizado e rápido . Então, a questão mais importante que todas as outras indústrias afetadas por essa transformação têm que perguntar é o que o desenvolvimento de software está fazendo de forma diferente? E como é capaz de transformar os desafios de velocidade e flexibilidade para se tornarem parte de sua própria natureza? A velocidade com que surgem novas possibilidades? Virtual de tirar o fôlego Temos a inteligência artificial Blockchain já se tornou a nova base tecnológica normal de qualquer jogo potencial. Os Changers rejeitam isso nos últimos anos. Aplicações práticas seguirão, sem dúvida, uma velocidade exponencial. Mas, mesmo quando essas novas tecnologias estão começando a atingir o mainstream, as próximas grandes coisas já estão sendo feitas. Consequentemente, reagir a tais desenvolvimentos é apenas uma parte dos desafios que as empresas têm de enfrentar, mantendo um olho no horizonte e identificando potenciais mudanças de jogo e compreensão. A implicação é uma segunda parte. A natureza generalizada dos avanços nas tecnologias digitais torna as coisas especialmente importantes. À medida que tudo está se tornando digital, torna-se ainda mais difícil antecipar toda a extensão do impacto de novos desenvolvimentos. As empresas que não estão preparadas para se adaptar a esses novos requisitos ficarão rapidamente para trás . Portanto, só é necessário que as empresas se tornem mais digitais. Também se tornaram mais rápidos e mais ágeis. Nada chocante de novo aqui. Então, a verdadeira questão é como começar e como vamos além das palavras de voz? Acreditamos que há uma área que mais beneficia de métodos ágeis, que é a inovação. Mas por que isso? Simplificando, a inovação ativa muitas vezes vem para baixo encontrar uma nova solução para um problema não apenas qualquer problema, mas um problema que muitas vezes reside no futuro. Por esta razão, os requisitos para uma solução podem mudar uma e outra vez, planejar um projeto do início ao fim e, em seguida, aderir estritamente a este plano é, em muitos casos, não mais rota direta para o sucesso, o as circunstâncias que mudam demasiado depressa se estes utilizadores de mudança de ar necessitam de requisitos tecnológicos, hábitos de consumo ou mudanças dinâmicas de mercado e os novos desafios que o acompanham inevitáveis. No entanto, palavras como inesperadas ou imprevistas são bandeiras vermelhas e magia clássica do projeto. Em contraste, não há nenhum problema equipes frágeis. O paradoxo do mundo corporativo é que quase todos os setores se sentem ameaçados pela incerteza e pela interrupção, mas, ao mesmo tempo, há mais dados de informações disponíveis do que nunca. Portanto, o problema, na verdade, é que o conhecimento de informações muitas vezes não é usado ou incluído corretamente na tomada de decisões , adotando princípios ágeis e alinhando sua organização com eles é o primeiro passo para resolver isso Desafio. Uma mente ágil define profundamente incorporado na cultura corporativa permite um olhar constante além da própria organização em cada ponto ao longo da criação de novos produtos ou serviços e por todos os indivíduos envolvidos com os processos ágeis corretos de mentalidade. Incorporar ou reagir a estas entranhas não deve ser um problema. Agora isso só é possível quando a agilidade é compreendida na sua totalidade. Estamos indo além da palavra-chave da mera otimização de processos para o desenvolvimento de software. A ideia de agilidade torna-se os elementos centrais que definiram o fim do NT de toda uma indústria. Ele ajudou a estabelecer uma base compartilhada para desenvolvedores sofridos em todas as organizações e nações. Ao mesmo tempo, disse que a indústria, além de processos no mundo analógico, fazê-lo os princípios ágeis para encontrar um novo tipo de cultura de trabalho perfeitamente alinhados para os requisitos, um ambiente digital, uma transformação do mundo fora do desenvolvimento mais suave precisa acompanhar. 3. Como é a gestão tradicional de projetos diferente do Agile?: Então olhando para a linha do tempo da cachoeira que temos na nossa frente, há sete passos. Como você pode ver, assim é reunidos requisitos de documentos, teste de código de design. Você é bonita, corrigir problemas de backlog e entregar o produto. Assim, durante esta mitologia de desenvolvimento, cada etapa precisa geralmente terminar antes que a próxima fase possa começar. No entanto, entre as diferentes sete tarefas que eu listei, o projeto precisa ser revisado e aprovado pelas partes interessadas antes que qualquer forma de design possa estar recebendo obviamente não é nada neste mundo. Vem um monte de positivos, mas também desvantagens. Vamos dar uma olhada nisso agora. A 1ª 1 é de acordos mútuos. Agora ambas as partes, cliente e desenvolvedor. Têm de chegar a acordo sobre o que será entregue antes do trabalho efectivo de implementação. Isso torna o planejamento e o design simples, e você pode esperar muito poucas mudanças na segunda parte progride, medindo todo o escopo do trabalho. Muito simples. Isto significa que o R A Y e os processos para o projeto já foram garantidos antes do início do trabalho. 31 é projetado é a primeira fase agora. Design não é fase anterior. A maioria das outras fases neste tipo de projetos isso significa que ele se presta muito bem para usar. Os componentes precisam ser construídos ou projetados. Por exemplo, você está construindo televisão, ICS de elétrons, sementes de carros, geladeiras, qualquer coisa grande e física. Número quatro todos os requisitos conhecidos de antemão agora, vez que todos os obstáculos requisitos são conhecidos antes tinha ele fornece uma imagem mais completa para os engenheiros e muito pouca área para erros. Agora vamos dar uma olhada em algumas das partes negativas de cachoeiras, de modo que o 1º 1 sendo stakeholders sendo a habilidade como olhamos, uma cachoeira é fortemente orientada para a coleta de requisitos também. A requisitos de disponibilidade das partes interessadas reunindo ditames fase do resto do projeto vai parecer que há muito pouco ou nenhum telhado. Flexibilidade diz que você tem um estado frio chave. É de férias por quatro semanas, e é aí que o seu apartamento espalhando sessões. Você pode ter um problema reunindo requisitos dos planos específicos da unidade de negócios e simulações e difícil de visualizar Agora, as partes interessadas e os clientes nem sempre são capazes de visualizar quais projetos, quadros de fio ou simulações parece como um tipo de produto. A maioria dos usuários finais também dificuldades em emparelhar estes com um requisito escrito dado antes do projeto. As mudanças de início também se tornam difíceis e muito caras, especialmente mais tarde no projeto. E se tudo se basear puramente em requisitos foram definidos meses, talvez anos de antecedência. E se tudo se basear puramente em requisitos foram definidos meses, Então imagine como seria difícil mudar a porta na geladeira ou três andares do arranha-céu versus escrever, re escrever algumas linhas de código. É isso que estou tentando conseguir. 4. Comparação ágil: Então, se olharmos para ágil, você vê que o primeiro ponto é realmente princípio chave dentro do trabalho com o dólar, Você freqüenta a entrega? Um valor de trabalho que o cliente vê frequentemente o trabalho sendo entregue dentro de sessões de revisão espiritual , geralmente dentro de 10 dias. Mudanças e decisões podem ser tomadas ao longo do projeto, sendo a segunda parte um forte senso de propriedade. Agora há sempre um forte senso de posse de esposas da equipe. A equipe trabalha em conjunto diariamente para construir um produto. Você tem todas as suas cerimônias em seu scrum, se você usar câmera muito fácil de produzir. M V P, agora ágil, orgulha-se de oferecer alto valor de negócios e software de trabalho, facilitando assim a produção de uma versão básica do referido software que pode ser cronometrada com objetivos de negócios, como marketing, etc. Todos os dias são um requisito. O desenvolvimento do dia é um foco mais do usuário, pois não há um único ponto no tempo para apartamentos. Mas todos os dias, Dia Exigência Comunitária, que me dão seção em mais sprints, adicionado ao backlog do produto e levá-lo para os futuros sprints que você terá. Agora vamos dar uma olhada no lado negativo do ágil aqui, então cada item pode não ser concluído na caixa de tempo. Agile como vamos explorar dentro deste curso é uma entrega de caixa de tempo. Isso permite alterações a cada priorização. Agora isso significa que os itens de entrega podem não ser capazes de completá-lo dentro da planta. Sprints deve distorcer um ser muito alto ou erroneamente estimado pela equipe durante um planejamento de sprint . Agora, os custos adicionais do projeto também podem ocorrer apenas recursos adicionais que estão sendo solicitados em todo o projeto. Precisamos de adaptar e mudar, bem como trabalhar um trabalho para reduzir a qualidade. Há um risco de possível redução na qualidade devido à fatoração re freqüente, é um escopo completo não é considerado na arquitetura ou design. Agora, se olharmos para o tempo ágil que o loop aqui, normalmente você tem seu plano de reunião. Estas são as sessões de grupo de pendências ou sessões de bronzeamento Sprint. Você também tem design. Você tem o código e o feedback da versão de teste, que você estava recebendo. Suas sessões de Sprint Review voltando para mim. O plano. Então vamos dar uma olhada rápida em uma comparação entre cachoeira e ágil. Assim, começando com a disponibilidade do cliente, os clientes se envolvem em determinados marcos no projeto. Por exemplo, aprovações há projeto AH entregue à morte. Há transferências de testes que você não entregou, então todas elas são muito auto-contidas. Se você olhar para a disponibilidade de um cliente com uma parte interessada ágil, disponibilidade é muito, muito importante em todo o projeto. Isso é realmente a chave. Você os tem em suas críticas. Você os tem dentro de seus sprints. Você os tem dentro de seu planejamento de sprint, sempre conversando uns com os outros, se comunicando. É também sobre os princípios da ágil. Então, quando olhamos para o escopo da cachoeira, os requisitos pré-definidos são fundamentais para a cachoeira, e eles funcionam muito bem quando as mudanças são limitadas. Isso significa que há um cenário pré-acordado para o trabalho fora, e isso é praticamente qualquer mudança no bem-vindo. Então, se você olhar um escopo, ágil adapta-se muito bem à mudança, ele vem a um custo do projeto não é conhecido com antecedência. Quando falamos sobre priorização e cachoeira, os clientes recebem tudo o que pediram. Se a tarefa é determinada dentro do contrato e a fase de requisitos, que é um pequeno acordo com essa cachoeira é que tudo é acordado na frente e, em seguida, a equipe executá-lo. Parecemos uma priorização com um valor ágil de entrega. Um software de trabalho reduz o risco e pode mostrar sinais de que o produto está no caminho certo. entrega rápida de um marco aumenta a chance de uma aprovação organizacional. Estamos olhando para o orçamento de custo de preços para cachoeira. Há sempre um acordo como major antes que o aperto de mão aconteça na frente. Isso significa que os custos fixos do projeto não significa ágil. Ele funciona muito bem com um orçamento rolante ou quando um custo este conjunto com os amigos limitadores, digamos 10 sprints ou o que for. No entanto, isso significa que o trabalho e ainda estar pendente. Assim, um modelo de custo frágil poderia ser o financiamento mensal para todo o projeto. Olhamos para o aspecto da equipe da Cachoeira Nigel sobre a cachoeira. As transferências da equipe aconteceram principalmente durante marcos separados foram alcançados projetados para o desenvolvimento. Por exemplo, se você olhar para ágeis, eles são equipes menores e pausar nós mesmos organizados a praticamente executar eles mesmos com este processo é o assassino da ágil 5. Cachoeira e carro agile: Então, como uma empresa de fabricação de automóveis, eu gostaria que meu cartão fosse produzido dentro de 12 meses. Todos os meus requisitos das naves são fábricas, todos os projetos de também masculinidade, e agora é hora de construir. Então, se olharmos para todo o processo águias desde o design, até o desenvolvimento agora o teste de acabamento com enviado em feito. Agora vamos dar uma olhada em uma maneira ágil de construir um carro para que o cliente e a equipe estejam completamente envolvidos no processo. Juntas, a equipe oferece o mais alto valor comercial primeiro, que é o carro porque queremos entregar um sólido M V p. Nós tiramos itens do trabalho de backlog do produto naqueles durante a primeira geração, enquanto permanecemos em comunicação constante com os clientes que podem adaptar nosso projeto à mudança. Deve haver em após a iteração, que é de duas semanas de duração, Nós, em seguida, apresentar nossos clientes com um carro. Depois de receber nosso feedback sobre novos insights de um gerente de produto, vamos olhar para melhorias que este carro em interesse dois e três, com cada iteração durando duas semanas 6. Princípio agile 1: o primeiro princípio da ágil diz que são a nossa maior prioridade é satisfazer o cliente muito cedo e entrega contínua de software valioso. Seu ouro aqui é focar na entrega de valor, seja software ou projetos para o plano organizacional. Isso significa que por como você faz isso, você scrum, mestre de cerimônias e, por exemplo, ferramentas diferentes são apenas ferramentas. Se você não chegar ao seu complexo de ouro, ferramentas e processos é obviamente um gargalo. Ele precisa ser cortado para reservar em ágil você vai entregar usado para ter um nível de usabilidade acordado . Isso significa que em uma pequena quantidade de tempo, você está em um entregável. Vamos ver seu primeiro sprint. Ele deve entregar o mais alto valor comercial para o produto. Você pode não ser perfeito, mas precisa seguir uma trajetória de processos iterados que tornam público espera para o primeiro mês Isso ajuda você a fazer é a entrega. Melhore o trabalho. Permita que os clientes avaliem o valor que você trouxe para a mesa e obtenham pontos de feedback , bem como abertura para a guerra. Comunicação com a sua equipe declinar para a organização. Aqui é onde nos referimos novamente ao gerenciamento de projetos em cascata, contato reclinado geralmente acontece no início no final do projeto, entrega contínua pode ser um desafio. Esses ambientes estão quebrando. Trabalhar no recurso de entrega ajuda incrementalmente a entrega de partes de projetos. O cliente para que eles receberam o segundo princípio de ágil diz, bem-vindo mudança requisitos mesmo tarde no desenvolvimento. Processos ágeis aproveitam a mudança para os clientes. Vantagem competitiva. O segundo princípio aborda um conceito métodos tradicionais de gerenciamento de projeto. Ser médico pode mudar no mundo do software dentro de uma organização? Mudança de escopo para detalhes no produto muitas vezes vêm em todos os tipos de riscos, como falta de um cliente importante esse prazo ou ultrapassar sua previsão orçamentária. A razão pela qual é uma mudança de corrida é fornecer sobre a mudança não fornece valor de qualquer tipo. Por que você faria isso? Bem, às vezes a orientação dos nossos clientes para as metas muda. Às vezes, eles também não entendem completamente suas necessidades até ver o primeiro valor incremental sendo entregue de ambas as partes ou mesmo dentro da organização. As partes interessadas se concentram no valor e têm essa mentalidade em todo o projeto. mudança não será tão difícil, também tomando uma abordagem navegacional. Em vez disso, não é abordagem significa que você pode obter um destino melhor, mas estar preparado para mudar de direção e encontrar vantagens ou as pessoas com quem trabalhamos decidem que a mudança pode abrir mais oportunidades para você, e as equipes fazem excelente trabalho. 7. Princípio agile 3: o terceiro princípio da ágil nos diz para entregar auto trabalhando frequentemente de um par de semanas a um par de meses com uma preferência para o menor período de tempo. É muito simples de lembrar, mas também a chave aqui é saber que sempre tentamos entregar valor. Esse princípio se concentra em fornecer primeiro o mais alto valor comercial, bem como fornecer uma parte da integração que o cliente pode realmente usar, ao mesmo tempo em que pode anexar relatórios de medidas do seu lado. Mesmo que estejamos olhando para um projeto muito áspero ou peça de software áspero, isso pode significar que ele ainda traz muito valor para a organização, especialmente acordado com um proprietário do produto. Mas por que entregar biscoitos meio assados e chamá-lo um dia? Bem, trabalho que é mensurável e que fornece valor também oferece uma ponte para mais feedback . Por exemplo, uma reserva Vigen para um site, uma página de detalhes do produto ou até mesmo um feedback de filtro de produto fornece no proprietário do produto uma base para a comunicação contínua. Entrega e feedback frequentes significa que as pessoas se acostumam a se comunicar, que também cria confiança em você, pois o scrum, mestre ou gerente de produto estão incluindo o cliente no núcleo do projeto, abrindo-se para ver como você trabalhar a tempo com confiança e comunicação. Próxima entrega também melhora com freqüência, no entanto, também não significa entregas rápidas. modo geral, ummodo geral,entregas rápidas tendem a ser vistas. EUA têm menor qualidade devido aos cantos de corte e entrega como o que algumas pessoas se referem como biscoitos meio assados. Se você pensar na frequência, isso também pode significar que você pode reestruturar seu trabalho para que você possa oferecer um trabalho melhor e mais valor. Olhando para todas essas informações sobre o trabalho vivo com freqüência, bem como receber feedback, comunicando abertamente. O resumo de tudo isso seria você entregar trabalho utilizável. Recebeu mais feedback. Entregas mais rápidas mostram que mais transparência deixa mais espaço para otimizar o trabalho mais cedo possível. Resulta em boa comunicação, que melhora os seguintes resultados. O quarto Princípio da ágil nos diz que pessoas de negócios e desenvolvedores devem trabalhar juntos diariamente durante todo o projeto. Este princípio centra-se fortemente no valor de diferentes tipos de comunicação cruzada e cooperação poderiam acontecer. O projeto. Essa mentalidade espera que você trabalhe com o cliente diariamente, falando diretamente e frequentemente com seu cliente ou membros dentro de sua organização que você está fazendo o projeto para aumentar, feedback de confiança, bem como uma direção para Ouro. Isso também pode levar a melhorias informais. Essas melhorias geralmente não são retirados seus pontos de ação e reuniões formais, mas sim configurações informais, como standdups ou show até onde todos vocês concordam em melhorar o produto com base na compreensão mútua do grupo, em vez de um direção definida por outra pessoa. Este tipo de melhoria vem com paixão e emoção em vez de apenas fazer o trabalho feito, eu descobri que misturar estes Beth é junto com sua equipe interna como também proprietários de produtos , faz ajuda e contribui para alcançar o nirvana de melhorias informais, passando atualizações umas às outras na folga, criando comunicações culturais abertas e regulares para recuperar e chamadas rápidas. Convide-os também a descrever cerimônias do Sr., como normas de alerta. Se o seu cliente incluir várias pessoas, mantenha-se em contato com elas na base de contato com ele com frequência. O quinto princípio de um trabalho nos diz para construir produtos em torno de indivíduos motivados. Você dá a eles o ambiente de apoio de que precisam e confia neles para fazer o trabalho. Este princípio toca no conceito de indivíduos criativos podem florescer se eles estão sendo microgerenciados, forçados a trabalhar no ambiente, a menor criatividade. Para que um projeto ágil seja bem-sucedido, uma equipe deve receber as ferramentas necessárias para ter sucesso e ter a confiança de que é capaz de realizar seu trabalho. Mas esse princípio é muito mais. Está a dizer que não se pode trabalhar sem. Os outros projetos não podem ser construídos sem indivíduos motivados. Então, para tornar isso muito mais fácil e para criar discussões em torno disso, vamos dividi-lo. Construir projetos significa que você está trabalhando para ouro definido. Esses objetivos vêm com seus próprios conjuntos de atividades e metas, bem como limites para trabalhar dentro da mente de todos. Lançar ou trabalhar dentro de um projeto é a necessidade de progresso saber como realizar progresso e sucesso é vital para manter a motivação. Sementes de interesse como ouro navegacional. Se você estava constantemente à deriva, como você sabe que consegue o que se propôs a realizar? Indivíduos motivados podem alcançar o impossível Motivação é fogos e nos impulsiona, trazendo também interesse no conhecimento, produto ágil e motivação vivendo simbiose constante , ágil, construído, olhando para as pessoas primeiro se as pessoas são desmotivadas com feedback ruim, têm problemas de comunicação e ir mostrar iniciativa. Um não pode existir sem o outro. Dê-lhes o ambiente de apoio para atender a qualquer tipo de desenvolvimento. Se é um software de criação organizacional requer um conjunto de ferramentas. São paisagem digital está sempre mudando mawr mais ferramentas saindo para simplificar a colaboração e o processo. Mas isso também vem bem. Apoie alguém para ajudá-los a resolver esses pequenos problemas irritantes, certificando-se que o ar vozes doem. É aqui que entra em jogo uma sensação de empatia e de transporte pelo bem-estar dos outros. Confiar nos membros da sua equipe para fazer o trabalho é uma situação desafiadora é que você pode encontrar-se em uma situação em que muitas vezes desenvolver leads de pacientes para ir sobre a saída. 8. Agile Princípio 6 7 8: o seis diretor diz que o método mais eficiente e eficaz de transmitir informações às mulheres na equipe de desenvolvimento é a conversa cara a cara. comunicação face a face é sempre a educação mais eficaz, este tipo de conversa. Não há espaço para interpretações erradas e ajuda você a chegar ao ponto de qualquer comunicação. Isto é especialmente verdadeiro quando um grupo de pessoas está trabalhando em um projeto em conjunto. Particularmente deve bater é o ouro. Você se comunica eficazmente aqui mais mesmo ou e trabalhar para eficiente. Eu vi mudança de comportamento da equipe e empresas sendo grandes contas de passagem aérea apenas têm equipes em um lugar em um trabalho projetos onde as equipes trabalham intensamente em um projeto por curtos períodos de tempo. Não há tempo para isso. A comunicação depende do porquê de haver um princípio face a face para a educação, mas eu gostaria de aproveitar a oportunidade para discutir o trabalho remoto como uma política. Se uma equipe está bem conectada através de todas as nove formas de comunicação e construiu um nível de confiança, por que o trabalho remoto seria um problema? comunicação remota pode distorcer o ritmo normal de nossas conversas para atrasar entre mensagens pode oferecer, adiar ou ocultar reações emocionais, comentários quantas vezes você escreveu e você sabe disso imediatamente. Mande tudo. Eles estão preocupados sobre como a sua bola viu seu e-mail noturno e considerada uma intrusão em um horário particular? Sem uma resposta imediata, podemos nos distrair. Segundo, adivinhem nós mesmos. Nós até ficamos frustrados com suas equipes. Então, para tornar isso mais fácil, não se queixe. Breves comunicações. Uma comunicação clara Em nossos esforços para ser eficiente, às vezes você usa menos palavras para se comunicar. Mas essa brevidade pode significar que o resto da equipe perde tempo tentando interpretar suas mensagens. Passe o tempo para se comunicar com a intenção de ser ultra limpo, não importa o meio. Na verdade, você nunca pode ser muito claro. É muito fácil ser menos claro do que você deveria criar um espaço intencional para a celebração. Bolos de aniversário da velha escola ainda são importantes para equipes remotas. Cranium, espaços virtuais, os rituais para celebrações. socialização pode fortalecer os relacionamentos e estabelecer as bases para a colaboração futura . O Sétimo Princípio da Agile nos diz que o software de trabalho é uma medida primária de progresso. Este princípio é o fato de que, como o trabalho é feito intensamente e rapidamente, às vezes erros serão cometidos e produtos falharão agora falhar rápido é uma terminologia. Use muito dentro da indústria ágil e não significa sucessos nulos. Isso geralmente significa que, dentro de um fracasso, você aprende e estabelece bases para o sucesso. As perguntas deles. Você pode se perguntar para avaliar o progresso de sua equipe. Ele é uma equipe de desenvolvimento, queimando histórias de consideração 100% sem se sentir sobrecarregado ou pouco usado. O proprietário do produto está satisfeito com as entregas do fim da federação? Sua equipe é adaptável à mudança? Não estamos vazando defeitos que cada iteração o ponto que o manifesto ágil estava tentando fazer aqui é que quanto mais você entrega, mais você aprende. Lembra quando falamos sobre navegação? Fiz parte de projetos em que clientes e clientes entendem o que realmente querem . Uma vez que vimos os primeiros bits comiserados entrega chegando, isso significa refinamento constante, entregando peças utilizáveis, bem como entregar revisão. Será que as partes que podem ser dobradas? Digamos, por exemplo, que você esteja trabalhando em um produto com uma lista de recursos, muito parecido com um jogo. À medida que você entrega seus protótipos que são testáveis, você os contrata com considerações mensuráveis de touros. Se você está apontando para um certo número para anexar aos olhos KP. Você pode medir isso com um produto viável, mesmo que seja muito áspero. Neste ponto, o oitavo princípio de ágil para o desenvolvimento mais sustentável os patrocinadores, desenvolvedores e usuários devem ser capazes de manter um ritmo constante em definitivamente na metodologia tradicional de gerenciamento de projetos. Alguns projetos exigem muito trabalho na frente e no final para manter a manutenção com metodologia ágil . Isso deve ser uma quantidade constante de trabalho Para explicar esses princípios mais ágeis declarar definitivamente que você deve encontrar e manter o ritmo que pode ser mantido indefinidamente, e todos devem ter esse ritmo. Isso também é o que chamamos de velocidade. Eu amo a fase é positiva, mas vamos encarar, é um princípio sobre não queimar processos adultos. Certifique-se de que o desenvolvimento que é sustentável, que os testes de velocidade de entrada todos direcionados para que todos e eu quero dizer que todos os envolvidos poderiam manter isso para sempre. Isso, é claro, faz sentido uma vez que você encontrar um ritmo factível, ser capaz de continuar previsivelmente ao longo do tempo. Quando há desvio, você pode se adaptar como você tem um ritmo estável em andamento. Quando é sustentável, você pode continuar entregando valor. Você não diz “Ei, vamos ser sustentáveis e isso acontece”. É algo que você tem que trabalhar. Este princípio recorda-nos a comprometer-nos a fazê-lo, a certificar-nos de que encontraremos o ritmo em que todos podemos trabalhar juntos. Patrocinadores são as pessoas que pedem o trabalho. Parece que o velho é óbvio. Não sobrecarregue as pessoas. Claro, não é tão óbvio. Cada um dos três grupos têm diferentes interações são produtos criados. Então, como é que os patrocinadores trabalharam com os outros grupos? Assim, os patrocinadores precisam entender o ritmo que os desenvolvedores podem trabalhar e apoiar, talvez até mesmo empurrado para trás. Esses patrocinadores que pressionam precisam trabalhar com desenvolvedores e estar disponíveis para que possam ajudar ambos os desenvolvedores, mas também ficar cientes de sua pasta e sustentabilidade. Os patrocinadores precisam entender as expectativas dos usuários, não apenas o que é procurado pelo que me dá conta. Pode parecer ótimo tirar coisas do Thomas, como patches para jogos, mas isso pode limitar o feedback. Os usuários de comunicação só podem lidar com tantos patrocinadores, devem ouvir os usuários e dar à FIBA encontrar maneiras de incentivar o desenvolvimento sustentável. Isso também pode significar entender música, perspectivas e o que eles querem e o que você quer. O meu diferente. Então, o que precisamos ter cuidado com os patrocinadores, desenvolvedores de sobrecarga, isso muitas vezes falha. Ele tem sangue ruim, e há mais de onde isso veio. Atitude eu vejo um pouco muitas vezes em campos criativos faz inimigos. Patrocinadores não prestam atenção aos usuários nem assumem o que querem. Eles costumam errar. Sua equipe versus patrocinadores fornecem aos patrocinadores essas informações para ajudá-los a acompanhar o ritmo. Trabalhando com você, mais preventivamente você dá a eles uma idéia do que sustentável mais rápido eles conseguirão. Ajude os patrocinadores a atingir um ritmo sustentável. Eles não fazem o trabalho. Eles podem não saber o que é. Você pode salvá-los de burnout, ou ser excessivamente pressionado irá ajudá-los a encontrar um resultado. 9. Princípio agile 9: o nono princípio de Joe nos diz que intenções contínuas de excelência técnica e bom design aumenta a agilidade, estão prestando atenção à excelência técnica. um bom design, você se torna ainda mais adaptável, mais produtivo e mais ágil, simples e elegância. Então, como você pode imaginar, eu vou analisar isso. Não é que esconda qualquer complexidade. É óbvio que há muito poder neste que qualquer um pode usar. Este princípio estabelece uma excelência técnica em bom design são coisas que se quer ser atenção para sempre. Isso, claro, é óbvio porque quem não iria querer prestar atenção em fazer as coisas certas ao projetar as coisas certas? Eles foram especificamente que aumenta a agilidade? Os benefícios dessas coisas não são apenas hey, bem feito aqui que você usa métodos ágeis e aplica princípios ágeis. Melhor é um benefício além do óbvio de fazer coisas. Bem, nós projetamos algo. Bem, é mais do que apenas um trabalho valioso. Ele oferece outros benefícios que proporcionam agilidade. Vamos olhar para eles e como eles se aplicaram ao criativo Seria bons projetos evitar erros desde que você pode acertar na primeira vez. Isso significa que você economiza tempo dizendo que você tem menos revisão em aspirar a um bom design. Concentre-se. Você está ouvindo a compreensão do cliente funciona. Você fornece valor que ajuda em ambientes imprevisíveis, que provavelmente você enfrenta muitos designs bons. Um que pode ser repetido em parte ou no todo, que economiza tempo no futuro que permite trabalhar mais rápido, já que você tem outras coisas para chamar, como modelos de design, código reutilizável ou mesmo listas de verificação úteis. Isso pode ajudar a ser obras criativas porque você já tem algum trabalho feito, pelo menos as partes menos previsíveis ou padrão. Um bom design não é necessariamente o mesmo que a excelência técnica. Bom design, talvez sobre colocar as coisas para fora e colocar as coisas juntas bem sobre fazer padrões organizados . Excelência técnica aparente é sobre atenção aos detalhes, sobre fazer as coisas certas sobre não sobre fazer as coisas novamente. São benefícios óbvios. De qualquer forma. Vamos ver como isso afeta a criatividade ágil. Dezenas Princípio de ágil nos fala sobre simplicidade. A arte de maximizar a quantidade de trabalho não realizado é essencial. Então imagine que você tem uma lista a fazer para mais de 100 itens nele software. É fácil se deixar levar, tentando alcançar absolutamente qualquer coisa que possa ser possível sob o sol, no entanto, metodologia ágil afirma para se concentrar em alcançar em Lee o que é absolutamente essencial para o sucesso do projeto, a fim de entregar o projeto o mais rápido possível. O que isso significa? Praticamente quando o valor certo é entregue às pessoas, você evita entregar trabalho. Estamos ficando presos em processos que acima da rotina atual. Isso significa focar na simplicidade desde a mão get go, realizando cada tarefa e da maneira mais simples possível. Não crie mais do que o mínimo necessário. Não fale sobre recursos que estão a quatro sprints de distância. Elabore seu backlog como seu progresso no projeto, o que significa itens principais no backlog bem refinados como você vai para baixo cada vez menos por multa. A parte interessante deste princípio é que ele é geralmente aplicável. Este princípio é verdadeiro e importante para uma ampla gama de processos fora da indústria de software . Ele poderia até mesmo ser aplicado em nossas próprias vidas pessoais é um princípio de gestão do tempo e de otimização do trabalho em muitas expressões diferentes deste mesmo princípio estão lá fora para eliminar baixa importância das maiores questões. Um exemplo colocá-los no não fazer isso. Sempre tentar manter o seu processo é o mais simples possível sem que o produto final perca a funcionalidade desejada. Pergunte a si mesmo se você está produzindo algo que é mais útil para o mínimo de tempo. 10. Princípio agile 11: o 11º princípio da Agile nos diz que as melhores arquiteturas, requisitos e projetos emergem de equipes auto-organizadas. Eu estive em ambos os lados do mundo durante o meu tempo a bordo de grandes corporações multinacionais, então eles são muito arcade com o gerenciamento de projetos, e eu estive envolvido em startups, pois todos nós fomos auto-organizados habilita para lidar com o trabalho à frente. Mas como tudo isso funcionou e por quê? Inteiramente. O que temos lido e falado nesta seção inteira está focado na auto-organização , um nível de autonomia, desde a comunicação até refletir, tentador e cultivar sobre a organização. Nós também começamos como isso praticamente funciona é que as pessoas usam suas mãos no conhecimento para projetar, organizar implante. Enquanto você estiver entregando valor às partes interessadas, apreciará sua abordagem. As pessoas também irão gravitar em direção a uma estrutura que funcione para elas. Você não tem todas as respostas que começam, mas ter equipes auto-organizadas diz que cada indivíduo fora em 1/2 para alcançar exatamente isso, respostas que podem aproximar a equipe no projeto. Esta abordagem permite a adoção. Você muda isso, um pai trabalha, e o que não se concentra no valor vai manter sua equipe por estar muito distraída com outros desperdícios para evitar a estruturação excessiva. Incentive a adoção com feedback. Encoraje também a comunicação. 12. Principle of Agile nos diz que em intervalos regulares, Equipe reflete sobre como se tornar mais eficaz do que músicas e ajusta sua gravação de fase. Chegámos agora a um princípio final em conjunto, que é tão transparente como um som. A equipe analisa regularmente formas de se tornar mais eficaz e orienta o navio nessa direção. A regra mais importante dentro desta regra é regularmente. Esta deve ser uma parte muito anti grande da estrutura da equipe. Então você sabe como está indo e está pronto para isso. Este certo ketchup ou retrospectiva, como é chamado, é um bom momento para a equipe refletir sobre o que foi ótimo ou poderia ir melhor. Ele coloca as pessoas em uma mentalidade de melhoria, e quando aprendemos que o que crescemos juntos, também incentiva lições que podem ser usadas no futuro, seja em nível de produto, equipe ou individual refletindo sobre ser mais eficaz. Parece ótimo, mas há um problema. O que significa para sua equipe ser mais eficaz? Não é uma pergunta óbvia, e é por isso que a importância é e como respondemos. Como você mede a eficiência? Você sabe que está melhorando. Eu não resolvo isso perguntando a uma equipe como eles querem medir a eficiência e, em seguida, andar por aí até termos um acordo de uma maneira para fazê-lo. Para muitos, é uma simples verificação geral do intestino. Fizemos o trabalho? Um sinal, você pode encontrar alguns fatores adicionais vêm em. Você também pode achar que ele muda ao longo do tempo. Não posso enfatizar isso o suficiente. Certifique-se de que essas avaliações levam a objetivos concretos para a equipe que eles podem medir. E os testes para a equipe foram indivíduos. Então você pode dizer quem finalmente alcançou a máxima eficiência. Certifique-se de que sua equipe apresente sugestões concretas para que você possa seguir em frente. Na verdade, quando eu faço isso, eu os revisto regularmente, muitas vezes durante outras reuniões e definitivamente no início da próxima revisão 11. Os quatro valores de núcleo do Agile: o primeiro valor da ágil nos diz que indivíduos e interações importam sobre processos e ferramentas. Portanto, está ficando cada vez mais claro para as pessoas nos dias de hoje que as pessoas respondem às necessidades dos negócios e impulsionam. Os processos de desenvolvimento são cruciais ao lado de todos esses processos. O contexto disso significaria também que projetos orientados por processos com forte dependência dos referidos processos oferecem poucas opções de flexibilidade, resultando em equipes que sentem a tensão, não sendo capazes de realizar suas tarefas de forma tão eficiente quanto Eles desejam. As ferramentas que usamos durante o desenvolvimento de sobre a implementação de mudanças organizacionais podem provar que na maioria das vezes você imagina que você tem uma equipe de desenvolvimento e design trabalhando em conjunto com outro em um produto. A equipe de desenvolvimento é fortemente dependente da equipe de design para fornecer especificações precisas e entregas se a equipe está presa em processos que giram ferramentas antigas que não são tão eficientes como um recém-descoberto, que pode causar um sério risco em termos de qualidade e cronograma, para não mencionar Team Moreau. Second Value of Agile nos diz que o software de trabalho é importante sobre documentação abrangente por experiência própria. Trabalhando em projetos de cachoeira. Eu vi organizações terem sido enormes quantidades de tempo documentando o produto para desenvolvimento, bem como chegar com uma lista de requisitos que poderia correr para cima e para baixo no arranha-céu no centro de Hong Kong. Todos eles tiveram que ir para as partes interessadas seniores que tinham visto suas partes interessadas, e todos eles precisam ser aprovados um por um. Isto é, obviamente, uma causa de um enorme atraso no desenvolvimento. Agile, no entanto, não elimina a necessidade de documentação. Ele só percebeu que de uma certa maneira, onde a equipe do projeto não ficar atolado para baixo em cada detalhe diferença do projeto, eu estou tentando apontar aqui é os documentos ágeis, todos os requisitos como usa história suficiente O suficiente para a equipe. Comece a trabalhar no Terceiro Valor da Agile nos diz que a colaboração com o cliente é importante sobre negociação de contratos. Aqui é onde podemos comparar cachoeira e ágil na negociação mais clara ou, por exemplo, backlog. Grooming é quando o gerente de produto e a equipe trabalhar os detalhes do estabelecimento de entrega marcos, expectativas e entregas. Esses detalhes estão sempre prontos para renegociação. No entanto, ela é modelo de equipe de desenvolvimento. Siga Maravilhoso. As negociações começam antes do produto começar e termina após a parte que isso significa que o nível de envolvimento é muito fino ou inexistente durante o processo de desenvolvimento real . O Manifesto Ágil descreve um cenário em que a colaboração é um valor fundamental, onde torna mais fácil para a equipe de desenvolvimento atender às necessidades organizacionais. Este método colaborativo geralmente segue um certo padrão ou previsibilidade. Por exemplo, há demonstrações periódicas, bem como as cerimônias seguintes framework scrum. Quarto Valor da Agile nos diz que responder à mudança importa sobre seguir um plano. Quando eu comecei como gerente de projeto, eu estava trabalhando em uma organização que estava mudando a mentalidade organizacional do porão de água Meu trabalho antes disso acontecer, desenvolvendo recursos ou um certo tipo de software era considerado como um despesa. Antes de passarmos para a fase de desenvolvimento, planos elaborados estavam em vigor tudo em uma alta prioridade e não podiam ser negociados com esse trabalho sendo trazido para a organização que as prioridades mentais não poderiam ser deslocadas. Federações e novos recursos sempre serão adicionados a novos. O manifesto significa que a visão que precisamos para ter seus praticantes ágeis é que a mudança fornece valor 12. O que são pontos de história e como trabalharemos com eles?: consiste em três componentes que precisamos considerar sempre que estamos revisando histórias de nossos usuários ou desejando estimar, e estes são complexidade de risco e repetição. Agora o risco pode ser devido a demandas pouco claras, dependência de terceiros ou incerteza no futuro. Alguns exemplos são Are stakeholders não assinou o escopo do acordo de trabalho. Nós ainda temos que fonte de desenvolvedores adicionais ou nossas partes interessadas apenas completamente indisponíveis agora, entrando em complexidade, esses esforços aéreos envolvidos no desenvolvimento em particular característica. Então, por exemplo, antes de começarmos a desenvolver, precisamos entender que eu era certa parte das obras de infraestrutura I T indo em repetição dessas tarefas monótonas de ar sem qualquer risco real ou complexidade anexada a . Então, os exemplos para isso são tarefas que não exigem muito trabalho, mudar de cor em um logotipo ou mudar um botão para a parte inferior de uma caixa. Agora, olhando para a escala de Fibonacci, a diferença entre um e dois não parece muito grande. Mas se você olhar para três para cima, você começa a notar uma diferença significativa. Uma prática geral para desenvolver pontos de história e emparelhá-los com suas histórias de usuário é desenhar uma tabela. Mas nesta tabela, você tem seus pontos de história set 1 a 21, então zero seria muito rápido para entregar. Nem incluiremos isso. Portanto, o Número um é rápido para oferecer uma complexidade mínima. Número dois. Rápido para entregar alguma complexidade. Número três. Tempo moderado para oferecer complexidade moderada. Número cinco mais longo no tempo para entregar alta complexidade e prováveis incógnitas. Isso pode ser que você saiba o que precisa ser feito em um nível alto, mas há uma boa quantidade de trabalho devido à complexidade do desenvolvimento, e suas grandes incógnitas descobrirão à medida que o fizermos funcionar. Número. Idades. Muito tempo para oferecer alta complexidade, incógnitas críticas. 13. Muito tempo para oferecer alta complexidade, muitas incógnitas críticas. E quando você está no 21 você definitivamente está fazendo as coisas um pouco errado. Eles precisam quebrar porque porque vai demorar muito tempo para entregar. O 21 poderia até mesmo ser visto como um épico 13. Como escrever histórias - INVEST: Eu defende histórias independentes deve ser um Sfar como possível independência. Cada um deles poderia ser desenvolvido e entregue separadamente e representa um uso negociável. As histórias poderiam ser discutidas mais adiante, e deve haver espaço para negociação. Essas coisas eram valiosas. Histórias de usuários devem resultar na agregação de valor ao cliente. E significa ouvir estimáveis. Suas histórias devem ser compreensíveis o suficiente para que possam ser divididas, divididas na tarefa e poderiam obter estimativas estimadas para pequenos usuários. Histórias não devem ser muito grandes. Normalmente deve ser feito com que 40 horas de trabalho. T é testável. Histórias de usuários geralmente têm critérios de aceitação teste se eles atendem às necessidades do cliente. Agora, para que nós realmente cozinhemos, isso usa a história corretamente. Precisamos escrever algo chamado critérios de aceitação. Critérios de aceitação é um ingrediente obrigatório para o histórico de uso. Critérios de aceitação é uma lista de verificação que determina se todos os parâmetros sobre usa história e determinar quando eles usam as histórias concluídas e trabalhando antes da marca de quebra desenvolver . A história de usos tem feito isso, por exemplo, para comércio e, aplicativo móvel, histórias de usuários, vamos usar o nosso como um comprador. Quero rever o meu carrinho para poder fazer ajustes antes de finalizar a compra. Como usuário, eu quero ver uma lista de produtos para que eu possa selecionar algumas cristas de mergulho. Como comprador, eu quero fazer o check-out para que eu possa obter meus produtos enviados para mim. Como usuário, quero ver uma notificação sempre que um novo produto entrar na loja. Agora você vê que o primeiro a usar essas histórias sobre critérios de aceitação está aqui. Podemos dar uma olhada neles para o 1º 1 O 1º 1 diz ver quantidades e itens no carrinho. Veja um custo total antes de impostos e frete. Remover itens, apenas quantidade de itens e clique para navegar em um detalhe do produto. 14. Redação de história de usuário: então isso explora o núcleo dos usos ágeis. Histórias aqui usam as histórias são ágeis eles mesmos, e eles podem usar para nós para seguir princípios ágeis. Mas precisamos manter três princípios de mente que aqui para usar a escrita da história Trabalho sofre a maior medida de progresso, nossas maiores prioridades para satisfazer o cliente através da entrega precoce e contínua de software valioso. A simplicidade da arte de maximizar o trabalho não feito é essencial. Então, o que precisamos fazer aqui é entregar valor aos pedaços do cliente e priorizar o que é valioso versus não valioso. A melhor maneira de fazer isso é representar o trabalho que estamos fazendo através de histórias simples usando investir. Então vamos dar uma olhada em algumas histórias de usos fáceis aqui. Como usuário, quero alterar minha senha para manter minha conta segura. Como visitante do site, quero subscrever a lista de discussão ou produtos. Eu posso receber novas ofertas Como um usuário administrador, eu quero desativar o usuário para que eu possa evitar pechinchas não autorizadas inalteradas por favor. Há algo muito estranho nisso, mas sempre precisamos cobrir quem, o quê e por quê. Usar um modelo é uma boa maneira de capturar com o usuário realmente precisa e o que iria entregar valor para os usuários. Mas isso não é ir ocupado um detalhes de implementação, porque estes são puramente objetivos. Mas como você conclui essas metas quando usamos histórias de usuários? Apoia nossos objetivos de visão. Ele apoia as práticas de desenvolvimento. Histórias pouco claras, obviamente confuso os desenvolvedores são projetados é um resultado de muitas perguntas sobre objetivos obscuros que você vai precisar explicar. Então, uma coisa chave a ter em mente aqui que sempre lembrar, é que Lembre-se que usar a história deve ser escrito de tal forma que você nunca tem que explicar o objetivo. Deve ser tão evidente no ponto que todos estão a bordo de todos os bons usos. As histórias são escritas a partir da perspectiva do usuário, e essa é a única perspectiva que você usaria. progresso é baseado nas ações valiosas que seu usuário pode fazer com o software, por isso é que você está trabalhando no uso de reservas de companhias aéreas. A história deve refletir o problema que você está tentando resolver em movimento. Então vamos dizer que o fundo para isso é que os usuários tiveram um tempo muito difícil selecionar um assento neste caso a história dos usuários para isso seria como um usuário. Eu quero reservar um assento para que eu possa escolher onde poderia sentar no vôo facilmente, certo? Bem, OK, que palavra? Realmente? Criar histórias que fazem sentido para os usuários obviamente não estavam atingindo o objetivo. Se não fizermos isso, como lidamos com a história dos desenvolvedores? Então é como um bom exemplo. Como desenvolvedor, eu quero usar o estúdio visual para que eu possa codificar mais rápido notar que a história em si é muito ruim . Quero dizer, a idéia em si é ótima. Você precisa de estúdio visual. Mas por que você todo o seu trabalho, dependeria de 12? É uma espécie de bloqueador, por isso é curto. Esta história é um requisito p de independência de qualquer outra história. Não é auto-começando com sentar em algum lugar no meio onde as coisas precisam acontecer. Para que isto seja completado. Isso é chamado de impasse, que é quando duas coisas dependem umas das outras 15. Por que usamos os pontos de valor?: alguns exemplos de por que usamos pontos de valor são estratégicos. Se não fizermos isso, investimento não será mais capaz de manter a quota de mercado antes que a conformidade possa ser. Se não fizermos este investimento, podemos estar a violar uma certa lei regulatória. Geração de receita significa que não fazemos este investimento vai perder nossa chance de criar um retorno significativo da gestão de risco de investimento. Se não fizermos esse investimento, poderíamos estar em uma posição em que acabamos com uma evitação de custos das partes interessadas insatisfeita. Se não fizermos este investimento, poderíamos realmente realizar custos adicionais no futuro. Agora, os pontos de valor podem oferecer uma ferramenta útil para ajudar com um processo de priorização. Por exemplo, você pode traçar esforços em relação ao valor para maximizar a entrega dessas histórias, fornecendo a maior quantidade de valor para cada unidade de esforço. Value Points também pode, em parte da equipe de desenvolvimento, identificar a solução mais adequada para usos específicos . História, por exemplo, os valores baixos, então eu não vou gastar tanto tempo nele como um dos cartões de valor mais alto 16. Vamos planejar nosso sprint: Então agora vamos pegar nossos pontos da história e tê-los em uma escala de valor. Então escalas de valor que eu chamo é chamado de pontos de loja no acesso e o valor de negócios no outro eixo. Agora, se olharmos para a escala de valor, vamos usar níveis de Fibonacci de 1 a 21 de valor comercial e de 1 a 21 em pontos de história . Sei que 21 parece alto, mas eles estão comigo. É só para dar a vocês um bom alcance. Um exemplo de como essas coisas funcionam novamente. Essas histórias não refletem a realidade. Podem ser uns ou dois. Mas eu só quero fazer uma boa propagação para todos para que você possa entender a largura de tudo. Agora olhamos para o primeiro cartão. Ah, como usuário, eu quero ver uma notificação sempre que um novo produto entrar na loja. Então, digamos que minha equipe tenha estimado este teste para ser um 21 e este teste para ser um três em valor comercial, então vamos adicionar toda a lista que estamos vendo como um comprador. Eu quero fazer o check-out para que eu possa obter meus produtos enviados para mim. Estavam olhando para um ponto de oito e história. Então estamos olhando para 13 o valor de negócios como um comprador. Quero revisar meu carrinho para poder fazer ajustes antes de fazer o check-in. Então, olhando para este, estamos colocando como um 13 um ponto de história, colocando como, ah, 21 sobre valor comercial porque super importante ser capaz de verificar como um usuário, eu quero fazer uma lista de produtos para que eu possa selecionar alguns para comprar, Obviamente muito importante para uma loja de comércio e. Isso é tudo o 21 e estamos olhando. Um três nos pontos da história estavam dizendo, Isso vai ser fácil agora. Assim que tivermos todos os nossos pontos de história e os nossos pontos de valor , sabemos quanto tempo alguma coisa vai demorar e quão valioso é que o ponto é o exercício. Seguindo em frente. Esta é a nossa propagação, uh, como um problema de loja. Para revisar minha história CARRINHO 0.13 Negócios 0.21. Como usuário, eu queria sua lista de produtos como um seleto alguns para comprar ou 0.3 21. E assim por diante 8 13 21 3 outros próximos cartões seguintes. Agora sabemos o valor do nosso negócio. Sabemos que os pontos da nossa história. Isso é ótimo. Mas também temos algo chamado “Bang for the Buck”. Então, por exemplo, como um comprador, eu quero verificar para obter para que eu possa obter meus produtos enviados para mim. O que fazemos aqui para determinar o banco do livro sobre por que o fazemos é determinar a granularidade real deste ponto. Isso é para que possamos priorizar melhor e mais fácil. Então o que fazemos é pegar o ponto de negócios e dividimos pelo ponto da história. E foi assim que ele voltou para o livro. Então, se olharmos para esta mesa aqui como uma loja ao redor com os checkouts, eu recebo meus produtos enviados para mim como valores comerciais. 13 pontos de loja. Oito estrondo pelo dólar é 1,625 Agora, se você olhar para esta lista, hum, quando sequenciamos isso, você verá que a última história aqui tem sete. As primeiras histórias 1.625 Então estes estão estreitamente alinhados. Então, esses são os que deveríamos estar olhando agora em termos de federação. Nós ainda temos que fazer qualquer trabalho, então nós simplesmente não sabemos ou velocidade a partir de agora. Mas vamos adicionar essas coisas à Federação 1 e ver o que podemos entregar. Então, digamos que duas semanas depois, conseguimos entregar 34 pontos de valor de negócios, 11 pornografia de história e bang para o dólar, 8.625 Então nossa velocidade para futuros sprints será 11. 17. Como funciona um gráfico de Burndowns?: Então, se olharmos para este gráfico de queimaduras que temos aqui, podemos ver que o Sprint foi queimado. Contém 87 a 64 56 48 40 32 24 16 e zero. Foi a última vez que queimou. Então nosso sprint durante o azul de Bernanke vai para 10 dias. Você pode ver em 80 pontos de história. Essa é a nossa linha de sprint. É o eixo X. Então, por que o acesso contém a história? Point disse que 80 estavam queimando de 80. Agora vamos dar uma olhada na velocidade real. Começamos com 80. Obviamente, é por onde começamos. Você queimou cinco na segunda corrida na segunda semana 70 na terceira semana, 58 na quarta semana, quinta semana. Vamos um pouco mais baixo. Vamos 43 seis semanas. Queimamos um pouco menos. Demorou um pouco mais de tempo. Então 36 sete nós olhamos para Ah, 30 indo para oito. Vamos olhar para o número. Digamos 20 número nove. Vamos olhar para 18 número 10 olhar para zero Então nós realmente conseguimos completar este sprint, mas você vê estes sobre unders que nós temos assim na primavera dois e três, nós passamos sobre a capacidade estimada. Então isso significa que eu então consegui resolver 72 que era o nosso objetivo. O único homem que eu deveria resolver cinco em vez de oito. Agora, isso significa que eles devem ter algo acontecendo. Talvez tenhamos superestimado comigo. Subestimamos a tarefa. Precisamos dar uma olhada em como estimamos isso. Sempre que o leão vermelho está acima do azul, isso significa que estamos atrasados no cronograma planejado. Se estamos abaixo da linha azul, significa que estamos à frente do cronograma planejado. Você vê isso acontecendo produtos o tempo todo. Às vezes você está acima, às vezes, seu baixo. Mas seu objetivo com este gráfico é atingir o ponto zero que seu sprint queimou está lhe dizendo. Algumas pessoas dizem que você tem que bater 80% e tudo bem. Mas de um modo geral, se você cometer um backlog que tem 80 pontos de história e você se compromete com isso, você deve resolver esses 80 pontos de história 18. Vamos analisar o Kanban: As equipes da Chemin geralmente centralizaram o trabalho em torno do acampamento a bordo. Isto, também, era um quadro branco de parede ou qualquer coisa em que você possa colocar notas pegajosas. Eles podem ser virtuais ou físicos, mas eles são ambos um recurso crucial e visualizar e rastrear a quantidade de trabalho em andamento sendo feito. Com isso sendo dito, todos os bloqueadores independência, Cesaire imediatamente identificado, bem como resultados. Se olharmos para um Camembert básico como o abaixo, veremos que segue três colunas para fazer em andamento. E, uh, há, no entanto, mais quadro de detalhes com itens como visualização codificadora ou chicote. Agora, o objetivo principal de apresentar cartões de trabalhadores é que toda a sua equipe seja capaz acompanhar qualquer trabalho de propósito de forma visual. Os cartões do contém informações críticas, bem como o trabalho que envolve na criação e resolução do problema de barra de tarefas, bem como uma estimativa de quanto tempo esse item de trabalho levará para ser concluído. Lembre-se que a estimativa que fizemos não muda. Ainda usamos pontos da história. Cambon também permite uma grande flexibilidade de planejamento como um produto de quando veio livremente, adicionar tarefas ou remover tarefas dentro do backlog de trabalho, contanto que ainda caímos. Os valores de negócios foram identificados na seção anterior. Ainda temos a certeza de que estamos a maximizar o valor para os nossos clientes. Isso significa que geralmente não olhamos para a duração fixa. Que sprints. Preferimos olhar para os ciclos. O prazo de entrega é um tempo a partir do momento em que o pedido foi feito por um cliente e colocado no dedo do pé da prancha. Todo o trabalho neste item é concluído e a solicitação foi entregue ao cliente. Então é um tempo total. O cliente está aguardando que o item seja entregue. O tempo de ciclo é a quantidade de tempo que a equipe passou realmente trabalhando neste item sem o tempo que o teste passou esperando na placa. Portanto, o tempo do ciclo deve começar a ser medido quando a tarefa do item entrar. Um trabalho chamou-o não antes, como tudo o resto no meu trabalho, seus princípios e valores para aderir. Então Cambon é um todo nove deles que vamos explorar os detalhes abaixo. Comece com o que sabe. Então chemin existe por conta própria, mas não é mutuamente exclusiva de outros fluxos de trabalho. Você pode coexistir pacificamente e trazer questões à luz. Não requer mudanças radicais apenas para melhor auto-organização. Você pode muito bem executar um projeto scrum em um acampamento e esperar concordar em buscar mudança evolutiva incremental . Cam Band é uma abordagem que permite a mudança e gestão de mudanças sem significado. resistência organizacional não canibaliza as estruturas internas e introduz uma forma visualizar o trabalho organizado. Respeitar o processo atual, papéis e responsabilidades. Uma crosta encoraja mudanças incrementais. Continua a não incutir medo que era semelhante ao progresso e à determinação. Ele permite um amplo suporte organizacional e pequenas correções de cursos que economizam projetos para grandes processos. Incentivar atos de liderança. Você não precisa ser líderes ou diretores mágicos para implementar essa mudança. A liderança vem das próprias equipes. Lembra quando falamos sobre equipes auto-organizadoras? Esse é um dos princípios que isso sustenta. Visualize o fluxo de trabalho. A maneira mais comum de visualizar seu trabalho é usar cartões e paredes. Cada coluna representa etapas nesse fluxo de trabalho, mas, o mais importante, progresso no trabalho de valor em andamento significa que você tem uma retrospectiva e que as coisas mudaram de para fazer. Os elementos críticos são que o trabalho em andamento que cada estado no fluxo de trabalho é limitado e que o novo trabalho é puxado para a próxima etapa quando há capacidade disponível dentro do local iria explodi-lo. Essas restrições irão iluminar rapidamente áreas problemáticas em seus fluxos. Você pode identificá-los e resolvê-los vivendo, que é uma pedra angular de Campbell gerenciado flutuar O ponto inteiro. Introduzindo Cambon na organização é para crescer uma mudança positiva de sinal. Visualize é como os valores que fluem através do sistema. A jornada em si é uma repetição de ciclos. Tornar processos políticas exemplo explícito de uma política que vem muito explícita em seu projeto é olhar para a definição de pato. Na verdade, ele pode ser criado para cada fluxo de trabalho, significa que os itens anteriores podem ser puxados para o seu ciclo. Ele precisa atender a certos critérios, como critérios de aceitação. Quando as equipes estavam alinhadas com o modelo preferido de responsabilidades de trabalho, riscos de rolagem, eles são mais propensos a construir uma compreensão compartilhada dos problemas e sugerir melhorias. 19. Artifacts de Scrum: artefatos de tempestade fornecem informações importantes que a equipe scrum e suas partes interessadas precisam ser raras durante o desenvolvimento do produto. Estas atividades que estão sendo planejadas, as atividades que estão sendo feitas no projeto nos seguintes artefatos são desafiadores e quadro de processo scrum . A visão do produto é um artefato para definir uma meta de longo prazo do produto ou produto, Ele diz. A direção geral e caras isso de T todos devem ser capazes de memorizar uma visão de produto . Portanto, deve ser muito curto e preciso. A lista de pendências do produto é mantida pelo seu gerente de produto ou proprietário do produto. É uma lista que nunca se move de recursos, melhorias, correções e atos como base para o seu backlog de sprint. Esta é a lista atual do futuro para fazer da sua equipe e é o assunto de re priorização. A lista de backlog da Sprint é uma lista de itens que você concordou com um gerente de produto proprietário para completar dentro de um determinado período de tempo, geralmente dentro de um sprint de duas semanas. Durante a sessão de planejamento de primavera, sua equipe para obter o com o gerente de produto ou transferir um conjunto de tarefas do backlog do produto para o spring back. Seu objetivo de sprint é o valor em um produto final utilizável que se formou no final do sprint. Durante a sua avaliação final da Sprint, a equipe mostra o que conseguiu, seja uma jornada. A terminologia para isso também está fazendo sua definição de feito. Essa definição precisa aderir aos valores que foram pré-planejados com um gerente de produto ou proprietário antes de iniciar o projeto. Agora chegamos à definição de feito. Cada item de backlog do produto tem critérios de aceitação que definem mensuravelmente o que deve ser atendido quando o item é declarado para ser feito. Muitos critérios aplicados a todos ou muitos produtos por quatro itens em vez de definir repetidamente esses critérios com cada item é provado ser útil para coletar esses critérios em um só lugar . A definição de feito. Assim, a definição de feito é uma compreensão compartilhada do adolescente esfregando sobre o significado do trabalho a ser completo e terminado. Ele geralmente contém critérios de qualidade, restrições e requisitos gerais não funcionais. Alguns exemplos são a definição de feito revisado por alguém ou uma determinada parte interessada. Conclusão dos testes de garantia de qualidade todas as questões seis. Conclusão de toda a documentação relacionada à história. Agora chegamos aos incrementos. O incremento é a soma de todo o produto de volta olhar, Eu estava concluída durante um sprint e todos os sprints anteriores no final do sprint. O novo na corrente deve ser feito, o que significa que ele deve atender a definição de equipes de matança de Doug. Ele deve estar em uma condição utilizável, independentemente de o proprietário do produto decidir realmente liberá-lo. Queimar gráficos. Esta é uma das coisas mais importantes que quero que você passe. Os gráficos de carga são uma ótima maneira de medir o valor que sua equipe está colocando para fora também quanto esforço e se eles estão sendo eficientes. Então Bruno gráficos ou gráficos, eles dão uma visão geral do progresso que sua equipe é feito como imposto. Como concluído, o enxerto queima até zero. Ele é usado como uma ferramenta e um guia durante o desenvolvimento para levar uma equipe à conclusão bem-sucedida de um sprint a tempo. Atualizado todos os dias, ele dá uma boa visão geral da promessa Sprint. Os gráficos de queima são úteis porque fornecem informações sobre como a equipe trabalha. Por exemplo, se você notar que a equipe termina consistentemente o trabalho mais cedo, isso pode ser um sinal de que eles não estão se comprometendo com o trabalho suficiente durante o planejamento da primavera. Se eles constantemente perderam sua previsão, isso pode ser um sinal de que eles cometeram muito trabalho no dedo do pé. Se o gráfico de burnout mostrar uma queda acentuada durante o sprint, isso pode ser um sinal de que o trabalho não foi estimado com precisão ou quebrado corretamente. Este relatório mostra a quantidade de trabalho a ser feito no Sprint. 20. Ceremonies de Scrum: scrum diário foi chamado Stand up Meeting é uma reunião diária. Como diz o título, cabe aos membros da equipe atualizar o grupo inteiro sobre seu progresso mais recente. Esta reunião de grupo em um mundo de desenvolvimento ágil é cada membro da equipe. Responda a três perguntas separadas. O que você fez desde a última reunião? que está trabalhando até a próxima reunião? O que está atrapalhando ou impedindo você de fazer seu trabalho? Isso diz à equipe exatamente o que está sendo feito. O que precisa melhorar essa coisa. Quaisquer problemas ou problemas que possam ter é crucial para que sua equipe saiba para ajudá-lo . E pequenos problemas devem ser sempre abordados que eles não se transformam em grandes problemas. Um bom truque também é ter sua ferramenta de gerenciamento de projetos visível. Isso pode ser na forma de uma câmera física a bordo ou software como Sprint. Se eu giri a, que são baixos, é importante para uma equipe para ver o que está sendo terminado no que está levando mais tempo do que esperado. Isso é especialmente útil para equipes que gastam muito tempo respondendo a perguntas importantes, também colocando todos no hábito de revisar o registro da ferramenta de gerenciamento de projetos para a reunião resulta em um grande aumento de eficiência. E o esforço colaborativo? Então, um dos erros de reunião scrum mais comuns é fazer um termo baseado em um cara do gerente de projeto ou mestre scrum. Isso derrota completamente o propósito do stand up e deve ser evitável. Evitado a todo custo. Este é um tempo valioso que deve ser tratado como esforço colaborativo para toda a equipe. Uma boa maneira de manter as reuniões de rolagem eficientes é estabelecer uma regra simples. Tudo o que disser deve ser valioso para todos na sala. Conversas individuais podem acontecer a qualquer hora do dia. Além da reunião padrão. Além disso, planeje a reunião em torno de sua equipe. Percebemos que, no mundo real, é impossível aderir a um cronograma rigoroso, mas é importante desenvolver algum tipo de rotina para suas reuniões permanentes. Sem uma rotina, procrastinação entrará em vigor. A mídia nunca vai acontecer. A segunda cerimônia discutirá o planejamento da primavera. Então, esta reunião de sala acontece no início de um novo sprint e foi projetada para o proprietário do produto e a equipe de desenvolvimento para atender e analisar o backlog priorizado do produto para uma série de discussões que as negociações a equipe deve finalmente criar um Sprint backlog . Isto contém todos os itens do ar comprometendo-se a completar no final do sprint. Isso é chamado de Sprint Gold, então Sprinkle deve ser um incremento de ervas de navio, que significa que pode ser demonstrado no final de um sprint. Ele precisa ser acordado por toda a equipe, modo que os proprietários de produtos responsáveis por eu estou no produto de volta já para revisão antes de jogar primavera começa. Então, quem está no atendimento? Então a equipe scrum, a equipe de desenvolvimento do proprietário do produto, todos eles que formaram a equipe scrum descrevem Mestre no final lá. Então, quanto tempo dura essa coisa? O comprimento da maioria das cerimônias de scrums é realmente o comprimento do sprint. Em termos de planejamento Sprint, ele deve durar duas vezes o comprimento do sprint. Por exemplo, se o seu sprint tiver duas semanas de duração, esta cerimônia de reprodução de impressão não deve durar mais do que quatro horas quando o sprint da semana não deve durar mais do que duas horas. Agora, isso soa como uma enorme perda de tempo calculando tempo assim. Mas se você se sentar na reunião de pergaminho e pode levar mais de duas horas. Você pode chamá-lo porque nada mais importante vai sair disso. Então vamos falar sobre entrevistas de strip spread. A preparação para uma reunião ágil do Sprint Review não deve demorar mais do que alguns minutos no máximo. Então Sprint Review concentra-se em demonstrar o que a equipe de desenvolvimento é feito. Sabendo que terminou usando histórias e estar pronto para demonstrar essas histórias, Funcionalidade prepara você para começar com confiança a reunião Sprint Review. preparação para o espírito de sua reunião envolve o proprietário do produto e a equipe de desenvolvimento . O proprietário da peça precisa saber que usa histórias de equipe de desenvolvimento concluída durante a equipe de desenvolvimento Sprint. Precisa estar pronto para demonstrar a nave concluída. Funcionalidade completa para uma equipe de desenvolvimento para demonstrar o produto no Sprint Review, ele deve ser completo de acordo com a definição de feito Então precisa ser desenvolvido, testado, documento integrado que se essa é a sua definição feita como histórias de usuários de concluída em toda a Sprint, o proprietário do produto e equipe de desenvolvimento deve verificar se o produto atende aos padrões. Esta validação contínua ao longo do sprint reduz e os riscos de sprint e ajuda este tempo equipes de depuração a gastar o menor tempo possível se preparando para a revisão da primavera . Tenho algumas dicas para fazer uma avaliação da Sprint. Então Sprint Review geralmente ocorre mais tarde no dia no último dia da Sprint, muitas vezes de sexta-feira. Uma das regras dos scrums para não passar mais de uma hora na reunião Sprint Review para cada semana das diretrizes de Sprint para sua avaliação do Espírito. Conhecendo nossos amigos, não há ponto de poder. Slides referiu-se ao backlog Sprint de você para exibir lista de histórias completamente de usuários. Toda a equipe scrum deve participar da reunião. Qualquer pessoa que estivesse interessada em reunião pode participar. Então, patrocinadores do Project Stakeholder , uh, ver Yokel teórico sendo esta uma revisão da Sprint, desde que eles adicionem e vejam valor. O proprietário do produto apresenta uma escola de lançamento, modo que o Sprinkle e os novos recursos incluídos. A equipe de desenvolvimento demonstra o que ele completou durante os sprints. Normalmente, a equipe de desenvolvimento apresenta novos recursos ou arquitetura. A demonstração deve estar no equipamento o mais próximo possível para planejar apartamento de produção , por exemplo, você para criar um aplicativo móvel, apresentar os recursos no smartphone, talvez viciado até o monitor em vez de um laptop, e as partes interessadas das liberdades questionam e fornecem feedback sobre o produto demonstrado. Nenhuma funcionalidade manipulada não divulgada, como valores de núcleo rígido de outros atalhos de programação para tornar o aplicativo mais maduro do que é atualmente. Então sempre mostre a coisa real. O pro gona pode liderar uma discussão sobre o que está por vir, com base nos recursos que acabam de apresentar. Um novo item foi adicionado ao backlog do produto durante o sprint atual, e eu apenas retrospectiva é uma reunião que é realizada no final de cada geração de desenvolvimento de software ágil . Durante uma retrospectiva, a equipe reflete sobre o que aconteceu na federação e identifica ações para melhorias no futuro. Cada membro da equipe responde às seguintes perguntas. O que funcionou bem para nós? O que não funcionou bem para nós, mas ações podemos tomar para melhorar nosso processo. Indo em frente. Sim, John retrospectivo. Me dê um pensamento como, ah, lições aprendidas. Reunir a equipe reflete sobre como tudo correu e, em seguida, decide quais mudanças eles querem torná-lo uma equipe retrospectiva de próxima geração orientada e os membros da equipe devem decidir juntos como as reuniões serão realizadas agora. Decisões que tomamos sobre melhorias 21. Papéis de equipe: no artigo original de Harvard Business Review que inspirou o Creation Scrum, o jogo de desenvolvimento de novos produtos. Dois professores observaram que grandes equipes eram uma transcendente. Você tem um senso de propósito além do comum, então esse objetivo auto-realizado permite que ele vá além do comum, para o extraordinário de uma maneira muito real. A própria decisão de não ser mediana, mas de ser grande muda a forma como nos vemos sobre o que eles são capazes de fazer. Equipes autônomas também auto-organizadoras, auto-gerenciadas, eles têm o poder de tomar suas próprias decisões sobre como eles fazem seus trabalhos e nosso império . Para tomar essas decisões ficar entre equipes funcionais de todas as habilidades necessárias para concluir projetos são planejamento de design, produção, vendas, distribuição. Essas habilidades se alimentam e se reforçam mutuamente, diz que um membro da equipe que projetou uma nova câmera revolucionária para Kennan descreveu. Quando todos os membros da equipe estão localizados em uma sala grande, informação de alguém se torna sua sem sequer tentar. Você então começa a pensar em termos do que é melhor ou segundo melhor para o grupo em geral, e não apenas onde você fica. Assim, as pessoas às vezes lutavam com a idéia de transcendência na transcendência podem ser descritas como um espírito de equipe. O primeiro da equipe assistiu a um vídeo no início de cada reunião diária de museus. Todos os negros equipe de Rugby. A energia dessa equipe está unida no propósito. O primeiro da equipe queria capturar esse espírito foi a determinação de esmagar qualquer espírito impedimento para celebrar cada sucesso na vitória dourada que é a transcendência da equipe , seja em uma equipe esportiva ou entrega de grandes produtos ou serviços. Os gerentes de produto trabalham em estreita colaboração com o desenvolvimento. Imagine a direção do produto com base em insights ou pesquisa. Comentários dos clientes, tema de pesquisa de mercado. Gerentes de produtos ágeis. Ouro é trabalhar com os clientes e a liderança da empresa para definir a direção do produto. O gerente de produto é responsável por representar a verdadeira voz do cliente. A melhor maneira de entender completamente os problemas dos clientes é conversar com os clientes. Visite seus sites, experimentou seu dia a dia de negócios e outras coisas. Ao fazer isso, gerente de produto vai ganhar visão em primeira mão. O cliente luta e será capaz de encontrar recursos e funcionalidades. Alivie os pontos problemáticos sem clientes diretos de indirecionamento de campo. Isso é impossível de entender completamente que o cliente tem dificuldades e necessidades também é um proprietário do produto em um ambiente ágil e esse proprietário do produto trabalha com a equipe de desenvolvimento para esclarecer histórias de usuários, visão do produto e especificações gerenciar pendências de maximizar o valor dos produtos para os negócios . Proprietário da faculdade comunica as intenções de negócios às equipes de desenvolvimento que eles têm uma compreensão clara de por que eles estão sendo convidados a fazer o que eles fazem. Eles são capazes de ver o quadro completo, entender as necessidades do negócio e do cliente, comunicando-se com temas de negócios para alinhar as atividades técnicas, a fim de oferecer exceção exponencial aos proprietários de produtos tipicamente têm ah compreensão básica de desenvolvimento de software, seus comunicadores eficazes e entender que precisamos resolver os problemas do cliente . É comum que os proprietários de produtos mantenham posições de analistas de negócios antes de se tornarem seu produto. Agora, o mestre scrum está no núcleo de toda a equipe scrum, então os mestres de esfoliação são os facilitadores extras pesos leves, quadro ágil com foco em orações de boxe tempo chamados sprints como facilitadores, atores de scrum mestre treinadores para o resto dos líderes do servo da equipe, como este de Deus o chama de ar bom scrum Mestre comprometido com isso desde a fundação e os valores permanecem flexíveis e abre oportunidades para a equipe para a cicatriz de fluxo de trabalho. Os mestres realizam algumas tarefas. Assim, eles realizam stand dups, reuniões de planejamento de sprint, revisões de sprint e retrospectivas de consultoria interna de um dos seus conselhos, administração e bloqueadores de relatórios. Assim, o papel de mestres de pontuação também é proteger o próprio processo scrum. Este mestre do crime é o especialista de casa de obras e como ele deve ser aplicado. Ele ou ela irá garantir que o proprietário do produto e equipe de desenvolvimento ficar dentro deste quadro Por extensão é de Master. King treinou todos os membros da equipe sobre como usar da maneira mais eficaz. Agora, este é um papel muito diferente do de um gerente de projeto tradicional, apesar de comparações freqüentes sendo feitas entre dois. Assim, os gerentes de projeto são responsáveis por gerenciar o trabalho fora dos membros da equipe do projeto e que orienta seu próprio dia hoje. Trabalhe com o mestre scrum. No entanto, a única responsabilidade formal é sobre o processo. Então vamos dar uma olhada. Uma equipe de desenvolvimento olhando para o scrum, responsabilidade mestre, não ter a responsabilidade de hoje, mas quem tem responsabilidade e é aí que a equipe de desenvolvimento entra. Assim, um script típico consiste de 5 a 9 pessoas e geralmente inclui as funções funcionais típicas foram separados projeto da empresa. Este desenvolvimento oferta. Por exemplo, isso significa testadores, desenvolvedores e designers do arquiteto . Mas esses títulos são apenas relevantes para estabelecer a experiência de cada indivíduo. Agora, a equipe age coletivamente para determinar como alcançar seus objetivos. As características específicas em que trabalham são determinadas pela prioridade estabelecida pelo proprietário do produto. A maneira como eles funcionam é guiada pelo processo scrum como monitorado por este mestre firme. Tudo o resto depende da equipe para gerenciar, com scrum master fornecendo tanto quanto necessário para permitir que isso aconteça. Por exemplo, cada membro da equipe pode pegar um recurso de um backlog priorizado do produto e, em seguida, decidir individualmente como executar esse trabalho. Este nível de autonomia é uma pedra angular foi de e incentiva fortes laços entre os membros da equipe e ajuda a criar um ambiente de trabalho positivo, enquanto a idéia de equipe AH existe na água para projetos também. Nesse ambiente, uma equipe é gerenciada funcionalmente pelo gerente de projeto de produto em vez de ser autogerenciada autogerenciada 22. O backlog de produtos: o backlog do produto é ligeiramente diferente do Sprint backlog. Aziz, o último é desenhado a partir do 1º 1 Sabemos agora que a forma como organizamos o scrum de trabalho é sprints e as geralmente últimas duas semanas e antes que alguém se dirija a qualquer um deles, há uma necessidade de criar esse backlog spin. É um conjunto de tarefas que visa atingir o objetivo da Sprint. Assim diz que o Sprint backlog é desenhado a partir do backlog do produto. O Prada volta A lista todos os recursos, funcionalidades e pesquisa que suporta o produto. O proprietário do produto é geralmente encarregado de cuidar desse problema backlog. Há mais alguma coisa no contrato ágil e scrum por valores com o maior valor precisa ser trabalhado primeiro com base no valor do negócio precisa de pesquisa em tendências de tecnologia em breve terrível compra no mercado. Um backlog tem organizado de que forma garante que o nosso trabalho e fornecer o máximo valor para organização. E como você pode ver, ele precisa ser constantemente atualizado para gerenciar. Esse processo é chamado de preparação de backlog. Sem atualizar o backlog, ele pode ficar bastante obsoleto e não permanecer atualizado para um roteiro muito longo que você está construindo deve conter metas de longo prazo para vários lançamentos. No futuro distante, no entanto, entanto, o livro de retorno do produto deve se concentrar no trabalho de listagem para a próxima versão com mais detalhes. Usando planejamento de ondas rolantes. Nós garantimos que os sprints imediatos são abordados em É possível e os mais distantes irão substituir mais baixo e detalhes surgirão à medida que você se funde em direção a um objetivo específico. Produtos que você cria, digamos, certo, compartilhando cujo propósito final é ridesharing também introduz uma carteiras toda noite precisa para suas costas. Agora, o benefício de usar um único backlog um substancial. Se o seu produto é enorme, digamos que um sistema operacional que poderíamos olhar para criar várias pendências. Não queremos hierarquia e importância mais tempo de almoço que conflitem um com o outro . Vamos falar sobre usos para épicos recentes. Agora isso é algo que abordamos anteriormente no curso, mas épicos é um novo, então vamos passar por isso. Já passamos por histórias de usos antes deste livro, mas apenas eles colocam ênfase nelas. Eles são as tarefas que você precisa para completar do ponto de vista do usuário, e estas são as histórias que você estava fora Suas histórias Sprint são geralmente muito grandes são chamados épicos, e eles poderiam levar vários sprints para realizar os épicos do geralmente histórias que contêm várias histórias. Pode ser 2050 100. Número varia Essas histórias de usuários, no entanto, precisam ser derivadas do épico. Para que o sprint comece, não se pode trabalhar fora da rede assim. Então vamos dar uma olhada. No exemplo aqui Way tem, como um grande site de viagens, Eu quero o sistema. Eles podem determinar os preços mais baixos, dependendo de variáveis como nas estações, para que meus visitantes no site possam receber os melhores preços agora. Esta é, obviamente, uma tarefa enorme, então precisa ser dividida em pequenas histórias de usos. Por exemplo, como um grande site de viagens, quero definir a tarifa ideal para voos com base em quais voos comparativamente estão cobrando novamente. Usando o planejamento de ondas rolantes, definimos as histórias de maior valor na cadeia, mas eles também precisam incluir a maioria dos detalhes. Então, é como uma escavação um pouco mais profunda nisso e ver se podemos realmente aprofundar o que a história dos usuários deve conter. Vamos olhar para o uso da história chegando aqui como um grande site de viagens, eu quero definir a taxa ideal para voos com base em quais voos comparavelmente estão cobrando. Algumas coisas que quero ter em mente aqui é que a função deve verificar as tarifas para todos os aeroportos dentro de 100 quilômetros. A função deve me dar a capacidade de classificar as tarifas por distância, a função. Ela me deu opções para classificar o preço e a função. Ela me deu a opção de classificar os aeroportos como partida e chegada. Então você vê como quando é um detalhe maior aqui e eu acrescentaria mais valor à história. Mais esclarecimentos para a história para que às vezes nos voltamos para diferentes histórias que não são necessárias, acrescenta histórias de usuários. Isso incluiria trabalho no back-end ou outras tarefas que não são realmente significados usuários, por exemplo, painéis de administração internos ou painéis de au que precisamos para mantê-lo. Eu deveria moderar os olhos KP. Estes testes são importantes para distinguir porque eles usam algo chamado de desenvolvimento orientado a recurso F duplo segredos profundos. Isso é muito simples, então você sempre tem uma ação, tem um resultado, e você tem o objeto. Então, por exemplo, se estamos olhando para uma longa sequência regular, vamos olhar para ela assim. Valida mais senha e usuário. Estes são os seus únicos quatro itens que lidamos com em nossas pendências scrum no produto Sprint Press . Possui bugs, trabalho técnico e aquisição de conhecimento. Então estes são realmente os únicos quatro que precisamos para ter o nosso atraso. Só há categorias. Uma boa maneira de começar a construir o backlog do seu produto é jogar todas as suas ideias na parede e ver quais carregam mais valor. Desde que tenhas histórias suficientes para o teu sprint, estás bem. Mantenha-o simples e dividi-lo novamente como por valor. A seguir, vamos ver como priorizar o seu produto. Lifelock. 23. Priorização: Agora que sabemos o que precisamos incluir em um backlog, como priorizamos, vamos dar uma olhada em como construímos e trabalhamos com um backlog de produto. Então, para fazer isso, vamos passar por uma lista completa para garantir que vamos abordar todas as áreas que temos. Você, como proprietário do produto, é o único responsável pelo retorno do produto. Você está encarregado de mantê-lo com todos os seus recursos de pesquisa e planejamento. Com base na visão do roteiro da organização. Product backlog é uma lista completa de todos os usuários histórias itens de trabalho para o seu produto. No entanto, você sempre pode atualizá-lo com requisitos mais variáveis e que mais insights à medida que você avança , você precisa ser um específico quanto possível. Com impressões e objetivos mais próximos, distantes podem estar envoltos em mistério. Por agora. Sempre use o usuário como um ponto de vista. Inclua correções de bugs, troca de conhecimento e outros trabalhos técnicos internos, como mencionamos antes de histórias FDD . Você classifica o valor em prioridade de todas essas histórias de usuários. Sua pesquisa e o insight específico sobre os desejos e necessidades do cliente impulsionam o produto de volta. Você não precisa olhar para uma estimativa agora nesta sessão de planejamento de impressão e acompanhar sua equipe irá ajudá-lo a fazer isso. Precisa classificar a lista de pendências do produto. O registo de pendências do produto é uma lista constante de alterações e adaptações. No entanto, seu sprint não deve mudar. Então, o backlog da Sprint é acordado e Onley desbloqueado quando a definição de doadores finalmente está sendo cumprida, você sempre pode adicionar para trabalhar no estande, então vamos dar uma olhada em como priorizamos este produto backlog aqui. Como um comprador, eu quero ver uma lista de produtos para que eu possa selecionar alguns para comprar, Obviamente Value 21 Prioridade o quê? Como um comprador, eu quero rever meus cartões que eu posso fazer ajustes antes de check-out 21 2 Como um usuário, eu quero check-out para que eu possa obter o meu provavelmente enviado para mim 13 e três. Como cliente, quero revisar meu pedido. Segundo, ver o que comprei no passado. Isso é um 84 Now. A maneira como olhamos para o processo de refinamento de backlog é o que chamamos de Acrônimo Profundo . Os stents foram detalhados adequadamente para que os itens no topo da lista tenham mais detalhes do que aqueles na parte inferior. Lembre-se, isso é o que chamamos de planejamento da onda governante, onde os requisitos imediatos da escola são muito conhecidos. Mas o longe uma vez vamos falar seis meses por ano abaixo da linha que não sabemos muito sobre uma vez que continuamos rolando. Uma vez que avançamos com um projeto, descobrimos mais, mais, mais, e que mais tarde não está mais envolto em mistério. Ele precisa ser estimada cada atraso de produto liberado. Os envolvidos na próxima versão devem ser estimados por relatórios ou tempo da loja. À medida que sua equipe obtém mais trabalho sob seu cinto, sua velocidade, a taxa na qual ele termina o item de seu backlog do produto se tornará mais clara e tornará a estimativa mais fácil. Emergente. Isso significa que uma lista de pendências do produto é adaptada a novos itens ou informações que surgem priorizadas . Todos os itens na lista de pendências do produto são encomendados com os mais importantes no topo. 24. Visão de produtos: trabalhando no produto sem uma visão recente do produto se assemelha a ir para a rua com os olhos fechados. Então, avançar um produto ou direção de vida ajuda a manter as coisas em andamento e torna as ações significativas. Por outro lado, o líder tem a responsabilidade de liderar e orientar isso também. Pios e gerentes precisam manter planos de negócios e confiança dos clientes em mente enquanto motivam todos a trabalhar em direção a um objetivo comum. Mas sem direção, uma equipe não pode pensar, e é sobre isso que vamos falar na visão do produto e como a direção ajuda as equipes a avançar com uma agenda com um mantra. Então, quando discutimos visão, temos em mente um plano de longo prazo para o produto. Estes são planos que estão longe, e eles ainda estão para se materializar. Estes são objetivos distantes, mas, no entanto, provam suas ambições de negócios. E o aspecto futuro da visão de resolução de problemas é geralmente de 2 a 5 anos ou até mais dependendo do produto que você está fabricando para qual indústria. Então, o que? Isso não é um monte de bobagens sem impacto imediato? Na verdade, não. Quero dizer, usar uma equipe de visão pode definir o ELA público ou ter uma estratégia sobre como chegar nas escolas , estratégias de dispositivos e táticas e dividi-los dentro do seu mapa do mundo do produto que discutimos anteriormente. Vamos dar uma olhada na declaração de visão do Google porque eu acho que esta é uma ótima. Foi Visão Statement é organizar as informações do mundo e tornar universal de uma universidade acessível, útil, modo a olhar para ele de uma forma muito fácil, você é um guia turístico e você está caminhando através MT. Você tem seu grupo de guia com você e você sabe o caminho que você está tomando direção, você está indo. Sua visão é levá-los para ver belas montanhas, cachoeiras e talvez até pegar um pouco de vida selvagem aqui. Então, sem essa visão, seu grupo de guia turístico será perdido em sua direção. Não saberia por que se inscreveram para a turnê para onde estão indo. Visão deve ser uma base que as decisões do cara e ajuda a priorizar características ou tarefas. Este elemento de recurso em ou contribui para o ouro? Se não, então você canaliza suas energias em atividades. A verdade Motivação também desempenha um papel importante aqui. Lembrou equipe que o tempo é que a direção para que eles entendam como seus papéis nas atividades diárias contribuem para o quadro maior. Isso os ajuda a se concentrar mais no trabalho que realmente faz a diferença em termos de desenvolvimento de produtos . A motivação também desempenha um papel importante aqui, lembrou equipe às vezes das direções, que eles entendam como seus papéis e atividades diárias contribuem para o quadro maior. A pedra-sabão se concentra mais no trabalho que realmente faz a diferença em termos de produto desenvolvido. Então, vamos explorar várias maneiras de criar uma visão de produto. Primeiro sente-se e com base em quais problemas ou dores os clientes enfrentam e como o produto os resolve. Ou a produção alcançou isso? Alguns podem achar óbvio que supõe mais desafios do que o esperado. Quem deve tomar o processo de parceiro? E a tarefa complexa criação Visão requer um monte de trabalho em equipe, Então o que você faz é convidar companheiros de equipe ou outras partes interessadas que podem contribuir para o quadro geral estão fornecendo conhecimento profissional, paixão ou habilidades visionárias. Qualquer um poderia realmente se juntar a desenvolvedores, designers , pesquisadores, negócios ou marketing As pessoas poderiam se encaixar aqui, mas certifique-se de liderar o fluxo de criação de empurrou uma equipe para chegar a um entendimento final Isso estava pensando. Olhe para as perguntas que você faz uma delas é Quem é o seu público-alvo? Quais necessidades do cliente? Os produtos podem satisfazer quais atributos do produto determina a satisfação dessas necessidades? Quem está competindo e como eles realizaram concorrentes externos internos? Que período de tempo e produto sobre um orçamento determinou o projeto, Então juntos em uma equipe de pessoas em mente, trabalho das declarações visionárias e liderar um workshop sobre o tema formado grupos menores onde as pessoas podem discutir alguns brainstorming perguntas diferentes. No final da primeira sessão, cada equipe deve apresentar uma lista de ideias ou respostas acordadas após cada equipe apresentar suas idéias. Ponha as ideias da votação. Então, para selecionar apenas as melhores idéias. Use métodos diferentes contra o pensamento abstrato das equipes utilizadas e sempre mantenha seu controle do progresso e faça com que todos se sintam envolvidos. Você também tem algumas outras perguntas que você faz. Poderíamos dar uma olhada na visão do produto Port Product Vision Board, feita por Roman. Imagem define de uma maneira diferente, então você tem uma visão que será preenchido mais tarde, mas você tem um grupo-alvo, então você define o público-alvo. Quem precisa do produto irá satisfazer olhar para as necessidades. O que esses clientes fazem? Que dores solucionáveis e desafios para o rosto. Olhe para os produtos que você define o produto, atributos genéricos ou futuros e contribuir para a felicidade do cliente. As escolas de negócios são muito importantes, então você precisa ter uma imagem clara de como o produto beneficiará a empresa e quais os objetivos e aspirações de negócios levaram à sua criação. Então, ao apontar para algo curto e cativante para a sua visão de produto, você pode usar o modelo de visão de produto de Geoffrey Moore, bem como o básico para minhas corridas da seguinte forma para o cliente Target que cliente que precisa ser resolvido. O produto. O nome é uma categoria de produto que beneficia o aquecimento, pontos de venda. Ao contrário do produto competitivo, nosso produto, quero dizer, diferença. Então, com esta ferramenta, pegamos essência na singularidade do produto. Enquanto eles estão encontrando os macacos, isso significa que isso pode funcionar bem em um ambiente ágil. Quando você começa a desenvolver também, uma visão não tem que se transformar em 20 Bíblia pintura ou um cartaz brilhante parede Bhutto fazer declarações convincentes ineficazes. Assim, o pai das visões, Roma Pickler, chama a visão ideal do produto clara, instável. Cada participante deve achar fácil de entender. Então evite frases vazias que não digam nada um caso e besteira ampla e envolvente. Então devemos retratar um quadro mais alto com o qual todos possam se relacionar e, em seguida, inspira as pessoas a dar o seu melhor para que isso aconteça. Encurtar. Esta semana ele precisa ir direto ao ponto adicional. Você o torna alcançável. Então, embora uma visão deva ser futurista, idéia do que o produto pode se tornar cínico, eles poderiam ser realmente atendidos. Perspicaz. Então você precisa criar a idéia com base nas necessidades e motivos dos usuários, e encontrar a principal razão por trás da existência de outros. Nike é visão e idéia de negócios é realmente muito, muito legal. Então, em uma chave, hum, nossa visão é criar uma vida cotidiana melhor para as muitas pessoas são negócios Idéia suporta essa visão oferecendo uma ampla gama de produtos de mobiliário doméstico bem projetados e funcionais a preços tão baixo que tantas pessoas quanto possível será capaz de pagá-los. Finalmente, você apresenta a visão do produto a todos os envolvidos. As partes interessadas do desenvolvimento devem saber a direção que estão indo, para que possam manter a confiança nas tarefas e decisões diárias. Compartilhe a visão de qualquer forma de apresentações, quadros , cartazes , reuniões individuais, etc. Você transmite a mensagem para que todos entendam que você pode se conectar a ela e ser honesto sobre ela. Incentivar perguntas e também apresentar casos de uso. Exemplos preocupantes são efeitos de visão, estratégias de negócios ou decisões de nível inferior. Fale o idioma do público de visões de produtos e mostre-lhes como eles podem contribuir para o melhoramento do produto. 25. Roteiro de produtos: produto. Os roteiros são uma importante ferramenta de gerenciamento de produtos, mas aplicá-los efetivamente pode ser um desafio. Os roteiros são muitas vezes focados em recursos, e os gerentes de produtos gastam muito tempo fazendo com que as partes interessadas concordem sobre um que recursos serão desenvolvidos. Um roteiro de produto é um plano estratégico de alto nível, que descreve como é provável que o produto se desenvolva e cresça nos próximos meses. Isso cria uma continuidade de propósito e ajuda seus gerentes de produtos e proprietários de produtos um coro financiamento para o projeto, partes interessadas da companhia aérea e também instalações privatização. Torna mais fácil coordenar o desenvolvimento emprodutos maiores e diferentes, produtos maiores e diferentes, além de proporcionar segurança aos clientes se o roteiro do produto for tornado público. Agora vamos dar uma olhada em quais são os roteiros de produtos que temos aqui? Vamos dar uma olhada neste gráfico, que o primeiro lançamento fora do mapa de estrada descrito acima contenha a data ou o período de tempo. Para os próximos lançamentos, você pode trabalhar com datas específicas, como primeiro de março ou um período como primeiro ou segundo trimestre. Eu acho datas particularmente valiosas mapas internos. Recusar um externo. Você pode querer remover a função ou usar o período de tempo solto, como nos primeiros 6 meses de 2014 a segunda linha indica o nome ou a versão dos lançamentos. Por exemplo, eu tinha sete anos ou saberia que Quinn ganhou. A terceira linha fornece uma meta específica do produto de cada versão principal para a versão do produto, o benefício comercial do usuário que deve fornecer ou o resultado que você deseja enganar. Objetivos de exemplo são adquirir ou ativar, usuários para reter usuários por mãos e experiência do usuário a bordo. Para acelerar o desenvolvimento, removendo a dívida técnica. Trabalhar com objetivos muda a conversa de debater recursos individuais para concordar com os benefícios desejados. Tomar decisões estratégicas sobre produtos em uma equipe de desenvolvimento, principais partes interessadas e o patrocinador da gestão devem todos comprar para os objetivos. Quatro. Jogue aqui fornece os recursos necessários para alcançar o objetivo. As características que Nossa marca significa acabar, mas não um fim em si mesmos. Eles serviram para criar valor e chegar a ir. Você pode pensar nos recursos como a saída necessária para criar o desejo de tentar viver no número de recursos para cada ouro para três. Mas não indique mais de cinco abster-se de detalhes nos recursos e se concentre nos recursos do produto. Eles são necessários para atingir o objetivo. Seu robô de produto deve ser um plano de alto nível, e os detalhes devem ser abordados no backlog do produto, incluindo épicos, e usar as histórias. 26. Gestão de liberação: proprietário do produto, como discutimos antes, é responsável pelo backlog do produto, mas também, em última análise, responsável pelo que você entregou aos clientes. Você precisa planejar isso e também criar uma estratégia sobre como liberar o que, quando e como. Vamos dar uma olhada em algumas coisas para ter em mente. Como mencionado por Robin Sherman de The Home um scrum que você precisa considerar o seu público para que seu público-alvo deve conduzir todas as decisões continua. entrega de valor é, obviamente, uma das pedras angulares em que o trabalho continua entregas tornando-se muito popular. E muitas pessoas querem ser capazes de fazer uma nova implantação de software praticamente a cada minuto. Claro, é muito útil poder liberar um pouco de esforço com o apertar de um botão. Se você realmente vai usá-lo ou não depende muito do contexto. Assim chamado de algum contexto, como o lançamento da Amazon várias vezes por minuto, parece ter muito valor em outro contexto de trabalhar em sistemas de folha de pagamento de RH, por exemplo, liberar por exemplo, uma vez por mês o suficiente. Pelo menos isso era antigamente. Número dois é criar um, liberável incorreto para Sprint. Então, em muitas organizações, as equipes estão trabalhando muito duro em muitas coisas diferentes no sprint. Isso geralmente resulta na equipe ter 100% do trabalho, 80% feito. Resumindo. Isso significa que muito trabalho foi feito e nenhum valor para os clientes. Os usuários foram entregues desde que não foi concluído. Feito assim ajudar a equipe de desenvolvimento oferecendo foco com um Sprinkle. Por exemplo, apoiar a equipe de desenvolvimento para entregar um incremento de produto feito o mais cedo possível no Sprint, o que é útil, já que você vai pelo menos acabar com um incremento que pode ser liberado se você quiser . número três é obter a propriedade do processo de lançamento ou, melhor disse, apoiar a equipe de desenvolvimento para obter a propriedade lá. Com esses processos e muitas organizações fazendo lançamentos para produção é algo que é de propriedade de um departamento como policial. Esses coordenadores. Quando a equipe de desenvolvimento não tem propriedade sobre o processo de lançamento, muitas vezes é mais difícil fazer o lançamento. Nada lhe custou como gerente de projeto ou gerente de produto um tempo valioso em geral, mas eu experimentei ser muito útil no passado é fornecer uma equipe de desenvolvimento com propriedade sobre o processo de lançamento. Isso é algo que nem você nem a equipe de desenvolvimento podem decidir por si mesmos. Então, o que você pode fazer como proprietário de um produto que você pode fazer é criar transparência sobre este tópico . Turness primitivo Por exemplo, quando seu bife foi perguntado, Como podemos nos tornar mais rápido? Como podemos oferecer mais valor? Em seguida, ajude-se a si mesmo e à equipa de desenvolvimento aumentando a conscientização sobre o processo lançamento, quando realmente só lançamos o trabalho que é feito em muitas organizações. Muitas equipes estão lançando desfeitas. O trabalho foi desfeito um trabalho que é liberado uma produção, mas que não é derivado para conformar a definição de feito. Isso cria dívida técnica, o que lhe custa muito tempo. Um monte de dinheiro para consertá-lo custaria seu valioso tempo. Mas você não gasta em oferecer valor para seus clientes e usuários para respeitar a definição de 27. Resolução de problemas - 5 Whys: Olá, todos. Então nesta aula vamos falar sobre o básico dos cinco sábios entendendo-os como trabalhar com eles e qual é a orientação dourada disso. Então, uma das muitas razões pelas quais ter cinco fios é tão popular como uma causa raiz e técnica de análise é a sua simplicidade. Assim, sempre que um problema ou problema ocorre, basta perguntar por que o problema ocorreu pelo menos cinco vezes para as pessoas que trabalham nele. Não há passos fantásticos. Nenhum acrônimo é. Não há necessidade de memorização e desenho de grandes diagramas. Cinco perguntas. Cinco maneiras, entanto, trabalhar em uma premissa de que cada problema tem uma causa por trás disso. Mas um superficial permite que diz apenas retratem sintomas, certo? Então, investigações persistentes necessárias para encontrar o rial chama a rota por trás das questões que soluções duradouras podem ser tomadas e o problema não reaparece. Então agora vamos passar a entender nossos cinco sábios com exemplos. Então, o exemplo de gangue de um, por exemplo , domínio de desenvolvimento de negócios. Você está trabalhando com um cliente, então o problema é que nosso cliente está se recusando a pagar por um site que criamos. Primeira pergunta é um sábio de tempo recusando-se a pagar bem, porque a maçã muitos bugs. Por que não tem muitos insetos? Bem, não conseguimos fazer testes de regressão. Por que você não conseguiu fazer testes de regressão? Bem, a linha do tempo e lançamento. Por que a hora do lançamento já estava marcada? Porque foi assim que o projeto foi vendido. Então, por que o produto foi vendido dessa maneira? Porque as pessoas de desenvolvimento de negócios não tinham o suficiente dentro do desenvolvimento para lançar um plano que permite o teste de regressão CC. Precisávamos de cinco sábios para finalmente decifrar o projeto foi vendido com falta de conhecimento sobre ciclos de desenvolvimento de software. Vamos dar uma olhada em outro. Então isso vem de você sabe, você 18. Então, por que o problema foi encontrado pelo cliente? Bem, acordo com o líder técnico, a equipe de testes não relatou qualquer problema para o desenvolvimento. Certo, então por que a equipe de testes não conseguiu entender o problema? A equipe de teste realizou testes arenosos e não testes de regressão completos. Por que eles só realizam testes arenosos porque não teve tempo suficiente para realizar um completo teste completoe funcional da aplicação completa. Então por que não teve tempo suficiente para testes funcionais? Porque ele constrói veio apenas um dia antes de você 80 cronogramas e eles são um funcional. O teste leva uns três dias. Por que foi faturado dado apenas um dia antes de você 80 por causa da Equipe de Desenvolvimento levou mais do que o tempo estimado, resultando alguns bugs. Então, como você pode ver neste exemplo, vemos que existem duas causas raiz, não apenas uma. Então os primeiros que os membros da equipe não foram capazes de dar estimativas corretas em torno das funcionalidades. E há uma necessidade de treinamento sobre técnicas de estimativa nas segundas causas de implementação . Há um problema com o gerenciamento do projeto como idealmente, um código livre deveria ter sido pelo menos quatro dias antes do U 80. Mas aqui a equipe estava trabalhando para corrigir bugs no último dia. Um vê um tipo de situações que surgem às vezes. Então vamos dar uma olhada no que podemos fazer para realmente conduzir uma análise de cinco etapas de uma maneira muito eficiente. número um é que você obviamente tem que reunir os membros relevantes da equipe. Assim, a lógica por trás de reunir cada membro relevante da equipe é obter um ponto de vista diferente do problema em questão. Assim, cada membro tem sua própria maneira de olhar para o problema e ouvir relatos de todas as pessoas associadas ao problema, e isso lhe dá uma visão de 360 graus. Isto é algo que é muito importante. Estamos olhando para as chamadas raiz, então o número dois será definir a declaração do problema, certo, então uma vez que a equipe está disponível, é hora de o problema real ser definido. O escopo do problema não deve ser muito grande, ou você vai acabar tendo muitas causas profundas, e não deve ser muito estreito, bem como você pode acabar tratando o sintoma. Assim, a declaração do problema deve ser equilibrada breve Ao dar uma explicação clara da questão que está sendo enfrentada. Por exemplo, os servidores falham com muita frequência. E enquanto a encontrar o problema que você pode querer que os membros individuais para encontrar o que eles sentem é problema, fazer uma lista de sua resposta Agora essas respostas podem então ser discutidas para chegar a um consenso da declaração do problema. Agora, se olharmos para uma versão muito, muito simples, detalhada desta análise de cinco etapas é, por exemplo, meu objetivo é que eu quero dizer meu próprio negócio, Por que eu quero essa tarefa. E novamente, por que eu quero essa tarefa novamente? Por que não quer esse teste? Então, no fim das contas, permite-me sustentar a minha família porque é a coisa mais importante para mim. Isso é que é tribunal s sempre ir para o tribunal com cinco esposas. Você pode até ter que ter seis. Se for esse o caso, perguntando por que, um chama você para perguntar aos membros da sua equipe por que a declaração do problema ocorreu. perguntando por que, Você obviamente sabe as respostas e cada passo, a resposta deve ser anotada. Deve formar a base do próximo Y. Uma vez que cinco técnica branca depende da relação de causa e efeito, é imperativo garantir que responde a cada porquê é uma resposta lógica é apoiada pela prova . Você está se perguntando por que temos que repetir o processo de perguntar por quê cinco vezes. Então aqui está a resposta, que é perguntar por que uma ou duas vezes era equivalente a apenas arranhar a superfície e tratar os sintomas iniciais com um problema para reaparecer mais cedo. Tentando sondar a razão por trás de cada uma das respostas faria você passar por quaisquer suposições ou especulações em torno do problema. Assim, uma vez que as causas reais raiz na terra do que deve ser discutido separadamente para encontrar a ação corretiva e contra-medida para garantir os problemas. Finalmente, tackle não voltará a acontecer. Esta é basicamente a poça na situação do chão que falamos antes, então poça no chão é devido ao vazamento de tubos. Por que a coisa dos canos? Porque não foram perfurados? Provavelmente. Então, por que eles construiriam corretamente? Os outros problemas? Você não terá problemas com a infraestrutura em casa, então sempre pergunte mais sábio. Então, algumas vantagens com isso é que incentiva a resolução de problemas colaborativos. Agente. um consenso amigável em áreas com problemas em vez de encontrar falhas ou culpar indivíduos. É simples, fácil de seguir o processo sem exigir uma análise estatística, mas com tudo também é limitações. E você deve saber sobre essas limitações. Você pode contrariá-los em suas reuniões ou mitigá-los com algum tipo de plantas. Então, às vezes, simplesmente não é possível isolar uma única causa raiz para esta técnica. Portanto, faça sua declaração de problema menor, menor ou identifique várias causas raiz. Se você estiver bem com isso, se o produto realmente vai ajudar, é uma técnica demorada, embora envolva uma análise profunda de todos os fatos. O sucesso desta técnica depende dos participantes. Portanto, se as pessoas relevantes não estiverem disponíveis, o grupo restante pode não ser capaz de encontrar a resposta correta para a pergunta branca. Hum, então vocês, é isso. Esse é o cinco sábio. E há uma folha na classe para vocês usarem, então vão à frente frente . 28. O diagrama de bona: Então, falando de problemas agora sobre como resolvê-los, vamos dar uma olhada em nossa primeira solução de primeira ferramenta para resolver problemas. É o diagrama de osso de peixe. Então, um exemplo particular que vem em mente ao explicar o diagrama de ossos de peixe é a poça no chão e sua essência. Está dizendo que a poça no chão existe por causa de uma causa raiz. Em vez de limpá-lo e comprar mais toalhas, a causa raiz precisa ser explorada e corrigida. Estes são os passos que tomamos para identificar a causa raiz. Sete. Faz-me listar no diagrama de aquário muitas vezes usado em marketing. Estes são produtos preço de serviço, lugar, promoção, pessoas, processo de pessoal, evidência física. Agora vamos dar uma olhada em um exemplo de um diagrama de osso de peixe, porque eu vou elaborá-lo para você. Então, digamos que estamos atrasados e gostaríamos de descobrir por que poderíamos ter problemas com o equipamento, as pessoas do processo, materiais, gerenciamento de ambiente externo. Nós olhamos de lado, as causas. Vemos problemas adicionais, por exemplo, equipamentos, equipamentos inferiores, fluxo de trabalho ineficiente, treinamento inadequado, materiais inadequados, atrasos de clientes ou atrasos aprovações. gerência pode ter atrasado as aprovações também. Você pode ver algumas causas secundárias em tudo isso é bom, então a presença e o processo que você pode ver em etapas otimizadas. Poderíamos ter um muito redundante estavam trabalhando. Você precisa cortar isso. Ou poderíamos estar olhando para uma duplicata de trabalho que causa um atraso, talvez ter sido certo no mesmo código para resolver o mesmo problema ou problema diferente. Talvez nossos materiais tenham tido má qualidade. Estaria usando os dispositivos de teste errados com este processo. Nós realmente investigamos as causas por trás de cada um desses problemas dentro do nosso projeto. Se soubermos como evitar este mercado específico com um assento, se ainda não soubermos, podemos descobrir, marcaremos com um X. Não podemos impedi-lo, nem o Detective marcará com uma rede. Veja geralmente significa novos procedimentos de trabalho. X necessidades de pesquisa e tentativa e erro. O final precisa de alguma proteção, seja mais agredido, trabalho escolar ou contratos melhores 29. Planejamento de pôquer: nesta palestra, vamos falar sobre livro de planejamento para que isso possa ser usado com os dias Ideal do Senhor Porno ou qualquer outra unidade de estimativa que você tenha. Honey Poker em Scrum reúne várias opiniões de especialistas para a estimativa de endereço de um projeto. Portanto, esse tipo de planejamento ágil inclui todos. Então Programmers Tester é engenheiros de banco de dados, analistas, designers de interação do usuário e todos os outros pessoais envolvidos no projeto. Como os membros da equipe representam todas as disciplinas do projeto sofrem, eles são mais adequados para a tarefa de estimativa. O objetivo de usar o poker de planejamento é que é, ah, processo que força você a quebrar departamentos em partes tão pequenas que se torna possível estimar corretamente o tempo necessário para cada bit. Então qualquer um era que os construtores de trabalhadores em tudo sabe que o tempo estimado é complicado. Não é possível estimar o tempo para testes que são muito grandes, então é possível determinar aproximadamente quanto tempo leva para um lugar. Uma janela era totalmente impossível de julgar quanto tempo levará para reconstruir toda a casa. Assim, as atividades que você estimar tempo para planejar poker deve ser tão pequeno que é possível estimar quanto tempo vai demorar para executá-los. Assim, a maioria das equipes realizará sessões de planejamento de poker logo após um atraso inicial do produto é escrito nessas sessões, o que pode levar vários dias. Eles costumavam criar estimativas iniciais, que são úteis para esculpir recitando seu projeto. Um, porque os itens de retrospectiva do problema, muitas vezes o formulário de história de um usuário continuará a ser dois ao longo do projeto. A maioria das equipes acha útil para realizar sessões subsequentes ágeis, estimando e planejando uma vez por geração, normalmente realizadas alguns dias antes da adoração sob a adoração imediatamente após um stand up diário . Porque toda a equipe perdeu todos juntos, então cada pessoa era uma parte. A equipe de estimativa está segurando um baralho de cartas com você, mas não seus valores, como 0 a 21. Então eu vi cartões de planejamento subir para 100, mas estamos definindo. Maior complexidade é 21 em vez disso, então você geralmente não vê nomeado levantando cartas mais altas deste. E a equipe estimada precisa fazer perguntas aos proprietários de produtos. Se eles parecem muito pouco claros. Então, o que é clareza varreu a sala. A equipe apresenta suas próprias estimativas individuais jogando uma carta do baralho de cartas . Importante notar é que todos precisam revelar seus cartões ao mesmo tempo. Se estamos todos jogando o mesmo número de nossos decks, isso significa que estamos de acordo sobre o ponto da história. Não deveríamos jogar as mesmas cartas? A equipa precisa de discutir a prisão. E uma vez que as discussões levaram à conclusão, a equipe então se repete para revelar o processo com outros pontos da história. Mas para as histórias de usuários, se não houver acordo sobre certas histórias de usos do que este é, a base para mais pesquisas tem adiado até que mais informações sejam necessárias. Então, com isso dito, vamos dar uma olhada, ah, planejamento sessão de poker ano velho eso rápido que estamos olhando como um usuário. Quero ver uma lista de produtos para poder selecionar alguns para comprar. Então temos Joe, Michelle, Richard e Lana, e todos eles vão estimar. Então, a estimativa é Joe em cinco. Michelle 13 Richard cinco longos três. Agora você pode ver que cinco e três não é tão grande, então um pouco de discussão pode ajudar a elevar a fasquia para cinco direita nos três, apenas para adicionar um pouco de complexidade. E eles são um pouco de amortecedor, mas 13 está meio preocupado. O que isso significa? Isso pode significar que Michelle não entendeu os requisitos. Quero dizer, que Michelle tem uma opinião diferente sobre o que vai acontecer quando chegar ao teste. Pode ser que haja muita complexidade na parte de trás e sistemas que você vai trabalhar através eso Este tipo de ajuda e eu guia para dizer Ok, Michelle, vamos ter uma conversa sobre isso mais tarde. Então você fecha isso aqui mesmo, mova para as próximas histórias de usuários que você quer Eles querem estimar. 30. Desafios de transformação Agile: Quando eu comecei como um mestre scrum, eu estava entendendo como o Sr. Roll realmente exigiu de uma nova estrutura de equipe de liderança cicatriz Laster , estratégia de produto, práticas técnicas, gerenciamento de mudanças e Coaching. Eu estava olhando para mim para antes de algum mestre Scrum sair. Este pode ser um caminho complicado caminhar em muitos rei e confuso e pego em todas as habilidades que eles precisam saber. Hoje vejo a mesma coisa acontecendo onde as organizações querem ser ágeis, mas não querem colocar em prática iniciativas suficientes para alcançar essa certa agilidade. Eles se concentram em scrum na câmera. Mas como já sabemos, Agiza filosofia e se você vai scrum é apenas uma ferramenta. Se você não sabe como construir uma casa, as tábuas, concreto e vidro não servem de verdade. As organizações podem se concentrar em melhorar as práticas de engenharia. Eles podem até enviar pessoas para participar de cursos de treinamento e há uma expectativa de que isso seja suficiente. Melhorias virão rolando. Isso, é claro, não aborda o núcleo do problema. Há murmúrios de nós tentamos ágil. Realmente não funciona aqui. Trabalhamos com um cliente como este. Você tem que cavar muito, muito fundo para entender usando a transformação. As coisas ficaram um pouco distorcidas principalmente, e eu digo que isso sem mais confiança é a parte mental adaptabilidade pessoal e capacidade para as pessoas mudar isso, superar seus medos e enfrentar certos riscos. Como eu, meus dias de mestre Scrum. Muitos treinadores e consultores estão se concentrando estreitamente em uma pequena peça do quebra-cabeça. Enquanto ignora partes vitais de informação. Sem colocar estes em foco, as chances de melhoria não são muito altas. Eu aceito que a divisão prestes a falar sobre vocês é uma divisão artificial maior, e não se pode abordar o domínio isoladamente. Eles são todos altamente interligados em cada domínio irá influenciar cada uma das outras áreas. Então eu faço a divisão em grande parte para aumentar a conscientização sobre as coisas que devem estar no radar liderando uma transformação. Então, vamos seis. Vamos explorar cada liderança de domínio. Cultura organizacional de pessoas no medidor significava governanta de financiamento e formas de trabalhar. Vamos começar com a gestão de liderança. Ouço muitas vezes dizer que os líderes devem apoiar ou aceitar a iniciativa de mudança, e eu concordo e discordo. Então, na minha experiência, muito mais. O apoio é necessário. Acredito que a mudança precisa ser impulsionada ativamente pela liderança. Eles próprios precisam passar por uma aprendizagem profunda e crescimento no papel e tudo começa lá. Há muitas maneiras pelas quais o gerenciamento de liderança de uma organização verdadeiramente ágil é irreconhecível a partir das versões tradicionais das regras. Mudanças vitais incluem uma mudança da liderança apoiada pela Diretiva 2, uma mudança de autoridade centralizada para descentralizada, uma mudança de foco no dedo do pé do trabalho, focando na direção e criando o ambiente para o sucesso, não apenas com palavras, mas com mudanças estruturais de políticas para permitir que as mudanças aconteçam. Essas mudanças não podem ser conduzidas de baixo para cima. Eles precisam vir da liderança. Vejamos a cultura organizacional. Assim, na versão 12 de um Relatório do Estado de Ágil, diz que cultura organizacional em desacordo com os valores ágeis foi mais uma vez o desafio número um ao adotar e escalar ágil foi destacado por 53% dos entrevistados, é continuamente emerge como um inibidor número um para aumentar a agilidade. Portanto, o primeiro passo é entender a organização cultural atual e desejada. O THES estará bem alinhado ou em conflito com a obtenção de maiores níveis de agilidade. Se a cultura desejada está em um daqueles que está em conflito, então eu questionaria onde a transformação deve ir em frente. Isso pode evitar um monte de desperdício de tempo, dinheiro e esforço, e tende a ser melhor para ajudar as pessoas a melhorar dentro dos parâmetros do que valorizam quando, seja lá o que for. Se é decidido que a cultura precisa ser deslocada, que precisa ser cuidadosamente planejada, não se muda apenas a cultura tentando mudar a cultura. Cultura é um produto dos comportamentos, valores e crenças das pessoas, dentro de uma organização ou dentro de seu departamento ou com uma nova equipe. As culturas só podem ser deslocadas alterando esses comportamentos específicos. Esses novos comportamentos devem ser suportados com novas políticas. Só então a cultura mudará no caminho. Este é outro facilitador fundamental da agilidade, e não deve ser ignorado. Vejamos as pessoas em engajamento. Assim, um negócio moderno, as regras do jogo mudaram. Não há mais nenhuma dúvida sobre a ligação entre o engajamento dos funcionários e os resultados dos negócios . Qualquer namoro que você olhar para os resultados são as mesmas empresas com funcionários engajar significativamente superar sua concorrência. É que uma gestão de obediência e diligência, como foi eficaz durante a Revolução Industrial, agora precisamos combinar para criatividade, iniciativa, paixão. Isso ajudará a atrair e reter os funcionários mais eficazes e proporcionará uma enorme vantagem competitiva na complexa economia do conhecimento de hoje. É de admirar que, no estado do Global Workplace Report da Gallup 2017, apenas 15% das pessoas retiradas estavam envolvidas em suas organizações de trabalho estão desperdiçando potencial humano ou não obtendo as melhores outras pessoas? Isso é ruim para as pessoas e ruim para os negócios. Portanto, criar organizações de adaptadores de alto desempenho gerenciando ativamente para o engajamento é a necessidade. Isso envolve reinventar muitas políticas desatualizadas de RH para o trabalhador do conhecimento do século XXI para governança e financiamento. Uma pergunta que ouço o tempo todo é: Como podemos ser ágeis? Precisará assinar os custos de escopo e os cronogramas antecipadamente, e eles não podem ser alterados sem revisitar o caso de negócios. Bem, você não pode responder rapidamente a um modelo de governança baseado em cachoeira que insiste em grande análise inicial e design. A criação de detalhes, casos de negócios, controle rigoroso de mudanças e financiamento de grandes lotes não é uma fragilidade de design de modelo. Muito pelo contrário é projetado para rigidez e faz muitas suposições, que não mantêm desenvolvimentos complexos. Suposições como se pudéssemos saber o que construir com antecedência. As coisas não vão mudar muito à medida que progredir e salvar o lugar grandes apostas sobre suas suposições quando o dinheiro gasto este fundamentalmente incompatível com muitos ágeis uma compra. Uma câmera de depuração que muda como o dinheiro é investido de planejar e prever para experimentar e se adaptar é um navio de mentalidade enorme. Colocar muitas pequenas apostas e curso correto e com base em feedback é a maneira menos arriscada de prosseguir . Mas as organizações precisam ser criadas para isso. Assim, as formas de trabalhar é o domínio em que a maioria das organizações dedicam a maior parte do foco . Seja implementando estruturas ágeis como uma confusão, Cambon ou o modelo Spotify, ou mesmo melhorando as práticas de engenharia. Este tende a ser o ponto de partida, maioria para buscar maiores níveis de agilidade. O problema é que se concentrar em formas de trabalhar com todos, mas garantir que a ágil não funciona aqui. A razão pela qual não funcionará será que as mudanças de liderança organizacional necessárias para criar físicos ambientais não aconteceram. Os frameworks mencionados acima pode ser muito valioso não seria aplicado no contexto certo. Assim, a lenda da cultura organizacional, que se presta a uma certa abordagem qualquer treinador adjunto ou consultor para nos aconselhar começando com uma estrutura particular sem entender o contexto, cultura, desejado resultado e atitude em relação à mudança. É alguém que provavelmente não tem a experiência de aconselhar você sobre sua transformação. Eu vejo isso muitas vezes. É uma falha dos processos reais da indústria, práticas e estruturas são importantes, mas eles não alcançarão resultados isolados. 31. Mestres de grandes Scrum: o maior problema e medo que você vai enfrentar é um treinador ágil é falhar. Sua missão em seu cliente é um problema que leva transformações ágeis que são insustentáveis e não flexíveis o suficiente como organizações alvo, mas mal avaliadas durante meus anos. Eu vi isso acontecer algumas vezes e eles podem ficar bastante difíceis. Portanto, eu quero criar uma palestra bônus fora disso. Mas comecei a trabalhar como mestre de scrum há nove anos. Agora eu tinha frequentado o curso de mestrado scrum, mas como todos sabemos, teoria é diferente de praticá-la na vida real. Estou falando de habilidades suaves, habilidades interpessoais, conhecimento do produto, experiência no assunto. Felizmente, eu estava trabalhando com alguns dos melhores mentores naquela época que poderiam me guiar e me mostrar onde e como eu posso encontrar minhas respostas. Encontrar meus pés é o mestre scrum não foi jornada educacional, mas muitas vezes novo mestre scrum escolher sua própria aventura sem a orientação adequada. Então, como abordamos esta questão e por onde começamos? Tendo trabalhado em várias agências? Nigel Coach, tendemos a nos tornar mais consultores dentro dessas organizações. Quando o projeto termina, nós empacotamos as coisas e deixamos para trás, uma organização que era altamente dependente de nossas habilidades para resolver os problemas. Eles foram claros, embora muitas organizações que embarcam nessa jornada ágil não vejam o valor em investir em uma jornada de sacola. Então líderes scrum Master proprietários de produtos membros da equipe eles só para aprender muitas novas habilidades e técnicas, técnicas que muitas vezes são diferentes quanto ao que eles estão acostumados a tomar um atalho. Por conseguinte, as empresas contratam consultores. Nancy Kline colocou da melhor maneira em seu livro, um tempo para pensar a coisa mais valiosa que podemos oferecer um ao outro é um quadro para pensar por nós mesmos. Então vamos dar uma olhada em como crescemos em mestres de scrum de trem para entregar esse valor. Agora, a estrutura do pensamento independente pode ajudá-los a crescer. Eu acredito fortemente que beber meus anos é Grão-mestre Nigel Practitioner. Encontrei três pilares que funcionam bem para o crescimento do mestre de sucata. Um deles é a liderança que entendem a importância de até Skilling. As pessoas estão dispostas a investir nisso. Em segundo lugar, sendo treinadores com experiência no histórico de crescimento de uma capacidade de professor 1/3 em ser um programa sistemático de treinamento e no coaching de trabalho para cobrir os governos apropriados ou competências. Então eles são todos eficazes e como as pessoas podem aplicá-los é Lian Cambon Scrum XP. Na prática de acompanhamento e padrões, que deve ser de segunda natureza, mas as pessoas progridem através dos níveis. Eles devem começar a investigar mais corpos de trabalho, incluindo pensamento de sistemas, teoria da complexidade. Na teoria do enfileiramento, Teoh elogios ampliar sua base de conhecimento quando se trata de organizações crescidas. Crime, Sr. Capacidad. Eu tendem a usar uma combinação de ensino, mentoring e coaching majoring elementary. Dado o amplo escopo do rolo mestre scrum, observei o melhor resultado em dividir o lançamento. São áreas de competência de alto nível. Ao pedir 10 treinadores foram provavelmente rendimento, me disseram respostas depois de muitos experimentos descobriram que a divisão de queda a ser efetuada. Facilitação é algo em que os mestres do scrum devem se tornar bons rapidamente. Estes poderiam incluir os fornos scrum, produto de mapeamento de história, oficinas de mapeamento do mundo, refinamentos de backlog e inúmeros outros. A capacidade de permanecer neutra e visitada facilitada discussões em grupo e tomada de decisões é fundamental, assim como a habilidade viável de projetar e entregar. Retrospectivas ineficazes do restaurante sprint. A dinâmica da equipe é crucial do mestre esfoliante como manifestantes como eles devem sempre ter o seu olho na dinâmica do desenvolvimento neste condado, eles devem entender como facilitar a criação da equipe AH, trabalhando com um acordo, um objetivo compartilhado e responsabilidade mútua para alcançá-lo, eles devem entender como construir confiança, para navegar conflito saudável. Eles devem ajudar a construir um ambiente de segurança psicológica. Capital social em colaboração. Ajudar os indivíduos a trabalhar de forma eficaz como uma equipe tem provado repetidamente mais eficaz do que simplesmente contratar os melhores indivíduos. Este é algum produto é uma responsabilidade chave do mestre US Crow. Isso significa ser um estudante de gerenciamento de produtos. Isso inclui treinar a criação de uma estratégia atraente de visão de produto e um roteiro. Além disso, isso significa ajudar o proprietário do produto com técnicas em torno do gerenciamento de backlog de produtos, como descoberta e divisão de histórias de usuários. Mudanças organizacionais, O aspecto mais ignorado da regra é sempre coaching a equipe de desenvolvimento no produto Owner scrum mestres são esperados para treinar organizações. Nos meus anos de matagal, encontrei este fato. Isso se torna a parte mais importante do papel uma vez que a equipe escolheu as vitórias fáceis em um nível local, as restrições tendem a se mover para a organização. Talvez eles traçam políticas estão incentivando o ismo individual sobre o trabalho em equipe. Talvez a infraestrutura não permita que você implante facilmente no ambiente de teste. Talvez as políticas de governança estejam te atrasando. Como um scrum, mestre, você deve estar disposto a enfrentar esses impedimentos. Isso significa educar as pessoas muito além da sua área. Agora eles poderiam comer a agilidade da equipe e ser um agente de mudança, treinamento, mentoria e ensino é tudo sobre ajudar as pessoas a crescer e desenvolver novos conhecimentos e habilidades, do lado mais diretivo para ensino ao lado menos directiva de habilidades de coaching um relacionado. Então eu os mantenho juntos. De qualquer forma, eles são todas coisas que scrum master deve ser capaz de fazer em graus variados no espírito de ajudar pessoas e equipes continuamente melhorar este sistema de auto-avaliação. Cada uma das áreas acima ajuda as pessoas a identificar suas áreas de strings e onde há mais espaço para o desenvolvimento. Isso então impulsiona uma conversa construtiva de coaching e mentoring centrada em onde eles estão agora, onde eles gostariam de estar e como eles podem trabalhar para alcançar esse crescimento capacidade de contagem de teatro senta-se firmemente em suas mãos estavam lá seus próprios workshops direcionados para ouvir as perguntas, plantar sementes e orientá-los através do processo de desenvolvimento de si mesmos. Podemos apontar para livros, artigos e vídeos que você me inspirou ao longo dos anos que não podemos fazer é um escolher esse caminho . 32. Parabéns! Você concluiu o curso: Ei, pessoal, este é o fim de um curso. Mas não é o fim das cidades de viagem. Mais algum feedback que você teria mais alguma coisa . Eles gostariam de saber isso. Por favor, deixe-me saber na seção de comentários, e eu iria direto para a última coisa que eu quero ver aqui antes de sair deste curso . É realmente fundamental para a estrada. Você tem que ter muitas dessas habilidades que temos falado no curso e não me entenda mal com muito, muito importante. Mas a habilidade chave para ser um tribunal adulto ou um mestre de scrum é prestar atenção a muitos detalhes. Estas decisões significam o preço dentro dos dados para tomar decisões difíceis todos os dias. E também precisamos ter uma abordagem de consultoria para a gerência sênior do cliente trabalhando conosco neste momento. Estou tão feliz que vocês se juntaram a mim nesta jornada. Aprender sobre algo que adorava fazer sozinha. Então, onde quer que estejas no mundo, seja lá o que estiveres a fazer, orgulha-te. Seja feliz, seja motivado. Mantenha-se em contato e parabéns por concluir o curso.