Scrum: gerenciamento de projetos ágil e coleta de requisitos

1. Boas-vindas: Bem-vindo a este curso sobre Scrum. Se você é um ScrumMaster, gerente de projetos, desenvolvedor e engenheiro, teste com apenas uma olhada em Agile, então este é o curso para você. Scrum é uma estrutura de gerenciamento de projetos. Ele foi originalmente desenvolvido para desenvolvimento de software, mas na verdade pode ser usado para qualquer coisa. Portanto, as habilidades que vou ensinar neste curso , tanto quanto possível. Vou tentar aplicar em todos os ambientes. Mas vamos continuar com um estudo de caso real. Então, vamos analisar a criação de uma plataforma de comércio eletrônico como um aplicativo de software. E vamos ver como o contorcimento se aplica a isso. Então você aprende a teoria, a prática, e nós também a aplicaremos a essa situação. Então, se tudo isso soa bem, então vamos começar. 2. Noções básicas para Scrum: Vamos começar com o básico. Então, o que é cultivado? Bem, é uma estrutura de gerenciamento de projetos. Ele ajuda você a entregar projetos, estruturá-los de forma que funcionem. Por isso, foi originalmente desenvolvido para o desenvolvimento de software, para o desenvolvimento de projetos técnicos, mas desde então tem sido aplicado a uma grande variedade de tópicos. Então, o tipo de desenvolvimento de software é seu lar. Mas, na verdade, você pode aplicar contorção em qualquer coisa e funciona muito bem. Eu usei na minha vida pessoal, usei projetos não relacionados ao tipo. E essas válvulas são muito boas. O Scrum faz parte da família Agile. Então, a agilidade é um movimento. Não é uma coisa. Agile é, é uma forma de ser e trabalhar. E você tem o tipo de filosofia bacana do Agile. Mas então você tem implementações específicas, coisas como Scrum, coisas como Kanban, esse tipo de manual de ok. Bem, aqui está como você coloca esses princípios ágeis em prática. Então, é uma parte escamosa do movimento ágil geral, e é uma implementação específica disso. Scrum. E o Agile em geral é realmente projetado para reduzir as falhas do projeto e tornar os projetos mais confiáveis. Então, da maneira antiga, os projetos tendiam a falhar muito. E então, afinal, todos vieram e disseram: Como podemos fazer isso melhor? Como podemos reduzir isso? E falaremos mais sobre como ele faz isso à medida que avançamos. Então, como o Scrum funciona? Como isso consegue todas essas coisas? Vamos explorar isso nas próximas aulas. 3. Ágil vs cachoeira: Vamos comparar uma metodologia em cascata de estilo antigo com uma metodologia mais ágil baseada em scrum. No sistema antigo, teríamos tudo em grandes etapas. Seria uma grande fase de especificação. Então, todo o trabalho de desenvolvimento poderia ser feito, seguido pelo teste e pela aceitação do usuário. Agora é aqui que isso dá errado. Talvez levemos muito mais tempo do que o esperado e, em algum momento, fiquemos sem dinheiro . Chegamos à fase de testes e percebemos que precisamos mudar os requisitos, mas já fizemos todo o trabalho de desenvolvimento. Ou chegamos ao estágio de aceitação do usuário e o colocamos na frente do cliente ou do cliente e eles não gostam e precisam de mudanças. E então o que devemos fazer isso porque já estamos no phage de aceitação do usuário. Então, em vez disso, Agile propõe que usemos um processo iterativo no qual realizamos várias pequenas etapas. Então, fazemos uma pequena amostra, pequena construção, pequenas tarefas, pequena aceitação do usuário e, em seguida reiniciamos o ciclo. Então, em vez de ter esses quatro grandes blocos onde tudo é feito ao mesmo tempo, temos esses pequenos ciclos rápidos. E as vantagens de fazer isso são coisas como, bem, podemos fazer um lançamento após o primeiro ciclo. Quando eles são uma metodologia antiga em cascata, você só conseguiria lançar no final. Mas aqui construímos algo muito básico e podemos lançá-lo após o primeiro ciclo. Também podemos colocá-lo na frente do cliente para que ele possa vê-lo. E eles podem fazer alterações se precisarem, se não corresponderem ao que desejam. E essas mudanças são boas porque depois de concluídas, a aceitação do usuário foi a primeira rodada. Voltamos à fase de especificação do treino. O próximo passo é que precisamos construir e, em seguida, construí-lo, testá-lo e devolvê-lo ao cliente. E continuamos nesses ciclos rápidos em que coletamos muitos comentários e divulgamos as coisas mais cedo, o que reduz a chance de falha e significa que elas corresponderão às necessidades do cliente. 4. Fortes e limitações: Vamos considerar alguns dos pontos fortes e limitações da rolagem. Uma das grandes vantagens é evitar falhas no projeto. Então, conversamos sobre essa ideia de projetos de cachoeiras demorarem muito tempo até o fim. E talvez eles não cheguem ao final porque os custos são excessivos ou porque o usuário não goste. E o fato é que um fracasso — o Scrum e o Agile em geral realmente evitarão isso? Os clientes podem ver isso cedo para ficarem mais felizes, pois podem ver o progresso e ver que está de acordo com o que eles querem, em vez de conseguir algo no final que pode ou não ser o que eles querem. É um relatório muito bom, mudando os requisitos do usuário. Então, se o cliente entender e disser: Oh, eu preciso mudar isso ou isso não está funcionando bem. É muito mais fácil mudar se você não construiu tudo. E se você está trabalhando em uma metodologia que diz mudanças, uma boa mudança faz parte do processo que elas são, o problema com a cascata é que o cliente fará mudanças à medida que você avança no projeto. E você precisa de uma maneira de lidar com isso. E sua metodologia iterativa realmente ajuda nisso. Isso significa que você pode lançar a primeira versão mais cedo porque não precisa terminar tudo para poder enviá-la. Você pode criar a funcionalidade essencial, enviá-la e continuar construindo depois de lançar os projetos. Agora, todas as limitações do Scrum e do Agile. Então, uma das maiores é que demora um pouco mais. Às vezes, as pessoas acham que o Agile soa um pouco mais rápido, mas não é. Ele foi projetado para reduzir as taxas de falha. Portanto, Waterfall, Waterfall é bastante eficiente se você acertar tudo 100%. Então, se você planejou e construiu 100% , testou e entregou, tudo funcionará perfeitamente. E não há mudanças nos requisitos do usuário que sejam mais rápidas do que esse ciclo iterativo em que você constrói um pouco, revisa, constrói um pouco, revisa, seria mais rápido. Agora, nunca vi um projeto em que tenha sido planejado para 100% e depois conhecemos as mudanças nos requisitos do usuário. Então, acho que a metodologia ágil funciona muito melhor. Mas, hipoteticamente, se você pudesse alinhar tudo isso , a cascata seria mais rápida porque Scrum funciona nesse ciclo iterativo, que demora um pouco mais. As partes interessadas nem sempre gostam disso. Então, se eles são do estilo cascata da velha escola , provavelmente estão um pouco nervosos em adotar essa nova metodologia ágil. E às vezes eles se preocupam com o fato de que, se estivermos desenvolvendo esse ciclo iterativo mostramos ao cliente um software incompleto que tende a deixá-lo em pânico. Minha experiência, os clientes adoram. Eles estão realmente engajados. Eles querem ver o progresso e entendem que não estão analisando o projeto finalizado. Mas muitos gerentes da velha escola realmente temem que mostremos, mostremos a eles um botão que não está completamente pronto e o cliente presuma que está pronto e o espere amanhã. E às vezes pode ser difícil gerenciar essas expectativas. Scrum tem muita flexibilidade, mas de alguma forma escamoso e inflexível. Então, funciona nesses sprints de normalmente duas semanas em que você diz o que vai fazer no início das duas semanas, depois faz isso e não muda isso. Agora, de certa forma, isso é bom porque se você permite mudanças dentro do sprint , geralmente os gerentes tentam trabalhar mais distraindo os engenheiros e afastando-os da tarefa. E isso não é ótimo. Mas existem alguns ambientes que você tem coisas urgentes surgindo. O contorno não é tão bom em lidar com isso quanto, digamos, algo como Kanban, que é outra estrutura ágil, projetada como uma espécie de quando você está vivo, fazendo negócios como de costume, apresentando contorno não é tão bom em lidar com isso quanto, digamos, algo como Kanban , que é outra estrutura ágil , projetada como uma espécie de quando você está vivo, fazendo negócios como de costume, correções, é mais adequado que com Scrum é mais adequado para se você estiver construindo um projeto pela primeira vez. E, você sabe, você pode dizer que temos um bloqueio de duas semanas aqui. Isso é o que vamos fazer e permitir que todos se concentrem nisso. 5. O sprint: Um dos principais conceitos do Scrum, que é diferente de alguns dos outros frameworks ágeis, é essa ideia do sprint. Esse é um período fixo de tempo em que a equipe concorda em fornecer um conjunto específico de recursos. Então, geralmente são duas semanas e dizemos, ok, nas próximas duas semanas, vamos criar esse recurso, esse recurso e esse recurso. Então, em um sprint, teremos uma meta, por exemplo, talvez a meta seja entregar a página de checkout para nossa plataforma de comércio eletrônico. E isso é composto por vários tickets que criam cada uma das funcionalidades necessárias para fazer isso. E então começamos um sprint e toda a equipe trabalha em conjunto para oferecer essa funcionalidade. Portanto, a entrega e a conclusão da meta do sprint não são o trabalho de qualquer pessoa. É responsabilidade coletiva de toda a equipe. Então, o que parece em um processo é que começamos com o Sprint Planning. No Planejamento de Sprint, a Meta do Sprint é acordada e escolhemos as tarefas que serão concluídas. Então, selecionamos os problemas ou os ingressos que vamos trazer e eles se tornam a lista de pendências do sprint, que é essencialmente a lista de tarefas dessas duas semanas. Em seguida, entraremos no sprint em si. Portanto, a equipe trabalha para fornecer os recursos acordados e nada de novo é incluído no sprint. Então, quando fazemos o planejamento do Sprint, começamos isso quando e depois bloqueamos esse sprint, esse período de tempo para dizer que é isso que vamos fazer e vamos trabalhar juntos para fazer isso. No final do sprint. Em seguida, temos a retrospectiva e a revisão. Assim, o trabalho concluído é apresentado em uma revisão e a equipe reflete sobre como foi, que é a retrospectiva. Então, os dois eventos se separam, e falaremos mais sobre eles em uma lição posterior. E todos os problemas não concluídos são transferidos para o próximo sprint ou são devolvidos à lista de pedidos do produto. 6. Comprimento de estampagem: A duração de um sprint pode ser a que você quiser. Então, normalmente, os sprints são feitos em períodos de duas semanas porque isso parece funcionar bem para a maioria dos projetos, mas isso não é uma regra. Às vezes eu fiz sprints de uma semana, às vezes fiz sprints de três semanas. O que você realmente quer fazer é descobrir quanto tempo você levará para entregar determinados recursos, parte do processo de desenvolvimento, e fazer disso a duração do seu sprint. Então, se você tem um recurso muito grande e complicado para entregar uma parte do projeto. Então, se isso vai levar , digamos, um mês para fazer, então você quer fazer seu sprint de um mês, se literalmente não pudermos ser divididos. E essa é uma boa pergunta para se perguntar se você está pensando, ok, eu preciso de um sprint de quase quatro semanas ou seis semanas ou algo assim. Reexamine se você pode detalhar isso ainda mais , porque provavelmente você pode. Mas se for literalmente impossível, não há problema em prolongar seu sprint, pois você pode adaptar o comprimento da tala para atender às nossas necessidades. Normalmente, duas semanas é um bom período de tempo. Todos podem baixar a cabeça. Você não está gastando muito tempo no ciclo de sprint e tem um bom período de dez dias úteis para fazer as coisas, mas pode torná-lo mais curto ou mais longo para atender às suas necessidades. 7. O que são artefatos?: Artefatos são informações que uma equipe Scrum usa para ajudar a planejar e realizar seu trabalho. Então, por exemplo, uma lista de recursos a serem construídos seria um artefato. Agora, isso pode ser mantido em uma planilha. Pode ser mantido em uma ferramenta como o JIRA, ou até mesmo em nossas cabeças. Mas eu não recomendaria isso porque isso obviamente cria um único ponto de falha. Neste módulo, vamos explorar os diferentes tipos de artefatos que é comum as equipes do Scrum usarem. 8. Lista de pendências do produto: O produto é o que você está entregando e a lista de pendências do produto é tudo o que precisa ser feito. Então, todas as tarefas envolvidas no projeto. Cada tíquete representa uma funcionalidade distinta. Portanto, um ticket, uma funcionalidade de entrega, por exemplo, se tomarmos o exemplo de nossa loja de comércio eletrônico, provavelmente precisaremos uma página de visualização do produto, na qual você possa clicar no produto e ver todos os detalhes. E isso tem vários componentes, pois provavelmente é como um título e uma descrição da foto do produto e algumas avaliações e especificações técnicas. Agora, cada uma dessas coisas pode ser seu próprio bilhete em uma lista de pendências de produtos. Então, adicionando a criação da página em branco, adicionando o título, adicionando a imagem do produto, eu não fiz especificações adicionando as avaliações. Todos podem ser ingressos individuais porque você pode entregá-los um de cada vez. Você pode entregar uma página que tenha apenas o título do produto. E então você pode voltar mais tarde e adicionar uma foto do produto ou algumas avaliações de produtos que diferenciem as funcionalidades e, portanto, eles recebem seu próprio ingresso. Agora, os ingressos podem ser usados em um trabalho maior. Então, nesse caso, temos nossa página de produto, ou a página do produto, pode ser o que chamamos de épica. Portanto, essa é uma coleção de tickets que funciona para oferecer uma funcionalidade maior. Portanto, nossa página de produto como um todo pode estar em um épico. E então temos ingressos individuais lá. Então, temos a descrição do produto, a foto do produto, a avaliação do produto, e tudo isso faz parte da página do produto épica, que podemos lançar em algum momento. Portanto, o objetivo da lista de pendências do produto é manter todas as tarefas que precisam ser feitas. Então, eles guardavam tudo para a página do produto, tudo para a página de navegação, tudo para a página de checkout, tudo dividido em tíquetes individuais e o separavam tudo para a página de navegação, tudo para a página de checkout, tudo dividido em nesses épicos. Então, sabemos a qual ingresso pertence, a que tipo de seção. 9. Exemplo de backlog de produto: Aqui temos um exemplo de lista de pendências de produtos. Então, isso é para nosso exemplo de loja de comércio eletrônico. E temos nossas histórias de usuários escritas aqui. Então, está escrito no formato de história do usuário, sobre o qual falaremos um pouco mais tarde. Mas coisas como, como visitante, eu não vou ver o nome do produto, a imagem do produto. E então, como gerente, quero ver uma lista de pedidos. E nesta coluna, nós o agrupamos por época. Então, tudo isso é épico na página do produto, seu checkout é apicamente épico no gerenciamento de pedidos. E colocamos um sprint provisório sobre eles aqui e na coluna de status para dizer se eles fizeram o que estamos fazendo agora ou se estão prontos. E haverá alguns que não estavam prontos porque não os refinamos aqui embaixo. Agora, há muitas ferramentas excelentes que você pode usar para gerenciar sua lista de pendências de produtos. Mas eu queria mostrar isso para você nesta planilha porque acho que é uma ótima maneira de aprender os fundamentos. Você pode fazer isso em uma planilha, você pode fazer em um pedaço de papel, você pode fazer o que quiser. Vamos nos aprofundar nas ferramentas porque elas também são muito importantes. Provavelmente é isso que você usará em um ambiente de negócios do mundo real. Mas essa é uma boa maneira de considerar os fundamentos. 10. Backlog de sprint: No início de cada sprint, você seleciona quais ingressos vai fazer nesse sprint. Então, digamos que você esteja trabalhando em um sprint de duas semanas. Você examina o backlog do produto e diz: Ok, a, B, C, D, Esses são os ingressos que vamos trazer e fazer neste sprint. Então, quando você inicia o sprint, esses tíquetes que você selecionou formam o que é chamado de lista de pendências de sprint. A lista de pendências do produto, tudo o que você precisará fazer para o projeto, a lista de pedidos pendentes do sprint que você fará para esse sprint específico. Então, quando alguém está pronto para trabalhar em algo, ele vai até a lista de pendências do sprint e pega um dos ingressos, qualquer um dos ingressos que você possa priorizar. Mas, normalmente, dentro de um sprint, não há muita priorização a menos que algo esteja bloqueando algo. Mas se você tiver um bloqueador, é melhor deixar isso para um sprint separado os ingressos possam ser retirados em qualquer ordem. Em seguida, eles partem da coluna de tarefas, que é a lista de pendências do sprint em geral à medida que passam pelo desenvolvimento, implementação e entrega. 11. Exemplo de backlog de sprint: Aqui temos um exemplo, o sprint backlog. Então, temos nossas colunas aqui com a lista de tarefas, a lista de pendências aqui. E então, à medida que fazemos esses ingressos, se eu disser que escolhi este como cliente, quero ver o nome do produto. Posso colocar isso em andamento enviá-lo para revisão do código. E continue avançando no processo. E digamos que esteja pronto para o teste. Os testes descrevem isso. Isso não funciona. Eles poderiam movê-lo de volta para In Progress e reatribuí-lo para mim. E poderia voltar a esse ciclo novamente e, eventualmente, espero que acabe na coluna concluída. Agora, essas colunas podem ser tão flexíveis quanto você quiser. Então, podemos, em vez de uma visualização em andamento do codificador, talvez queiramos dividir isso. Adicione uma nova coluna aqui embaixo. Lá vamos nós. Eu ligaria para ele antes que pudéssemos dizer que estamos prontos para a revisão do código. E na revisão de código. E depois de terminar escrever o código, eu poderia colocá-lo aqui. E então outra pessoa poderia retirá-lo. Quando eles o pegam. Pode entrar aqui, por exemplo, então, nessas colunas, não há regras, mas há alguns princípios gerais de que você provavelmente quer algum tipo de atraso enquanto ele precisava de uma lista de pendências, e ele não precisava dessa. E em andamento em algumas análises e testes de código. Então, em última análise, eles querem acabar na coluna Concluído. Agora, novamente, existem muitas ferramentas excelentes para fazer isso, mas é bom ver isso em um nível muito básico. Muitas pessoas usam quadros físicos com post-its para mover. Isso foi muito popular quando todos trabalharam no escritório nos últimos milhares de casos de pandemia e as equipes remotas são muito mais influentes. Mas você pode, se estiver fazendo isso em um projeto individual, ainda é uma ótima maneira de fazer isso, porque você tem uma experiência realmente tátil de mover as cartas pelo tabuleiro. 12. Definição de done: Como saber quando um ticket pode ser movido para a coluna Concluído? Um documento importante aqui é a definição de concluído. Este é um documento que descreve exatamente o que é necessário para que um ticket seja considerado concluído. Então, por exemplo, se analisarmos o software novamente, um engenheiro poderá criar o recurso. Mas isso não atenderia à maioria das definições de feito porque não é, não foi para lugar nenhum, não está sendo testado. Portanto, a definição de concluído listará todas as etapas, por exemplo , foi construído e testado. Foi implantado. Há cobertura de teste suficiente lá. Talvez haja algum monitoramento e algum registro para você possa salvar esse recurso que dê errado ou interrompa posteriormente. Ele foi testado em desempenho e segurança para garantir que não tenha introduzido nenhuma falha, coisas assim. todas as etapas adicionais em que você pode dizer que esse tíquete foi concluído, não precisamos adicionar nada extra. Não precisamos voltar e dar uma olhada. Estamos felizes por estar lá fora, na selva. Na próxima lição, veremos um exemplo de Definição de Concluído para que você possa ver como é na prática. 13. O que são cerimônias?: Cerimônias são eventos que ajudaram no planejamento, execução e entrega do sprint. Normalmente, eles envolvem os membros da equipe de scrum, mas em algumas cerimônias, podemos optar por convidar também partes interessadas externas. Neste módulo, exploraremos cada uma das principais cerimônias por vez. 14. Scrum diário: O scrum diário é uma reunião diária. Geralmente acontece pela manhã, mas não precisa e é como um check-in para todos os membros da equipe de scrum. Normalmente é feito em pé, portanto, geralmente é chamado de stand-ups no PC. termos de agilidade cruzada, várias estruturas ágeis usarão o termo stand-up no Scrum, que é tecnicamente chamado de The Daily Scrum, mas é a mesma coisa. E o formato é cada membro diz o que fez ontem, no que está trabalhando agora e qualquer obstáculo, para que qualquer coisa esteja atrapalhando seu trabalho, eles possam levantá-la. Então. O objetivo é ajudar todos a se manterem responsáveis uns pelos outros. E também é uma boa chance de pedir qualquer ajuda de que precisemos. Não foi projetado para ser uma reunião longa. Normalmente, o prazo é de no máximo 15 minutos e é feito em pé. Portanto, todos são incentivados a mantê-lo curto e direto ao ponto. Então, se há algo que precisa de uma discussão mais aprofundada, você tinha o que chamamos de colocar isso offline. Então, organize uma reunião separada. Podemos discutir isso com as partes relevantes porque é provável que todos no Daily Scrum não precisem se envolver. Então, nós realmente nos limitamos a essas atualizações concisas. É útil ter seu prancha de sprint aberto enquanto você faz isso, para que as pessoas possam se lembrar no que estão trabalhando, conversar sobre os ingressos e mostrar ao resto da equipe onde estão os ingressos e como estão se movendo. 15. Refinamento de backlog: Uma reunião de refinamento da lista de pendências prepara os ingressos para o sprint. Então, quando você cria sua lista de pendências de produtos pela primeira vez, provavelmente não fornecerá tantos detalhes, pensando ok, página do produto, imagem do produto, produto, filmes. Manter as coisas bem simples nesse tíquete realmente não está pronto para ser contratado por um engenheiro para ser contratado para ser implementado. E é nisso que o refinamento da lista de pendências ajuda. Portanto, pode envolver toda a equipe do Scrum ou envolver, digamos, o proprietário do produto e talvez o engenheiro-chefe trabalhando juntos. E as tarefas do refinamento da lista de pendências R21 dividem o tíquete em seus menores pedaços. Portanto, se o ticket for a página de visualização do produto, ela pode ser dividida em avaliações e imagem do produto e a própria página em pequenos pedaços. Então, devemos garantir que o tíquete esteja pronto para ser usado. Então, aqui estamos falando sobre a elaboração dos ingressos. O que exatamente o proprietário do produto quer a empresa? A especificação é realmente clara. Há alguma nota técnica ou implementação que precisa ser adicionada ao ticket para que o engenheiro entenda o que precisa ser feito? Há alguma nota sobre os testes do testador para entender o que precisa ser feito? Há informações suficientes para que esse tíquete entre em um sprint, seja retirado e comece a trabalhar nele sem precisar fazer perguntas adicionais. E então analisaremos todos os bloqueadores. Então, por exemplo, se o ticket for adicionar as avaliações do produto à página de visualização do produto, esse tíquete será bloqueado pela criação de uma página de produto em formato shell view. Porque se essa página de visualização do produto não existir, você não poderá adicionar nenhuma avaliação a ela. Portanto, isso seria um bloqueador e precisaríamos levar isso em consideração. Portanto, para que um tíquete passe pelo refinamento da lista de pendências, ele deve estar pronto para ser colocado em um sprint. Isso significa que ele não tem bloqueadores, está pronto para e tem uma definição clara do que precisa ser feito. 16. Estimativa de pontos: Uma das coisas que você precisa saber antes de levar um ingresso para um sprint é, bem, quanto tempo isso vai levar? É um bilhete pequeno e um bilhete médio? Um grande bilhete. Precisamos de algum tipo de ideia aproximada sobre quanto tempo o tíquete vai levar para que possamos tentar estimar quanto trabalho podemos realizar no sprint que estamos tentando planejar no momento. Agora, no escopo, em vez de usar o tempo, usamos pontos. E os pontos são arbitrários, então não há necessariamente uma correlação de zero ponto que leve tanto tempo. O que você faz é ver, estimar os pontos ver quantos pontos você pode fazer em um sprint. E então, a partir de então , você sabe, ok, bem, eu posso fazer com que achemos que podemos superar dois pontos como equipe. Então, precisamos somar dois pontos na próxima vez. Agora, como isso funciona? Se você já precisa ter feito alguns sprints e descoberto quais são seus valores de pontos. Gostar. Como você começa com isso? Bem, aí você precisa inicialmente criar uma pequena ligação entre o tempo e os pontos. Então talvez você diga: “Bem, não adianta um dia para uma pessoa ou meio dia para uma pessoa”. Então, se você acha que o engenheiro vai levar dois dias para o teste ou um dia, e outro dia da hora de alguém ser implantado, então você diz, ok, bem, são quatro dias, então vamos chamar quatro pontos por enquanto. E, na verdade, todos os ingressos de forma semelhante. E então, à medida que você aperta os olhos, cresce e continua e obtém comida em vários sprints, você começa a ter uma ideia de, ok , bem, esse bilhete tem aproximadamente esses pontos. Portanto, a implementação levará muito tempo. Sabemos que podemos ultrapassar cerca de 30 pontos para correr. Assim, podemos trazer 30 pontos de coisas para o giro. Pontos de ingressos. 17. Pôquer ágil: Uma boa maneira de fazer estimativas de pontos é com o pôquer ágil. Com alguns desses cartões, você pode obtê-los, obtê-los em qualquer lugar. Assim, cada membro da equipe receberia um conjunto dessas cartas. E as cartas têm valores de pontos seguindo a sequência de Fibonacci. Então você tem metade de 0,123, 581320. Esses vão para 25, então eles compram muito pouco cartas. Você nunca teria bilhetes de 100 pontos. Você tem o infinito desconhecido. Então, a ideia é que todos recebam um conjunto desses. Todos os seguravam como um pôquer e você calculava, então você diz: Ok, vamos estimar esse bilhete agora. E talvez, talvez eu pegue esse. Talvez outro membro da equipe vá e pegue este. E então, uma vez que todos nós escolhemos, nós os entregamos. Eu saí de graça, outra pessoa vem por oito. Então, uma grande diferença que falamos sobre essa diferença e então concordamos com um valor em pontos, mas isso permite que todos forneçam uma estimativa independente. Então você pode descobrir se todos escolheram três , exceto uma pessoa. Provavelmente quero ir de graça depois de um pouco de discussão. Mas é uma boa maneira de obter a opinião independente de todos antes de se reunirem e discutirem os problemas e tentarem descobrir o valor dos pontos. 18. Velocidade: Falamos sobre essa ideia de que os pontos não precisam necessariamente coincidir os tempos. Você pode apontar para a complexidade aberta. Então, algo muito simples pode ser um ponto único. Algo realmente complexo pode ser, digamos, 13 pontos. E depois de fazer alguns sprints, você meio que tem uma ideia de quantos pontos você está conseguindo em um sprint. Na verdade, normalmente medimos isso. Então, vemos quantos pontos movemos para a coluna de enterrada em um determinado sprint e isso pode ser qualquer coisa. Então, digamos que a lata tenha atingido 35, 42 ou 47 pontos, seja o que for. Bem, se você tem esse histórico de sprint, então um sprint, você fez 55 quando fez 42, quando necessário, para sete. Bem, então você sabe que, em média, você obtém cerca de 38 pontos por sprint. Então essa média se torna o que chamamos de velocidade. Isso é o quão rápido estamos nos movendo e a rapidez com que estamos nos movendo, neste caso, normalmente é cerca de 38 pontos por sprint. Então, depois de calcular essa velocidade, então, você sabe, ok, bem, no próximo sprint, podemos trazer aproximadamente 38 pontos em coisas, porque isso é o quanto normalmente fazemos em um sprint. 19. Planejamento de sprint: planejamento do sprint acontece no início de cada sprint. Você concordará com a duração do sprint e, em seguida, calculará quantos pontos acha que pode concluir nesse período. Então, se você está fazendo, digamos, sprint de duas semanas e tem uma velocidade de 38 pontos, então você provavelmente ganha 38 pontos com os ingressos. Se, por algum motivo, encurtá-lo. Então, talvez fazendo um Sprint de uma semana, mapas digam que você provavelmente conseguirá superar cerca de 19 pontos na metade do tempo. Você calcula com quantos pontos você tem que jogar. E então você traz uma quantidade adequada de ingressos para preencher esse valor de pontos. Então, se você tem 38 pontos para jogar, acessa a lista de pendências de produtos e seleciona 38 pontos em ingressos, que se tornam sua lista de pendências de sprint. Então, essa é a lista de tarefas para o sprint em que você está trabalhando atualmente. Nesse ponto, a estimativa pode acontecer no refinamento ou no planejamento do sprint, se não tiver acontecido em refinamento, refinamento ou boa ideia. Se eles já foram feitos e você executa o planejamento de sprint, talvez algumas pessoas envolvidas no refinamento e no planejamento do sprint seja um bom momento para verificar se todos concordam com os pontos. E, portanto, esse é um trabalho razoável que você pode realizar neste sprint. Depois de terminar, você pode começar seu sprint e começar a trabalhar em todos esses ingressos. 20. Retrospectiva: A retrospectiva, também chamada de estrada retrô, acontece no final de um sprint. Aqui você analisa o que funcionou bem e o que não funcionou tão bem para que possamos descobrir o que queremos melhorar no futuro. É importante observar aqui que esta é uma reunião de processo e não uma reunião sobre o trabalho em si. Então, digamos que compramos um ingresso para o sprint e depois descobrimos que ele tem um bloqueador. E então não podíamos fazer nada. Isso não foi feito dentro daquele sprint. No retrô, não falaríamos sobre como desbloquear esse tíquete para que possamos concluí-lo. Mas podemos falar sobre coisas como, bem, não percebemos que ele tinha um bloqueador e, portanto, parado. E o que podemos fazer no futuro para garantir que não estamos trazendo ingressos que não possam realmente ser concluídos em um sprint. Então, você provavelmente comenta sobre alguns dos ingressos em que trabalhou e quais edições eles compraram. Mas não estamos comentando diretamente sobre o trabalho, mas mais sobre como podemos trabalhar juntos como uma equipe melhor no futuro para uma equipe americana ainda mais rápida e eficiente. Você pode fazer um retrô da maneira que quiser. Mas eu tenho algumas ideias para você na próxima lição. 21. Ideias para retrospectivas: Nesta lição, veremos algumas ideias de como realizar suas retrospectivas. Então, esse é realmente um ponto de partida e você tem suas próprias ideias, faz as coisas de forma criativa, se diverte com elas. Um dos clássicos é Start, Stop, Continue. Então, dê a todos da sua equipe uma caneta e alguns post-its e coloque-os na parede ou pare, comece e continue. E as pessoas podem escrever suas sugestões sobre coisas que devemos parar de fazer, coisas que devemos começar a fazer e coisas que devemos continuar fazendo. Portanto, neste exemplo, por exemplo, as sugestões são: deixará de comparecer às reuniões tarde e de ter longas discussões em stand-up. Talvez estejam atrapalhando. Então, no próximo sprint, a equipe se concentra deliberadamente em interromper esses comportamentos do que nos ácaros, coisas que queremos começar, como talvez as retrospectivas sejam sempre organizadas última hora, então reservar uma sala de reunião seria útil e depois as coisas continuem. Então, começamos a usar um novo servidor de testes há semanas, quando ele está funcionando muito bem. Vamos, vamos continuar fazendo isso. Outra forma de fazer isso é usar pontuações. Então, você pode ter títulos como : quão confiante você vai entregar este projeto? Quanta energia você acha que temos como equipe e como psicologicamente, o campo de segurança e cada membro da equipe podem dar um número de pontuação. Ele pode ser colocado lá anonimamente. E então você pode analisar esses números e mapear seu progresso ao longo do tempo. Então, talvez faça isso a cada dois meses e veja como isso muda. Mas também se você notar, nossa confiança diminuiu muito ou a segurança diminuiu muito. O que estamos fazendo como equipe para melhorar? Talvez falemos mais sobre esse assunto. Lean Coffee é um tipo de reunião que funciona bem em ambientes retrô e também está fora dos metrôs. E a forma como isso acontece é que não há uma agenda pré-estabelecida. Então, a primeira tarefa é criar uma agenda. E, novamente, talvez faça com que todos publiquem isso. Algumas pessoas escrevem o que querem discutir em um post-it, colocam na parede e toda a equipe pode votar em uma ordem para a discussão. Então você fala como se escolhesse as cinco principais coisas sobre as quais quer falar, novo cronograma, cada uma delas. Então, digamos que a equipe queira falar sobre a forma como estamos fazendo stand-ups. Em primeiro lugar, você define um cronômetro para 5 minutos e tem uma discussão para cinco minutos. E quando o alarme dispara , a equipe pode votar em qualquer um dos casos, queremos falar mais sobre isso Vamos continuar falando sobre stand-ups. Ou queremos passar para o próximo tópico. E se a equipe votar para seguir em frente, você pega a segunda postagem e fala sobre ela. E, novamente, você faz a mesma coisa. Ele ensinou por 5 min. Ao final desses cinco minutos, você decide onde isso precisa mais tempo ou quer seguir em frente. E, finalmente, a formação de equipes. Nem toda retrospectiva precisa ser trabalhada para que uma equipe trabalhe de forma coesa. Coisas como Smalltalk, coisas como jogar, coisas como atividades de formação de equipes podem ser muito importantes para prender essa equipe. Então, se a equipe está cansada ou não, é muito desafiador quanto você gostaria. Então, criar equipes e jogos divertidos também pode ser muito bom. 22. Formas de trabalhar: Uh, a forma de trabalhar em reunião é a equipe concordando em como eles vão trabalhar juntos. Portanto, cada equipe é diferente e os membros podem querer trabalhar de maneiras diferentes para equipes diferentes. Então, perguntas como: Bem, você pode pegar algum tíquete da lista de pendências ou ele tem que ser o melhor? Você o atribui à próxima pessoa ou deixa em branco e deixa para que ela escolha o que está em nossa definição de concluído. Quando as cerimônias acontecerão e quem vamos convidar? Quanto tempo durará o Sprint? Todas essas são questões de processo as quais a equipe precisa concordar. E você discutiria tudo isso em uma forma de reunião de trabalho. Normalmente , você precisaria se reunir quando estivesse formando uma nova equipe e começando a trabalhar. Mas também se muitos membros da equipe saírem e novos membros entrarem, ou se já faz algum tempo que você não sofre uma lesão e quer renegociar algumas das regras da equipe , convocar uma reunião de formas de trabalho é uma ótima maneira de fazer isso. A chave para o sucesso é garantir que todos tenham voz e tenham sua opinião sobre o que funciona e o que não funciona, como gostariam de fazer as coisas. E depois fazer com que todos concordem com isso, para que todos na equipe realmente acreditem nessa forma de trabalhar e trabalhem juntos para apoiar uns aos outros. 23. Revisão da Sprint: Uma revisão ocorre no final de um sprint ou após sua conclusão. O objetivo da revisão é revisar e demonstrar o trabalho que foi feito. Então, todos estão convidados, todos da equipe Scrum e também partes interessadas externas querem descobrir o que a equipe também está fazendo. A equipe se reveza para demonstrar cada um dos recursos. E pode haver perguntas de partes interessadas externas. Normalmente, mantemos essas avaliações até o final das avaliações, que mostram tudo e, em seguida, permitem algum feedback. Neste momento, todos os ingressos estão prontos. Portanto, se houver alguma mudança, se houver algo adicional que surja , deve ser criado como novos tíquetes. 24. Equipe do Scrum: O Scrum tem tudo a ver com trabalho em equipe e as equipes Scrum são multifuncionais. O que isso significa? Bem, antigamente, as equipes podiam ser organizadas por cargos. Então você teria uma equipe de designers aqui, uma equipe de engenheiros aqui, uma equipe de testadores aqui. E quando você quiser criar algo, mande-o para o pool de design. E o pool de design funcionaria em tudo e depois o devolveria. Então, qualquer coisa que precisasse de design para toda a empresa, procuraríamos uma equipe de design específica. As equipes Scrum não funcionam desse jeito. Eles são multifuncionais A equipe Scrum deve ter tudo o que precisa. Uma equipe Scrum teria, por exemplo, um designer e engenheiro, um testador, quaisquer que fossem os objetivos um analista de negócios de que precisássemos, pois tudo está contido na equipe. Então, em vez de precisar ir até os designers, até o engenheiro, o texto é tudo o que você precisa em uma equipe. Então, essas equipes são como uma unidade militar móvel que pode operar de forma independente sem ser bloqueada por outras equipes, sem precisar ir. Precisamos de um testador para isso, mas não há nenhum teste disponível. Tudo está contido na equipe. Então, quando estamos tentando superar nosso acúmulo de sprint, estamos tentando entregar nossos ingressos não foram bloqueados por outras pessoas. 25. Proprietário de produtos: O proprietário do produto é principal responsável pelo produto ou projeto. Então, eles se preocupam em tomar decisões e prioridades, sobre como será a aparência do projeto e como ele funcionará. Então, por exemplo, se pensarmos em nossa página de produtos de comércio eletrônico, como exatamente ela será? Para onde está indo, para onde, qual será a sensação da experiência do usuário? E também prioridades, como qual parte do sistema deve ser construída primeiro? Deveria ser a página do produto que verifica a navegação? Qual parte? Agora, o que não é uma função técnica. Então, quando eu digo como isso vai funcionar, isso é basicamente uma questão de experiência do usuário. É imaginar ser o cliente usando essa coisa, em vez de qualquer conhecimento técnico. Todo o conhecimento técnico residirá nos engenheiros e o proprietário do produto realmente não precisa saber como ele é implementado. Eles dizem o que querem que seja implementado. Agora, cada produto deve ter um proprietário de produto. Então, se você tem, está pensando em colocar dois proprietários de produtos no mesmo produto. Você provavelmente precisará dividir esse produto. Mas o proprietário de um produto pode cuidar de vários produtos. Portanto, se você tem muitos produtos pequenos, um proprietário de produto pode cuidar de vários deles. O que torna um bom proprietário de produto alguém que sabe o que quer, mas também é flexível quando algo não pode ser feito. Então, por exemplo , digamos que você esteja construindo uma casa. O proprietário do produto é a pessoa que diz: Ok, bem, eu gostaria de quartos, banheiros e garagem. Mas então, se a Comissão de Planejamento voltar e dizer, bem, você não pode ter uma garagem, você quer que o proprietário do produto esteja disposto a dizer, ok, bem, vamos mudar isso e eu especificarei outra coisa. Mas tem uma visão clara para dar à equipe, para dar aos engenheiros o que eles estão procurando. 26. Mestre do Scrum: O Scrum Master ajuda a equipe de scrum a funcionar sem problemas. Então, apesar do nome Master, eles são na verdade outro membro da equipe e estão no mesmo nível. Eles não são os chefes da equipe. Eles organizam e facilitam cerimônias, mas a pedido da equipe. Portanto, isso não precisa necessariamente ser feito pelo Scrum Master. Qualquer um pode liderar qualquer uma das cerimônias. Qualquer um dos membros da equipe pode se levantar e dizer: Bem, eu vou deixar o retrô, vou deixar o Scrum diário ou se preferirem, o ScrumMaster pode fazer isso. trabalhos típicos de um ScrumMaster podem envolver reservar salas de reuniões e facilitar as cerimônias, falar com outras pessoas sobre bloqueadores. Portanto, se a equipe precisar se comunicar com outra equipe para resolver algo com os mestres da escola, é uma boa pessoa para enviar para lá, representando a equipe em reuniões mais amplas da empresa. Falaremos um pouco mais sobre isso em Scaling Squirm. Mas, na verdade, sempre que a equipe precisa falar com a gerência, precisa falar com outro grupo. O escamoso é uma pessoa muito boa para representá-los , garantindo que as regras sejam cumpridas. Então, se concordarmos em uma reunião de trabalho, como se todos chegássemos na hora certa para nosso meio-dia Daily Scrum e as pessoas não chegassem na hora certa , normalmente cabe ao professor não repreendê-las , mas dizer: Ei, só um lembrete. Concordamos que todos estaríamos lá no meio e nenhum de vocês também está treinando e motivando a equipe. O scrum master normalmente tem um bom conhecimento de Agile e Scrum e pode trazer essas recomendações como ótimas maneiras de trabalhar em equipe e animar a equipe com o trabalho que está fazendo. 27. Analistas de negócios: Os analistas de negócios, também conhecidos como BA, estão envolvidos na coleta de requisitos. Qual equipe normalmente teria um ou dois BAs. E o trabalho deles é entender os requisitos do usuário e formar uma ponte entre o que o proprietário do produto deseja e o que os engenheiros precisam saber. O proprietário do produto pode dizer algo como Eu quero que os clientes rastrear suas entregas e ver onde estão suas entregas. O BA iria embora e dividiria isso em uma jornada do cliente. Então, por exemplo, o cliente , como cliente, eu quero poder ver meus pedidos como cliente. Quero ver os detalhes de um pedido específico como cliente, quero ver as informações de rastreamento de qualquer carreira em que o pedido esteja sendo enviado. Assim, eles pegavam solicitação geral dos proprietários do produto, dividiam em tíquetes e desenvolviam critérios de aceitação. Então, como saberemos quando isso for feito, por exemplo, se estivermos analisando um ticket como cliente, quero ver as informações de rastreamento. O critério de aceitação seria, por exemplo, que o cliente possa ler o número de rastreamento. O cliente pode clicar em um link para acessar o site de Carreiras e obter mais informações. E talvez esse seja o critério de aceitação desse ingresso. Portanto, o BA é responsável por traduzir esses requisitos gerais em mais específicos com os quais os engenheiros possam trabalhar. 28. Engenheiros: Os engenheiros ou as pessoas que trabalham na coisa, seja ela qual for, seja qual for o projeto em que você está trabalhando. Por isso, geralmente é chamada de Equipe de Desenvolvimento, mas inclui um campo mais amplo do que esse. Então, coisas como testadores, engenheiros de automação, engenheiros de garantia de qualidade, todas essas pessoas seriam incluídas nela. E isso realmente depende do tipo de projeto em que você está trabalhando e do que isso incluiria. Em um projeto de software, você teria seus engenheiros de software reais e provavelmente alguns engenheiros de automação de testes. E então o teste são eles mesmos. Mas se você está trabalhando em, digamos, um projeto de pesquisa, então você é engenheiro. A equipe de desenvolvimento seria, na verdade , a equipe de pesquisa ou os pesquisadores. Se seu projeto é construir uma casa, então podem ser construtores, trabalhadores para homens, esse tipo de coisa. De certa forma, não importa porque, no Scrum, há um foco real em trabalhar juntos como uma equipe para entregar tickets. Então, embora você possa ter suas funções individuais de Eu sou designer, sou engenheiro de software, sou um teste ou o que quer que seja, na verdade, o que realmente importa é o resultado da equipe. Então, onde quer que todos estejam cumprindo suas funções, fazendo coisas diferentes, ajudando uns aos outros. O importante é que todos trabalhem juntos para atingir a meta de entrega desses ingressos e não se concentrem tanto compartimentar todos nessa equipe de design. Esta é a equipe de implementação, essa é a equipe de testes. Há apenas uma equipe Scrum de todos contribuindo para o sucesso do projeto. 29. investidores: partes interessadas são pessoas de fora da equipe, mas com interesse no trabalho da equipe. Então, que tipo de pessoa pode não ser? Bem, alguns exemplos: gerentes de nossa empresa, membros de outras equipes trabalhando em soluções de projetos relacionadas, arquitetos e arquitetos técnicos trabalhando em toda a empresa. Equipes de marketing e vendas. setor jurídico também poderia estar envolvido e, potencialmente, coisas como clientes, fornecedores e reguladores também seriam partes interessadas. Os proprietários de produtos costumam convidar as partes interessadas para as avaliações do sprint e também são bem-vindos ao Scrum diário. Mas eles não teriam nenhuma opinião sobre o The Daily Scrum para que pudessem vir e ouvir, mas serão os membros da equipe Scrum que falarão. Normalmente, as partes interessadas não seriam convidadas para o planejamento ou a retrospectiva do sprint porque essa é uma zona segura para a equipe discutir seu funcionamento internamente. 30. Uma equipe típica do scrum: Vamos dar uma olhada em uma equipe típica de scrum. Então, dentro da equipe, provavelmente temos um proprietário de produto, um scrum master e um ou mais analistas de negócios. Então, um proprietário de produto, scrum master, normalmente um ou dois analistas de negócios. E então temos engenheiros. Os engenheiros cobrem, na verdade, qualquer um dos executores. Então, tipo desenvolvedores, designers, testes de controle de qualidade, pesquisadores se você está trabalhando em um projeto de pesquisa, e trabalhadores, se você está construindo uma casa, seja o que for, essas são as pessoas que fazem os ingressos reais. E então, fora da equipe, você tem partes interessadas. Portanto, isso pode incluir gerentes de empresas, membros de outras equipes, profissionais jurídicos de marketing e vendas, clientes e fornecedores e reguladores. 31. Adicionando membros da equipe: Se você está adicionando membros à sua equipe , como você considera isso? A quantidade de trabalho que eles podem fazer ao planejar futuros sprints. Bem, a primeira coisa que queremos fazer é calcular nossa velocidade e nossos pontos por membro da equipe. Então, digamos que nossa velocidade seja 48, e atualmente há seis membros na equipe. Então, podemos dividir 48 por seis e podemos ver que cada membro da equipe está produzindo aproximadamente oito pontos. Se adicionarmos um novo membro da equipe , saberemos que teremos mais oito pontos com os quais jogar. Isso significa que, no primeiro sprint, normalmente usamos um multiplicador de zeros. Portanto, presumimos que eles não colocarão nenhum ponto no primeiro sprint. Segundo sprint, ficaremos em forma se fossem oito pontos, aumentaremos o tempo em 0,5 e isso nos dará quatro pontos. E então, no terceiro sprint, presumimos que eles estejam atualizados e contribuindo, o que significa que podem dar todos os oito pontos para a equipe. 32. Tipos de edição: Nesta lição, veremos os problemas ou tipos de tíquetes. E há três principais. Então, a primeira é uma história de usuário. Portanto, essa é uma nova funcionalidade escrita da perspectiva de um usuário, de um produto, por exemplo , como usuário, quero poder ver avaliações do produto que estou vendo no momento. Isso adiciona algo novo ao sistema. Então temos um defeito ou um livro, um livro com um recurso existente que precisa ser corrigido. Já enviamos e ele precisa de uma solução. Por isso, precisamos levantar uma multa. Agora, o mais importante aqui é que só é um bug se não funcionar da maneira pretendida. Então, se construirmos algo de uma certa maneira e o gerente disser, eu quero que funcione de uma maneira diferente. Isso não é um defeito, é uma nova história de usuário mudando a forma como o sistema funciona. Se o bilhete original corresponder aos critérios de aceitação , não é um defeito. Se não fizer o que estava escrito no bilhete original, então o faça e aumente em massa. E então temos dívidas de tecnologia. Portanto, esses são problemas com o código que não têm efeito observável no sistema. Então, algo subjacente que o desenvolvedor sabe que precisamos corrigir, mas, na verdade, um usuário não necessariamente notaria. 33. Stories do usuário: Em Agile, escrevemos tickets como histórias de usuários. Isso significa que, em vez de ter um ticket que diz algo como um formulário de login, escrevemos algo como, como cliente, quero verificar o status do meu pedido. Agora, muitas vezes isso envolveria um formulário de login para que eles pudessem fazer login e ver seus pedidos, mas talvez não. Então, por que escrevemos isso nesse formato estranho de história de usuário? Quais histórias o mantêm focado no usuário. Então, nosso objetivo é que a jornada do cliente, que consiste em analisar tudo o que estamos construindo e escrevendo dessa forma que realmente mantenha o foco no usuário final. Em segundo lugar, evita trabalhos desnecessários. Então, se você tiver algo parecido, quero ver minhas faturas anteriores, aquelas que exigem um formulário de login. Na próxima lição, veremos um bom estudo de caso que mostra que talvez nem sempre seja esse o caso. E, portanto, podemos economizar algum trabalho se usarmos essas histórias de usuários. Isso cria critérios de aceitação muito claros. Se o seu tíquete, diz formulário de login. Bem, como saber se o usuário é capaz de alcançar o que deseja? Eles querem fazer o login? Que propósito isso lhes dá? Por outro lado, se for algo como eu quero como cliente, quero verificar o status do meu pedido. É muito claro onde o sistema V0 faz isso ou não. O cliente pode ver o status do pedido? Sim ou não? Você tem alguns critérios de aceitação muito claros. E é por isso que usamos histórias de usuários. 34. Estudo de caso de desenvolvimento baseado em comportamento: O que estamos falando aqui quando escrevemos histórias dessa maneira é o desenvolvimento orientado pelo comportamento. Essa é uma metodologia que diz que escrevemos o que os usuários devem ser capazes de fazer em inglês simples. E então esse se torna nosso critério de aceitação. Escrevemos testes automatizados para ver se o sistema está fazendo isso. E digamos que há uma grande quantidade de trabalho e eu tenho um estudo de caso para você. Então, havia uma empresa de contabilidade e o que eles queriam era para os clientes pudessem ver as faturas anteriores. Agora, se entrássemos nisso e o construíssemos da maneira normal, teríamos dito: Bem, tudo bem, precisamos de um formulário de login e cada cliente precisa de um login, então eles precisam inserir seu endereço de e-mail e depois precisam de uma senha. Então, o cliente, teríamos mais uma senha para lembrar nesse mar de milhares de senhas e ele provavelmente a esqueceria. Então, precisaríamos criar um link de senha esquecida que enviaria a eles uma nova senha por e-mail. Então, quando eles inevitavelmente esqueceram a senha, eles poderiam solicitar uma nova. Eles poderiam redefinir sua senha e, em seguida, fazer login e ver as faturas antigas. Em vez disso, esse produto usa essas histórias de usuário e desenvolvimento orientado por comportamento. Portanto, o critério de aceitação foi: como cliente, quero ver as faturas anteriores. Então, quando o projeto analisou as coisas dessa forma, eles perceberam que a coisa mais simples a fazer era permitir que o cliente inserisse seu endereço de e-mail. E isso lhes enviaria por e-mail um link mágico que lhes permitiria ver todas as faturas anteriores. Então, em vez de ter que criar todo o formulário de login e o formulário Esqueci a senha, em vez de o usuário precisar se lembrar outra senha analisando-a desse ponto de vista da história do usuário, todos perceberam que, na verdade a maneira mais rápida de fazer isso é um link por e-mail que permita acessá-la. E é tão seguro quanto ter um login, porque você tem acesso ao e-mail e eles podem ver todas as faturas anteriores sem muito trabalho de desenvolvimento e sem que o usuário precise armazenar outra senha. Usar essas histórias de usuários, usar essa abordagem de desenvolvimento orientada por comportamento pode economizar muito tempo e também produzir uma experiência melhor para o cliente. 35. Ser "bom o suficiente": Um conceito-chave aqui é a ideia de algo ser bom o suficiente. Precisamos criar o recurso até que ele atenda aos requisitos do usuário, aos critérios de aceitação. E então precisamos parar e fechar esse bilhete. E se precisarmos trabalhar mais tarde, podemos levantar uma nova multa. Mas, basicamente, o que tentamos cumprir, o que precisa ser cumprido, supondo que precisamos de todas essas coisas extras. Então, por exemplo, digamos que estamos falando que temos nossa loja de comércio eletrônico e você pode ver a página de produtos e queremos mostrar produtos similares. E talvez a história do usuário seja que, como usuário, eu quero ver produtos semelhantes a este. Bem, poderíamos começar e construir um sistema de IA extremamente complexo que recomendasse produtos. Mas também poderíamos simplesmente colocar produtos da mesma categoria que atendessem aos requisitos do usuário. E não acabaríamos com uma grande tarefa de desenvolvimento porque talvez apenas mostrar produtos similares e a mesma categoria fosse realmente ótimo. E podemos enviar isso muito rapidamente e isso funcionaria. Na verdade, não obteríamos nenhum benefício com a criação de um enorme sistema de IA para recomendar produtos. Ou talvez enviemos a coisa mais fácil. E então percebemos que, na verdade , obteríamos valor com melhores recomendações de produtos. qual ponto podemos construir a coisa melhor, porque sabemos então que vale a pena investir tempo. Isso é conhecido como metodologia Lean. Então, você divulga algo em nosso formulário básico. Você vê usuários como esse, vê o que eles respondem, depois reavalia e volta novamente, vê o que eles respondem, depois reavalia e volta novamente, assim como falamos sobre essas metodologias ágeis, você está iterando, entregando algo, dizendo como funciona, aprimorando-o, em vez de criar esse enorme produto do big bang que pode falhar desde o início. 36. Investir: Nesta lição, veremos o acrônimo de investimento que pode ser usado para boas histórias de usuários. Portanto, eu sou para cada independente, cada loja deve se manter sozinha e é negociável. As histórias não são corrigidas, mas podem ser atualizadas se necessário. Então, trazer essas informações e coisas como, mesmo quando você inicia a implementação, se algo não pode ser feito devido a requisitos técnicos, é frustrante, mas talvez você precise ver como reformular a história. Se for esse o caso, V é valioso, ele precisa agregar valor genuíno para o usuário. Como o usuário vai ter uma experiência melhor por causa dessa mudança? E é para estimável. Portanto, você precisa ter uma ideia aproximada de quanto tempo isso levará. Se você não conseguir estimar isso , o que provavelmente precisará fazer é levantar um tíquete de investigação. um ticket que é como um desenvolvedor, quero investigar quanto tempo seria necessário para implementar esse recurso. E então reserve um tempo para, digamos, meio dia e veja se você consegue calcular uma escala de tempo aproximada. E então, com base nessa escala de tempo, você saberá se deseja seguir em frente com o tíquete ou não. S é para pequenos, então ele pode ser entregue em um único sprint. Tudo o que está fazendo vários sprints precisa ser detalhado ainda mais. E T é testável. Critérios de aceitação claros, como um usuário saberia se esse tíquete foi concluído? E, idealmente, também automatizamos os testes. Então, estou realmente pensando em como podemos testá-lo na cobertura automática de testes desde o início. 37. Prototipagem e laboratórios de usuários: Uma estratégia cooperativa de Agile e Lean é construí-lo rapidamente, criar algo, basicamente, colocá-lo na frente do usuário e ver como isso funciona. Agora, uma boa maneira de fazer isso é com a prototipagem. Assim, você pode usar algo como o Adobe XD para criar interfaces de usuário simuladas. E então você pode dar isso a um usuário. Veja como eles usam o sistema, veja como se comportam, faça algumas alterações antes de você mesmo criar o complicado software. Como você faz isso? Bem, você simula isso em algo como o Adobe XD. E então você pediria um usuário da amostra que viesse talvez a um laboratório. Você os filmaria, filmaria a tela. Vá observá-los enquanto estão fazendo isso e apenas anote, ok, o que funciona para eles. Entre em um diálogo com eles, diga: Ok, ok , ok, eu gostaria que você encontrasse este produto. Como você faria isso? Eles vão navegar pesquisar e ver o histórico de pedidos para ver se o compraram anteriormente e podem encontrar o link dessa forma. Qual método será melhor para eles. Você dá a eles a demonstração pede que eles façam a tarefa. Você fala com eles sobre onde eles estão pensando em fazer com que eles falem sobre você, ok? Eu já disse, tente encontrar este produto. Em que você está pensando agora? E o usuário pode dizer: Ah, bem, eu provavelmente uso uma pesquisa, e pesquisar é minha forma favorita de fazer isso. E então eles poderiam pesquisar e chegar. Dessa forma, sabemos exatamente como um usuário deseja que o sistema funcione, se é onde podemos construir esse sistema e se podemos adaptá-lo às suas necessidades. Agora, muito disso é demorado, mas pedir a alguém que venha ao seu escritório, montar um laboratório onde você possa preencher o que está acontecendo ou assistir e dar a essa pessoa um conjunto de tarefas. Tudo leva tempo, mas esse tempo realmente compensa quando você entrega algo que está exatamente de acordo com o que o cliente deseja. Se você puder ver como eles usam o sistema, otimize-o e realmente receba esse feedback desde o primeiro dia. Inicialmente, leva muito tempo, mas seu tempo de desenvolvimento é muito menor porque você está construindo exatamente o que eles querem. Em relação aos sistemas tradicionais, você faria o grande bloco de desenvolvimento. Então, descobrimos que não era realmente o que eles queriam e temos reprojetar tudo investindo esse tempo cedo. Podemos então criar exatamente o que o usuário deseja e oferecer essa funcionalidade com mais rapidez. Isso mesmo, exatamente o que eles precisam fazer. E podemos fazer isso por meio de coisas como prototipagem rápida e laboratórios de usuários. 38. Requisitos funcionais: Os requisitos funcionais indicam o que o sistema deve ser capaz de fazer. Por exemplo, se dissermos que estamos tentando verificar o status do pedido, o requisito funcional pode ser que o usuário possa ver o status e os outros clientes não possam ver o pedido específico do cliente. Ou se estivermos construindo um sistema de login, por exemplo , por senha, por e-mail, meio de autenticação de dois fatores? E como estão as senhas? Reiniciar? Então, existe um mecanismo de reinicialização? Talvez os usuários devessem ser capazes, deveriam ser solicitados a alterar sua senha a cada 90 dias. Todas essas coisas são requisitos funcionais porque os requisitos funcionais documentam as funções do sistema. Eles documentam como o sistema funciona. Não é um pouco diferente dos requisitos não funcionais. E quando eu continuar a discuti-los, acho que você será capaz de ver a diferença de qual é qual. 39. Requisitos não funcionais: Requisitos não funcionais são coisas importantes ou essenciais, mas não afetam diretamente o funcionamento do sistema. Então, que tipo de coisas podem ser essas? Bem, coisas como desempenho, que rapidez o sistema responde? Disponibilidade e escalabilidade para alta carga? O serviço sempre estará disponível como monitoramento de segurança? Então, como você saberá se algo interrompe a reportagem? Podemos perguntar ao back-end? Podemos ver o que está acontecendo? Acessibilidade e usabilidade? Esses requisitos provavelmente mais funcionais agora muito importantes para eles e depois para a documentação. Como os futuros desenvolvedores ou usuários do sistema saberão como isso funciona? Então, observe que essas coisas não são opcionais, certo? exemplo, segurança e acessibilidade são requisitos legais porque nossos projetos precisam ser acessíveis. E se não tivermos segurança suficiente, violaremos a lei do GDPR. Então, essas coisas não são extras opcionais que todos precisam incluir, mas na verdade não fazem parte de como o sistema funciona. Por exemplo, se você tem uma página de status do pedido que mostra ao cliente onde está a entrega, esse é o requisito funcional de que a página informe onde está a entrega. Mas também há vários requisitos não funcionais . Então, por exemplo quão rápido uma página demora para carregar? Bem, poderia levar, não demoraria um segundo ou 1 minuto. Agora, se demorar 1 minuto, os usuários ficarão muito irritados e provavelmente sairão e farão compras em outro lugar. Mas, tecnicamente, se for exibido, que atenda aos critérios de aceitação usuário poderá ver o status do pedido. Portanto, não é tecnicamente um requisito funcional, mas é muito importante. Da mesma forma, a segurança, se outra pessoa puder ver o status do pedido, isso não necessariamente viola os requisitos funcionais. Mas seria muito importante porque exporíamos dados privados a alguém que não deveria ter acesso a eles. Portanto, é muito importante que pensemos requisitos não funcionais quanto nos requisitos funcionais. Mas eles são fáceis de esquecer. Esqueci de criar um recurso e você esquece de executá-lo no teste de segurança ou no teste de acessibilidade e o F ou algo fica confuso. É por isso que é muito importante incluir esses requisitos não funcionais na definição feita. Portanto, não permita que um ticket seja movido para a coluna concluído, a menos que tenha sido monitorado, a menos que tenha sido testado quanto à usabilidade, a menos que tenha sido testado o desempenho. Mas todas essas coisas em sua definição de feito e depois, você sabe, testá-las para que você saiba que tudo o que está incluído nela não as chama atendem aos requisitos funcionais e não funcionais. 40. Dívida de tecnologia: Há um tipo de multa que um engenheiro pode levantar: dívida de tecnologia ou dívida técnica. Então, isso ocorre quando fazemos algo para acelerar a entrega, sabendo que teremos que resolver isso mais tarde. Por exemplo, digamos que estamos criando algum software que talvez seja como um aplicativo meteorológico. O que ver se os dados meteorológicos vêm de uma fonte externa. E estamos usando a biblioteca a. Mas agora precisamos usar a biblioteca seja porque ela é melhor ou nos permite fazer algo e só queremos mudar para a biblioteca B. Uma maneira muito rápida de fazer isso seria trazer a biblioteca B para nosso aplicativo sem remover a biblioteca a como essa que ainda atendia aos requisitos se agora usássemos a biblioteca B, mesmo que a biblioteca a ainda estava incorporada ou trazida para a base de código de alguma forma. Agora, se fizéssemos isso, isso geraria uma dívida tecnológica. Como a biblioteca a ainda precisa ser removida em algum momento, ainda não fizemos isso. Agora, por que é importante lidar com a dívida tecnológica? Bem, primeiro, isso torna o código muito mais fácil ler se você é novo no projeto e está pensando : Ah, por que estamos usando a biblioteca be, mas também temos a Biblioteca a lá. O que está acontecendo lá? Isso pode ser muito confuso e, portanto, é mais difícil integrar pessoas. É mais difícil fazer trabalhos de desenvolvimento futuro. Isso pode retardar coisas como o processo de construção. Então, quando estamos compilando o software, se estamos trazendo duas bibliotecas, isso vai torná-lo maior do que o necessário para ser lento lá embaixo. Ou isso poderia afetar o desempenho, por exemplo, se fosse uma biblioteca JavaScript do lado do cliente. E estamos trazendo a biblioteca a, a biblioteca B, mas usando apenas a biblioteca be. Em seguida, carregaríamos a biblioteca a no navegador do usuário sem a necessidade dela. Portanto, ele tem muitos efeitos não funcionais, mesmo que não necessariamente afete a função do software. E essa é a dívida técnica e por que é importante enfrentá-la. 41. Cancelando um sprint: Em raras ocasiões, os requisitos do projeto podem mudar no meio do sprint. Temos esse princípio do Scrum de que nada de novo entra em um sprint. Então, definimos as tarefas que queremos fazer no início do sprint e, em seguida, iniciamos o sprint e as fazemos. E não trazemos mais ingressos até o próximo sprint. Então, o que fazemos se tudo em que estamos trabalhando se tornar irrelevante e não precisarmos mais cumprir as metas do sprint? Bem, nessas ocasiões, podemos cancelar um sprint e o proprietário do produto tem autoridade para cancelar o sprint. Eles acham que os requisitos mudaram e não adianta continuar trabalhando no que estamos trabalhando. Eles podem ir em frente e cancelar o sprint. Qualquer tíquete que estivesse funcionando, volte para a lista de pendências do produto e formamos um novo sprint. Então, temos uma nova reunião de planejamento de sprint. Descobrimos quando nosso papel de jornal será impresso e trazemos tíquetes de dados sobre novos tíquetes para atender aos novos requisitos. 42. O que é gerenciamento de lançamento ágil?: Quando falamos sobre Agile, estamos falando de pequenas iterações, pequenos recursos que criamos, que preparamos e depois os aprimoramos. Agora, algumas organizações adotam essa ideia de trabalhar com Agile, mas, na verdade, as implantações ainda são feitas de uma forma Big Bang. Então, há todas essas equipes ágeis trabalhando nos recursos de um software, mas o software só é lançado a cada dois meses e todos os recursos são lançados ao mesmo tempo. Então, quando falamos sobre o Agile Release Management, estamos falando sobre se livrar desse lançamento do big bang. Estou substituindo-o por um ciclo mais iterativo, pouco mais alinhado com o trabalho de desenvolvimento que estamos fazendo no sprint, nos sprints e nas equipes do Scrum. Portanto, a ideia é que você possa obter um conjunto de recursos e lançá-los independentemente dos recursos nos quais outras equipes estão trabalhando. Então, diga equipe a, crie alguns recursos e os implante e construa alguns recursos com base em equipe e eles serão implantados separadamente. Podemos até estar falando sobre ingressos individuais. Então, o TMA finaliza um tick como parte desse acabamento, ele está se fundindo com a base de código principal, implantando-a e implantando esses problemas um de cada vez. Seja qual for a forma exata de gerenciamento ágil de versões, acaba sendo implementada. Trata-se de reduzir esse ciclo de desenvolvimento, esse ciclo de vida do software, para que possamos obter pequenas funcionalidades sem ter esses lançamentos do big bang, em que lançamos muitos recursos ao mesmo tempo e não fazemos muitos lançamentos e dizemos que queremos pequenos lançamentos regulares de acordo com o processo ágil. 43. Ciclo de gerenciamento de lançamento: Todo desenvolvimento passa por um ciclo. E, nesse caso, analisaremos o ciclo de gerenciamento de lançamentos. Portanto, você pode começar a qualquer momento, mas começaremos pela parte superior com solicitações de mudanças. O proprietário do produto quer que algo mude. Por isso, projetamos uma solução, criamos alguns critérios de aceitação que implementariam essa mudança. Em seguida, criamos e escrevemos o código e o enviamos para outra pessoa para análise, para que ela possa verificar se o código faz sentido e é uma boa ideia. Em seguida, testamos para garantir que funcione e, se for aprovado, implantará esse trecho de código. Em seguida, teremos alguns tipos de métricas, que são relatórios sobre seu desempenho. E se houver algum problema , faremos o possível para relatar alguns problemas. Trabalharemos juntos como uma equipe para resolver um defeito ou criar outra história de usuário para alterá-lo. E então isso realimenta a solicitação de mudanças. 44. Vantagens do gerenciamento de lançamento ágil: Por que gostaríamos de fazer lançamentos ágeis? Bem, aqui estão as vantagens reais do processo de lançamento do Agile. O número um é que ele faz as coisas saírem mais rápido. Então, nosso objetivo é encurtar esse ciclo de desenvolvimento. Assim, você cria um recurso, o lança imediatamente pode começar a receber feedback sobre ele imediatamente. Se for uma mudança importante, ela sairá mais rápido, agrupando em uma versão maior no futuro. Número dois, ele funciona de acordo com o Agile. Então, se você tem todas essas equipes de Scrum trabalhando dessa forma muito ágil, por que seu processo de lançamento não suportaria isso? Por que voltaríamos repentinamente à abordagem do big bang, que tem todos os riscos de fracasso. Número três, ele permite que a equipe de scrum assuma a responsabilidade pelo lançamento. Então, da maneira antiga, todas as equipes desenvolviam coisas e, em seguida, parte da equipe teria que assumir a responsabilidade de lançá-las, analisar os bugs e monitorar o impacto das frutas. Quando você o devolve a um processo ágil em que cada equipe pode lançar os recursos nos quais está trabalhando. Então, a equipe de scrum pode assumir a responsabilidade por tudo isso. Eles podem expandir os recursos, monitorar o que está acontecendo. Eles podem fazer uma reversão, se necessário. Na pior das hipóteses, há alguns problemas e eles precisam fazer isso. Mas isso se encaixa na ideia de que as equipes Scrum são unidades independentes, multifuncionais. Eles assumem a responsabilidade pelo tíquete do início ao fim e podem orientar todo o processo sem serem bloqueados por outras equipes. E número quatro, pode ser mais seguro. Então, há esse tipo de mentalidade da velha escola da ideia. Ao criar todos esses recursos, você os entrega aos testadores e seu texto é incluído em todos esses cenários para garantir que tudo funcione em conjunto. Mas a realidade é que quando você lança 100 recursos de dez equipes diferentes ao mesmo tempo, eles provavelmente interagirão de maneiras que você nem imaginava e é muito provável que as coisas corram mal. E quando as coisas correm mal, é muito difícil reverter, porque você está revertendo 100 recursos de dez equipes. Quando você permite esses lançamentos iterativos muito pequenos. Então, se uma versão der errado, é muito fácil revertê-la porque você só muda uma coisa. E a equipe que o mudou está gerenciando o lançamento para que eles possam reverter rapidamente. Eu diria que o Agile Release Management não é apenas mais rápido e melhor, mas também mais seguro. 45. Horários de lançamento comuns: Vamos dar uma olhada em alguns cronogramas de lançamento comuns. Todos eles. estilo mais antigo seria o que chamamos de lançamento do Big Bang. Portanto, é um grande lançamento para várias equipes e uma grande equipe de teste revisar todos os recursos. Então, esse é o tipo de, digamos que você tenha três equipes diferentes trabalhando em um produto. Você está trabalhando como Microsoft Windows nove e quer lançar o Microsoft Windows 10. Então, todas as equipes que trabalham nisso fazem todas as mudanças e você as libera. Big Bang, que é o Windows 10 tem todas as mudanças ao mesmo tempo. E você precisa de uma grande equipe de testes para analisar todos os recursos, porque todos estão fazendo essas mudanças e não está claro como eles interagirão ou como as coisas falharão porque você precisa testar tudo novamente. E por isso é muito lento. Então temos algo como um sprint. Então, aqui estamos entrando em nosso processo de lançamento mais ágil. Então, um lançamento no final de cada sprint. É bom porque tem um cronograma de lançamento muito previsível. E qual é o objetivo? exemplo, você pode ter algumas talas em que tem muito para liberar e alguns sprints em que não tem muito o que liberar. Então, você provavelmente quer obter essas coisas quando está produzindo muitas coisas que podem sair, você provavelmente quer retirá-las mais rápido. E quando você não está produzindo muitas coisas que precisam ser enviadas, então por que você faria isso, por que lançaria? Portanto, isso cria um pouco de flexibilidade lá. Descendo, temos essa ideia de lançamento de recursos. Então, liberado manualmente, cada recurso está pronto. Assim, a equipe do Scrum preparará um recurso. Em seguida, você o mesclará manualmente na base de código e o lançará. Rápido. Pequenas mudanças. É bom e fácil de reverter. É necessário algum gerenciamento, como se fosse um processo de liberação manual. Mas isso ocorre mesmo no mundo ágil, que tem empresas que realmente adotaram o lançamento de recursos ágeis ainda é muito popular porque oferece mudanças tão rápidas e pequenas sem correr os riscos de contínuas, sobre as quais falaremos a seguir. Então, contínua é quando toda mudança, assim que você mescla algo, ela é enviada para o servidor de produção. Hum, então é super rápido, muito fácil de reverter porque você está enviando uma única confirmação. Então, quando você está revertendo as coisas, a única coisa que você precisa considerar é que a última confirmação fica um pouco complicada se você perceber que ela está quebrada. E então talvez você precise ter vários commits de volta. Mas se você está apenas lançando um, testando, se ele funciona na produção e depois em frente e pode avançar muito rápido. Mas isso exige um nível muito alto de cobertura de teste, porque literalmente tudo será retirado e, portanto, pode quebrar a qualquer momento. E você realmente precisa desse alto nível de cobertura de testes para garantir que tudo esteja funcionando. 46. Chaves para o sucesso: Aqui estão algumas chaves para o sucesso do Agile Release Management. O número um é obter a adesão da gerência. Isso vale basicamente para tudo o que você faz. Se você conseguir incorporar a gerência, terá muito mais facilidade. E, como discutimos anteriormente, há algum tipo de gerência da velha escola que prefere lançamentos do Big Bang porque acha que são mais seguros. Então, eu costumo me concentrar em realmente vendê-los com a ideia de na verdade, se fizermos esses lançamentos muito pequenos poderemos reverter com muita facilidade. E isso seria apenas lançar uma coisa vez para que saibamos como ela interage com todo o resto. É mais seguro. Portanto, não só vamos obter seus recursos mais rapidamente, mas também faremos com que as coisas corram mal com menos frequência. A segunda é projetar recursos com a implantação em mente. Então, quando você está criando um recurso, como você vai divulgá-lo? Um ótimo exemplo são coisas como interruptores de recursos. Assim, você pode implantar o código se colocá-lo atrás do switch de recursos e ativá-lo posteriormente. Então implante o código, ative o recurso. Se não funcionar, basta desligá-lo imediatamente e não precisa entrar em pânico. E se você puder pensar com antecedência em quais são as etapas que eu precisaria para implantar esse tíquete, você achará muito mais fácil fazer esses lançamentos. O número três é ter um bom plano de reversão. Se algo der errado, você pode reverter rapidamente? Tradicionalmente, na metodologia em cascata, não temos um bom método para fazer isso, mas é muito mais fácil quando estamos fazendo esses lançamentos muito pequenos e muita confiança se, mesmo quando as coisas correm mal, basta digitar esse pequeno comando. Ele rola por toda a parte traseira automaticamente e está tudo bem. Número quatro, tem alta cobertura de testes automatizados. Portanto, você quer ter certeza de que depois de fazer a alteração, você possa executar toda a jornada do cliente em todos os cenários que você precisa fazer automaticamente usando todas as ferramentas de teste automatizadas disponíveis. Porque quando você está fazendo lançamentos muito pequenos , você vai querer testar constantemente. Você faz uma mudança, testa tudo e faz uma mudança, testa tudo. A única maneira de cobrir isso é com testes automatizados porque você não poderia ter testadores suficientes para fazer todos esses cenários. Portanto, se você obtiver essa cobertura de teste, isso dará muita confiança para você e para a gerência de que as coisas funcionarão. E número cinco, coordene com outras equipes. Certifique-se de saber o que as outras equipes estão fazendo e como elas podem interagir com você. E também em termos de agendamento de um ucraniano lançado esta manhã, eles estão fazendo e lançamentos pela manhã, como você vai saber quando ele pode se revezar para fazer esses lançamentos, que você possa divulgar as coisas de forma rápida e eficiente. E então vocês não vão pisar nos pés um do outro. 47. Integração contínua: A integração contínua executa os testes automatizados após cada confirmação. Então, pode ser que toda vez um desenvolvedor envia algum código, ele o executa, ou pode ser que toda vez que um ticket é mesclado com um master, você queira executá-lo nessas filiais, dependendo de quanto você deseja gastar em suas ferramentas de integração contínua. Agora vou mostrar um exemplo aqui usando o Travis, que é apenas uma das opções disponíveis. E eu tenho esse projeto aqui, que é um ambiente de aprendizado de código aberto. E eu defini um arquivo de configuração aqui apenas para dizer ao servidor de integração contínua que ele está escrito em PHP. E eu queria testá-lo novamente, de repente, ponto 4.8, 0.0. E aqui estão todas as etapas necessárias para configurá-lo. Isso significa que, quando eu pressiono um commit, ele executará as tarefas tanto no PHP quanto no PHP 7.01. Podemos entrar neles e ver o que aconteceu. Travis estabeleceu tudo. Ele executa a instalação conforme solicitado e , em seguida, executa a unidade PHP para executar os testes e é aprovado. Então isso é ótimo. E então ele é feito exatamente a mesma coisa aqui, mas está funcionando novamente, 7.4. Portanto, se você tiver várias configurações de produção diferentes, poderá testar o servidor de integração contínua em todas essas configurações. E eu também posso ver uma história completa. Então, se eu acessar o histórico do Build, isso mostrará que toda vez que eu pressiono um commit, ele fez uma compilação. E, por exemplo, aqui, tivemos um que falhou na construção. Então, podemos entrar e não podemos mais ver os registros, infelizmente, mas sabemos que algo deu errado lá. E então eu conserto outra coisa aqui. Então, nesse caso, ele estava mudando a versão do PHP para corresponder ao servidor. E podemos ver que a construção está funcionando novamente. Portanto, é muito fácil de rastrear. Você pode executar os testes automatizados uma variedade de ambientes e ver facilmente o que está errado, pois pode ver exatamente onde a compilação parou de funcionar. 48. Entrega contínua: Um passo à frente da integração contínua é a entrega contínua. Então, aqui, o código passa automaticamente por todos os testes automatizados e é implantado automaticamente em seu ambiente de produção. Agora, isso não significa que você está implantando cada confirmação. Portanto, há várias estratégias de ramificação. Você poderia usá-lo, você poderia tê-lo para ter uma filial de produção. E toda vez que você mescla algo do master à produção, ele executa todas as tarefas automatizadas. E se isso funcionar, eles sobem sem qualquer intervenção humana adicional. Ou você pode colocá-lo onde o Master está sentado em seu ambiente de produção. E toda vez que uma equipe mescla ticket individual em master, ela executa todos os testes e é implantado automaticamente. O que isso é, está tirando a ideia de implantação manual. Portanto, um tíquete pode mesclar uma parte do recurso em que todos os testes são executados automaticamente e, se estiverem corretos, são enviados para o ambiente de produção. 49. Ferramentas de entrega contínuas: Há uma grande seleção de diferentes servidores de construção e ferramentas de integração contínua disponíveis. Nesta lição, discutiremos alguns deles. O primeiro a mencionar é provavelmente Jenkins. Portanto, esse é um servidor de automação de código aberto. Então você precisa hospedar isso sozinho. Você precisa ter um servidor em sua organização e executar o Jenkins sozinho. Mas é de código aberto, é gratuito e você pode executá-lo internamente. Depois, temos os ambientes hospedados aos quais normalmente se conectam. Se você tiver algo como um repositório do GitHub, ele se conectará a ele e extrairá seu código de lá. Então, temos Travis CI, qual mostrei o exemplo. E então também temos um CircleCI. E se você preferir manter as coisas no GitHub , o GitHub realmente tem uma coisa chamada GitHub Actions, que permite que você faça processos de CI e CD e, obviamente, se conecta muito bem se seu repositório estiver lá ou você puder usar uma plataforma como Get lamp. É como um servidor de integração contínua e um hub integrado em um. Portanto, é tanto para o servidor Git quanto criar seu software para você. E então o Team City é outro servidor de integração contínua que também é muito popular. 50. Software ágil: Até agora, fizemos coisas principalmente com planilhas e as publicamos. E essa é uma ótima maneira de aprender os fundamentos e entender como os sistemas funcionam. Mas em um contexto de negócios, muitas dessas coisas normalmente são feitas usando um software de gerenciamento de projetos. E isso é muito bom, especialmente se você tem uma equipe remota as pessoas estão em todos os lugares e todas precisam poder ver o tabuleiro e, em seguida, onde estão os ingressos. E você tem todos colaborando juntos. É aqui que o software de gerenciamento de projetos realmente se destaca. Então, neste módulo, vamos explorar algumas dessas soluções que já estão disponíveis para você usar. 51. Jira: Jira é possivelmente a ferramenta mais popular para fazer scrum online. Então, vamos em frente e criar um projeto aqui. Vamos chamá-la de loja de comércio eletrônico. E vamos mudar nosso modelo aqui para limpar. Perfeito. Sim, parece bom. Vamos seguir em frente e criar isso. Vou deixar de usar nenhuma ferramenta por enquanto. Ok, ótimo. Então, temos nossa lista de pendências aqui. Então, abaixo disso, temos nosso roteiro. Aqui, temos uma lista de pendências para que possamos começar a adicionar problemas à lista de pendências, se quisermos. Ou podemos começar a adicionar coisas também. Então, aqui esta página do produto é meio épica. E eu vou dizer que, como visitante, quero ver o título do produto. Como visitante, quero ver uma foto do produto. Como uma visita. Quero ler as avaliações dos produtos. Então, poderíamos adicionar outra época aqui. Então, poderíamos dizer Portal de Gerenciamento. E então, como gerente, quero ver a lista de pedidos. E, como gerente, quero despachar e fazer pedidos. Essa guia de roteiro permite o UPS. Em vez disso, criei esses épicos. E ajudaria se eu soubesse soletrar. Vamos despachar e fazer o pedido. Ótimo. Então, isso provavelmente não nos permitirá excluí-los, mas vamos tentar. Lá vamos nós. Então, podemos entrar em cada um deles e adicionar uma descrição. E então podemos adicionar alguns pontos da história aqui. Então, talvez muitos. Digamos que sejam três. E esse é cinco. Este vai ser um dois. E esse também vai ser um cinco. Ótimo, então temos alguns valores de pontos. E se tivermos uma lista de pendências, podemos começar a organizá-las em sprints. Então, aqui temos nosso primeiro sprint. E podemos arrastar alguns desses tíquetes dentro. Então, temos os tickets da nossa página de produtos n, os deixamos na lista de pendências. E se apertarmos Start Sprint do que isso, agora estamos na guia do tabuleiro. E aqui temos nossa prancha. Então, podemos adicionar algumas colunas aqui, se quisermos. Poderíamos chamar isso de revisão de código. Vou colocar isso lá. E também adicionaremos um para testes. Coloque isso aí. Então, se eu quiser começar com um tíquete, posso atribuí-lo a mim mesmo. Eu posso enviá-lo para o modo em andamento. E aqui temos nosso quadro À medida que atualizamos todos esses tíquetes, você atualizará para todos. E, obviamente, ao convidarmos os membros da nossa equipe , eles também poderão ver os tíquetes se movendo pela tela à medida que os transferimos. 52. Gráfico de gravação: Portanto, uma métrica importante que você deve observar em seu sprint é o Burndown Chart. Então, se clicarmos neste botão Insights aqui, podemos ver que temos esse progresso de sprint que nos diz qual porcentagem é feita está em andamento ou não foi iniciada. E também temos esse Sprint Burndown Chart aqui. Então eu o defini como um sprint de duas semanas. E podemos ver, em teoria, que deveríamos completar esse número de pontos. Então, na metade, devemos estar na metade dos pontos. Então, à medida que transferimos esses tíquetes, apenas atualizamos que agora podemos dizer que estamos 100% em andamento, mas nada foi feito ainda. Mas então, se eu pegar um desses tíquetes e movê-lo para Concluído. E, novamente, vamos atualizar. Agora estamos em, agora estamos 56 por cento concluídos, 44% incompletos. E podemos ver que nosso gráfico detalhado parece muito bom porque queremos essa linha azul, que é o trabalho feito para chegar a zero antes daqui. Portanto, precisaríamos atingir essa linha para alcançá-la. Se estiver aqui, não estamos concluindo o trabalho tão rápido quanto pensávamos que faríamos. Se estiver aqui embaixo , estamos concluindo o trabalho mais rápido do que pensávamos. 53. Trello: O Trello é uma ferramenta muito simples para criar quadros e listas de tarefas. Então, eu tenho um quadro totalmente novo aqui e podemos adicionar qualquer coluna que quisermos a e talvez adicionemos uma em andamento. Se eu souber soletrar. E depois uma revisão do código, teste e pronto. E então eu posso começar a adicionar coisas aqui. Então, eu quero ver o nome do produto. Como visitante, quero ver uma foto do produto. Diga visitante. Quero ler as avaliações dos produtos. E depois, podemos clicar neles. Eu posso atribuí-los a mim, por exemplo, eu posso adicionar uma descrição, então salve-a. E então minhas pequenas fotos, porque eu as assinei, posso colocá-las em andamento. Agora, o que o Trello não fará porque é muito simples começar a usar o Trello . É isso. Estamos em alta agora. Isso não nos fornecerá todos os relatórios que algumas das ferramentas mais avançadas farão. Mas é ótimo para projetos pequenos, projetos simples ou projetos que você só quer continuar, seguir frente e não quer perder muito tempo brincando porque você pode facilmente criar esses pequenos quadros, compartilhá-los com sua equipe e fazer com que todos trabalhem muito rapidamente. 54. Mural: Aqui está outra ferramenta chamada Miro, que tem muitos modelos. Então, quando você o carrega pela primeira vez e nós o teremos, você pode usar esses laços de amizade pendurados. Mas se você optar pelo Agile, ele tem muitas coisas legais. Então, por exemplo , ele tem um modelo retrospectivo, Start, Stop, Continue retrospectivo. Muitas coisas sobre as quais falamos. Ou podemos reduzir até a planilha de cinco porquês, muito boa para navios de guerra, retrospectiva de equipes e contorções diárias. E isso traçará uma visão geral. E, novamente, prováveis orbitais. Você pode compartilhá-lo com todos os membros da sua equipe e, em seguida , começar a usá-lo. 55. Construindo segurança psicológica: A segurança psicológica é saber se os membros da equipe sentem que têm a confiança necessária para expressar seus pensamentos e ideias. E é realmente responsabilidade da equipe construir isso. Porque, infelizmente, muitos de nós tivemos a experiência de não querer falar abertamente. Não queremos compartilhar ideias porque estamos preocupados. Seremos julgados, gritados, demitidos, seja o que for. Esses não são ambientes psicologicamente seguros. E no Scrum, reconhecemos que cada membro da equipe tem algo realmente valioso para apresentá-los e comentar sobre eles. Então, se pudermos criar segurança psicológica para que mais membros tímidos ou da equipe, ou mesmo qualquer membro da equipe, possam realmente ser honestos sobre seus sentimentos ou opiniões , isso é realmente benéfico. Então, como construímos segurança psicológica? Bem, estabelecê-lo verbalmente e de forma funcional é uma ótima maneira de apenas ressaltar que a opinião de todos é válida. Então, escrever isso e ter tudo isso concordando, como equipe, que realmente queremos essa contribuição e que não vamos julgar. Vamos ouvir e respeitar a opinião de todos , ajuda muito a construir essa segurança. As boas regras podem incluir: não há problema em cometer erros. Se tivermos uma cultura de julgamento e culpa, as pessoas não admitirão seus erros e , portanto, não aprenderemos nada. Por outro lado, se estabelecermos uma cultura em que não culpamos as pessoas pelos erros, apenas observamos o que deu errado e como podemos garantir que isso não aconteça novamente, é mais provável que as pessoas sejam honestas. E, portanto, podemos resolver esses problemas. Ter a opinião de todos é valioso, é só ter isso como regra: muitas pessoas podem achar que sua opinião não é importante. Portanto, se toda a equipe concordar que a opinião de todos é importante, isso pode realmente incentivar algumas pessoas a serem mais abertas. Ter uma cultura de respeito, respeitar a ideia de tampões e não interromper. Provavelmente todos nós já estivemos em reuniões em que uma pessoa continua interrompendo e isso é muito irritante, é rude e é desrespeitoso. E a pessoa que está sendo interrompida acabará desistindo e não compartilhando suas ideias. Então, se estabelecermos essa ideia de que, quando alguém está falando, não o interrompemos, o que deveria ser uma maneira básica, mas muitas vezes precisamos de um pouco de lembrança. Então, essa pode ser uma ferramenta muito útil Uma das maneiras pelas quais podemos construir isso é garantir que haja retrospectivas regulares para garantir que as pessoas tenham sua opinião e que as pessoas possam falar sobre como pensam que as coisas estão indo e como estão confiantes na equipe. E pode ser muito bom retirá-los do local. Então, se você tem um escritório aqui, talvez você tenha uma cafeteria aqui. Pode ser muito bom entrar naquela cafeteria ou ir para outro lugar. Basta tirá-lo do escritório para que as pessoas se sintam como se estivessem no escritório, claramente como o domínio do gerente. E podemos ficar um pouco mais nervosos se você levar isso para ambiente mais descontraído, como uma cafeteria, que também pode realmente ajudar as pessoas a se abrirem. 56. Reuniões de levantamento: As reuniões de adoração acontecem após a conclusão de um projeto, mas também, provavelmente, o mais importante depois que algo dá errado. Este é um momento em que as pessoas estão preocupadas com a culpa. Portanto, o objetivo da reunião é realmente descobrir o que aconteceu e o que podemos fazer melhor na próxima vez. É muito importante enfatizar que não é uma investigação, mas tentar encontrar algumas pessoas para culpá-las e puni-las por isso, mas apenas entender o que aconteceu e onde podemos consertá-lo. Então, da próxima vez , podemos fazer melhor. Agora, uma ferramenta muito boa em reuniões de adoração é usar o que é chamado de Cinco Porquês. Então, perguntamos por que cinco vezes. E quanto mais fazemos isso, mais chegamos à causa raiz do problema. Então, digamos que tivemos uma falha no servidor e as equipes se reuniram para uma reunião de encerramento. E podemos dizer: por que o servidor falhou? Quando, por quê? Bem, ficou sem espaço em disco. Ok. Por que ficou sem espaço em disco? Bem, os pulmões o encheram e havia tantos registros que ele encheu todo o disco rígido. Então, por que o servidor ficou cheio de registros? Bem, não havia configuração de monitor no servidor para nos alertar quando o disco rígido estava 80% cheio. Por que não havia configuração do monitor? Bem, não estava em nossa definição de concluído quando estávamos criando o servidor, então esquecemos de fazer isso. Por que não estava em nossa definição de feito? Bem, nunca tivemos uma reunião de trabalho para a equipe resolver isso. Assim, podemos ver que quando fazemos todas essas perguntas sobre o porquê e continuamos pesquisando, continuamos investigando um problema que pode parecer que, à primeira vista, foi a queda de um indivíduo. Foi alguém que deixou o servidor falhar. Na verdade, na causa raiz disso. É um problema de equipe e algo que podemos fazer melhor na próxima vez. Podemos ter formas de trabalhar. Podemos melhorar nossa definição de concluído. Podemos voltar e analisar isso, melhorar o monitoramento. Todas essas coisas surgiram porque continuávamos perguntando por que ir à raiz do problema, em vez de pensar na culpa. O ponto chave sobre a reunião de adoração é realmente falar. Falamos sobre segurança psicológica, construindo esse ambiente. Bem, não estamos culpando, estamos apenas analisando o que deu errado para sabermos o que podemos mudar no futuro. 57. Vender ágil para gerenciamento: metodologia ágil pode parecer ótima para muitos de nós, mas gestão nem sempre está de acordo com ela. Então, como podemos convencê-los que é uma maneira melhor de fazer as coisas? Bem, primeiro, devemos considerar quais preocupações, quais preocupações a gerência pode ter. Primeiro, é uma mudança. A mudança pode ser assustadora. É uma maneira diferente da maneira como eles fizeram as coisas antes. Portanto, se uma empresa teve sucesso ou pelo menos está lidando com isso até agora, então muda. Sempre há um elemento de risco lá dentro. Pode parecer que leva muito tempo para fazer qualquer coisa, em vez do tipo de método antigo em cascata, que é eficiente se funcionar perfeitamente. Nephron funciona perfeitamente, é claro, mas hipoteticamente poderia, enquanto estamos vendendo gerenciamento e ideias. Ok, bem, vamos criar uma página de produto em branco. Então vamos colocar um título nele. Em seguida, vamos colocar uma imagem nela e vamos lançar , mostrar e revisar todas essas coisas nesta etapa Você pode parecer que vai levar anos. E também capacita equipes em vez de gerentes. E isso é assustador se você é gerente e está acostumado a microgerenciar e controlar tudo. E então alguém apareceu e disse: temos essa metodologia de scrum e é muito bom capacitar a equipe para fazer o trabalho, então eles podem ficar nervosos com isso porque gostam de ser controlados. Então, como lidamos com esses medos, essas preocupações? O número um é um documento com falhas dispendiosas e processos de aprovação lentos. Então, se houver, digamos que o big bang seja lançado e continue e leve horas para revertê-lo. E há todo tipo de reclamações, então isso é ótimo para documentar. Ou, se esse processo de aprovação demorar quando você quiser, você lança um recurso e leva duas semanas. E os termos do produto perguntam: onde está, onde está? E você está dizendo, bem, que será lançado no próximo lançamento, mas fazemos lançamentos para toda a empresa, então não podemos fazer nada do que você apresentará, será comer até tarde. E então perdemos um documento de prazo, tudo isso. Porque se você puder ir até a gerência e dizer: Olha, houve um grande fracasso porque fizemos os lançamentos do Big Bang. Aqui, perdemos um prazo importante para mudar algo porque tivemos que esperar até o próximo lançamento. Essa é uma boa evidência de que o processo em vigor atualmente não está funcionando. Número Para focar nos benefícios de uma entrega mais rápida, os gerentes geralmente gostam de divulgar as coisas o mais rápido possível. Então, se pudermos contar a eles, olha, esse recurso que você pediu levou oito semanas para ser feito. Depois, houve mais duas semanas esperando por um alívio. E, na verdade, achamos que podemos obter uma versão básica dessa metade desse tempo, incluindo o lançamento. Nem precisaremos esperar até o próximo lançamento. Isso vai ser um grande argumento de venda. E falamos anteriormente também trazem essa ideia de segurança. Essa ideia, se estivermos fazendo lançamentos pequenos, mais fáceis de reverter , teremos menos dessas falhas catastróficas. O número três é falar sobre equipes mais felizes. Geralmente, as equipes preferem trabalhar de forma ágil em vez de em cascata. De uma forma em cascata, a equipe não está realmente no controle. Funciona em uma parte do sistema. Não se responsabiliza por isso. Não supera isso, não capacita a equipe. Desperdiça tudo o oposto disso. Isso capacita totalmente a equipe a assumir a responsabilidade pelo que está construindo e como vai entregá-lo. E as pessoas adoram que as equipes tenham adorado isso, elas adoram isso. A empresa está confiando a eles essa responsabilidade. E então eles são capazes de fazer esse trabalho e são capazes de fazê-lo bem. E isso significa equipes mais felizes. E do ponto de vista da gestão, isso significa redução da rotatividade. As pessoas não vão sair porque vão gostar mais do trabalho e, portanto, permanecerão na empresa. O número quatro é reconhecer que a mudança é assustadora. Eles podem estar preocupados com todas essas coisas e podemos dizer: Bem, sim, essas são preocupações. Temos certeza de que, quando 99% de certeza de que se contorcer é melhor do que uma cachoeira, porque todo mundo está acontecendo atualmente. Mas por que não fazemos isso como um julgamento? E um julgamento é uma ótima maneira contornar objeções, porque se você disser Ok, vamos tentar isso por três meses ou seis meses e ver como funciona. E se tudo explodir, voltaremos à cachoeira. Mas se funcionar e pudermos expandi-lo e implementá-lo em todas as equipes, é muito mais provável que você consiga aderir, pois isso vai dar certo. E é menos arriscado porque é apenas uma coisa temporária. Mas é claro que então vamos tentar. Que trabalham muito bem. Eles vão adorar e poderemos implementá-lo em toda a organização. 58. Boas práticas de treinamento: Mencionamos a ideia de que, às vezes precisamos treinar as melhores práticas e incentivar sua equipe a realmente usar toda a estrutura disponível nos esfoliantes. Então, como fazemos isso? Como treinamos de forma eficaz? Bem, o número um é começar onde a equipe está agora e ver o que funciona para eles. Então, às vezes, há uma tendência de entrar e simplesmente tentar começar a fazer mudanças. Mas se fizermos isso, a equipe provavelmente será bastante opositora. E eles estão felizes com a forma como as coisas estão. Se entrarmos, veremos o que funciona, veja o que não funciona. E podemos observar, fazer perguntas e depois ver o que não está funcionando bem para eles. E nesse ponto, podemos começar a sugerir mudanças e dizer: percebi que isso não está funcionando para você. Que tal se tentássemos dessa maneira, talvez isso ajude a resolver o problema. Faça sugestões, não comandos. As pessoas geralmente não gostam que digam o que fazer. Então, como acabamos de discutir, se pudermos fazer sugestões e oferecê-las à equipe, eles poderão optar por aceitá-las. Eles podem escolher não abraçá-la. Se eles se sentirem no controle das mudanças, concordarão muito mais em fazê-las do que se tentarmos impor algo a elas. Use como ou quais perguntas, em vez de por que perguntamos a alguém, por que você faz isso dessa maneira? Parece bastante acusatório. E isso coloca as pessoas na defensiva. Se usarmos como ou quais perguntas como, ok, bem, como você faz isso e como é isso? Como isso está funcionando para você? Então, você faz com que as pessoas examinem um pouco mais a situação, em vez de ficarem na defensiva como podem fazer perguntas sobre o porquê. Lembre-se de que contorcer o ArcGIS não é uma religião. Portanto, foque no que funciona, leve para ele o que funciona, e você não precisa usar o que não funciona. Se algo não está funcionando bem para você dentro da estrutura do Scrum, não use essa parte , use as partes que funcionam para você em sua organização, em sua equipe, seja o que for, absorva as coisas boas e não seja muito dogmático sobre as regras. Seja um modelo. A coisa mais importante que podemos fazer é seguir nós mesmos as melhores práticas. Se não o estamos seguindo , não podemos esperar que outras pessoas o sigam. Então, se há áreas em que achamos que talvez não estejamos totalmente alinhados com a forma como vemos as melhores práticas, então nos dedicamos a esse curso para modelar o que são as boas práticas. E também quando as pessoas veem isso funcionando para nós , acho que não está funcionando para Chris, talvez eu adote isso também. Veja o panorama geral das equipes dentro das organizações. Então, às vezes, a equipe está fazendo algo de uma certa maneira e há uma maneira melhor de fazer isso. Mas às vezes essa é a melhor maneira de fazer isso dentro da estrutura organizacional em que estão contidos. Portanto, é importante considerar como os valores mais amplos da organização podem afetar a equipe e levá-la a fazer as coisas de uma determinada maneira. E então experimente as mudanças como um experimento. Portanto, a mudança pode ser assustadora, mas se a vendermos como um experimento, por que não tentar isso nos próximos dois sprints e ver como funciona? muito mais provável que as pessoas se envolvam nisso porque não acham que estão se comprometendo com uma mudança permanente de dígitos. Ok, vamos experimentá-lo para a Sprint. Dois sprints duram alguns meses, seja o que for, se você está tentando nadar em geral, provavelmente deseja se comprometer com uma escala de tempo maior, talvez três a seis meses, pelo menos, algo assim. Mas se você formular isso como um experimento, vamos tentar isso e podemos voltar à maneira antiga. Se não estiver funcionando, as pessoas ficarão muito mais relaxadas experimentar coisas do que se você disser, certo, precisamos mudar agora. Isso soa muito permanente e muito assustador quando dizemos: vamos tentar como um experimento e ver se funciona ou não. É muito mais provável que as pessoas se envolvam. 59. Como escalar o Scrum: Scrum é projetado para uma equipe de cerca de dez pessoas a mais do que isso na equipe e começa a se tornar incontrolável. Você não pode fazer tudo em um scrum diário. E o significado, as atualizações são menos significativas porque as pessoas aqui e as pessoas aqui provavelmente trabalharei em coisas diferentes. Portanto, as atualizações realmente não funcionam e não é um ambiente de equipe. Mas o que acontece se você tem um projeto que precisa mais de dez pessoas trabalhando nele, como costumamos fazer nos negócios? Bem, nesse caso, você precisa de várias equipes Scrum. Mas as áreas de preocupação o que acontece se a equipe de scrum começar a pisar nos pés uma da outra e a se atrapalhar. Como podemos escalar de uma única equipe Scrum para várias equipes Scrum? Bem, é isso que vamos ver neste módulo. 60. Scrum de Scrums: Se tivermos várias equipes de Scrum e elas precisarem ser capazes se comunicar para impedir que pisem umas nas outras. Então, como podemos fazer isso acontecer? Bem, uma solução é o Scrum of Scrums. Então, isso é essencialmente um scrum diário. Então, a mesma coisa que o Scrum diário. Mas cada equipe de Scrum envia um Scrum de Scrums delicado e esse formulário é um pouco maior. Portanto, isso pode ser feito diariamente, também pode ser feito semanalmente, se isso funcionar em sua organização ou em qualquer frequência que funcione para você. Mas é o mesmo formato de um scrum diário. Cada natação é representada por uma pessoa, que pode ser qualquer um. Então, pode ser o Scrum Master, se isso faz sentido, pode ser, digamos, um engenheiro-chefe, mas realmente pode ser qualquer um. Você pode girar em torno da equipe para que todos tenham chance de ir ao Scrum of Scrums e ver como ele funciona. Quando você está no próprio Scrum do Scrum, ele funciona como os scrums diários. Então, a pergunta a ser feita é: O que fizemos? Especialmente coisas que podem estar impactando outras equipes? O que estamos fazendo agora que pode afetar as equipes e com quais bloqueadores outras equipes poderiam nos ajudar. Então, da mesma forma que quando estamos fazendo nosso scrum diário, falamos sobre o que fizemos individualmente anteriormente, fazendo agora e quais bloqueadores temos, estamos chegando ao Scrum of Scrums e dizendo para nossa equipe isso é o que fizemos, é nisso que estamos trabalhando. Esses são bloqueadores com os quais precisamos de ajuda. Cada equipe se alimenta para que as equipes saibam no que cada um de nós está trabalhando. E então o delegado volta para sua equipe individual do Scrum e envia informações irrelevantes para o resto da equipe. 61. Dividir produtos: Um conceito-chave no Scrum é um produto tem um proprietário de produto. Você não pode ter um produto. Temos vários proprietários de produtos. O que acontece se você as equipes do Scrum precisem trabalhar no mesmo projeto. Parece que você terá dois proprietários de produtos diferentes que desejam em cada equipe trabalhando no mesmo produto. Como você lida com isso? Bem, nesse caso, precisamos dividir os produtos de alguma forma em seções separadas. Então, vamos trazer nosso site de comércio eletrônico novamente, como exemplo. É uma grande luta e queremos que diferentes equipes de scrum trabalhem nela. Mas não podemos ter dois proprietários de produtos proprietários do site de comércio eletrônico. O que poderíamos fazer, por exemplo, é dividi-lo em front-end e back-end. Então, por domínio de front-end, as coisas que o cliente verá se estiver acessando o site para navegar. E então, o sistema de back-end é o que a equipe do armazém e a equipe de vendas trabalham no site de comércio eletrônico usam para gerenciar e enviar todos os pedidos. Ao separá-los, você pode ter uma equipe Scrum assumindo a responsabilidade por cada um. Assim, você pode ter equipe Scrum trabalhando no lado voltado para o cliente. equipe Scrum trabalhará no back-end do produto e você terá um proprietário de produto para cada um que os gerencia. Agora, outra solução que você pode fazer é ter um proprietário de produto trabalhando em várias equipes Scrum. Portanto, a equipe a está trabalhando no front-end, equipe B está trabalhando no back-end. E há um proprietário de produto que gerencia e trabalha em ambas as equipes, o que o torna um proprietário de produto bastante ocupado. Mas, dependendo da quantidade de decisões e da autonomia da equipe, isso também pode funcionar muito bem. 62. Alinhamento de sprint: Se você tem várias equipes Scrum, talvez queira começar a pensar em alinhamento de sprint. Então, se você tem a equipe a e a equipe B ou seus sprints começarão ao mesmo tempo? Eles serão diferentes? O tempo em que eles funcionam ao mesmo tempo funciona muito bem porque se você tem alguns bloqueadores, como o TMA, é bloqueado por algo em que a Equipe B está trabalhando. A equipe começou a trabalhar nisso e disse: sprint free e team a nose, que eles poderão retomá-lo no sprint quatro, brilhando, está terminado. E então tudo está alinhado. Você pode alinhar seus roteiros de produtos. Então você pode dizer, mais ou menos, que teremos o TMA trabalhando nesta equipe, trabalhando nisso. E então, em duas semanas, quando o sprint e nós o alteraremos. Então, alinhá-los pode ser muito útil. Para algumas organizações, é melhor não alinhá-las apenas por motivos logísticos. Tão seguro, você só tem uma sala de reuniões. Então, se você tiver todas as suas equipes de scrum começando e terminando com a aspirina, elas serão gastas no mesmo dia. Ambos vão querer a sala de reuniões para o Sprint Planning e para as retrospectivas no mesmo dia. Então, nesses casos, você pode realmente querer deixar a equipe de sprint ser uma estrela aqui e fazer um sprint de duas semanas e equipe B começar aqui uma semana depois. Então, a compensação, para que eles não se deparem com esses encontros com conflitos. Em termos de alinhamento e alinhamento das diferentes equipes gastas. É aqui que variar a duração do sprint pode ser realmente útil. Digamos que você tivesse TMA e acabou comprar o Team Be On uma semana depois. Mas você realmente quer alinhar seus sprints e pode fazer com que a equipe a faça um sprint de três semanas, para que ambos terminem ao mesmo tempo. Ou você pode fazer com que a tuberculose se reduza a um Sprint de uma semana. E depois disso, eles voltam para se você estiver usando sprints de duas semanas por padrão, eles voltam às duas despesas e depois se alinham. Então, você pode fazer isso da maneira que quiser, mas ter um pouco de antecedência para saber se você quer que eles estejam alinhados ou se você quer que eles estejam alinhados ou não e como você vai alinhá-los usando comprimentos de sprint pode ser muito útil. 63. Outras metodologias: Este curso se concentrou no Scrum, mas existem outras metodologias ágeis você pode querer usar de tempos em tempos e em vez de estruturas que talvez você queira incluir junto com o SCRUM que realmente complementam o crescimento. Então, neste módulo, vamos discuti-los sobre metodologias e estruturas ágeis que seria muito útil para você conhecer ao trabalhar dentro do Scrum. 64. Kanban: O Scrum e o Kanban são provavelmente as estruturas ágeis mais populares para gerenciar projetos. Então, quando você usaria o squirm e quando você usaria o Agile, era muito adequado para entregar novos projetos em que você está construindo algo, algo Greenfield, você tem um trabalho a fazer. Você sabe, você tem, digamos, seis meses para fazer isso em. E você só precisa passar por todas as coisas. Kanban tende a ser mais adequado para nosso tipo de ambiente de negócios , como de costume. Então, talvez você já tenha construído sua plataforma de comércio eletrônico. É ao vivo e você só precisa ver o que aparece. Pequenas melhorias, pequenas correções. Você não tem o tipo de grande roteiro de produto que desenvolveu. Mas você precisa responder às coisas com muito mais rapidez porque está lidando com problemas ativos no site. Portanto, o kanban funciona de forma um pouco diferente pois não há sprint scrum. Temos essa ideia de sprints e temos, digamos, um bloqueio de duas semanas. Decidimos o que vamos fazer e começamos com duas semanas e fazemos isso por duas semanas e analisaremos o que vamos fazer. Em Kanban. Há uma placa contínua e o acúmulo de produtos. E o tipo de coisa que achamos do Sprint Backlog, da lista de tarefas, é a mesma coisa. Portanto, a lista de pendências do produto já está na coluna de tarefas do quadro e em ordem de prioridade , para que você escolha a primeira. Então, digamos que vamos usar nossa plataforma de comércio eletrônico novamente. Nós o temos ao vivo. E notamos que o símbolo da moeda não está sendo exibido corretamente, certo? Para alguns usuários. E isso é um problema muito grande porque se trata de pagamentos. Assim, o proprietário do produto levantaria um tíquete para dizer que símbolo da moeda não estava sendo exibido corretamente, provavelmente o enviaria direto para o topo da lista de pendências. Então, o próximo engenheiro a pegar alguma coisa, nós poderemos pegá-la. Então, em vez de ter esses sprints, tudo está em uma lista. Você pega a coisa de cima e se algo precisar ser feito com urgência, basta trazê-la e colocá-la diretamente no topo da lista de pendências para que você possa começar a trabalhar nela. Agora, isso significa que, no Scrum, medimos a velocidade. Quanto mais pontos conseguirmos comida por sprint, melhor será o nosso desempenho. No Kanban, falamos sobre o tempo de ciclo. Então, a partir do momento em que o tíquete é levantado, rapidez podemos distribuí-lo e liberá-lo e pronto. Então, como um resumo rápido, Scrum é ótimo para quando você tem tarefas fixas e fica feliz em trabalhar nesse sprint de duas semanas quando tem algo disponível e só precisa fazer pequenos ajustes. E você está menos preocupado em fazer um grande trabalho. Você só precisa obter essas correções rapidamente. O Kanban pode ser mais útil. Lá. 65. Programação extrema: A programação extrema é uma abordagem ágil para escrever código. exemplo, o Agile em si não é um conjunto claro de regras, mas antes existem vários princípios e várias técnicas que se formam para formar o que chamaríamos de programação extrema. Geralmente envolve várias pessoas trabalhando no mesmo trecho de código. Então, isso pode ser um código escrito em pares, Pair Programming, que uma pessoa é o piloto realmente digitando as coisas, mas ela está colaborando com alguém sentado ao lado dela falando sobre as decisões que são capazes de identificar o que está funcionando e como projetá-lo. Você pode até mesmo escalar até a programação em massa. Então, quatro ou cinco pessoas estão examinando um trecho de código, seja em seus próprios computadores, colaborando em tempo real ou em um computador todo sentado, se isso funcionar para você. Dessa forma, ele garante um código realmente de alta qualidade. Mas é claro que leva mais tempo. Se você estiver em pares, apenas metade dos seus engenheiros está escrevendo código e programando em massa ainda mais. Então. O código deve ser amplamente revisado e aprovado por outra pessoa. Portanto, isso deve estar em tudo o que você escreve. Se você escrever um trecho de código, envie um pull request ou uma revisão de código para outra pessoa. E outra pessoa deveria examinar esse código, se certificar de que faz algum sentido. Faça comentários e repasse para a pessoa. Se uma passagem for imediata ou se houver alguma alteração necessária ou sugerida, passe-a de volta ao autor para ver se ele deseja fazer essas alterações. As tarefas automatizadas devem ser escritas para tudo. Portanto, adotar essa ideia de integração e entrega contínuas deve ser um teste automatizado para cada funcionalidade que escrevemos, porque é impossível para testadores humanos aprenderem tudo isso, mantendo-o o mais simples possível. Então, na verdade, sempre queremos escrever o mínimo de código possível e torná-lo reutilizável. E se pudermos escrever um trecho de código que possamos usar em três lugares diferentes e excluir o código antigo e volumoso , isso é ótimo porque menos linhas de código significam menos lugares onde as coisas podem dar errado. Depois, desenvolvimento orientado por testes, sobre o qual falaremos na próxima lição. 66. Desenvolvimento orientado para testes: desenvolvimento orientado por testes, também conhecido como TDD, é uma forma de escrever código em que escrevemos o teste unitário antes de escrevermos o próprio código . Por que fazemos isso? Bem, isso nos impede de adicionar código que não precisamos. Então, falamos anteriormente sobre essa ideia de escrever uma história de usuário e dizer, como usuário, eu quero fazer isso. E então podemos escrever o código sabendo que, assim que atendermos aos critérios de aceitação , cumpriremos o trabalho. Bem, isso é basicamente o mesmo, pois escrevemos primeiro o teste para dizer o que esse código precisa ser capaz de fazer. E então escrevemos o código para preencher esse texto. Assim que o teste de unidade for aprovado, agora podemos começar a escrever código. Não precisamos adicionar nenhum outro inchaço porque passamos pelo teste unitário e , portanto, ele faz tudo o que precisamos fazer. Portanto, escrever o teste primeiro e depois o código funcional nos ajuda a garantir que tudo tenha cobertura de teste. E segundo, não estamos adicionando nenhum inchaço ao código porque podemos parar assim que o teste for bem-sucedido. 67. Desenvolvimento baseado em comportamento: O desenvolvimento orientado por comportamento é uma extensão do desenvolvimento orientado por testes, que escrevemos nossos testes em histórias de usuários e, em seguida, escrevemos o código para preencher essas histórias de usuários. Então, o que isso realmente significa? Bem, digamos que estamos codificando o sistema de checkout para nossa plataforma de comércio eletrônico. Podemos escrever uma história como como cliente, eu quero poder ver o total da minha cesta. Ou, como cliente, quero poder efetuar o pagamento do meu pedido. E esse seria o idioma em que escrevemos o teste. Esse seria nosso teste, digamos, e é muito compreensível. Qualquer um pode dar uma olhada nisso, o próprio proprietário do produto poderia escrever. Qualquer pessoa que esteja assistindo ao teste, mesmo que não seja uma pessoa técnica, entende o que está acontecendo lá. Em seguida, temos uma camada de código no meio, que traduz isso em testes reais, em vez de dizer: “ Quero efetuar o pagamento do meu pedido”. Quais são as etapas automatizadas para realmente testar isso? Então, traduzir a linguagem natural em um teste. E então, é claro, temos nosso código funcional, a própria plataforma de comércio eletrônico. E então há meio que 33 peças lá dentro. O que é, qual é a vantagem de fazer isso? Quando escrevemos o código em linguagem natural. Todos podem entender isso, o proprietário do produto, coisas não técnicas e entrar e ver exatamente o que estamos testando. Em segundo lugar, ele realmente se concentra em atender aos requisitos do usuário. Assim, podemos escrever nosso teste primeiro. Preciso que o usuário consiga concluir esse pagamento. Em seguida, escrevemos nosso teste e nosso código funcional para cumprir isso. E assim que cumprirmos isso, podemos parar. Não estamos adicionando nenhum exagero porque sabemos que essa história de usuário está definida e já temos uma cobertura de teste completa sobre ela. Portanto, sabemos que podemos executá-lo por meio um pipeline de integração contínua e tudo funcionará muito bem porque o teste abrange isso, não há nada mais necessário e todos podem entender o que está acontecendo. Agora, existem várias populares de BDD de desenvolvimento orientado por comportamento estruturas populares de BDD de desenvolvimento orientado por comportamento. Temos pepino em Ruby, temos b hat em PHP, temos J se comportar em Java, mas seja qual for a linguagem em que você esteja trabalhando, provavelmente existe uma estrutura BDD por aí. Então, eu recomendo subir, uma olhada e ver o que está lá , experimentar e ver como você lida com isso.