Gerenciamento de projetos ágil: como criar qualquer coisa digital

1. Introdução: Olá e seja bem-vindo. Aqui está um resumo muito rápido deste curso. Este é um curso que não vai te ensinar como fazer nenhuma codificação. A não vai te ensinar como projetar uma interface de usuário brilhante. Ele não demonstrará a você como anunciar e lançar um aplicativo para se tornar viral em toda a Internet. Agora, em vez disso, este curso fornece uma visão geral completa do ciclo de vida de desenvolvimento de software Agile que você pode aplicar a qualquer produto digital você preveja desenvolver. E isso explica quais membros da equipe e conjuntos de habilidades você precisa apontar com você para ter sucesso. Meu nome é Alex. Estou sediado em Londres, Reino Unido e nos últimos dois anos tenho trabalhado como sênior de elite e gerente sênior de elite e projeto em grandes projetos de transformação digital, normalmente para bancos, consumidores, clientes de varejo e cuidados de saúde. Ao final deste curso, você saberá a diferença entre o desenvolvimento de software Agile e Waterfall. Você entende as principais funções e responsabilidades dos membros da equipe e de uma equipe de desenvolvimento ágil, incluindo a sua própria no formulário como gerente de projeto. E você poderá explicar cada fase do ciclo de vida de desenvolvimento de software ágil, que inclui a fase de ideação , desenvolvendo requisitos, projetando e construindo seu software e mostrando que é testado regularmente e, eventualmente, chegando a lançá-lo no mercado. O curso é muito voltado para iniciantes, colocando que combina interessados em desenvolvimento de software. Você já pode ser um desenvolvedor ou designer júnior querendo mudar para uma posição de gerenciamento de projetos. Ou talvez você seja um inovador com uma ótima ideia para uma ferramenta digital. Mas você não tem certeza por onde começar ou qual conjunto de habilidades é necessário, caso em que este curso é para você. Se isso soa interessante, então vamos começar e entrar direto nisso. 2. Desenvolvimento de cachoeira: Portanto, a abordagem dentro do mundo do desenvolvimento de software, eles tendem a ser duas idéias-chave para as principais abordagens para o desenvolvimento de software. Uma é a aproximação da cachoeira e a outra é a ágil. Waterfall é uma metodologia sequencial onde a tarefa é um pouco mais linear. Enquanto, em contraste, o ágil é uma metodologia muito iterativa, que inclui um processo cíclico e colaborativo. É um debate muito acalorado o que é melhor e o que é melhor. Na minha opinião pessoal, dependerá muito da preferência pelo seu projeto, seu conjunto de habilidades e natureza do projeto. E se você precisa de um processo iterativo ou talvez gravar um sequencial. No entanto, certamente há um viés, eu diria 20 como desenvolvimento ágil no desenvolvimento de software. E, como resultado, vamos nos concentrar nisso hoje. No entanto, vamos mergulhar na cachoeira rapidamente apenas para que você tenha um entendimento também. O modelo em cascata é definitivamente o mais antigo e direto. Basicamente, terminamos uma fase e depois começamos a próxima página. É muito fácil, muito direto. Então, como resultado ou como exemplo neste slide, você pode querer fazer toda a análise do projeto primeiro e depois, e só então você inicia seu desenvolvimento de back-end. Eles são definitivamente alguns benefícios que podem ser, que podem ser discutidos para desenvolvedores e clientes concordaram muito cedo sobre o que realmente será construído. No início, você define a análise, você define o escopo do trabalho. E isso torna o planejamento sem dúvida, um pouco mais direto. De forma semelhante progride facilmente medido. Você tem esse escopo completo de trabalho em mente. E, como resultado, você pode facilmente dizer o quanto já foi construído com isso. Como resultado, o software pode ser projetado completamente e com muito cuidado com base na compreensão completa de todos os produtos de software. Mas, mais uma vez, isso é da teoria. E há definitivamente muitas desvantagens que foram vistas na prática real. Talvez o mais importante, eu diria que é a falta de eficácia dos requisitos. Se você começar, quando você inicia um novo projeto, a realidade é que você não sabe de nada. Você não sabe sobre a complexidade, você não sabe como construir nada ainda. Você não sabe o que o cliente quer, como o mercado vai responder. Então, o que quer que você analise no início, talvez não seja completamente significativo no final depois de lançar o produto. Então, mais uma vez, quaisquer pequenos detalhes que possam ser deixados de fora, detalhes que podem estar completamente errados. Eles então segurarão todo o processo que quer descoberto. E, como resultado, um projeto não só fica atrasado, mas se torna bastante caro. Além disso, uma vez que você lança algo depois de um longo tempo analisando, desenvolvendo e testando, bem pode ser que o produto no final seja completamente indesejável ou talvez desatualizado no momento em que da vida. Portanto, a possibilidade de um cliente estar insatisfeito com o produto de software entregue é definitivamente alta. E mais uma vez, isso se torna caro. 3. Desenvolvimento ágil: Então, quando se trata de ágil, uma rápida lição de história aqui é cerca de 2000, 2001 as pessoas se reuniram, os desenvolvedores de software se reuniram e compartilharam muito a frustração sobre o atual estado das coisas, como o desenvolvimento de software estava sendo abordado. E, mais importante, todos concordam que o planejamento excessivo e a documentação do desenvolvimento de software são ineficientes. E realmente o que importa é agradar seus clientes e isso está sendo perdido. Então, como resultado, eles introduziram e criaram o desenvolvimento ágil de software. desenvolvimento ágil de software tende ou procura dividir todo o trabalho de desenvolvimento em marcos menores. E você cria seu aplicativo, seu produto em uma série de ciclos. Então, mais uma vez, em vez de construir tudo e depois lançar, você só se concentra em um determinado recurso que você inicia e, em seguida, você prossegue cada ciclo como visto neste slide, nós iremos inclua que você estágios semelhantes, como uma cachoeira, você faz algum planejamento, faz os testes de desenvolvimento e revisa. Mas, mais uma vez, crucialmente, você envia e, em seguida, lança para os clientes no início. E, como resultado, cada versão fornece um campo de testes onde rapidamente você deve receber feedback do cliente, do mercado real. E com base nisso, você pode iterar e alterar seu produto para as necessidades reais do cliente e do mercado. Realmente, a principal consideração aqui quando se trata de ágil é que o cliente está no coração da equipe de desenvolvimento e o cliente trabalha muito, muito juntos. Eles colaboram, e é o cliente que os hóspedes veem e usam o produto no início e, como resultado, podem fornecer feedback. E com base nisso, as coisas mudam o tempo todo. Não há nenhum plano linear que esteja sendo seguido. Mas depois de um lançamento rápido, é o cliente quem fornece seus comentários e o plano está sendo adaptado de acordo. Existem alguns princípios-chave que surgiram que criamos como resultado. E isto é, queremos nos concentrar em indivíduos e interações em processos e ferramentas. São as pessoas, os clientes que no centro de tudo, não é processado ou ferramentas ou você pode ter estabelecido uma vez, vamos adaptar as coisas o tempo todo de forma semelhante. É um software funcionando, coisas reais que estão funcionando e sendo usadas. Isso é mais importante do que documentação excessivamente abrangente, planos de projeto e assim por diante. Absolutamente, é importante escrever coisas para compartilhar conhecimento, mas o software de trabalho é a coisa mais importante. Eu meio que já insinuei isso. A colaboração com o cliente é fundamental. A realidade da vida é, olha, o cliente não sabe o que quer. Eles provavelmente não vão acertar na primeira vez e mudarão de ideia. Então, trabalhar duro com os clientes, mas essa é uma espécie de realidade do trabalho. há absolutamente nenhum sentido de ter um contrato em vigor e aderir ao contrato. Quando se verifica que um cliente não está absolutamente interessado foi escrito. O que está escrito nele? Sim. Portanto, tudo está se adaptando ao feedback do cliente para investir o que eles encontram. Em vez de aderir a algo que foi negociado há muitos, muitos anos. E isso realmente me leva ao último ponto. Só estamos, você quer responder à mudança. Você não quer seguir um plano que foi configurado há algum tempo, mas sim, você responde ao que o cliente percebeu. Se você estiver mais interessado, esses princípios dão uma olhada no Manifesto Ágil que foi estabelecido pelos desenvolvedores de software em 2001. É um fundamento fundamental para o desenvolvimento eficaz de software que está sendo usado o tempo todo em todos os grandes projetos. No software. 4. Cerimônias ágeis: Eu realmente quero abordar cerimônias ágeis, o que é uma palavra muito chique para reuniões. Vou apenas abordar 44 cerimônias principais de reuniões-chave que estão sendo usadas dentro, dentro do desenvolvimento de software. E que planejamento de sprint, planejamento de sprint. Há muito mais detalhes por trás disso, mas bastante abstrato, de nível bastante alto, isso significaria que você planeja o que vai construir na próxima semana ou assim. Então, todos os desenvolvedores, analistas, designers e assim por diante, especialmente os clientes e gerentes de produto se reúnem e decidem qual é o próximo recurso, qual é a próxima coisa que nós quer construir? Uma mulher se compromete com isso dentro dessa sessão de planejamento. E o objetivo é construir algo nas próximas duas semanas e morrer. E novamente, seguido pelo lançamento que vimos que vimos agora. A próxima coisa é dirigir o stand-up diário. Você terá que se levantar. Dito isso, acho que a maioria das equipes realmente faz. Mas dentro do nome é diário e é a equipe se unindo. E a ênfase aqui é muito na comunicação, comunicação regular dentro do stand-up diário. E é realmente apenas uma sessão de 15 minutos todas as manhãs, você comunica o que fez ontem, o que está planejando fazer hoje. E, mais importante, se você tem algum problema de risco que você tenha onde precisa de ajuda. E assim todo desenvolvedor, analista, designer, quem estiver na equipe funcional, como parte da reunião. E, como resultado, rapidamente você recebe atualizações de cada membro da equipe e entende onde todos estão e se alguém precisa de ajuda. Quando se trata de comunicação, comunicação visual é importante. Você quer visualizar o que realmente está sendo construído. Você quer receber feedback rapidamente. E, como resultado, você tem uma demonstração de sprint pode acontecer toda semana e acontecer cada duas semanas ou mais. Mas a ideia por trás disso é novamente, você quer compartilhar, então ele foi falhar muitas vezes você quer obter feedback muitas vezes em uma bacia que quer iterar. Portanto, uma demonstração de sprint pode ser qualquer coisa desde algum desenvolvimento que foi feito, até um novo design, até alguns comentários dos clientes que você possa ter recebido. A ideia é que, em todas as várias funcionalidades, várias funções dentro da equipe, você quer ter um compartilhamento transfronteiriço para os membros da equipe o que está acontecendo. Por fim, há uma retrospectiva. Realmente tudo o que diz é que a equipe se reúne após determinados períodos de tempo. Ele tende a ser depois de um sprint que foi concluído. Sprint pode ser qualquer coisa de uma semana, duas semanas, quatro semanas no máximo. Mas a ideia é que a equipe se reúna e discute o que correu bem dentro desse ciclo de trabalho e o que tem que ser melhorado. Mais uma vez, é uma ferramenta para comunicação. Garantir que as pessoas colaborem, certificando-se de que todos estejam felizes, certificando-se de que a equipe trabalhe de forma eficiente. E realmente que qualquer uso de um risco pode ser atenuado em qualquer spreads futuros. 5. Seus membros e habilidades de equipe: Então teorias, notas, metodologia são incríveis. Nenhum deles importa. Se você não tem algo para colocar em prática. Para colocar algo em prática, você precisa de pessoas reais, você precisa de uma equipe. Então, nesta seção, forneceremos uma visão geral rápida de como é uma equipe ágil típica. Claro, não se engane como sempre. Depende do tamanho dos gastos, complexidade e da maturidade do seu projeto. Mas a ideia é ter uma ideia do tipo de membros típicos da equipe. Então, muito famoso mesmo software é fácil, as pessoas são gostosas e eu ficarei bem. Pessoalmente, acho que isso é verdade. Então invista em sua equipe. Vamos dar uma olhada. Em primeiro lugar, no mundo ágil, esse é o Scrum Master de uma palavra extravagante. Se você quiser, você pode perdoá-lo a dizer o gerente de projeto, gerente de programa. Há nuances nisso, mas por uma questão de visão geral de alto nível, acho que podemos dizer que talvez o caso de um scrum master seja responsável por repetir uma cola entre todos, entre todos os partes interessadas, pessoas, desenvolvedores, analistas, designers recusam o cliente e assim por diante. Foi então que gerenciou o processo de planejamento. Eles conduzem várias versões, facilitam o planejamento de versões. Eles são responsáveis pelo agendamento de todas as cerimônias ágeis que mencionamos. Eles fornecem acesso a ferramentas e pessoas. E, como exemplo, qualquer coisa que sai de uma reunião diária de standup, verdade, as ações que eles são responsáveis pelas suas até encontrarem o dono certo. Scrum master também é relatado sobre o status do projeto para todas as direções para baixo e para cima. Eles chamam isso de suporte à liberação de coordenadas. Eles são responsáveis por avaliações de risco. Então olhe, como você pode ver, é um trabalho muito diversificado, conjunto diversificado de responsabilidades que é difícil de definir. Mas, na verdade, eles querem ajudar a proteger a equipe e desbloquear quaisquer problemas e garantir que os processos ágeis sejam seguidos para serem eficientes e efetivos em seu desenvolvimento. Cada produto com um proprietário de produto, alguém que é responsável pela visão para a visão de curto prazo e de longo prazo. E, portanto, o proprietário do produto normalmente é o CEO do produto realmente. Eles são responsáveis pelo mercado e pelo business case por qualquer tipo de análise competitiva. Eles tendem a ser especialistas do setor, conhecendo a indústria e os clientes de dentro para fora. Eles têm uma ideia do retorno sobre o investimento e o lucro líquido. Eles estão representando seus clientes. Muitas vezes, mais do que não, é o proprietário que vem com os requisitos. Alguém que prioriza o trabalho e, portanto, representa o que o cliente, pelo menos o que ele acha que o cliente quer. Então, uma pessoa crucial e crucial dentro da equipe. Os analistas de negócios geralmente se sentam muito perto do proprietário do produto. Porque, como eu mencionei, os requisitos são frequentemente determinados pela parte do corpo sobre isso. Mas, na verdade, é atual no nome que o analista de negócios é responsável por qualquer solução analítica. Eles aumentam o valor comercial colaborando com o proprietário do produto. Eles criam um backlog de produtos, o que, novamente, é uma palavra extravagante de dizer um conjunto de requisitos. Eles podem desenvolver um caso de negócios trabalhando em estreita colaboração com a parte Maja. E então, o mais importante, eles anotam os requisitos. Então eles, eles, eles não param no alto nível, mas eles realmente entram nos detalhes, anotam todos e os transmitem para o resto das equipes. Muitas vezes, na maioria das vezes, os requisitos sempre devem ser feitos em equipe. Mas é o negócio dessa responsabilidade realmente elaborá-los em transmitido ao fazer, por exemplo, um plano de sprint. Por fim, eles podem apoiar as práticas ágeis. Eles incentivaram a melhoria dos serviços e, claro eles se tornam especialistas dentro de certas funções. O UX e o designer de UI, há uma importante diferenciação entre UX e UI. Ux designer, por exemplo, pode estar conduzindo pesquisas com usuários. Eles estão criando persona do usuário, que é uma representação dessa pesquisa do usuário. Eles podem determinar a arquitetura de informações de um produto digital. Eles podem estar esboçando fluxos de usuários, ou podem estar esboçando o que um aplicativo, o que um design, design poderia olhar, amar. E então, com base nisso, eles criam protótipos que estão sendo testados. Enquanto, em contraste, mas nem sempre exclusivamente, um designer de UI coloca isso em um design de interface de usuário real. Eu, design de alta fidelidade parece bom e parece o produto final que está sendo desenvolvido pela equipe de desenvolvimento. Portanto, no geral, responsável pelo mapeamento de jornada, os fluxos de ponta a ponta estão sendo definidos e projetos são responsáveis por estar juntos com os clientes. Tente entender o que eles procuram. E fazer muitos testes e seguida, traduzir isso em um design real. Um desenvolvedor, novamente, em um nome, desenvolve certos recursos, mas acho importante que existem responsabilidades adicionais. Isso geralmente está sendo negligenciado. Os desenvolvedores são cruciais para estimar o tamanho de quaisquer novos requisitos em qualquer avaliação da viabilidade técnica. Eles ajudaram a entender o que pode ser feito, em que período, quão complexo e pode ser, o que pode ser necessário e assim por diante. Então, eles se ovalizam junto com uma equipe, ajudam a implementar os itens de backlog. Eles garantem que teste está sendo feito para tudo que as matrizes que estão sendo feitas estão sendo projetadas e definidas. Além do desenvolvimento real, eles também garantem o controle de qualidade. Não está apenas sendo desenvolvido, mas também está sendo testado minuciosamente antes, antes de entrar no estágio de envio para o mercado. E eu mencionei testes, mencionei antes que eles estejam testando muitas vezes, também são negligenciados. É absolutamente crucial que você teste seu aplicativo, que você teste seus novos futuros antes que ele seja enviado para o mercado. E assim, a qualidade dos testadores de controle de qualidade garante a garantia. Eles são responsáveis por escrever planos de teste, o que impôs a aceitação geral de novos recursos. Eles fizeram isso tão mentalmente. E eles também automatizam essa abordagem geral. Desenvolvedores e testadores trabalham muito juntos e integram a base de código continuamente com essas compilações manuais e automatizadas que testes funcionais e testes de regressão e assim por diante. E entraremos nos detalhes dos testes mais tarde só porque acho que é tão importante. Mas, mais uma vez, testes à medida que medem a qualidade que eles encontram em primeiro lugar para melhorar a qualidade. E eles impuseram um problema de qualidade como e as melhores práticas com isso estão sendo realizadas o tempo todo. Agora, não se engane. Esses são apenas alguns exemplos. As equipes são pequenas e grandes, dependendo da maturidade, complexidade e tamanho do seu projeto, você precisará de arquitetos de soluções para definir o cenário geral da tecnologia. Você precisa ter determinados ambientes disponíveis onde você pode testar, escrever, codificar e, eventualmente, implantado. Você quer ter certeza de que os lançamentos estão sendo feitos de forma automatizada. Você provavelmente quer alguém que gerencia seus dados. Você precisa de uma equipe de operações, use pesquisadores, redatores. Você quer ter certeza de que o produto de ponta a ponta é seguro. E novamente, quando se trata de, você pode precisar de alguns advogados são alguns conselhos de conformidade e assim por diante. Então, ele realmente não pára por aí. Mas o importante é que a equipe multifuncional típica, talvez composta por esses membros da equipe ágil que foram mencionados. Esquecemos o mais importante e temos enfatizado algumas vezes e, portanto, deveríamos mais uma vez. É seu cliente. Você deve estar o mais próximo possível de seu cliente quanto puder. Você projeta para seu cliente, não para si mesmo. E esse é o erro número um. Vemos o tempo todo. Achamos que sabemos o que o cliente quer, mas na verdade só construímos para nossas próprias necessidades e pensamentos. Sim, claro, existem outras pessoas como eu e, portanto, deve ser a coisa certa que estamos construindo. Confie em mim, você não sabe e estará errado ou no prédio. Portanto, faça com que seu cliente conduza a pesquisa do cliente o tempo todo testes com os clientes e da forma ágil que discutimos, o lançamento geralmente faça isso cedo, faça isso o tempo todo e aprenda com os erros. Aprenda com o feedback que um cliente fornece a você. 6. A fase de ideação: Certo, falamos sobre o ciclo de vida do ciclo de vida do desenvolvimento de software o tempo todo. E é muito simples, pois pode ser visualizado assim. Você tem uma ideia. Você quer se envolver em uma fase de descoberta em que você expõe a ideia um pouco mais uso de requisitos definidos e você se acumula. Então, primeiro conjunto de designs. Em seguida, você o constrói, você o testa e, em seguida, você inicia. Mais uma vez, nós dentro do mundo ágil aqui. Portanto, não confunda isso com a metodologia em cascata, mas sim você está olhando para um certo futuro que está construindo. Sim. E então você fornece um lançamento e você faz isso de novo e de novo e de novo e de novo. Nós dissemos antes, todo bem começa com uma ideia. As chances de você ter um ou você pode ter absolutamente nenhum, ambos como perfeitamente bem. Em ideia. Raramente acontece quando você se senta, você tem que trabalhar para isso. E se você não tem ideia suficiente, então tudo bem. O melhor lugar para começar é realmente se treinar todos os dias e pensar, você sabe, qual é o problema e o que é uma solução potencial na minha vida cotidiana? Você realmente quer se perguntar o tempo todo, por que fazemos as coisas de uma certa maneira? Existe uma maneira melhor de resolver um problema? E se você puder identificar um problema ou uma espécie de ineficiência do mercado, se quiser. Você já está na metade do caminho. Agora. Há muitas maneiras de criar ideias legais e certamente iria muito além do escopo deste curso para explorá-las todas, vou colocar algo na descrição, se puder. Mas, mas o que eu gosto e sempre uso é a criação e o uso da jornada do cliente. A jornada do cliente realmente não passa de um processo que meio que analisa o que o usuário passa. Digamos que, por exemplo, um usuário possa estar olhando o seu site de comércio eletrônico que você está construindo. No início, há um dia de estágio de descoberta. Eles precisam descobrir o fato de que seu site existe, quer possuir ou eles podem navegar, eles passam pelo que pode ser comprado em seu site. Eles pensam nisso. Eles fazem uma avaliação de like, vale meu tempo e meu dinheiro para fazer essa compra? E então, eventualmente, eles fazem sua compra onde potencialmente estão bastante ansiosos com isso até verem sua auto-confirmação final que o pagamento foi concluído. E essa é a experiência de ponta a ponta. Você quer procurar cada um desses estágios no site de ação que o usuário passa. Então, por exemplo, no estágio de descoberta, você está em uma espécie de estágio de consciência. Você está tentando descobrir sobre o serviço que está prestando. A ação pode ser que você abra o aplicativo, o site que você pode ver tutorial, e o tipo de emoção do usuário neste momento é que eles são curiosos e depois o bebê, mas cético em termos de o que você está tentando vendê-los. Mas eles são curiosos. Enquanto um inconsciente na fase de compra mais tarde, eles agora estão convencidos sobre seu produto e você está vendendo dia. Eles têm o desejo de tê-lo. E a ação é fazer o pagamento e depois fazer o checkout. Mas a emoção aqui é muito mais do que eles estão estressados e eles estão procurando afirmação de que eles absolutamente indefinidamente deveriam estar fazendo os pagamentos de pontos de compra e espero que sejam então posteriormente, feliz por ter feito isso. E o ponto que estou tentando fazer aqui é dentro da jornada do cliente em si, essa é uma habilidade de entender o que o usuário está sentindo, o que eles são e, crucialmente, o que você pode melhorar dentro de uma jornada existente. Ou, mais importante, o que você pode criar uma nova jornada e um novo produto ou novo projeto é algo que pode encantar o cliente, algo que os deixa felizes ao entender o que os vários processos, quais são as várias etapas, ao entender o que o cliente passa , é sua capacidade, sua oportunidade de melhorar e tornar esse processo muito suave. 7. A fase de descoberta (tecnologia): Agora, com uma ideia em mente para o seu projeto, você quer se certificar de entrar um estágio de descoberta antes de realmente construir qualquer coisa. A ideia por trás do estágio de descoberta é reforçar suas necessidades, brincar com o primeiro conjunto de designs para visualizar como um produto poderia ser. Você provavelmente não está surpreso quando eu digo que você pode até virar, provavelmente deve até testar com clientes que já estão nesta fase. E também para determinar como o aplicativo realmente será construído, quais tecnologias serão usadas? Então, com isso em mente, começaremos com a visão geral da solução. Neste ponto, é o arquiteto de soluções do líder tecnológico e os vários desenvolvedores se unindo. E eles querem transmitir e determinar a visão geral da solução. Está fornecendo uma visão geral de como cada componente será construído e mastigando Isso será bem construído. Portanto, uma visão geral da solução é um esqueleto de um programa, de uma característica de um projeto por falta de um elemento importante nessa arquitetura de projeto, você pode colocar em risco o sucesso de todo o seu projeto. Não podemos enfatizar isso o suficiente. A arquitetura adequada permitirá economizar muito tempo, energia e custos no futuro. Você quer ter certeza de que você acerta isso. Agora, qualquer, qualquer design de arquitetura geralmente é composto por várias camadas dentro do aplicativo, como a camada de apresentação no topo. Isso é o que o usuário tende a ver que, como a interface do usuário carrega componentes, o design de interação, isso é o que o usuário realmente tende a visualizar ao usar seu produto. Abaixo está uma camada de negócios que envolve ou inclui toda a lógica de negócios ou os processos, todos os fluxos. E, por último, abaixo disso está a camada de dados, que por sua vez inclui toda a sua lógica de dados antiga, o próprio banco de dados e assim por diante. Isso, por sua vez, está sendo embrulhado. Você quer ter certeza de que você tem segurança em vigor, qualquer tipo de configuração. Não vamos entrar em todos os detalhes aqui é obviamente um trabalho muito complexo, e isso está sendo feito geralmente por um arquiteto de soluções, pelo líder tecnológico e pelos vários desenvolvedores da sua equipe que juntos transmitir e imaginar como seu produto está sendo construído a partir de um ponto de vista da camada tecnológica. Como sempre duvidam de inúmeras abordagens e tecnologias em suas linguagens de programação que podem ser usadas para, para construir um design técnico de alto nível ou em uma pilha de tecnologia curta. E, como sempre, todos eles têm pontos fortes e deficiências. Alguns são mais baratos de usar, mas talvez menos desempenho. Outros podem levar muito mais tempo para serem implementados. Pode ser até exagero ou ser um melhor desempenho. Como resultado. A pior possibilidade é construir em uma pilha de tecnologia moribunda ou não confiável. Então, queremos ter certeza de que você não faça isso. Se você cometer esse erro, talvez seja necessário reconstruir o aplicativo inteiro novamente. Ou você paga um prêmio para desenvolvedores avançando. E novamente, sem entrar em muitos detalhes, há tão poucos princípios fundamentais que quero destacar quando se trata da pilha. E isto é, você quer construir com base nos seguintes princípios. Tem que ser eficiente. Sim, então seu aplicativo precisa executar as tarefas e executar as funções em qualquer condição. Portanto, ele tem que ser confiável com qualquer tipo de carga, qualquer tipo de quantidade de usuários que estão no seu, em sua plataforma. Deve ser flexível. A solução escolhida tem que ser fácil de mudar. Você pode alterar elementos e isso não deve influenciar que o todo, todo o projeto automaticamente, de forma negativa. Você deve ser capaz de estendê-lo. Então, você quer ser capaz de adicionar quantas funções quiser aplicativo 2D. importante ressaltar que ele deve ser escalável. Deve ser sempre possível estender. A arquitetura, deve permitir desenvolvimento direto e vários segmentos paralelos. E, por último, testabilidade. Você deve ser capaz de testar a arquitetura facilmente, que significa que o número de erros diminui e sua confiabilidade aumenta. Mais uma vez, esse é o trabalho do arquiteto de soluções. 8. A fase de descoberta (Design e roteiro: Indo, entrando em uma esfera completamente diferente em termos de trabalho. Design UX previamente mencionado. E, novamente, isso é da visualização de como poderia ser o produto. Sim, então aqui na fase de descoberta, começamos criando designs e telas, e começamos a atribuir cada função e dados. Tudo bem que eles moram em vários lugares. Você não tem ideia de onde ele se senta no momento atual, você apenas brincando. E, na maioria das vezes, esse processo ocorre em quadros brancos, em papel ou, como você pode ver atualmente na tela, algum tipo de ferramenta de rabisco onde você pode se certificar de que pode jogar muito rapidamente e mude as coisas rapidamente sem levar muito tempo. A ideia aqui é que você quer fazer alterações, você quer fazer isso agora, em vez de mais tarde no processo. Atualmente, é muito mais barato apagar algo. Então, mais tarde, na biblioteca, você tem que reescrever o casaco inteiro. Certo. Fluxos de trabalho são os caminhos, os usos podem viajar dentro do seu aplicativo. Sim, Então, novamente, dentro disso, você quer considerar cada uma das coisas que o usuário deve estar fazendo em uma determinada tela, quantos cliques são necessários para concluir uma ação. Você quer ter certeza de que cada clique é um aditivo de dois que realmente não leva muito tempo ou trabalhe para realizar alguma coisa. À medida que você encontrar problemas com seu fluxo de trabalho, atualize esses wireframes. Então, o que vemos e esses rabiscos são chamados de wireframes lá em cima, depois comece novamente testes com um cliente, garante que ele funcione antes de você entrar em alguns projetos mais complexos. O que você tende a fazer aqui também é usar protótipos. Então, o modelo de cliques é onde você coloca todos esses wireframes juntos e tem a capacidade clicar neles como se fosse um aplicativo real, mas sem ter feito nenhum desenvolvimento real. Mais uma vez, se uma maneira fantástica testar algo no telefone muito rapidamente para testes mais realistas e obter feedback imediatamente a partir daí. Esta é uma maneira fantástica de entender quais são suas necessidades. É nisso que entra um analista de negócios. Então, digamos, por exemplo, que uma UX está em perigo determinou um tipo de design UX no lado esquerdo. Como você pode ver, temos um menu onde quer que barra de pesquisa tenhamos algum tipo de filtro no topo, você tem várias coisas diferentes. Então, clique em oficinas ou marketplace ou o que quer possa estar nesse aplicativo específico. E assim foi facilmente transmitir atualmente visualmente precisa ser colocado em mais detalhes em 3D, que se torna o backlog de requisitos. Assim, os analistas de negócios trabalharão conjunto com o proprietário do produto, com designers, com os desenvolvedores para garantir a visão e que os projetos estão sendo colocados em requisitos reais. E eles estão sendo definidos com detalhes mais antigos que são necessários para que o desenvolvedor realmente construa. Por fim, e novamente, um aspecto completamente diferente do trabalho é o roteiro do produto. É nisso que entra um proprietário do produto, o CEO do produto. E dentro da fase de descoberta, você quer ter uma ideia. Não precisa ser muito preciso, mas você quer ter uma ideia dos temas de alta prioridade que ajudarão todos a realmente focar seu tempo e energia para fazer algumas coisas. Va eles bem, produto ágil, roteiro é a ideia por trás disso como uma ferramenta de navegação. Sim, ajuda as equipes a se concentrarem em onde estão, onde estão indo, mas também lhes dá a liberdade de corrigir o curso conforme necessário. Por exemplo, se formos fundamentais no momento, entendemos o que estamos construindo nos próximos meses. Mas ainda é a liberdade de mudar e adaptar o que pode ser construído no segundo trimestre, quarto trimestre. Então, realmente um roteiro de produto ágil é uma visualização de estratégia de alto nível, e está focado em resultados, em vez de saídas e conversas, e temas e épocas em vez de recursos. Portanto, nada é definido nesse ponto. Então, visualização e indicação do que está por vir. E isso ajuda a comunicar a estratégia do produto com as outras partes da organização e com um cliente. E garanta que você receba buy-in de sua equipe e das principais partes interessadas. No geral, essa foi uma visão rápida de várias coisas que você pode estar fazendo na fase de descoberta. Como sempre, há muito mais. Isso depende do projeto. Mas veja, garantir que você tenha uma base tecnológica sólida e uma visão geral da solução é absolutamente crucial. Você quer ter uma espécie de opção para visualizar como o produto final poderia ser e testá-lo com os clientes. No início. Você quer ter uma ideia dos requisitos que estão sendo construídos no primeiro conjunto de semanas estão sendo feitas pelo analista de negócios. E você quer garantir que o CEO do produto, esse proprietário do produto seja capaz de transmitir a visão e para onde vamos, não apenas nas próximas semanas imediatas, mas realmente com uma visão de longo prazo diz e como é o produto final para se parecer. Se isso for feito além qualquer outra coisa que você possa ter que fazer, entraremos na fase Bill. 9. A fase de desenvolvimento: Ok, construiu provavelmente um dos períodos mais interessantes e intensos dentro do projeto, indiscutivelmente a fase de ideação e descoberta, bem como a fase de lançamento no final, leva significativamente menor tempo do que a fase de construção, pode muito bem ser 70%, 80% do projeto de ponta a ponta que você lidará com a fase Bill e, como resultado, em incrivelmente importante, mas também onde a maioria das coisas dá errado. E então eu preciso ser melhorado. É um processo longo e não quer ser negligenciado. Vamos dar uma olhada rápida no dia a dia de trabalho para a equipe, que está dentro do mundo ágil, você estará seguindo. Esse fluxo de trabalho aqui é de alto nível novamente, seja, você tem o backlog de requisitos que você reuniu anteriormente. E assim, todos os dias realmente, você escolherá qual item você vai enfrentar. Você vai colocar isso no OpenFlow. E, ao longo do tempo, isso deve ser selecionado para estar em andamento, estou sendo desenvolvido. Ele entra na garantia de qualidade da coluna de controle de qualidade onde está sendo testado. Uma base nisso. Se for passivo for feito e se não tiver passado, ele volta para o em andamento. maioria das vezes, isso realmente acontece fisicamente em uma parede, em um quadro branco, ou similares, é claro, pode ser feito digitalmente também. Mas muitas vezes, são apenas um monte de cartazes que estão sendo entregues de coluna em coluna. E é uma ótima maneira de as equipes visualizarem o trabalho que está sendo feito. E bancos de dados, especialmente fazendo um stand up para visualizar e transmitir a todos o que está sendo trabalhado ativamente. E muito rapidamente você poderá ver se há algum impedimento, se há algum bloqueador. Por que um determinado bilhete, por que certos requisitos não estão avançando? Então esse é o fluxo de trabalho geral de ponta a ponta. Você toma um requisito e trabalha no seu caminho através das várias etapas do fluxo de trabalho. E ponto de vista de análise de negócios ruim. Agora é o objetivo escrever as histórias de usuários, os requisitos que eles são, eles são chamados de histórias de usuários. E, como exemplo, se você pegar, por exemplo, o menu, seja esse agora certo recurso, certos requisitos. Você tende a escrevê-lo no seguinte formato, que é o, você define para quem ele é. Portanto, nesse caso, é um usuário que já bloqueou seu aplicativo como um usuário autenticado e, em seguida, define o objetivo para esse usuário específico. Então, neste caso, quero acessar o menu lateral que é o desejado como objetivo. E então você diz, bem, por quê? Então o que, o que é, e daí? E assim você define isso como um para que, neste caso, eu possa visualizar qualquer tipo de recursos adicionais que possam estar disponíveis dentro do produto. Então, mais uma vez, a Diocese do negócio fora desse trabalho. Isso entra em muito mais detalhes, mas em alto nível está listado como uma história de usuário. Onde você encontra quem é o usuário? O que eles querem fazer, qual é a ação e por quê? Qual é o objetivo? Então, como usuário autenticado, quero acessar um menu lateral para que eu possa visualizar quaisquer recursos adicionais que retocam uma tarefa de nível muito alto para o analista de negócios. De forma semelhante, um designer de UX que já abordamos antes definiu vários fluxos de trabalho. Berries, telas UX, telas experientes nos EUA que podem olhar para cima, parecem assim. Neste ponto, você pode rabiscar e certamente nada que você queira enviar e lançar no mercado real. Então, agora é neste momento o tipo de tarefas para os designers colocarem isso em algo um pouco mais brilhante, em uma interface de usuário real. E por isso pode, por exemplo, se tornar algo assim. Sim, você vai de uma interface UX e isso é então interpretado pelos designers a partir da interface do usuário final ou os desenvolvedores vão realmente pegar e desenvolver Naturally. Então também temos que construir, absolutamente não vamos entrar nisso neste curso em particular. Muitas e várias maneiras de construir código, passando por diferentes idiomas e assim por diante. Haverá um curso totalmente diferente, totalmente diferente. Então, vamos ter que pular isso. Mas, mais uma vez, tenha em mente que estamos seguindo a metodologia Ágil em nosso exemplo específico. Sim, então vamos passar pelo fluxo de trabalho de análise, cobrando tudo por um determinado recurso e eles o lançarão muito rapidamente para que recebamos feedback do cliente imediatamente. Antes de fazermos isso, há um aspecto que eu quero enfatizar e isso é testar. Portanto, não vamos abordar o desenvolvimento hoje, mas acho que o teste é algo que queremos dar uma olhada rapidamente antes que qualquer futuro seja lançado. Ele deve fazer um teste completo de alimentos, e deve fazer isso o tempo todo, idealmente, deve ser feito automaticamente. Então, vamos dar uma olhada nisso. 10. A fase de teste (#1): Então, testando, agora mencionei muitas vezes o quão crucial e extremamente importante encontro testes e estou dentro de qualquer parte do ciclo de vida de desenvolvimento de software. Felizmente, hoje em dia, a tecnologia nos permite uma vida muito mais fácil dos testes da cápsula e muitos deles podem ser automatizados, enquanto alguns aspectos, é claro, ainda precisam ser feitos manualmente pelo desenvolvedores, todos os testículos, equipes de garantia de qualidade ou mesmo negócios fora disso, quem quer que talvez gerentes de parque e assim por diante. se estamos analisando o aplicativo, No entanto, se estamos analisando o aplicativo, o teste é crucial, então vamos dar uma olhada nos vários tipos de testes normalmente estão sendo feitos. Um deles é o teste unitário, geralmente em uma ação degenerada feita pelos desenvolvedores. Eles usam testes manuais ou automatizados e garantem que cada unidade em seu software atenda aos requisitos do cliente. Então, mais uma vez, você pode testar esses casos de teste, principalmente o que, é claro, é demorado. Demora muito tempo, é repetitivo e, portanto, exige um pouco de esforço. Uma boa notícia é, no entanto, ferramentas automatizadas de automação de testes nos dias de hoje, elas podem permitir que você grave e salve um teste e, portanto, você pode repeti-lo quantas vezes for necessário sem mais intervenção humana. Portanto, sempre que nova frieza sendo desenvolvida e implantada antes da implantação, um desenvolvedor deve escrever seu teste de unidade e executar os testes unitários, garantindo que essa nova peça específica do o código foi completamente testado com base no requisito. Em seguida, testes de integração, absolutamente cruciais. Pense nisso como modelos individuais estão sendo testados pela primeira vez isoladamente como parte de testes unitários. Mas depois que isso for concluído lá, então integrado. Então, se você estava pensando, pense nisso como um prédio, um carro, você pode estar testando as portas, você talvez, você sabe, testando o motor, aquele porta-malas, seja qual for a cor, seja qual for. Mas, em seguida, um a um, integrando lentamente isso também como um único sistema. E, portanto, o teste de integração garante que qualquer tipo de novo código altere qualquer coisa que você adicionar ao sistema geral, não afeta a funcionalidade existente do software. Você quer garantir verificar se o comportamento combinacional faz sentido. Você deseja validar se os requisitos são implementados corretamente ou não. Muitas vezes, isso é seguido por testes do sistema, o que significa que queremos testar todo um sistema. Todos os modelos, todos os componentes são integrados para verificar se o sistema funciona como esperado ou não. Mais uma vez, se você pensar no exemplo do carro, é ótimo que você tenha verificado completamente se cada item individual foi testado por unidade. Você não verificou se todos eles estão integrados e integrados testados ao montar o carro. Mas, por último, não se esqueça que todo o carro em si ainda precisa ser verificado para todos os vários aspectos diferentes, requisitos e precisa ser conduzido sem problemas, tem que ter as quebras e engrenagens corretas e precisa trabalhar por milhares e milhares de milhas continuamente. A cor precisa fazer sentido. Portanto, o sistema como um todo também foi uma parte crucial a ser testada e isso está sendo feito após os testes de integração como parte do teste do sistema. Posso ter mencionado o cliente de tempos em tempos neste curso, e nenhuma surpresa aqui, então teste de aceitação do usuário é comumente referido como em resumo UAT. E recompensa isso significa que é, você sabe, mostrar o produto ou o recurso a um cliente e ele faz o teste adiante. Então, pessoas reais, clientes reais determinaram se acham que o software que você criou pode ser aceito , pode entrar ao vivo. Portanto, isso não é tão automatizado quanto os exemplos anteriores. Em vez disso, essas são sessões intensivas de tempo, mas esperamos que sessões irregulares, onde pessoas reais, usuários reais se reúnem como parte de pequenos grupos. Isso pode ser uma família na França, eu posso ser os primeiros adotantes, que podem ser usuários avançados, que podem ser pessoas pelas quais você paga dinheiro. E realmente você quer ter várias maneiras de testar que você quer às vezes apenas mostrar o software e perguntar o que eles pensam. E, por outro lado, você pode querer ser muito específico e escrever casos de teste e fornecer amostras muito específicas a serem exploradas por esses usuários específicos. E então eles têm muitas oportunidades de fornecer feedback a você. 11. A fase de teste (#2): Realmente isso lhe dá a oportunidade de ter um feedback muito aberto pessoas que usarão seu aplicativo no final, no mundo real. O desempenho é, naturalmente, um aspecto crucial. Imaginando que você construa um site, mas ele não carrega pessoas que tendem a clicar fora após o 2.5º de não verem seus resultados. Portanto, é incrivelmente importante testar tanto para os testes baixos, fazer tempos normais de uso e horários de pico, mas também para testar o estresse da sua aplicação, ou seja, você tenta encontrar maneiras de quebrar o sistema. Mais e mais usuários você está sendo assimilado? E você quer verificar, faz a escala do sistema. Há muito retorno à estrutura de aplicativos e arquitetura Oval que discutimos anteriormente. Você quer ter certeza de que uma tecnologia que você precisa projetar e imaginar, na verdade, esse trabalho é capaz de lidar com todos os usuários estão acessando sua plataforma. acessibilidade geralmente é chamada diretrizes de acessibilidade de conteúdo da web para navegar. É um conjunto de recomendações reconhecido internacionalmente para melhorar a acessibilidade da web. Esse é um exemplo específico para, para web design. Mas, na verdade, ele se aplica a qualquer coisa que realmente seja o seu aplicativo ou o que quer que você esteja construindo em um mundo digital, você quer garantir que todos possam e possam usar seu produto final. E então o que eu era composto é ter certeza de que a visão é muito clara. Ou seja, talvez, você sabe, usuários com deficiência visual severa. Eles precisam ser capazes de usar seu aplicativo. Pode haver pessoas com dificuldade auditiva e talvez surdas. E eles precisam ter algumas ferramentas específicas para acessar a mobilidade do aplicativo. Aqueles que podem achar difícil usar um mouse ou teclado, você deseja fornecer alternativas a eles. E então pensando, pensando em entender pessoas que têm dislexia, autismo, qualquer tipo de dificuldade de aprendizagem. Novamente, você deseja fornecer uma abordagem simplificada para que eles usem o aplicativo. Como resultado, mesmo que seja legal ou não, você quer pensar absolutamente sobre a acessibilidade desde o início. Se você quiser redesenhar nossa necessidade de redesenhar em retrospecto, confie em mim, isso vai levar tempo. Vai ser preciso uma quantidade insana de esforço e custo para isso. Então pense nisso como um requisito chave absoluto desde o início, execute todos os seus testes de acessibilidade desde o início do autodesenvolvimento. E você estará fora para um material voador. De forma semelhante. compatibilidade garante que seu software seja capaz de ser executado em diferentes navegadores e sistemas operacionais. Hoje em dia, temos milhares de tamanhos de dispositivos para lidar. Todos eles parecem diferentes em telas diferentes. Pense nisso, no iOS, mas particularmente no Android e tem muitos tamanhos de dispositivos e sistemas operacionais diferenciados. Então, você sabe, constantemente, você quer garantir que o novo software que você em qualquer novo futuro que você está lançando seja compatível com esses requisitos que podem ser feitos manualmente, mas cada vez mais, a maior parte está sendo feita automatizada de forma automatizada por meio de emuladores e simuladores onde você nem precisa mais de nenhum dispositivo. Tudo é feito na nuvem. E você pode garantir que você sabia código é executado em todas essas plataformas. E, por último, cada vez mais crucialmente, acho que para todos e, especialmente, porque recebeu um pouco de escrutínio da mídia é, claro, a segurança do aplicativo. Você precisa garantir que você realize testes regulares de caneta. Você está testando a segurança? Veja, se você tiver uma loja de comércio eletrônico, por exemplo, e puder assistir a compras on-line, você estará regredindo informações da pessoa, informações cartão de crédito e assim por diante. O usuário precisa confiar em você. E se eles não tiverem, então você não tem clientes. E B, você pode ter um grande problema com as autoridades. Mas você verá que não há segurança significa que qualquer tipo de acesso autorizado seja concedido para proteger os dados. E o acesso não autorizado é restrito. E você quer garantir que você não tenha vulnerabilidades em nenhum tipo de código e código personalizado ou qualquer código de terceiros. Tenha em mente que se seus usuários de fornecedor diferente, você aparecer com um terceiro, você absolutamente quer ter certeza de que eles também são capazes de resistir a qualquer ataque. Mais uma vez, isso é apenas uma visão geral de alto nível dos testes típicos que estão sendo feitos. Há, como sempre, mais. É suave, dependendo da pendência do seu, sua complexidade e do tamanho do seu projeto em termos de quanto você faz do qual. Mas é crucial que o teste seja uma espécie de aspecto fundamental e monetário do seu aplicativo de software. Essa abordagem. 12. A fase de lançamento: E estamos quase lá. A hora do almoço, provavelmente a mais intensa, talvez a parte mais emocionante de todo o ciclo de vida que vimos até agora. Você provavelmente tem pensado sobre sua ideia há anos, se não mais. E agora, nos últimos meses, você vem construindo seu código, seus desenvolvimentos, você projeta e agora está pronto para lançar o primeiro conjunto de recursos para o mercado. Quando se trata do lançamento, é sempre uma boa ideia começar as coisas com amigos e familiares. Você tem um pouco mais de uma espécie de público amigável. E você pode testar e receber feedback. Logo no início. Novamente, estou me repetindo, mas não subestime a importância de um tipo de feedback inicial amigável do cliente, onde você pode iterar e melhorar rapidamente seu produto. Além disso, lembre-se quando você iniciar algo para, por exemplo, uma App Store, é sempre um processo que você deseja garantir que o APSA esteja configurado corretamente para sua versão. Você tem que preencher alguns formulários para cada loja que você vai enviar mostra um pouco de material de marketing, uma descrição e tanto. Então, um pouco de trabalho foi feito lá também. E, em seguida, seja Google ou Apple, eles podem Mallory revisar todos esses aplicativos enviados para a App Store. Bem, a Apple, na verdade, há muito mais do que o Google. Mas é possível que eles não pressionem várias alterações com base na sua configuração. Portanto, tenha isso em mente quando se trata de sua linha do tempo. Uma vez que você esteja ao vivo e os produtos no mercado real, há, é claro, algumas maneiras de promovê-lo além de seus amigos e familiares e tipo de boca a boca. O óbvio hoje em dia são as mídias sociais. Seja esse Twitter, tiktok, e outras coisas. Redes profissionais como o LinkedIn. Esse é um dado da avenida que um é mais para os blogueiros e vloggers, progridem através do marketing de afiliados. E, claro, se você tiver o dinheiro, poderá participar um anúncio de campanha mais extenso. Faça isso lentamente no início e, obviamente, de forma mais agressiva quanto ao planejar um lançamento completo. Mas, mas uma coisa que eu quero enfatizar é que este não é o fim, certo? Portanto, o desenvolvimento de aplicativos não pára na fase de lançamento. Em vez disso, é um ciclo contínuo de iteração, como agora enfatizamos muitas vezes no mundo do desenvolvimento ágil. E então você quer ter certeza monitorar o aplicativo e a absorção pelos usuários. Você quer ter certeza de que você é capaz acessar quaisquer falhas que possam ter sido experimentadas. Existem bibliotecas que as rastreiam. E eles dizem o que o usuário estava fazendo, o dispositivo que estamos usando, qualquer tipo de informação técnica que possa ser importante para replicar o problema. Você definitivamente quer começar a entender melhor seus usuários. Você quer fazer uso de ferramentas analíticas , como Google ou Facebook analytics. E isso, novamente, ajuda você a entender quem está usando o aplicativo. Qual é a idade deles, o gênero, de onde eles são, quais idiomas eles falam e assim por diante. Quantas vezes eles usam o aplicativo quando estamos fazendo o dia? Quanto tempo está sendo gasto no aplicativo, quais telas estão sendo visualizadas, predominantemente, quais não são, e assim por diante. Sou oportunidades fantásticas e incríveis por aí. A criação de mapas de calor onde você pode ver onde as pessoas clicam, em quais telas. Vou clicar nisso com mais frequência e assim por diante. Mas, na verdade, a ideia aqui é que você é capaz de melhorar com base nessas análises. Você não quer apenas construir partes do capítulo que raramente utilizam, mas quer investir onde está a ação, qual é o maior potencial de crescimento? E são realmente aquelas ferramentas que fornecem insights, garantem medir o desempenho. Eu mencionei antes, as pessoas não são muito pacientes quando se trata disso. Portanto, você quer medir o desempenho técnico e a facilidade do sistema que implantamos, tem um amplo monitoramento de desempenho em vigor o tempo todo. Dessa forma, você é capaz de rastrear quantas vezes uma ação ocorreu, quanto tempo demorou. E, e novamente, você acha isso como uma boa oportunidade de espaço para otimização. Você também pode colocar alertas e lugar para saber quando uma ação talvez esteja demorando um pouco mais lenta, se seu servidor, seu ambiente está sobrecarregado. Então você é bastante enigmático e procura consertá-los também. E, é claro, mesmo um tipo de monitoramento manual quando se trata de olhar para a App Store, por exemplo, responda aos comentários de custos dos clientes. Leve seus comentários em, em consideração, certifique-se de que o gerente de produto os veja. E de acordo com o, esse é o feedback chave que você precisa para melhorar e eles rapidamente obtêm outra próxima iteração do seu aplicativo. 13. CONCLUSÃO: Isso nos leva à conclusão onde o final do curso. Espero que esses vários estágios do ciclo de vida de desenvolvimento de software façam sentido e isso tenha sido um pouco útil para você. Olha, se há uma coisa que eu diria no final é um tamanho único não é isso. Enquanto a metodologia do desenvolvimento ágil e que o processo em si funciona e pode ser aplicado de forma consistente. Claro, depende muito do projeto, da complexidade, do tamanho, do, do, do, do, do financiamento está disponível para você, do conjunto de habilidades das pessoas e assim por diante. E cada projeto é diferente. E em um, você pode ser pesado, pesado em sistemas de tecnologia e back-end e no domínio de negócios, enquanto outros, pode estar muito mais focado em design gráfico e engenharia de som e o desenvolvimento lá. E você precisa se adaptar conforme S necessário. E a única coisa que eu diria de uma perspectiva de gerenciamento de projetos, ou você sendo um gerente de produto ou um CEO de uma pequena startup é devidamente por valores. Porque você, como PM, como gerente de projeto ou alguém que não está envolvido em todos os estágios, mas sim a cola entre as pessoas. Você nunca será o especialista em nada. Muito mais. Foi você quem forneceu uma visão geral holística, mas você não é um especialista em domínios. Então, devidamente por esses valores, eu gosto dos mostrados na tela. Confiança, empatia, transparência e colaboração. Certifique-se de que as equipes possam se organizar, capacitá-las, para que possam fazer o que é necessário para resolver o problema. E eu acho que se você liderar por esses valores e se você estabelecer essa confiança e tipo de acreditar nos conjuntos de habilidades das pessoas, então você também pode construir um pró-fármaco assassino, um produto digital incrível que o ciclo de vida de desenvolvimento de software apresentado hoje. Foi isso. Espero que tenha sido divertido. Espero que isso tenha sido útil se houver alguma dúvida. Não hesite em entrar em contato comigo e nos veremos na próxima vez.