Engenharia de software para nível intermediário: modelos de desenvolvimento e programação ágil

1. Introdução: Olá, todo mundo. E bem-vindo a este curso. Nós vamos estar falando sobre modelos de desenvolvimento de software neste curso, e ele disse então o que isso vai se resumir a alguns dos modelos realmente populares que temos usado por muito tempo em engenharia de software, bem como falar sobre esta nova idéia de scrum ágil e combinar, que está conduzindo forma mais flexível de desenvolvimento de software. Então eles vão neste curso nós estamos apenas indo para rever diferentes modelos e como eles se relacionam com o mundo real e como você pode usá-los para melhor desenvolver software. Agora, uma nota rápida. Esta é uma classe 102. Você pode levá-lo de forma independente por si só, e a maior parte vai fazer todo o sentido. No entanto, em uma classe única, falamos sobre o básico de todas essas coisas. Então, se algumas dessas coisas não estão soando 100% vamos dizer claro para você. Talvez pareça um pouco confuso. Confira o curso 101. Ele vai ter um tipo muito grande de introdução a todo este material antes de você realmente entrar nos modelos eles auto, Então eu só quero dar esse aviso rápido. Também está no meu canal. Se você gostaria de verificar o um em um vídeo fora também. Mas todos, bem-vindos à partilha de habilidades. Se você tiver alguma dúvida, deixe-os nos comentários do curso e terei todo o prazer em ajudá-lo em qualquer uma das áreas, e mal posso esperar para começar. 2. Modelo de causa 1-1: O primeiro grande modelo que vamos cobrir é o do modelo cachoeira. Então, com o modelo de cachoeira, o que estamos fazendo é basicamente a água caindo do passo ao passo dois. Então, iniciamos os requisitos e, assim que tivermos certeza de que os requisitos são perfeitos, passamos para o projeto que passamos de lá para a implementação, assim que tivermos certeza de que isso é perfeito para testar a implantação até manutenção. Agora isso não tem que ser. Sabe, esses passos. Pode ser qualquer Siris de passos que nos leve a esta conclusão final. Mas a importância da água para o método ou o modelo de cachoeira é que estamos nos movendo do passo ao passo dois, e é uma espécie de que temos vindo a cobrir todo o curso, como estamos falando como se tudo estivesse em um fluxo linear e Você sempre segue. Siga esses passos. No entanto, o problema com o modelo cachoeira é que ele não é muito adaptável. É muito, muito preditivo. Lembre-se dessas duas palavras que usamos na última palestra, e porque é muito, muito preditivo, significa que se encontrarmos erros, digamos, na fase de teste, isso significa que teremos que ir para trás. Então, se, por exemplo, o encontrarmos no teste, vamos mudar a cor aqui, então vamos realmente ter que voltar para a implementação e, em seguida, da implementação de volta para o design e, em seguida, requisitos e basicamente, o que vamos ter que fazer digamos que encontramos um ar aqui um erro muito sério com a forma como programamos é o nosso software. Vamos ter que mudar os requisitos, consertar os requisitos. Então vamos consertar o projeto, criamos novos projetos de subsistemas, novos projetos de módulos, etc. Então nós vamos voltar para a implementação, vamos ter que recodi-lo, e então nós vamos ter que testá-lo novamente. E se as coisas já foram implantadas, temos que ir ainda mais longe. Temos que continuar voltando e refazer tudo de lá. E assim que chegarmos à fase de manutenção, é como um círculo aqui em baixo, vamos continuar. No entanto, se estamos fazendo grandes mudanças na fase de manutenção, ainda temos que fazer exatamente a mesma coisa ou ainda calor gráfico indo todo o caminho de volta e refazer tudo para ter certeza de que toda a documentação tudo é suportado dentro do modelo cachoeira. Então o modelo de cachoeira é um que é muito, muito, muito como eu disse, preditivo. É algo onde sua equipe deve ter codificado isso antes para ser bem sucedido. Agora com isso, também é muito eficiente e é muito simples de usar. Então, há muita sobrecarga. Então novamente, se você está criando vários sites ou algo assim, então este modelo é provavelmente algo que vai ser bom time medo, porque eu não tenho que gastar muito tempo realmente pensando sobre o design de software processo. Eles podem usar um processo que já foi projetado com um monte de passos, e eles poderiam apenas trabalhar com isso agora com o modelo cachoeira. Também temos esse problema com esse custo ao longo do tempo para corrigir. Então, digamos que cada uma dessas etapas diferentes, então você sabe que isso é uma vez que os requisitos são concluídos. Uma vez que o projeto é concluído, uma vez que a implementação é concluída, uma vez que todos os testes são concluídos, o que é implantação é concluída e assim por diante novamente, pode ser etapas diferentes. Mas a importância deste gráfico é mostrar que à medida que você vai mais longe, não é apenas um custo linear ao longo do tempo, que significa que Oh, se nós corrigi-lo, se nós temos que fazer algo aqui, é apenas tudo isso combinados para voltar a este ponto. É esse tipo de coisa exponencial em que se cometermos um erro e descobrirmos sobre ele, talvez na implementação ou perto da fase de implantação, levará muito mais tempo do que se corrigi-lo na fase de requisitos talvez até 50 vezes a quantidade de tempo para voltar e mudar tudo para fazê-lo funcionar novamente. E por causa disso, o modelo de cachoeira não é flexível. Cada passo deve ser extremamente bem planejado. Temos que nos certificar de que é tudo perfeito, e algumas corporações farão isso, e na verdade é muito, muito tipo de coisa. Muitos programadores vão se sentar e girar seus polegares, esperando que os requisitos ou algo seja passado através de um monte de comitês diferentes para garantir que ele é perfeito e para que aqueles que podem haver alguma perda de tempo em lá também. Mas precisa ser extremamente bem planejado. E vai levar um tempo para colocar o produto no mercado. Se fizermos algo sobre o qual falaremos mais tarde, algo mais, mais iterativo onde criamos um V um que é realmente básico, e começamos a adicionar recursos com o três e a versão para a inversão cinco. Então tiramos o produto muito, muito em breve. E então, a partir disso, nós podemos, você sabe, começar a construir sobre ele, e eu não sei por que, mas um boneco de neve meio que veio à mente aqui, e nós podemos realmente obter um produto que, você sabe, meio que começar a trabalhar para isso. Podemos obter feedback daquele teste beta enfraquecer que podemos obter dinheiro para, mas com isso estamos fazendo tudo de uma só vez. A primeira versão do produto provavelmente vai ser a versão final do produto, e porque nós poderíamos realmente perder nossa oportunidade de mercado, talvez se tivéssemos saído, você sabe, metade assed muitos três meses antes, teria sido muito mais bem sucedido do que estar três meses atrasado com todos os recursos, e algo que é muito importante é que a tecnologia se mova rápido e o que isso? Não seremos capazes de nos adaptar à nova tecnologia. Então, se estamos em um campo de desenvolvimento rápido, como, por exemplo, carros onde você sabe que software de carro está realmente desenvolvendo coisas muito rapidamente mesmo com, como, Internet das coisas software, Sabe, como relógios inteligentes ou camisas inteligentes ou algo assim. Todo esse mercado está se desenvolvendo muito rápido. E novas tecnologias estão saindo 68 talvez um ano de cada vez. E então por causa desse tipo de iteração rápida, por causa da, você sabe, a iteração anual ou talvez até mensal da tecnologia, se estamos construindo um pedaço de software que leva dois anos para construir, E não vamos colocar nada entre esses dois anos, quando tirarmos nosso software, a tecnologia pode ter mudado e todo o nosso projeto está obsoleto, então precisamos levar isso em conta também. Mas o modelo da cachoeira. Por causa de tudo isso, é decentemente ruim em muitas áreas, mas não deve ser descartado imediatamente. Ele tem seus benefícios em estruturas mais organizadas e lugares onde as equipes estão criando as mesmas coisas várias vezes, e ele tem essa eficiência, baixo custo para executar uma espécie de idéia com ele. Mas este é o primeiro modelo, a água para modelo. É muito importante e muitas coisas são baseadas nisso. 3. Modelo de 1-2 V: Então o próximo modelo de que estamos falando vai ser o do modelo. E o modelo V é uma espécie de melhoria no modelo cachoeira. Ou pelo menos ele cuida de um problema que as pessoas notaram com o modelo cachoeira. E este modelo V basicamente leva a queda de água. Então a cachoeira sendo, você sabe, o baixo, que para baixo, para baixo e para baixo e ele o leva e ele dobra neste tipo de implementação aqui em baixo, e ele traz o teste para o lado direito, e, em seguida, a implantação é apenas uma espécie de como talvez o próximo passo para a direita aqui, uma vez que tudo isso está concluído. Mas o que este modelo faz é funcionar assim. Então não penses que vamos assim e depois voltamos para o lado direito. O que estamos fazendo é que estamos trabalhando basicamente nessas camadas bem aqui. Então nós temos esta camada superior, que é esta conexão entre requisitos e testes de aceitação do que projeto e teste de sistema , integração arquitetônica e módulo e teste de unidade. E a razão pela qual fazemos isso é porque lembre-se na última palestra, estamos falando sobre como houve um problema com isso em que testes é a situação em que encontramos bugs, certo? Bem, se encontrarmos um bug grande, temos que voltar para consertar esses bugs. Então temos que ir. Todos os ambientes ativos projetaram a implementação para corrigir esses bugs. Bem, alguém morreu. Bem, se fosse, se este é o passo onde encontramos o maior número de bugs não faria sentido não colocá-lo no final, mas perto do início e fazê-lo em cada passo à medida que descemos. E é isso que o modelo V faz. Então, com isso, temos cada passo, e então temos testes para verificar essa etapa. Então, há o lado direito aqui é basicamente verificação de verificação. Então, o estilo certo será nós verificando que cada um desses passos é realmente bom antes de seguirmos em frente. E este lado direito é exatamente o que temos feito. Que o design agora com este modelo, nós pegamos esta parte de design e nós realmente dividi-lo em seus sub-componentes. Lembra-se de como falamos sobre arquitetura e eles diferentes módulos e, em seguida, projetar como um todo? Então é isso que estamos fazendo aqui. Nós estamos levando isso em foram realmente quebrá-lo para que nós possamos ter diferentes partes para testar. Assim, o 1º 1 é requisitos com requisitos. O que temos é que temos essa ideia de aceitação. Testando, aceitação. Testar é testar para garantir que os requisitos são exatamente o que queremos. Um exemplo disso seria apenas apresentar os requisitos e tentar quase criar simulações ou potencialmente criar documentos que detalhariam cada caso de uso. Então, como exatamente estamos planejando que o usuário use o sistema? E então estamos basicamente tentando simular quase o que um usuário faria e ver se ele vai realizar essas tarefas. Então, olhamos para os requisitos. Tentamos criar um usuário que o usasse e ver se há algo que perdemos, algo que não estamos entendendo. Isso geralmente é feito com o cliente para garantir que novamente é aceitável, fazendo o que queremos fazer e, portanto, será uma solução aceitável. O próximo passo é o design, e quando falamos sobre design como este, estamos falando sobre todo o sistema projetado, então estamos falando sobre esse realmente nível superior ou nós dizemos que vamos ter esta seção, esta seção, esta seção nesta seção e talvez apenas um pouco, como, talvez comunicação aqui e comunicação como essa. E isso vai ser todo o pensamento que este é o projeto de todo o sistema como um todo. E quando conseguirmos isso, vamos fazer alguns testes de sistema, talvez criar alguns casos de teste até um pouco de código apenas para ver e garantir que este design está funcionando corretamente. Então vamos um passo mais longe. Nós realmente invadimos esses. Começamos a projetar arquiteturas, descobrir tudo isso, funciona e, em seguida, fazemos integração, teste, teste, certificando-se de que tudo isso funciona em conjunto e, em seguida, ele funciona em conjunto, ainda com o outro uns. E então nós fazemos todo o caminho até o teste de módulo, que é onde nós dividi-los em módulos minúsculos, os bits de código que estão realmente se comunicando uns com os outros. Fazemos essa ideia de testes de unidade, sobre a qual falamos, e então nós tipo de ir talvez para cima da cadeia para ter certeza de que o resto vai funcionar com tudo o resto por causa de tudo isso porque nós fizemos todos os testes neste fase. Uma vez que chegamos à implementação e a cobrimos, terminamos porque o teste foi feito durante toda a parte. E agora estamos a garantir que não nos deparamos com esta grande área onde teremos muitos bugs que os encontrarão mais cedo e portanto, reduzirão o custo porque em vez de encontrá-los talvez aqui no cronograma de custo, encontramo-los aqui em baixo. E estamos tentando nos certificar de que os encontramos antes deste ponto, e eles não acabam em cascata até esse ponto. E é disso que se trata o modelo V. É uma espécie de um próximo passo na garrafa de cachoeira. Agora o único golpe com isso é que há mais trabalho adiantado nisso. Cada passo que damos, temos que chegar a algoritmos de teste inteiros. Lembre-se, estamos falando de testes. Testar é difícil. É algo que não é muito fácil de pensar e também não é muito fácil de implementar. Então, com isso em mente, temos que entender que por causa da maneira como estamos fazendo isso, temos que testar que cada seção da SEC aqui, e isso significa que teremos mais custos iniciais. Vai ser mais difícil. Vai ser um pouco mais complexo gerenciar este software. Mas é ótimo se talvez não tenhamos 100% de certeza, temos uma espécie de idéia do caminho que queremos ir, mas não estamos 100% certos sobre como chegar lá nessa situação. Queremos usar o modelo V para que possamos tomar medidas para continuar testando-o para garantir que estamos caminhando pelo caminho certo. 4. Modelo de sashimi: O próximo modelo que vamos falar é um modelo Sheemie? E esse modelo meio que foi construído a partir de uma idéia que talvez não pensássemos no início. Mas quando você pensa sobre isso, é muito prático, e é que em cada uma dessas fases, não temos necessariamente os mesmos engenheiros. Então, muitas vezes estamos sob a suposição de que talvez tenhamos um ou dois engenheiros e eles vão fazer os requisitos e, em seguida, projetar e, em seguida, a implementação no teste e implantação na manutenção. Mas geralmente o que temos é, especialmente em grandes empresas, é que temos engenheiros específicos que fazem coisas como os requisitos que fazem coisas como o design, seja o back-end ou o front-end, que temos engenheiros de implantação. Temos engenheiros de teste, temos engenheiros de implantação e manutenção. E por causa de tudo isso, temos esse problema em que se fizermos isso passo a passo, como nos exemplos anteriores com o modelo E V e o modelo de cachoeira, todos esses engenheiros, ele aqui em baixo tem que esperar até o anterior é concluída e, em seguida, uma vez que a etapa anterior é concluída, todos os engenheiros e o topo estão esperando mais uma vez. Então você obtém esse tipo de área onde muitos de sua força de trabalho estão sentados esperando outra força de trabalho conclua suas tarefas. E assim o modelo sashimi, nós temos a capacidade de desenhar essas linhas para baixo. Então, basicamente, cortamos. Então é o modelo sashimi. Se você já comeu sashimi, é um, uh, um prato de basicamente peixe cru cortado, e geralmente é colocado em cima um do outro, como normalmente um sobre o outro. E é por isso que isto é assim. Ela me modelo é porque você tem esses pedaços todos colocados em cima um do outro, e então você basicamente cortando duas categorias diferentes aqui. Então, se formos em frente, não poderíamos desenhar essas fatias aqui e o que é isso. Estas são as diferentes fases de desenvolvimento, e nós, naturalmente, naturalmente, talvez fazer essas fases como se talvez tivéssemos objectivos de um mês ou objectivos de dois meses. Mas essencialmente o que estamos fazendo é fazer um pouco de tudo em cada uma dessas fases. Então, com os requisitos e este gráfico vamos por aqui. Então, o tempo enquanto atravessamos o tempo, vamos por aqui. Então, quando começamos, você sabe, começamos com os requisitos, o design e talvez um pouco de implementação, talvez um pouco de teste aqui e, em seguida, a próxima fase. Ainda estamos trabalhando nos requisitos e no design e, agora, em grande parte da implementação . Mas também estamos recebendo nossos testes e nossa implantação é manutenção. Os engenheiros envolveram a implantação. Os engenheiros estão descobrindo a melhor maneira de fazer a manutenção ou talvez criar sistemas. Talvez existissem modelos de teste ou betas. Que esses caras estão trabalhando está bem, e nós continuamos fazendo isso a cada passo. Então, no próximo passo aqui, o que temos é que agora estamos fazendo tudo. Estamos cortando tudo ao mesmo tempo. E então aqui embaixo, nós lentamente diminuímos até estarmos na fase de manutenção. E, novamente, isso nos ajuda porque permite que diferentes disciplinas comecem a trabalhar mais rapidamente e também reduz o tempo de desenvolvimento em vez de ter que esperar. Digamos que, se fosse, você sabe, aparecer duas semanas. Então esta é a quantidade de semanas 23456 e sete semanas para cada um destes. Após esta tarefa ter sete semanas para ser concluída, esta tarefa levaria cinco semanas. Imagine se fizéssemos estes um de cada vez que seriam dois mais três mais quatro mais cinco mais seis mais sete. Ou o que podemos fazer é trabalhar em todos eles um pouco, e todos nós basicamente estamos começando quase na mesma semana. Então, o tempo total provavelmente vai sair para alguém em torno de sete ou oito semanas em vez de adicionar tudo isso juntos. E isso é muito do tempo seguro lá. Agora, o problema que podemos ter com isso é que pode resultar em ar e redesenhar. O que isso significa é como o quê? O modelo da cachoeira. Se encontrarmos um ar, ATT é algum ponto, nós vamos ter que voltar todo o caminho, e o erro é Mawr prevalente nesta situação, e isso é porque nós não terminamos os requisitos ou o projeto. Ainda assim. No momento em que estamos implementando e testando, que significa que aqui podemos encontrar algo que precisa ser completamente retrabalhado e tudo de trás, talvez assim aqui precise ser retrabalhado. E por causa disso, todo o trabalho que não temos Onley só tem que retrabalhar os requisitos. Agora temos de reformular tudo o que os requisitos tocaram. Então, tudo aqui em baixo, vamos ter que retrabalhar. Então, meio que nos abre para este, esse potencial onde se não pensarmos sobre isso e se formos um pouco desleixados e tendo ar tarde, teremos que fazer um monte de retrabalho e isso pode realmente resultar que vai tornar mais lento o desenvolvimento desta forma se tivermos esses ares. Mas se não tivermos essas setas, temos um ótimo trabalho para sua utilização e eficiência e realmente reduzimos o tempo de desenvolvimento. 5. 1-4 Incremental de uma pessoa: Então, para os próximos modelos, precisamos entender alguns termos. Então, isso faz sentido. E isso vai ser essa idéia de verso incremental. Iterativo e incremental e iterativo são bastante semelhantes, exceto que eles têm uma espécie de maneira diferente de ter o no produto. E o que queremos dizer com isso é que ambos avançam e avançam para o objetivo final construindo um produto original. Então, há algo com o qual começamos e estamos construindo sobre ele. No entanto, com incremental foram construindo ao longo do tempo. Pense em como uma linha de montagem onde nunca chegaremos ao produto final até que estejamos no produto final e uma iterativa onde realmente construímos muitos produtos finais e continuamos fazendo novos que estão um pouco mais próximos do nosso produto final. Mas isso funciona quase totalmente. Então vamos rever o para ouvir um pouco mais em profundidade. Então, novamente, nosso 1º 1 é incremental. Construir passos ao longo do tempo, linha de montagem , você sabe, temos, você sabe,nós começamos com um carro e começou como um quadro, e então ele se move para, você sabe, o lado externo do interior do Talvez o motor, etc, etc. Talvez estivéssemos falando sobre construir um computador. Então começamos com, você sabe, o caso, e no próximo passo, enviamos para as pessoas que colocaram as placas-mãe. Então nós temos um pequeno quadro mãe lá, e então no próximo passo, nós enviamos para as pessoas que vão colocar a CPU dentro Então agora temos uma placa mãe na CPU e próximo passo. Agora temos uma placa mãe CPU, e depois colocamos um pouco de RAM nele, e assim por diante e assim por diante até termos um computador finlandês. Mas reparem que, em nenhum momento, temos um computador que possa funcionar. Não há nada onde nós realmente vamos ter basicamente algo que possamos dar a um cliente para ver como está indo. Estamos construindo ao longo do tempo. Estamos dando um passo para o próximo para o próximo. E isso é o que o modelo incremental é. Nós olhamos para esses passos, esses objetivos que queremos alcançar, e basicamente nós construímos até esse objetivo e nós temos esses, como quase muitos projetos para construí-lo deste estado para este estado. Então digamos ST 123 e quatro. Então nós estamos construindo do estado um para tentar levá-lo ao início do estado para então nós vamos do estado para tentar chegar ao início. Estate três e nos movemos, assim agora com o modelo iterativo estavam construindo protótipos, e estamos ajustando com novos protótipos. Seria como se construíssemos um carro e construíssemos uma versão muito ruim. Talvez com, tipo, quase, você sabe, roubar assentos lá dentro. Então não há nem mesmo como estofamento no interior. É só este assento de aço dentro disto. Este carro, ele tem um par de rodas nele, e é praticamente isso lá. Ainda é um quarteirão até nós nem desenhamos essa parte. Mas no próximo, começamos a refiná-lo um pouco. Talvez possamos adicionar um pouco de forma a ele. Então, em vez deste tipo de aparência bloqueada agora, nós realmente temos ah melhor parte da aerodinâmica nele. Tínhamos, sabe, melhores rodas para ele. Tivemos melhor semeadura, e depois a próxima parte tivemos as características de luxo. Talvez tivéssemos outra coisa e assim por diante. Mas cada um desses produtos vai realizar as tarefas em mãos, o que significa que se tivermos essa taxa de produto aqui, ele deve ser capaz de fazer basicamente tudo o que o produto final deve ser capaz de digerir. No entanto, este produto aqui vai ser uma versão pior disso. Vai usar parte mais barata. Vai ser onde o projeto não está totalmente implementado. Talvez algumas coisas sejam experimentais nisso. Estamos testando algumas coisas. Estamos testando as rodas sobre isso, por exemplo, mas ainda devemos ser capazes de operá-lo. Ainda devemos ser capazes de mostrá-lo a um cliente. Se este é, ah, software em cada um desses lados, este aqui, nós nunca seríamos capazes de mostrar a um cliente até esta parte aqui, talvez possamos mostrá-lo quando estiver quase pronto. Mas definitivamente não no começo. Enquanto essa taxa depois de terminarmos o primeiro protótipo, devemos ser capazes de mostrar isso ao cliente e dizer: “ É aqui que estamos agora, sabe?” Vamos, vamos fazer um pouco de teste, deixe-me mostrar-lhe como este programa funciona. Deixe-me mostrar-lhe alguns dos pequenos detalhes do programa. E então da próxima vez, talvez eles vão dar feedback e isso vai para a nossa próxima geração. Vamos fazer alguns ajustes e mostrá-lo para o início e de novo. E essa é a diferença entre incremental e iterativo. É uma diferença importante. Eles parecem muito, e eles são muito fáceis de confundir, mas entender isso é importante para alguns dos próximos passos. 6. Modelo incremental de 1-5: então o modelo incremental usa esse termo que acabamos de falar, que é incremental, estavam implementando algo passado. Então, com o modelo incremental, o que fazemos é basicamente completar o processo de desenvolvimento de software várias vezes ao longo do curso do desenvolvimento. No entanto, com cada processo, temos um certo objetivo em mente. Então nós temos, por exemplo, o ouro para, você sabe, construir o back-end ou construir um para montar. Construa uma página para fora e vamos em frente. Criamos os requisitos para projetar a implementação, os testes e, em seguida, implantamos o que nosso produto final vai ser. Então, basicamente vamos para o primeiro incremento. Uma vez terminado, vamos para o segundo ou não tem que ser. Além disso, não temos que terminar isso para chegar ao segundo. Muitas vezes vai passar para os passos e, em seguida, uma vez passado, por exemplo, a implementação que vamos para testar o desemprego começará. O próximo incremento começará a próxima fase de desenvolvimento, e isso nos permite ter esse pouco de sobreposição aqui, que novamente nos permite continuar trabalhando em um ritmo eficiente, e ao longo desse processo, estamos lentamente construindo em direção ao produto final. Os incrementos do também nos permitem mostrar partes finais do design. Então, se isso, por exemplo, fosse a primeira página e um par de formulários, poderíamos enviar isso para o cliente e dizer, essa parte dele parece boa novamente? Isto não é um produto acabado. Não podemos deixá-los testar a coisa toda e nos dar feedback para mudar a coisa toda . O que podemos fazer, entanto, é dado um pouco de feedback sobre as peças e peças atuais que construímos e ver como, exatamente eles gostam dessas peças e peças. Então nós construímos a primeira página e um par de fazendas em algumas páginas, e esse é o nosso primeiro incremento. Uma vez feito isso, podemos enviar para o cliente para feedback e, em seguida, passar para a próxima fase, uh, com qualquer uma dessas mudanças, ou nós criamos uma nova fase sobre realmente mudar qualquer coisa que o cliente teve problemas com, e com isso temos essa idéia de ser capaz de tipo de colocar esses portões durante todo o processo onde podemos continuar. Podemos continuar produzindo, mas também podemos continuar recebendo feedback para ver se o produto e o projeto estão indo na direção que queremos que ele esteja indo. Adiciona um pouco de adaptação ao processo. Lembre-se de preditivo e adaptativo. Isso nos permite chegar um pouco mais longe naquele lado adaptativo onde podemos realmente nos mover e nos adaptar com o que o cliente está pensando e com a forma como a produção está indo. Isso também adiciona camadas desses comentários que nos ajudam também. Um lado negativo disso é novamente retrabalhos. Se precisarmos fazer retrabalhos do Major aqui, talvez já tenhamos começado a desenvolver com isso em mente aqui, então talvez tenhamos que mudar alguns dos futuros desenvolvimentos. Altere os requisitos apenas aqui, mas aqui e aqui, que mudaria todo o conjunto de processos mais tarde também. Temos que retroceder e reconstruir coisas diferentes. Outra coisa é o custo. O custo para executar um monte de incrementos diferentes vai ser muito maior. Não só vamos ter que ter essa sobrecarga de gerenciar essa coisa, nós também teremos que ter várias equipes trabalhando em incrementos diferentes porque a mesma equipe que está trabalhando nesse incremento para terminar isso pode não ser a mesma equipe que pode trabalhar nisso. Caso contrário, nós meio que entramos nessa coisa linear ou estamos apenas passando de um para o outro, e isso pode ser um processo. Podemos fazer um processo incremental em que simplesmente passamos de um para o outro. Mas perdemos um pouco do benefício quando fazemos isso, porque perdemos um pouco dessa velocidade e tal. Ganhamos com isso, mas esse é o modelo incremental. É uma ótima maneira de empacotar diferentes processos de design. E o que é legal sobre isso é que em cada um desses processos, podemos realmente usar um modelo totalmente diferente. Então este pode ser o modelo incremental, e poderíamos usar a cachoeira para este modelo. Poderíamos usar o modelo aqui em baixo, e poderíamos usar um “ela me “aqui em baixo. Isso realmente não importa porque eles são todos pequenos produtos individuais. Mas o modelo incremental é importante, e é um bloco de construção muito bom para outros modelos no futuro. 7. Framework de processos Unificado: Então o próximo modelo que vamos falar não é realmente um modelo, mas mais de um que chamamos de framework, e a razão para isso é que podemos realmente usar modelos dentro deste modelo. Então, ao longo deste processo, podemos usar diferentes modelos como o modelo de cachoeira ou modelo de TV. Isso é me ver ao longo de todo este passo com aqui? E então nós não somos uma espécie de constrangido a um único modelo, foram basicamente ter um plano de jogo ou uma visão geral do que estamos tentando fazer. E então, a partir disso, usamos modelos para realizar essas tarefas. Então esta é a estrutura unificada do processo. E há muitos desvios disso provavelmente acima de 20 desvios diferentes de pessoas que olharam para isso e tentaram chegar a um que resolve um problema específico . Por exemplo, há um chamado de modelo Rational, Unified Process. Há um que é muito leve. Há um que foi projetado especificamente para mais coisas como Agile. Há um monte de iterações diferentes porque esta é uma maneira muito boa de capturar a idéia de desenvolvimento de software e, em seguida, tipo de dar uma visão realmente Ni disso. Então este é o gráfico aqui à esquerda de onde passamos nosso tempo. Temos essas diferentes fases chamadas início, elaboração, construção e transição. E estes aqui são basicamente espaços reservados. Se você está em uma empresa, você criaria seus próprios olhos ou facilidade ou vê Ortiz e cada um deles teria um objetivo no final. Então, em cada fase de construção, você colocaria um objetivo no final da fase. E é assim que você sabe, se você mudou para a próxima fase de uma vez, essas coisas foram concluídas, e isso está apenas tentando lhe dar uma idéia sobre como esse processo funciona. Está na fase inicial. Estamos determinando a viabilidade do projeto. Pode ser algo que possamos construir isso mesmo possível? Nós olhamos para o cronograma e custo potencial do projeto. Tente estimar, sabe, quanto tempo vai demorar? Quanto vai custar à empresa? Qual é o retorno do investimento? Então nós decidimos. Queremos comprá-lo ou construí-lo? Talvez haja uma solução lá fora. Talvez haja uma solução parcial lá fora que possamos comprar a solução parcial e construir a partir daí. Temos de analisar isso também na fase inicial. E então a entrega ou o objetivo para isso é tentar obter algumas metas de ciclo de vida, tentar descobrir o plano, descobrir para onde estamos indo, quanto custou, quem precisamos de uma coisa maior como essa. E isso é nesta fase inicial, e você verá que nós temos esse tipo de o que temos falado todo esse tempo no lado esquerdo. Aqui temos os requisitos para projetar a implementação, testes e implantação aqui e , em seguida, essa idéia de modelagem de negócios, que é apenas essa idéia, você sabe, custos e pessoas para contratar e coisas assim. E então vocês notarão que na fase inicial, o que estamos fazendo é que estamos fazendo um pouco de requisitos, talvez dando um esboço áspero do que estamos tentando criar. Mas realmente modelagem de negócios, estamos descobrindo que é algo que nossa empresa quer gastar o tempo eo recurso é construir, e isso é importante porque nós não queremos construir algo que não vai nos fazer dinheiro a longo prazo. E esta é uma ótima maneira de gerenciamento de riscos. Em vez de entrar em um projeto e gastar muito dinheiro, gastamos uma pequena quantia de dinheiro exploratório adiantado e descobrimos se isso é bom para nós uma vez que estamos fora dessa fase. Uma vez que temos uma ideia, temos algumas marcas de verificação que dizem, sim, vamos em frente com ela. Passamos para a fase de elaboração, as fases de elaboração onde tomamos essa ideia. Esta e esta idéia de que tivemos um início e nós construímos isso, nós chegamos com suas necessidades. Então é aqui que os requisitos vêm pesados. Aqui abordamos os fatores de risco conhecidos. Verificamos e validamos as arquiteturas do sistema. Então, nesse caso, nós estamos realmente indo para potencialmente construir o próprio código de protótipo núcleo para teste. Então vamos construir um tipo muito, muito solto de idéia de código que vai falar um com o outro. É meio que vai fazer o que temos, mas basicamente vai nos mostrar que é possível. Basicamente, prova de conceitos é o que chamamos a isso. Então vamos digitar algum código, ver se funciona da maneira que achamos que vai funcionar. E a partir daí podemos realmente começar, você sabe, elaborá-lo sobre ele na construção. Mas nesta fase, estamos fazendo apenas um pouco disso. E é por isso que você pode ver que a implementação vai para cima aqui. Estamos começando um pouco a implementação novamente para tentar descobrir Pode ser feito? E em caso afirmativo, de que maneira? Estamos fazendo um pouco de teste porque precisamos ver se ele está fazendo o que achamos que deve ser e, em seguida, implantando. Estamos implantando para outras pessoas estavam dando para testadores estavam mostrando às pessoas que, hey, esta prova de conceito realmente funciona. E então isso é pesado e a análise e o design também. Então estamos construindo diagramas de casos de uso e diagramas de classe e diagramas de arquitetura, etcetera em construção com a construção. O que estamos fazendo é construindo a coisa. Então, estamos realmente trabalhando fortemente na implementação aqui. Vamos colocar todos os nossos recursos nisso, e esta é a fase mais longa e maior do projeto. Você pode ver por isso que eles elaboraram com vários valores ver aqui, várias fases diferentes e formas de passar por isso. Este sistema é construído sobre a base estabelecida pela elaboração. Então nós construímos este tipo de arquitetura, este modelo muito pequeno ou talvez até mesmo um pequeno projeto. E a partir disso vamos construir a partir daí. Os recursos são implementados em iterações de caixa de tempo curto. Isto é importante. Isso significa que estamos construindo basicamente totalmente trabalhando em produtos sem recursos. Então nós temos, é claro que você sabe, ele começa com a caixa, e mais tarde nós adicionamos as características como se fosse um carro que tínhamos as rodas e mais tarde nós adicionamos, você sabe, você sabe, o pára-brisas, etcetera, etc. Mas o que estamos fazendo é começar com uma unidade viável. Então aqui, você sabe, eu quero dizer o mal. Desistir. Nós poderíamos colocar, você sabe, blocos quadrados aqui. Ainda é um carro. Ele ainda é capaz de ser conduzido, mas com o tempo estamos tornando-o melhor e melhor e melhor. Estamos adicionando mais recursos foram recebendo um pouco de feedback, e estamos adicionando mais recursos por causa desse feedback e fazendo iterações melhores e melhores . E isso está se dando bem com essa idéia de aeração. Lembre-se, intuitivo e incremental Will isso realmente realiza um pouco de ambos nas pequenas partes aqui. O que estamos fazendo é incriminar. Então estamos fazendo um fazendo pequenos incrementos até fazermos uma iteração real. Uma vez que terminamos a geração, nós implantamos, obtemos algum feedback dele, e começamos de novo em pequenos incrementos até chegarmos a essa iteração e assim por diante e assim por diante e assim por diante. E a entrega O quê? Aqui está um fluxo contínuo de melhoria de software. Então nós vamos ter, você sabe, aqui é onde nós temos a versão. Você sabe, eu acredito que geralmente começa com, tipo, tipo, 0,1, que nós temos 0,20 ponto três etcetera, onde nós realmente começamos a chegar com esses rótulos de versão à medida que ficamos melhores e melhores. E finalmente temos essa ideia da transição. A transição é onde o sistema é implantado para usuários de destino. O feedback é recebido, refinamentos são feitos e o touro de entrega é assim que este estiver completo, o produto final também estará completo. Então, na fase de transição, maior parte do nosso design é praticamente feito estavam ficando para baixo. implantação estava refinando e garantindo que a modelagem e os requisitos de negócios completamente encontrados. A fase de teste começa aqui, e nós realmente começamos a fase de implantação onde nós damos para as pessoas e vemos o que eles pensam sobre isso. Veja se precisa haver mudanças se precisarmos fazer mais algumas iterações no projeto final. E assim, com esse tipo de ideia com essa ideia, temos uma estrutura na qual poderíamos criar nosso plano. Então isso não é algo que você sabe que pode olhar. E haverá um guia 123 sobre como criar uma estrutura de processo unificada para o seu projeto. Tudo o que é é que são apenas esses grupos e esse tipo de esboço do que você deve fazer. E depois disso, você tem que desenvolver um plano inteiro para o seu projeto. Devido a isso, temos certos prós e contras associados a isso. Os profissionais são adaptativos. Sua qualidade e foco de reutilização. Ele está focado na gestão de riscos em cada etapa. Estamos tipo de re avaliando os requisitos, descobrir se precisamos continuar ou se devemos abandonar o projeto flexível fazendo corporativo. Outros modelos que podemos, como eu disse, incluir outros modelos e áreas em cada um dos passos cada incremento. Podemos mudar completamente o modelo e trabalhar a partir daí. Os contras O r Se você olhou para isso e disse, Bem, como nós realmente implementamos isso? Bem, o jeito que você faz é que você precisa de um monte de bons gerentes e pessoas habilidosas para inventar esse plano desde o início. Não é fácil. Não é algo onde podemos olhar para ele e dizer, Sim, OK, deixe-me apenas pegar um pedaço de papel e escrever isso muito rápido. Tem um monte de sobrecarga, e isso torna isso muito complicado. Vai ter muita sobrecarga para projetos de pequena escala, se você quiser. E pequena escala é algo tão , como, grande quanto, como,como, um aplicativo como um aplicativo na loja de APP que apenas como uma única tarefa, digamos que talvez seja um jogo na loja de APP. Isso pode ser muito pequena de uma escala para que isso seja realmente um quadro viável para usar. E isso significa que você tem essa coisa realmente grande onde você não tem um monte de projetos que se encaixam nisso. Estamos falando realmente grandes ou projetos que têm um monte de diferentes disciplinas envolvidas. Você sabe, coisas que contatam servidores e diferentes olhos de AP e coisas que são construídas no front-end e no back-end e todas essas coisas diferentes. É aí que você pode isso ser justificado. Mas para muitos projetos, isso é muito complicado e também por causa da maneira que ele é projetado por causa dessa maneira de onde estamos fazendo todas as fases de uma só vez, e estamos potencialmente trabalhando em diferentes modelos e orações tudo ao mesmo tempo, vai precisar de mais. O recurso está em execução. Quanto mais programadores, mais gerentes, mais testadores. Mawr Uh, basicamente tudo mais dinheiro para fazer isso, e o cronograma também provavelmente vai ser bem rápido, mas vai custar muito, então temos o jeito. Essa é a velocidade de que é importante devido a este custo. Mas essa é a estrutura unificada do processo. Eu definitivamente ir procurar isso no Google ou algo assim, e olhar para ele um pouco mais porque há um monte de variação diferente deste, e eles são todos carne bonita e carne e bom para entender sempre que você está aprendendo sobre engenharia de software. Mas esta é uma coisa muito importante, e esta é, na verdade, uma das estruturas mais usadas dentro da indústria hoje em dia. 8. Modelo espiral de 1 a 7: Então agora temos o modelo espiral. O modelo espiral é apenas que é uma espiral. O que estamos fazendo aqui é que estamos constantemente indo sobre o mesmo tipo de áreas de desenvolvimento repetidamente para garantir que ambos estamos hiper analisando os riscos ou analisando a cada passo. E estamos nos certificando de que estamos indo e validando o que estamos fazendo à medida que avançamos, há um risco muito orientado. Estamos tentando avançar com passos muito pequenos e nos certificando de que temos essa idéia de ir ou não ir. Significado. Queremos continuar o projecto, ou queremos acabar com o projecto aqui? É muito bom para idéias experimentais, idéias que você acha que podem ser possíveis, mas você realmente não sabe ainda, então nós meio que dar esses pequenos passos em frente e garantir que não vamos todos em ponto não editado. Nós só queremos ter certeza de que estamos analisando a situação, analisando o que fizemos e procedendo se ainda é viável e uma boa idéia para prosseguir . Então, o que? O modelo espiral? O que fazemos é começar nesses quadrantes e nos movemos continuamente através deles. Então este é o quadrante 123 e depois quatro. E o que fazemos é ir. 123412341234 Como este e o que estamos fazendo enquanto continuamos indo cada vez mais longe é estamos expandindo o escopo, o custo, o nous em profundidade de cada passo, o tempo total que gastamos com ele. Então, no início, estamos criando protótipos rápidos. E quando saímos, torna-se mais lento. Nós olhamos mais para ele. Colocamos um pouco mais de análise no que fazemos. Mais testes até chegarmos ao produto final em algum momento. Então vamos dizer que nós começamos aqui taxa nesta parte, que é nós vamos determinar objetivos, alternativas e restrições. Então aqui estamos determinados esses objetivos, as alternativas que as restrições estavam determinando tudo o que o projeto é, nós estamos basicamente criando um plano. A partir daí, movemos e identificamos e resolvemos os riscos. Neste ponto, estamos apenas identificando riscos. Não há nada para resolver, já que não codificamos nada e criamos um protótipo que nesta situação é apenas um plano. Então começamos a executar esse plano, o conceito de operação. Então aqui podemos ter em vez de realmente codificar nesta primeira fase inicial, talvez nós criemos, você sabe, modelos de classe. Ou talvez tenhamos uma ideia geral sobre como o conceito vai funcionar. E é por isso que isto é uma validação de conceito. Nós nem fizemos isso nos requisitos e coisas assim. Em seguida, criamos o ou olhamos para ele. Então, jogamos na próxima geração. Então, nós criamos esse conceito que vem com essa idéia geral de como um protótipo deve funcionar, analisar o risco. Agora, vamos criar o plano de requisitos e o plano de ciclo de vida. Como é que vamos desenvolver isto? Como vamos chegar a um conjunto sólido de requisitos e então planejamos isso, e isso é sobre exploração. Então agora estamos chegando aqui, fazer outro conjunto de análise de risco é que ainda é algo que parece ser viável com nossos custos, nosso orçamento e nossa mão de obra. Se sim, construímos o próximo protótipo novamente. Isso pode ser apenas uma iteração no plano. No geral, ele não precisa ser um protótipo de trabalho real. É apenas uma espécie de talvez a documentação é um pouco mais grossa aqui. Em seguida, passamos para as simulações. Eso estão nesta situação particular. Estamos fazendo modelos de simulação ou benchmarks. É toda a área dele. Então estamos meio que aqui estendendo o que estamos fazendo. Então neste loop em particular estavam provavelmente fazendo requisitos de software, validação , coisas assim, nós apenas chegando com o plano geral dele. Então nós realmente elaboramos um plano para a próxima fase, que é o desenvolvimento. Mover aqui, fazer o desenvolvimento da verificação, fazer a análise de risco para o movimento de integração. A próxima fase Fazer análise de risco, Olhe para um protótipos operacionais de algo que podemos realmente dar a alguém condenação ou testes de benchmarks e, em seguida, liberar. E este é um modelo muito, muito básico. Pode haver ah, muitos loops, e entre estes, especialmente durante a fase de desenvolvimento, podemos fazer este tipo de modelo iterativo nesse sentido. Então aqui nós tínhamos um único loop onde basicamente cobrimos a coisa toda, e ele seguiu em frente, mas pode haver uma tonelada de loops, e pode haver, você sabe, 100 pouco diferente. Ele orations dentro desse processo de desenvolvimento em que estamos constantemente verificando o risco e planejando nossa próxima fase, constantemente passando por cima dos objetivos e restrições e nos movendo para fora de lá. E este é um modelo muito, muito poderoso porque essa coisa focada em risco é muito bom se estamos, você sabe, dando passos em frente em uma área desconhecida, e é muito, muito adaptável. Então, mais uma vez, é ao longo dessa idéia de. Em vez de ir em linha reta, talvez tenhamos que nos mover para chegar ao nosso objetivo. Este é um ótimo modelo. Faça isso porque estamos constantemente reavaliando o que estamos fazendo, olhando para o que fizemos no último ciclo e criando uma nova idéia para o próximo ciclo. Agora isso parece complicado, e isso é porque é complicado, especialmente em projetar isso para um projeto riel. Fica muito complicado, e custa mais gerenciar. Você precisa ter uma idéia muito boa do que você está fazendo para manter tudo no controle então você não, você sabe, começar com uma espiral e eles apenas tipo de, ok, nós vamos apenas revestir e você sabe, não realmente passar pelo teste e a implementação e a análise de risco constante. E você também precisa de engajamento mais constante das partes interessadas. O que é isso, a parte interessada é como o cliente, a pessoa que está pagando pelo software. Você precisa do envolvimento constante deles nisso. Se você está indo para ir com as opções para ir ou não ir, o que significa que nós continuamos, ou vamos abandonar o projeto? Você vai precisar que eles digam cada loop. Se esses loops são, digamos a cada cinco dias, talvez lá a cada duas semanas. Até você vai precisar daquela parte interessada a cada duas semanas para vir a uma reunião, sentar-se, saber o que fez na semana anterior e decidir se querem continuar ou não. E isso pode ficar um pouco entediante para eles. Então você precisa de partes interessadas que são propensas àquilo que querem estar engajados com o projeto . Muitas vezes eles não fazem. Eles só querem pagar a pessoa que o construiu, eles não querem realmente estar envolvidos no processo do dia-a-dia dele. Mas se você tem tudo que modelo spire é um ótimo modelo para esse risco. O gerenciamento é um ótimo modelo para criar coisas que precisam ser descobertas, onde você está tentando dar pequenos passos em frente. 9. Introdução ágil de 2-1: Agora passamos por algumas das áreas mais tradicionais. Eu queria repassar algo que é muito novo. Quero dizer, quando digo novo, é nos últimos 20 anos. Mas é algo para o qual muitas empresas mudaram, e essa é a ideia da metodologia ágil ou ágil. Em geral, Agile é uma maneira de pensar. É uma espécie de conjunto de princípios que você aplica. E então vamos rever um monte de modelos diferentes que funcionam com a metodologia ágil , coisas como Scrum e Kon Bon e outros termos que você pode ter ouvido porque eles são mais prevalentes na indústria de hoje. Os antigos, não eram maus. É que eram lentos. Estávamos desenvolvendo produtos do ponto A ao ponto B. Então começamos. Atravessamos em linha reta e chegamos lá. Às vezes, talvez tenhamos desviado um pouco. Tivemos que voltar e encontramos nosso objetivo final. Mas isso é tudo o que podemos fazer com os antigos. No mercado de hoje, as coisas mudam. Formas de desenvolvimento de tecnologia estão mudando a cada dia, e por causa disso. Precisamos ter certeza de que estamos desenvolvendo o software que resolve o problema. O problema em si pode mudar. E por causa disso temos essa idéia desse tipo de manifesto ágil e esse conjunto de princípios que nos permitem ser realmente fluidos e flexíveis em nosso processo de desenvolvimento. Então isso significa que podemos chegar a idéias que nos fazem ir em direções completamente diferentes e continuarão desenvolvendo com o cliente até encontrarmos exatamente o que eles estavam procurando. E com o modelo típico, seria muito difícil para nós continuar movendo isso. Nós perderíamos muito dinheiro, mas com isso nós realmente tomamos em pequenos incrementos e podemos continuar nos movendo a cada incremento na direção certa e com o tempo começamos a desenvolver o software correto. Então cada decisão que tomamos, nós lentamente começamos a usar. O cliente está feliz ou constantemente se comunicando com eles para construir seu produto final e para o método cachoeira ou a cachoeira tipo de conjunto de idéias, que é tipo de tudo no exemplo anterior que esse conjunto de, você sabe, nós primeiro fazemos design e então ou nós primeiro fazemos requisitos e, em seguida, nós fazemos design e, em seguida, começamos a implementar e, em seguida, começamos a testar esse tipo de idéia. Onde vamos um para o próximo tem problemas. Um deles é durante a verificação. Muitos problemas inesperados surgem. Nós, por exemplo, se codificamos um bug na arquitetura e estamos na verificação antes de descobrirmos isso , não há realmente nenhum onde possamos ir com isso. Ou se chegarmos a uma verificação, mostraremos aos nossos clientes. E eles dizem, “ Oh, não, isso não é exatamente o que queríamos, mas houve um pequeno erro de comunicação. Isto é o que queríamos. Bem, não há como voltar atrás e nós realmente não tivemos uma oportunidade de consertar isso antes com Agile. Tem algumas soluções para isso. Os sistemas de software são complexos e não podem ser 100% previstos. Isso é algo que é muito, muito verdadeiro é que se estamos contratando alguém para criar uma soneca, talvez não saibamos exatamente o que queremos. O aplicativo para dio. Queremos nos comunicar com eles ao longo do tempo para construir lentamente este aplicativo para construí-lo. Do jeito que queremos, e queremos que eles nos ajudem a descobrir o que queremos em um aplicativo, porque eles são os únicos que sabem programar. Eles são os únicos que sabem como criar as coisas, nós como a ideia. As pessoas não sabem exatamente o que queremos que o aplicativo faça e o que é capaz. Então, queremos trabalhar com alguém muito, muito inteligente. Uma empresa de tecnologia que realmente se desenvolve apta a chegar com a idéia final e uma metodologia ágil ajuda você com isso. No final, alguns softwares não atenderam aos requisitos originais ou modificados novamente. Se não for muito flexível, os requisitos podem ter mudado ao longo do tempo, e queremos ser flexíveis para que possamos mudar com eles e, em seguida, os mercados se movem ao longo do tempo. O produto pode estar desatualizado quando terminarmos. Ah, muitos dos modelos ágeis realmente têm essa idéia de criar um M V P ou um produto mínimo viável, algo que podemos colocar no mercado, você sabe, você sabe, dentro de quatro meses algo que nós pode jogar lá fora que tem apenas as características básicas , mas nada mais. E nós podemos realmente começar a receber feedback do usuário e podemos começar a resolver o problema. Talvez não 100%, mas pelo menos estamos resolvendo um pouco com isso. Com a cachoeira, normalmente não tiramos um produto até que esteja completamente 100% acabado. E por causa disso, temos um grande problema de que pode estar desatualizado. Digamos que leva dois anos para desenvolver este software totalmente bem. O problema já poderia ter sido resolvido por outra empresa naquele tempo. O problema poderia ter mudado com esse tempo. Muitas coisas diferentes podem acontecer onde podemos ficar ultrapassados quando terminarmos etodo esse dinheiro é desperdiçado. Muitas coisas diferentes podem acontecer onde podemos ficar ultrapassados quando terminarmos e Por isso, queremos ter a certeza de que podemos ser flexíveis em situações em que sabemos que os mercados estão constante movimento. E o manifesto ágil era assim. É um grupo de engenheiros que se juntaram e decidiram que a mudança era necessária. Juntos, eles vieram com o manifesto ágil que vamos discutir em detalhes na próxima palestra é um conjunto de idéias para desenvolver um software melhor, mais rápido e mais ágil. Eu deveria melhorar o sistema em geral, e um monte de empresas descobriram que ele faz exatamente isso 10. Manifesto agile de 2-2: Então agora vamos falar sobre o manifesto ágil. Nós mencionamos isso na última palestra, mas vamos repassar um pouco mais em profundidade. A coisa importante a entender sobre isso é ágil é um conjunto de diretrizes que conjunto de idéias com as quais desenvolvemos modelos. Então não há um modelo ágil lá fora. Não há um processo de desenvolvimento ágil. Há a diretriz ágil e, em seguida, criamos modelos baseados nas diretrizes ágeis. Algo como Scrum, por exemplo, é um modelo baseado nessas diretrizes. Então scrum é o modelo que desenvolveríamos em scrum. Mas scrum é um modelo ágil, e isso é apenas algo importante porque muitas pessoas se confundem com isso. Dizem que estamos desenvolvendo uma ágil quando tecnicamente não é verdade. O que eles estão fazendo é que eles estão usando um modelo que é baseado em ágil, então ágil novamente é este manifesto. É essa ideia. É o conjunto de diretrizes que usamos para desenvolver software, e podemos, se quisermos, colocar esses números aqui e eles são diferentes tipos de inquilinos ou ideias e diretrizes diferentes . Em vez de engenheiros, eles basicamente, a história diz que eles basicamente se juntaram e eles vieram com isso. Acho que foi em algum lugar no início dos dois milhares. Todos se reuniram e decidiram que a engenharia de software em geral tinha um problema. Havia um conjunto de problemas, e foi principalmente porque a engenharia de software veio da engenharia regular. Ele foi projetado como uma transição quase direta de, você sabe, você sabe, como construir uma ponte e as pessoas pensaram, OK, vamos construir um software da mesma forma que construímos uma ponte. No entanto, software é um pouco diferente, e há requisitos e maneiras ligeiramente diferentes de fazer as coisas quando você fala sobre software. Então eles se reuniram e pensaram, vamos encontrar uma maneira que melhoraria toda a indústria de desenvolvimento de software e juntos eles inventaram esses quatro inquilinos e muitas empresas usam isso para inquilinos hoje em dia porque eles são basicamente uma maneira muito, muito boa de fazer negócios. Eles aumentam a produtividade, aumentam as relações com os clientes e aumentam o lucro geral, que é o que as companhias aéreas vão buscar. Assim, o 1º 1 é indivíduos e interação sobre processos e ferramentas. Então este está focando nos indivíduos e engenheiros e todos os envolvidos na construção do software usando alguma ferramenta ou algum processo que usamos no passado e muitas empresas. Sempre que eles se desenvolvem ou vão de certa forma, eles recebem um conjunto de processos e um conjunto de ferramentas que eles usam. E se uma equipe de engenheiros chegar a uma liderança e eles dizem, você sabe, nós achamos que essas ferramentas e processos seriam melhores. Muitas vezes essas ideias caíram no ar porque é o jeito que sempre foi feito. Esses antigos processos e ferramentas já estão no lugar, então por que mudá-lo neste estavam tentando dizer que o indivíduo deveria ter mais controle sobre a forma como eles desenvolveram o software. Se o conjunto de indivíduos se juntarem e decidirem que um novo conjunto de processos, um novo conjunto de ferramentas deve ser implementado para basicamente melhorar a situação do que deveriam ter maior prioridade sobre a velha maneira de fazer as coisas, e nós queremos tipo de também neste sentido trabalhar, dizendo que o indivíduo é mais importante do que o processo nas próprias ferramentas, queremos tratar os indivíduos com respeito. Queremos tratar as interações que eles têm com respeito. Queremos tentar criar um bom ambiente de trabalho. Nós não queremos, você sabe, colocar as pessoas para você sabe, baixo porque eles querem usar novos softwares e ferramentas porque eles estão ligeiramente desviando dos processos e ferramentas atuais. Queremos elevar os nossos engenheiros e dar-lhes o maior respeito possível. número dois está trabalhando em software sobre documentação abrangente, e isso é um desvio bastante longe das idéias anteriores que passamos sobre as metodologias de cachoeira e os modelos de sashimi e tudo mais. E isso é porque ele sabe que estava muito focado em documentar e resolver tudo antes de começarmos a desenvolver aqui, apesar de termos virado isso em sua cabeça. E queremos um software de trabalho antes ou pelo menos como uma prioridade mais alta do que a documentação abrangente . A documentação é sempre importante porque permite que o nosso software seja mantido. No entanto, há um limite em que se tivermos 15 livros sobre como nosso software deve funcionar e como ele vai ser construído, provavelmente não seremos capazes de mostrar isso a ninguém e realmente obter qualquer feedback real sobre isso. Queremos criar um software de trabalho com um pouco de documentação. Talvez, você sabe, uma quantidade média de documentação, algo que possamos dar aos clientes ou dois testadores ou aos usuários e obter feedback real sobre isso para que possamos fazer mudanças em tempo real. Nós não queremos esperar até o final para começar a receber feedback, perceber que algo está errado, ter que mudar todo o software e depois ter que reescrever toda a nossa documentação. Não faz sentido. Portanto, queremos nos concentrar em fazer o software funcionar, obter software projetado, corretamente, construído corretamente sobre a documentação de todo o processo. Novamente, não estamos dizendo que estamos desistindo da documentação. Estamos apenas dizendo que queremos dar um pouco mais focado para obter o software realmente construído, em seguida, trabalhar para obtê-lo perfeitamente documentado. Número três Colaboração do cliente sobre negociação de contrato. Queremos ter um bom relacionamento com nossos clientes e nossos clientes. Nós não queremos ter que apontar para um contrato cada vez que uma mudança queria ou cada vez algo precisa basicamente apenas mover um pouco um monte de vezes com as empresas. Eles conseguem este contrato e apontam para o contrato. Sempre que surgir algo e dizer, o que diz o contrato? Certo, não estamos fazendo nada diferente. Estamos tentando dizer que a colaboração com o cliente é o que vai nos dar esse bom produto final. Se o cliente entrar e dizer “Ok, eu amo onde o software está indo, mas há uma coisa nova que recentemente saiu e vai ser, você sabe, talvez este software precise de um pouco de além Aqui. Talvez precise ser um pouco retrabalhado lá. Queremos fazer o cliente feliz para que um eles nos dê boas críticas. Eles nos pagam corretamente todas essas coisas. Queremos fazer com que o cliente se sinta apreciado. Queremos tornar o processo muito, muito bom para eles. Se cada vez que eles vêm e pedem mudanças de voo, nós dizemos , bem, vamos retrabalhar o contrato. Acabamos entrando em envolver equipes jurídicas, reajustando preços e passando por tudo isso. Vai ser uma dor e ninguém vai querer trabalhar connosco. Então o que estamos tentando dizer é que queremos tornar essa colaboração primordial para Oh, foi, foi, pelo menos sobre contratos de negociação de contrato. Mais uma vez, eles ainda são importantes. Não vamos jogar tudo isso fora. Só estamos dizendo, vamos falar com o cliente Mawr. Vamos fazer uma relação muito forte para irmos e continuarmos. Lee trabalhou com contratos para responder à mudança em vez de seguir um plano. Queremos ser capazes de ser flexíveis. Nós não queremos ser presos em um certo plano, e cada vez que um problema surge, nós dizemos, bem, qual é o plano diz que vamos ficar com o plano se não pudermos responder à mudança que estamos não em e de seu ent ou em si mesmo, ágil, que a palavra ágil não estava sendo que nós não estamos sendo flexíveis com nosso processo de design, e isso é o que Agile está tentando fazer é tentar criar um empoderamento das pessoas, realmente construir o software e fazer software que muda com os tempos porque tecnologia muda rapidamente. Não queremos processos que não nos permitam mudar rapidamente com a tecnologia, então queremos dar novamente. Queremos um plano, mas queremos permitir que mudem esse plano. Não permitiremos que sejamos flexíveis para mover o software desta forma. Dessa forma, sempre que colaborarmos com o cliente, vamos criar um software de trabalho para que o cliente possa ver o que está acontecendo, e eles podem nos dar ideias para que possamos responder à mudança. Queremos ter esses indivíduos e interação com o cliente e com nossos engenheiros para que novas ideias, ideias melhores sejam apresentadas. Podemos mudar as nossas ferramentas, podemos construir software de trabalho, podemos mostrá-lo aos nossos clientes e podemos responder às mudanças. E, no geral, esse é o manifesto ágil que estamos tentando criar. Este conjunto de diretrizes que nos permitem mudar e mover-se com o dedo do pé Times nos permite desenvolver software de uma forma mais otimizada. E a ágil fez uma ótima maneira de classificar que nas próximas palestras vamos começar realmente a falar sobre os modelos que são baseados em ágeis, e você pode ver que você será capaz de ver como essas são maneiras mais rápidas e rápidas de desenvolvimento do que o que já falamos anteriormente. 11. Scrum 2-3: Então o primeiro modelo ágil que vamos estar falando é o modelo scrum, então scrum que você pode ter ouvido antes porque é uma maneira muito popular de desenvolver software e Scrum se concentra nesses intervalos de 1 a 4 semanas diferentes. Então, basicamente, eles são chamados de sprints e sram. É um sprint scrum e o sprint é essa idéia de desenvolvimento rápido, adicionando os recursos de maior prioridade, depois indo para o cliente, as partes interessadas, todos os envolvidos, mostrando para eles, recebendo feedback e refazendo o ciclo. É a ideia dele de planejar, construir, aprender, repetir. Então vamos fazer todo o nosso design definido, construir e testar dentro deste tipo de sprint scrum aqui. E é aqui que as idéias de como back to back testing entram em jogo porque enfraquecer usado de volta para trás testes para garantir que entre sprints, que não estamos quebrando algo do anterior e para garantir que os novos recursos são funcionando corretamente também. Então, a cada sprint, vamos criar um produto que é um pouco melhor do que o sprint anterior . É a sua ideia de basicamente prototipá-lo. Então, cada protótipo será apenas um pouco melhor do que o protótipo anterior e muitas vezes talvez após o terceiro ou quarto sprint temos um produto que podemos realmente lançar no mercado e então começamos. Continuamos desenvolvendo , acrescenta. É lançado no mercado para que possamos obter um produto fora em, você sabe, três meses, talvez quatro meses que o cliente pode começar a ganhar dinheiro pode começar a tomar essas idéias sobre como corrigi-lo e torná-lo melhor. E podemos continuar desenvolvendo com base na interação do usuário. E assim o scrum é muito popular por causa disso, é muito rápido para o cliente começar a ganhar dinheiro, e também permite extrema flexibilidade no processo de desenvolvimento. Então eles são um par de pessoas diferentes envolvidas no processo de scrum. Nós temos o proprietário do produto e eles são basicamente as partes interessadas, todos que estão envolvidos em querer este pedaço de software, então a partir deles nós obtemos contribuições dos executivos, da equipe, das partes interessadas, clientes e usuários e, em seguida, o proprietário do produto olha para todo esse tipo de entrada e eles ajudaram a priorizar a lista dos próximos passos, o que devemos fazer para o nosso próximo sprint. Então precisamos de comunicação constante com o proprietário do produto e isso é uma espécie de desvantagem porque talvez tenhamos um proprietário do produto que não gosta de gastar o tempo priorizando o que vem a seguir. Eles só querem que façamos tudo. E se esse for o caso, os inquilinos do tribunal de Scrum desmoronam porque nós deveríamos estar basicamente criando esse design flexível que funciona com o proprietário do produto. Se ele sair, ele ou ela sai. Não temos essa entrada e começamos a desenvolver em direções potencialmente erradas. O mestre Scrum. Eles mantêm a equipe responsável a scrum idéias e eles facilitam reuniões e fazer a resolução de conflitos para um pouco de planejamento do lado. E então a reunião Scrum é basicamente a pessoa principal para o modelo Scrum lá. Outro pode ser um engenheiro de software líder também. Isso é, você sabe, trabalhar com mais o código, mas o mestre scrum está segurando o dedo do pé da equipe responsável, certifique-se de que eles estão seguindo todos os inquilinos scrum e eles estão fazendo tudo da maneira correta e da moda Porque se desmoronarmos e pararmos, sabe, de aderir aos nossos sprints. E nós não atingimos nossos objetivos durante nossos sprints. Então todo o processo novamente vai desmoronar porque não vamos ter produtos acabados para mostrar ao nosso cliente. Não vamos receber esse feedback, e não vamos ser muito flexíveis. E então, finalmente, temos a equipe, e essa é a equipe realmente construindo o software. E isso não são apenas engenheiros de software. Podemos ter engenheiros liderando engenheiros. Podemos ter designers. Podemos ter apenas codificadores básicos que não sabem muito sobre engenharia, mas eles são muito bons em uma única linguagem, fazendo uma única coisa. Ah, muitas vezes isso pode estar fora contratado ajuda para uma tarefa específica. Talvez devêssemos procurar um site freelance. Nós contratamos alguém só para este sprint para construir um módulo, pagar a pessoa, e então ele está fora para o próximo sprint. À medida que temos mais e mais pessoas, então há a equipe pode tipo de mudança. Mas há pessoas essenciais na equipe, e há papéis, e todos eles se reúnem para criar o produto no. Este é um tipo típico de maneira que scrum funciona é que temos essa idéia do backlog produto . Este é um conjunto de, ah, lista basicamente coisas que precisam ser feitas. Então nós temos, você sabe, essa lista de idéias e coisas que precisam ser feitas, o problema. Não sabemos como priorizar essa lista. Então, muitas vezes vamos trazer as partes interessadas bem para a reunião de planejamento sprint. Então vamos perguntar a eles. O que vocês querem agora neste processo? O que o ajudaria ou o que gostaria de ver? O que é mais importante para tirar este produto? Uma vez que tenhamos essa idéia configurada, criamos um backlog sprint onde este é essencialmente o conjunto de idéias que vamos estar trabalhando para este sprint atual. Nós estabelecemos um prazo. Se vamos fazer isso em três semanas, em duas semanas, faremos em 15 dias. Vimos algum tipo de prazo para isso, temos a nossa lista de objectivos e, em seguida, começamos o processo de criação. Então começamos a ter essas reuniões diárias de scrum, que é essencialmente elas são tipicamente menos de 20 minutos. A equipe de scrum se reúne, eles falam sobre o que fizeram ontem, o que planejam fazer hoje e quais obstáculos estão lidando e, potencialmente, quais os passos que usarão para consertar esses bloqueios. E essa comunicação é importante porque talvez um determinado usuário ou um certo engenheiro fale sobre como eles estão lidando com esse obstáculo com a integração do banco de dados ou algo assim. Bem, outro engenheiro , você gosta Bem, na verdade, eu fiz isso no passado. Eu sei como consertar isso. Vamos nos reunir hoje e mostrarei como consertar isso e passar por aquele bloqueio. Assim, esta comunicação permite a entrada de engenheiros diferentes em diferentes projetos ou partes diferentes do projeto, e para ajudar uns aos outros. Eles completam todo o seu trabalho no dia seguinte. Eles têm a reunião diária do Scrum, e continuam avançando. Isso também permite que todos mantenham o controle de quão perto eles estão de terminar seu sprint e manter ou garantir que eles estão no horário para o seu sprint. Uma vez que o sprint é feito, ele vai para Sprint Review. Normalmente trazer as partes interessadas de volta em demonstrar o Sprint leva algumas sugestões, eles perguntaram a uma parte interessada, É isso que você estava falando. Eles dizem que sim. Exceto que estávamos pensando que essa área deveria fazer isso e aquilo. Nós marcamos isso, fazemos essas anotações, e normalmente, isso talvez volte para o backlog do produto. Enquanto temos as partes interessadas aqui. Nós perguntamos a eles. Ok, o que você quer na próxima primavera? Eles nos dizem o que estão procurando no próximo. Eles priorizam nossa lista. Começamos o processo de novo. Agora, a coisa é, nós também fazemos uma retrospectiva de sprint. Então, depois de termos feito a visão sprinter com as partes interessadas, os proprietários de produtos, todos que, você sabe, basicamente, não viram este produto nos últimos dois são de 1 a 4 semanas. Então vamos para uma retrospectiva Sprint, que é apenas a própria equipe de software. Falamos sobre o processo sobre como as últimas 1 a 4 semanas foram e vemos se suas maneiras de fazer melhor o que você sabe, nos atrasaram em uma espécie de ambiente de equipe. E o que nos atrasou individualmente são as maneiras que podemos corrigir que depois de uma retrospectiva da Sprint , começamos o próximo planejamento da Sprint. Obtenha todas essas listas e repetimos o processo uma e outra vez até que o produto esteja completo. Então scrum é ótimo por sua flexibilidade, porque temos tanta revisão, tanto feedback de nossas partes interessadas estavam constantemente recebendo orientação sobre o que devemos fazer a seguir. Nós não estamos nos comprometendo com algo em que nós, você sabe, criamos esse projeto gigante e quando o produto é desenvolvido, ele está completamente errado. Estávamos nos certificando de que estamos fazendo esses pequenos sprints, caminhando para a frente, passo a passo e levando em feedback, Então nós criamos o produto que o cliente está nos contratando para criar. 12. 2-4 Kanban: nosso próximo modelo ágil é o de combinar. Então, se você sabe alguma coisa sobre a língua japonesa, esta é uma palavra muito japonesa, e a razão para isso é que ela foi realmente desenvolvida no Japão. Suas origens podem ser rastreadas até o Reino Unido no desenvolvimento Spitfire. Aqueles são realmente bons aviões que eles desenvolveram naquela época, no entanto, foi popularizado, refinado e realmente implementado no mercado consumidor com Toyota e Toyota é uma empresa japonesa. Eles basicamente deram uma olhada no processo atual de fabricação de carros, e eles queriam torná-lo mais situado. Então tudo estava disponível que os fabricantes de carros da fábrica poderiam obter. Estava tudo disponível como se não fosse um supermercado e você poderia subir e pegar o que precisasse para completar seu processo. Basicamente, eles queriam tudo para uma pessoa, fazer seu trabalho para estar ao alcance do braço, e eles queriam uma placa para rastrear o progresso, olhar para o fluxo atual e continuar melhorando o fluxo para que eles pudessem fazer mais e mais e mais carros, e tornou-se muito popular. Tornou o banheiro um convento muito bem sucedido desde então foi adaptado para o mundo do software e é o mesmo tipo de técnica que queremos mentir popular ou você quer refinar nosso fluxo. Eu quero pegar o fluxo de cartões de bugs de recursos, e queremos descobrir onde os gargalos estão e continuar melhorando continuamente sobre ele. E aqui está um pequeno exemplo disso. Ah, muitas empresas de software usam algo assim, então você terá cartões. O backlog é o uso do que é mais preenchido, então você tem um monte de cartas no backlog, e então quando queremos começar um projeto, queremos começar um dos cartões. Nós apenas movê-lo para cima. Então vamos dizer que temos um casal na fase de análise um na fase desenvolvida, e então talvez tenhamos quatro na fase de teste e, em seguida, dois na fase de liberação. Só de olhar para isto, vemos duas coisas que vemos. Temos um monte de coisas para levar. Ainda há muito neste projeto, e vemos que temos um pequeno gargalo na fase de testes. Há um problema aqui. Talvez não tenhamos engenheiros suficientes nos testes. Talvez nossos testes atuais ou nossas metodologias atuais com testes sejam lentos ou não estejam funcionando corretamente. Talvez haja muitos erros ou erros que estão acontecendo dentro do teste por causa da má análise. Sabemos apenas olhando para isso que há um problema com a fase de teste e que queremos melhorar a fase de teste e tentamos fazer isso de forma lenta e incremental. Fazemos uma pequena mudança. Passamos por isso de novo e vemos se estamos melhorando isso. Estávamos tentando pegar esses números grandes aqui. Estamos vendo quais porcentagens na coluna de testes. Talvez agora seja algo como 25% de todas as cartas estão sentadas aqui, e então tentamos fazer algumas mudanças. Damos uma olhada em dois ou três meses, e tentamos reduzir para 15% melhor tipo de distribuição em vez de, você sabe, eles estão sendo um grande caroço e, em seguida, para baixo e em um grande caroço e, em seguida, de volta para baixo. Estamos tentando, você sabe, você sabe, fazer com que seja perfeitamente nivelado para que o desenvolvimento esteja se movendo perfeitamente , e com tudo isso, temos um par de inquilinos principais. Aqui temos as Propriedades Con Bon e os princípios CONVEN, as propriedades ar, apenas algumas idéias e coisas que podemos querer seguir. Embora os princípios estejam praticamente trancados em pedra, estas são coisas que cada vez que você olha para cima, combinam princípios. Você vai ter esse conjunto aqui, e então vamos repassar isso primeiro. Então o número um é começar com. O que você sabe? Isso é importante porque o sistema Kon Bon pode ser implementado em seu sistema atual . É uma forma de acompanhar o progresso e melhorar o fluxo desse progresso para que você possa tecnicamente colocá-lo em qualquer coisa e continuar melhorando o fluxo. Você pode até mesmo anexar isso para como um método de cachoeira da maneira correta e ver o que está segurando você durante esse método com Khan Bun o primeiro novamente, Vamos começar com o que você sabe? Não queremos jogar tudo fora e começar completamente do zero. O que queremos fazer é acabar com isso, implementar uma pequena mudança. Talvez nossas mudanças estivessem implementando um quadro como este para que possamos realmente começar a rastrear o progresso e então nos movemos de lá. A partir daí, concordamos em buscar mudanças evolutivas incrementais. O que isso significa é que não estamos tentando mudar tudo de uma vez. Nós não vamos olhar para isso e fazer o teste é obviamente onde o gargalo está. Vamos contratar mais cinco engenheiros de teste. É uma grande mudança. E pode causar outros problemas na estrada. Um, ou talvez um tipo melhor de mudança que podemos fazer é dizer, hey, quem está trabalhando no desenvolvimento, talvez possamos ter um desses caras a cada duas ou três semanas, passar algumas semanas e testando e pulando para frente e para trás. É uma pequena mudança sempre que os engenheiros vão mover rolos apenas por um pouco de inteligência para trás e para frente por algumas semanas todos os meses. E que depois contestamos isso está ajudando? Isso está doendo e vai fazer mais mudanças com base nisso. Então queremos mudança evolutiva incremental, não saltos gigantes. Queremos respeitar o processo atual, papéis, responsabilidades e títulos, e isso é importante porque não queremos descartar completamente um sistema só porque achamos que pode estar errado. Queremos novamente fazer essas pequenas mudanças para que queremos respeitar o processo atual. Queremos respeitar tudo o que está acontecendo com nossa configuração atual. Queríamos dar uma olhada muito séria neles e apenas fazer pequenas mudanças. Não queremos começar a demitir pessoas e mover pessoas por todo o lado. Ele cria esse medo de instabilidade dentro do projeto que vai nos atrasar ainda mais, então queremos olhar para o problema, ver como podemos torná-lo melhor e fazer essas pequenas mudanças. E, finalmente, este é adicionado às vezes, às vezes não. Mas eu acho que é importante incentivar atos de liderança em todos os níveis. O que isso significa é que queremos encorajar nossos trabalhadores mais baixos a mesma quantidade que o nosso mais alto dos trabalhadores, o mais baixo dos trabalhadores, que significa que eles estão apenas codificando. Eles não estão fazendo muito do processo de design. Eles só estão fazendo mudanças. Queremos ter certeza de que estão sendo honestos e eles estão sendo francos da maneira que estão codificando. Queremos que tomem boas decisões. Embora os revestimentos incentivem esses atos, e a liderança aqui não tem que significar que estavam realmente liderando outras pessoas, isso pode significar simplesmente que eles estão inspirando os outros porque lá trabalhando muito duro e eles estão criando código sólido e muito livre de bugs. Então o que? Encorajo que, em todos os níveis e em algumas das propriedades, algumas das maneiras que podemos chegar a esses princípios é uma. Visualize o trabalho completo. É muito importante com a combinação. Queremos colocá-lo em uma parede gigante ou em um site, ou onde todos possam acessá-lo para que possamos olhar para o fluxo de trabalho. E qual é o problema com isso? Vemos obviamente que temos o problema nos testes e precisamos trabalhar com ele. Limite o trabalho em andamento. Esta é uma das principais chaves neste é que queremos limitar quanto trabalho continuamos passando . Não queremos que todo esse trabalho esteja em andamento, porque nesse ponto todo mundo se espalhou muito e não estamos fazendo muito progresso. Não estamos sendo capazes de ver o fluxo porque não há nenhum fluxo. Todos pararam e Onley dando passos muito, muito pequenos em direção ao produto final. Ainda estamos tentando tornar isso um pouco ágil. Ainda estamos tentando acelerar o processo de desenvolvimento. Então, sempre que vemos algo assim, queremos parar qualquer inclusão de backlog e tentar trabalhar através dos bugs atuais antes de introduzirmos mais no processo. Gerencie o fluxo novamente. Queremos olhar para o fluxo e queremos gerenciá-lo. Queremos ver onde estão os problemas e qual a mudança que esses problemas não quebrariam. Políticas de processo, reunião explícita. Não queremos apenas explicar a alguém, sabe, sabe, é assim que se faz. É assim que fazemos , assim. Queremos ter um pedaço de papel com todas as nossas políticas, detalhes que possamos dar às pessoas que queremos que elas tenham acesso mais fácil e explicitamente escritas . Não queremos mais nenhuma área cinzenta. Queremos algo que seja muito, muito explícito, muito fácil de encontrar e muito fácil de seguir isso novamente. Isso faz com que todos os nossos engenheiros estivessem seguindo o processo e se nós sabemos que todos eles estão perfeitamente seguindo o processo, nós sabemos como mudar o processo porque todos os engenheiros não estão seguindo nossa política , não importa como fazemos alterações na política, ainda não vamos segui-la e nenhuma mudança ocorrerá de fato, então precisamos ter certeza de que eles estão seguindo isso. A única maneira de fazer isso é torná-lo muito explícito, certificando-se de que eles podem lê-lo e aplicá-lo. Em seguida, podemos fazer alterações com base nele e, finalmente, melhorar colaborativamente. O que queremos dizer com isso é que queremos melhorar como um grupo iria melhorar colaborativamente ajuda ruim lá mesmo. Queremos melhorar juntos. Nós não queremos fazer apenas pequenas mudanças de cima para baixo, significa que o líder olha para tudo. Diz que estamos a fazer esta mudança. Queremos melhorar como grupo. Então você quer ter reuniões de grupo, quer ter problemas levantados, nós queremos ter, talvez trazer as partes interessadas também. E queremos ter essas pequenas reuniões e colaborações sobre como vamos melhorar . Todos devem estar envolvidos para que possamos continuar melhorando o processo porque talvez nós como um , digamos, nós como um gerente de programa, nós não entendemos os problemas aqui e testando. Então nós tentamos implementá-lo, você sabe, mudanças nos testes pelo que nós achamos que o teste é bom, isso não vai realmente nos ajudar, porque se nós trouxemos alguns dos engenheiros de testepara porque se nós trouxemos alguns dos engenheiros de teste você sabe, mudanças nos testes pelo que nós achamos que o teste é bom,isso não vai realmente nos ajudar, porque se nós trouxemos alguns dos engenheiros de testepara vai nos explicar melhor por que há um gargalo lá. Talvez estejam dizendo que estamos muito sentados e que não temos gente suficiente para lidar com isso. Talvez haja processos no final do estado de análise, onde você está realmente criando o design. Talvez sejam erros no desenvolvimento. Os desenvolvedores são apenas seu lápis chicoteando tudo, e eles não estão fazendo um bom código. Queremos falar com os engenheiros de testes e falaremos com todos os engenheiros para descobrir esse problema. E assim melhorar de forma colaborativa é uma parte muito importante. Mas comum é uma forma muito, muito legal de desenvolver código. E é um divertido esperar até olhar para todos os visuais e para continuar melhorando a cada dia basicamente 13. Startup lean de 2-5: Vamos falar sobre a inicialização enxuta, que é outro modelo ágil. A inicialização enxuta é muito, muito interessante, e é algo que é relativamente novo e algo que você realmente só pode fazer com tecnologia. O lean startup é esse tipo de forma experimental de construir produtos. Por experimental, quero dizer literalmente. Você está fazendo experimentos para ver se seu produto pode realmente ganhar dinheiro no mercado. Então o que fazemos é ir para esta idéia de aprender, construir medida. Pegue as medidas que aprendemos construindo, etc., e estamos tentando criar um produto o mais rápido possível e o mínimo possível para ver se há um mercado lá fora. Então o que fazemos é fazer algum tipo de suposição. Fazemos uma hipótese se você gosta do método científico, e estamos tentando descobrir se essa hipótese ou suposição é verdadeira. Então o que fazemos é construir um experimento. Construímos um site, construímos um serviço e vemos se as pessoas estão interessadas nele. Em seguida, usamos esse interesse como uma métrica, e ajustamos com base nessas métricas. Um exemplo muito, muito popular disso é da empresa Zappos, Zappos foi basicamente fundada em 1999 quando a Internet estava apenas começando a tomar um pouco de vapor. Muitas compras online ainda não eram muito populares. Naquela época, no entanto, o Foundered foi a um shopping local tentando encontrar alguns sapatos, e ele não conseguia encontrar os sapatos que ele queria. E foi basicamente isso. Ou ele comprou sapatos no shopping ou não comprou sapatos. Era assim que era antigamente. Então ele pensou, “Ei, vamos construir um site que possamos colocar em sapatos de todo o lugar para que possamos sempre encontrar o par de sapatos que queremos. Então fomos para a câmera gráfica do shopping, tiramos um monte de fotos e posamos para todos no site. Agora, em vez de comprar um inventário adiantado, o que ele fez foi construir o site, então ele fez a suposição de que as pessoas iriam comprar sapatos online. Ele construiu o site e então ele estava apenas medindo quantas pessoas conseguiriam vendas. E em vez de comprar o inventário e construir todo o produto, o que faria é se alguém basicamente fizesse um pedido ele iria olhar para o pedido. Descobrir o que eles deveriam querer? Dirija até a bola local pelo sapato, coloque-a em uma caixa e mande-a para essa pessoa. Assim como este processo muito manual. Não havia manutenção de inventário. Não havia nada, exceto ele ser toda a lógica do negócio. Tornou-se muito, muito, muito popular. Ele percebeu que tinha algo realmente grande em suas mãos. Sua métrica foi confirmada que isso iria ganhar muito dinheiro, e por causa disso, por causa do interesse que ele estava então aberto a investimentos. Ele estava aberto a mudar o seu processo para torná-lo um site real para ganhar dinheiro. E acabou sendo uma das empresas mais bem sucedidas de todas as linhas começando no início dos dois milhares. Então, através deste processo, este processo lean startup, ele foi capaz de investir risco mínimo para ver se uma proposta ou uma ideia de negócio era viável. E é por isso que é muito popular, porque podemos usar essa startup enxuta para fazer exatamente isso é descobrir se nossas idéias pena e eles vão ganhar dinheiro. Então essa é a inicialização magra. Basicamente, não há mais nada com este. A maneira que você constrói é que você usaria outro como um estilo scrum. Ou você poderia usar alguma basicamente apenas codificação e hackear maneira de começar algo e então você apenas medir. E depois que você descobrir que é ah, vá. Então nós temos essa idéia de ir e não ir, quer dizer, continuamos? Adoree, pare! Se for atrás, desenvolvemos o software. Estamos usando um dos outros métodos. Se é um não ir O quê? Nós apenas paramos o produto lá e esperamos vir acima com idéias mais tarde. Mas inicialização magra realmente interessante de aprender.