Transcrições
1. Introdução: Olá. Meu nome é Stephen Holt recebe porque John explicou que sou um desenvolvedor de software líder que tem mais de 25 anos. Experiência como uma indústria. Eu também sou treinador on-line que cada sala de aula workshops em todo o mundo e bem como tudo o que eu sou um poppet, palestrante e autor recentemente criado. Este curso é por causa da minha carreira. Passei muito tempo trabalhando em empresas que acreditam que estão sendo ágeis. Você vai entrar. Você observa que, garantindo que eles não rolam restaurações, o que pode banir placas e histórias. Mas então, quando uma mudança vem em um requisito, tipo de todo o inferno se solta. E você conhece esse tipo de pânico. Então, oh meu Deus, as coisas estão mudando o que vamos fazer. As pessoas têm que ir aos melhores departamentos para aprovação. Eles geralmente podem ser uma bagunça em seu não bêbado. Não é disso que os nossos trabalhos se tratam. Então, neste curso em strip away. Um monte de metodologia de gerenciamento de projetos é este curso não é sobre scrum. Não se trata de programação extrema. Se você falar brevemente, este tribunal é realmente sobre os princípios fundamentais da ágil o que significa ser uma piada e desde que você siga esses valores fundamentais, então você pode ser ágil. Não importa se você está fazendo Scrum XP ou o que quer que seja. As mais recentes metodologias favoritas. Por que você segue esses quatro valores fundamentais? Então você poderia ser um emprego. Então, com isso, vamos começar. Se gostar do curso, ficarei muito grato se puder me seguir. Vejo algumas das minhas causas futuras. Além disso, se você gosta do curso, eu ficaria muito grato se você pudesse sair no Twitter quando para o tamanho das mídias sociais ser fantástico. Então, com isso, vamos começar.
2. História da Waterfall: Olá e bem-vindo à minha causa, Agile explica. Sou seu anfitrião, até chifres no curso dele. Vamos analisar os princípios fundamentais do desenvolvimento ágil de software e dissipar alguns equívocos
comuns. Este não é um curso sobre scrum ou programa extremo em, como eles são meramente técnicas para facilitar o desenvolvimento de software ágil. Este curso é sobre os princípios fundamentais que todas as equipes ágeis precisam aderir. Vamos começar olhando para a água mais tradicional para o processo de desenvolvimento de software e seus problemas. Se você não está trabalhando em uma empresa baseada em ágil, então as chances são de você estar trabalhando em uma forma de água para desenvolvimentos de software em sua primeira seção. Vamos olhar para o que é a água e identificar seus principais problemas, o que nos levará a falar sobre ágil com mais detalhes. A metodologia de desenvolvimento da cachoeira foi introduzida pelo cientista da computação Winston Royce em 1970. Winston Royce discutiu pela primeira vez a idéia de desenvolvimento de software ágil em um artigo chamado Managing the Software Developments of Large Software Systems. Royce não se referia diretamente ao modelo em seus papéis. Guerras por desenvolvimentos. Este artigo foi sobre o processo que foi falho para desenvolvimentos de software, foi seu design original realmente mostrou mais repetição entre os estágios do modelo, que foi para não deixar Você fazer Winston Voices. Modelo real foi mais intuitivo em como ele funciona em permitiu mais espaço para manobrar entre estágios. Discutiremos uma forma mais frequente de trabalhar comigo. Discuta o Agile mais tarde neste curso. Embora a voz não se referiu a este modelo foi prêmios para Modelo diretamente, ele é creditado com a primeira descrição do que nos referimos é o modelo cachoeira. artigo original da Rússia consiste nas seguintes etapas, que entrarão em mais detalhes em um momento. As etapas são as especificações de requisitos estágio o estágio de projeto detalhado, integração fase de
construção, testes e o esforço na instalação e manutenção. Então, não é. Dê uma olhada em como o modelo de cachoeira realmente funciona.
3. Como a caixa de de água?: em cachoeira. O processo é dividido em estágios separados, onde o resultado de um estágio de entrada para o próximo estágio. A primeira etapa na água para foi começar com requisitos cobrindo todos os requisitos. Análise. Onde todos esses requisitos para o sistema que está sendo desenvolvido são registrados em nossas especificações. Documentos, requisitos, especificações. Então vamos ser assinados por outra parte interessada do projeto, geralmente do negócio. É responsabilidade do analista de negócios no projeto para criar os
documentos de requisitos . Se você está esperando por uma equipe menor, que isso poderia ser feito é uma colaboração entre os membros da equipe nesta fase do ciclo
cachoeira com analista de negócios ou pessoas direita em um documento, tente capturar todos os requisitos e características do sistema das principais partes interessadas da empresa. Isso pode incluir o conjunto completo de funcionalidades Qualquer negócio, não
foi automatizando e então você tem processos operacionais de uma
perspectiva da empresa e regulatória . O próximo estágio assistente projetar as especificações requisitos da primeira etapa ou inspecionados e designers assistentes juntos. Isso é Ryan ajudou na especificação dos requisitos de design e também ajudou a criar na arquitetura de
sistemas ovais . Nesta fase, é um membro técnico da equipe, que inclui desenvolvedores e arquitetos que decidem como o sistema geral será construído. Uma vez que um sistema projetado enfrenta ser concluído, passamos para a fase de implementação. É aqui que os desenvolvedores da equipe tomam o design de software anterior e começam a
escrever o código para fazê-lo funcionar após a face de implementação, onde eles passam para a fase de
integração e teste. Este é o lugar onde a equipe de testes irá reunir todos os componentes do sistema do e
testá-lo é um único produto. A equipe de teste nesta fase deve ter um plano de testes detalhado que eles trabalham até mesmo realizando testes manuais ou desenvolvendo testes automatizados. Uma vez que a equipe de testes tenha concluído seu trabalho e assinado, o sistema está apto e adequado. Em seguida, ele está pronto para implantação para os usuários finais. Você pode começar a ver os benefícios depois que uma solução for implantada na produção e, em
seguida, entrar em uma fase de manutenção durante esse período. Se os usuários finais relatarem quaisquer defeitos que precisarão ser corrigidos, testados serão reimplantados na produção. Se algum destes números é acabar por ser muito grande em escopo, uma decisão pode ser tomada para iniciar a cachoeira novamente redefinindo os requisitos. Projetar a implementação, testar e, em seguida, reimplantar se isso acontecer só pode ser bastante demorado, que não se presta para corrigir isso tinha que ser feito urgentemente.
4. Onde é a cachaça adequada a preço?: enquanto no mundo Adroll, há muita ênfase em dizer que a água para não é adequada. Há, no entanto, alguns projetos quando, o que para a metodologia é apropriado. Vamos dar uma olhada em alguns. Primeiro de tudo, o que é adequado se seus requisitos de projeto de software já foram bem definidos documentados. Mas, na realidade, com que
frequência é esse o caso das minhas próprias experiências? Um designer de software e desenvolvedor, eu não consigo me lembrar de nenhum dos muitos projetos que eu entrego onde os requisitos
foram claros desde o início para que eles possam ser capturados no documento Isso não muda é um projeto rola na próxima a definição do produto deve ser estável. Ok, e eu não consigo pensar em um único projeto onde este tenha sido o caso de May. Como fatores externos, como mudar o mercado ou mudar os negócios, as prioridades significam que seu produto evoluirá. Trabalhei em muitos projetos onde o produto final foi totalmente diferente do que foi inicialmente especificado debaixo d'água, pois isso não deveria acontecer. Mas, na realidade, o que você está construindo não pode mudar nada de errado com esse bebê. Isso é lutar contra um processo de entrega de software. Em seguida, a tecnologia deve ser bem compreendida. Isso significa que os desenvolvedores devem entender a tecnologia está lá vai estar usando e como eles funcionam. Uma vez que você foi para a implementação da fase de construção do projeto, os desenvolvedores geralmente têm que trabalhar para prazos muito rígidos e definidos. Na minha experiência, trabalhando na água para o projeto, um monte de esforço é expulso dos requisitos e fase de design, que normalmente consome o tempo necessário para realmente desenvolver o código. Próxima cachoeira funciona melhor em projetos são curtos. Em suma, quero dizer projetos em torno de 2 a 4 meses no total. Quanto mais tempo o projeto for executado, mais chances há de que os requisitos e a definição do produto estejam se tornando
desatualizados . Finalmente, o que para Works melhor. Quando toda a sua equipe de produto está disponível para trabalhar em conjunto, é bastante normal para um desenvolvimento parece ter uma porta de recursos. Ele pode ser compartilhado entre muitos projetos diferentes. Se outro projeto é longo, executado por qualquer motivo, então você pode não ter todas as pessoas disponíveis no momento e agora necessário isso pode afetar
significativamente os projetos cronogramas amplas datas de entrega em risco
5. Vantagens e Disadvantages da queda: Eu quero fazer agora é dar uma olhada em algumas das vantagens e desvantagens para o modelo
cachoeira. A primeira vantagem é que, dividindo seu projeto, entregas em estágios menores é mais fácil para uma organização manter o controle sobre o processo de
desenvolvimento. Isso torna muito mais fácil para os horários serem planejados com antecedência. Isso torna uma vida de gerentes de projeto muito mais confortável. Foi por esta razão que encontrei a experiência. Os gerentes de projeto tendem a favorecer o processo de cachoeira como você poderia tornar suas vidas muito mais fácil. Vamos ouvir um projeto para as várias faces do processo de cachoeira. Você pode facilmente entrega ISA departamental do seu projeto. Você pode atribuir funções diferentes a vários departamentos e obtê-las. Uma lista clara de entregas e escalas de tempo se algum desses departamentos não puder entregar por várias razões, é fácil para um gerente de projeto ajustar um plano de rifle. Infelizmente, na realidade, eu vi o método adaptado onde a fase de implementação fica apertada quente ou o que
significa que a equipe de desenvolvimento tem menos tempo para entregar a solução de trabalho e está chegando. A qualidade sofre e os atalhos tendem a ser tomados. Geralmente são unidades baseadas em código e teste de integração que são afetados primeiro. Isso tem um efeito de bater sobre as equipes de teste na fase de testes à medida que obtêm uma solução. Contém mais problemas, o que torna suas vidas muito difíceis. Assim, enquanto a organização departamental é vista como uma vantagem, ela pode rapidamente se tornar uma desvantagem se outra equipe está atrasada em entregar sua parte
do projeto para modelo completo não permite qualquer tempo para reflexão ou uma visão para um design. Uma vez que os requisitos foram assinados, eles não devem mudar. Eles devem significar que a equipe de desenvolvimento tem um design fixo, que suas glândulas, palavras, palavras. Na realidade, isso não acontece, e as mudanças nos requisitos podem muitas vezes resultar em caos, pois os documentos de projeto precisam ser atualizados e reassinados pelas partes interessadas. No momento em que a equipe de desenvolvimento começar Então o trabalho lá é praticamente esperado para
acertar na primeira vez e eles não têm muito tempo para pausar para reflexão sobre o código que eu implementei. Mas o tempo que você chega ao ponto em que você acha que uma mudança de direção técnica é normalmente muito tarde para fazer qualquer coisa sobre isso, a menos que você queira afetar os dias
de entrega. Isso pode ser bastante motivador para a equipe de desenvolvimento que eles têm que prosseguir com. 10 incluem implementações, cheias de compromissos e dívidas técnicas. Uma vez que o produto tenha entrado, o estágio de teste muda praticamente impossível. Se isso é para o projeto geral ou a água de implementação real para era um
processo simples . Entenda sem papel. Parece uma boa ideia para executar um projeto. A cachoeira também é mais fácil de gerenciar seus gerentes de projeto. Tudo é entregue em etapas. Pode estar programado nos planos. Tesouros são concluídos um de cada vez em que a saída de uma face é alimentada na entrada do próximo estágio. Cachoeira funciona bem para projetos menores onde o risco de mudança de requisitos e escopo é menor, cada passo na água para um muito claramente definido. Facilita a atribuição de funções claras. Duas equipes e departamentos que você tem que alimentar para o projeto causa cada etapa é bem para encontrar. Ele faz um marco estabelecido pelo gerente de projeto. Mais fácil de entender. Se você estiver trabalhando em um estágio na análise de requisitos, você deve saber o que você precisa entregar para o próximo estágio quando submerso para o processo e os resultados de cada estágio de todos documentados. Cada estado tem entregas claras documentadas e assinadas pelos principais interessados do projeto para o modelo se encaixa muito bem, INS começou Charles,
Então, um gerente de projeto é mais feliz quando eles reclamam tudo. Kautz e ver o projeto Timeline na aplicação que funciona de projetos. Uma das maiores desvantagens prêmios para modelos. Você não tem nenhum software funcionando até o final do processo. Isso significa que seus usuários finais não conseguem ver sua visão ganhar vida até que seja tarde demais para mudar qualquer coisa. Pode ser difícil e para as pessoas técnicas serem claras sobre como querem que um aplicativo funcione, e é normalmente até que possam visualizar um aplicativo que eles podem dar um bom feedback . Você pode mitigar isso fazendo a partir de prototipagem na face de design do sistema para ajudar os usos, visualizar seu sistema. Não há nada como dado um código de trabalho real, e software para experimentar para modelo poderia introduzir um alto nível de risco e incerteza para qualquer coisa, exceto pequenos projetos. Isso ocorre porque um conjunto de requisitos e design foi assinado não significa que as condições não vai mudar para era sobre obter os requisitos, projeto e implementação correta. Primeira vez, que é uma grande idéia em um mundo perfeito, mas no mundo real é muito raramente o caso, e é um grande risco para um projeto. Mais complexidade que está envolvida aumenta o risco de comércio necessário ainda mais abaixo. Complexidade no sistema também é muito difícil de implementar e testá-lo muitas vezes pode causar atrasos nos estágios posteriores da água para o desenvolvimento de software. Ciclo de vida Se você está trabalhando em um projeto onde a mudança é esperada, necessidade
deles não é o modelo certo para você. Eu trabalhei em projetos de empresas de serviços financeiros onde variações na lei financeira porque em conformidade ou regulamentos para mudar. Infelizmente, estas regras são muito abertas à interpretação, que significa que a equipa jurídica esteve envolvida numa fase muito precoce. Isso significou que a interpretação mudou algumas vezes durante o projeto. Se isso tivesse sido prêmios para o projeto, nós estamos em apuros. Os produtos frequentemente vêm de um conjunto fixo de prazos. Este foi um ajuste perfeito para o projeto natural. Se você estiver trabalhando em um projeto grande nas mudanças de escopo, o impacto disso pode ser tão caro e dispendioso que o benefício comercial original para o projeto e evapora. E então o projeto se aconselhou. Eu vi isso acontecer algumas vezes, e é uma vergonha, que projetos
que mostram promessas reais param devido a restrições no processo. Finalmente, a integração e entrega de um projeto tinha feito como um big bang em prêmios para Projeto. Isso significa que você vai introduzir grandes quantidades de mudança ou de uma vez ele está indo rapidamente sobrecarregado equipes de teste e suas equipes operacionais.
6. O que é Agile?: Agora que estamos dando uma olhada Uma água mais tradicional para o processo de desenvolvimento de software. Vamos agora começar a investigar desenvolvimentos de software alternativos e
ágeis. Afinal, desenvolvimento de
software é um conjunto de práticas de desenvolvimento de software que promove um design
evolutivo com equipes que podem se auto-organizar. No nosso software. desenvolvimento inspira o desenvolvimento de software de lesões malignas, métodos de planejamento
adaptativos, uma entrega antecipada de valor do seu software para os clientes de urina. A palavra ágil foi ligada pela primeira vez ao software de desenvolvimento em 2001, quando o
manifesto ágil foi criado por um grupo de líderes visionários e desenvolvedores de software. Eu não sou tradicional discagem e práticas como metodologias ágeis cachoeira. Tal scrum e programação extrema são focados em
equipes auto-organizadas cross-disciplinar que praticaram planejamento e implementação contínuos para oferecer valor aos seus clientes. A principal ação do desenvolvimento de software ágil é fornecer software de trabalho que dê valor mais cedo ao usuário final. Cada um desses métodos enfatiza a associação contínua entre tecnologia e o negócio para quem você está desenvolvendo o software, afinal, metodologia de
software, é um considerado leve que eles se esforçam para impor um processo mínimo e sobrecarga dentro do ciclo de vida do desenvolvimento. Os métodos Adroll são adaptáveis, o que significa que eu apoio mudanças nos requisitos e
prioridades de negócios . Para fora todo o processo de construção de software muda. Os requisitos naturais devem ser abraçados e acolhidos com um
projeto de desenvolvimento de software ágil . Há também uma ênfase considerável em capacitar equipes de decisão colaborativa. Faça-o. Anteriormente, eu falei sobre como o processo de desenvolvimento baseado em cachoeira segue uma série de etapas que
resultam em um big bang de software implantado no final do processo. Uma das principais ideias por trás do desenvolvimento de software ágil é que, em vez de entregar um lançamento
Big Bang para produzi-lo no projeto, você lançou várias versões de códigos de trabalho suas partes interessadas continuamente. Isso permitirá que você priorize recursos que ofereçam o máximo valor aos usuários mais cedo para que a organização possa obter um retorno antecipado sobre seus investimentos. Sobre esse investimento vem sob a forma de dinheiro gasto e tempo consumido no desenvolvimento e planejamento do número de entregas em produção. Isso depende de quanto tempo o projeto complicado é, mas idealmente, você gostaria de fornecer software de trabalho no final de cada sprint ou iteração. Eu amo uma boa maneira de visualizar a premissa do nosso Joe está no diagrama você escondendo tela. Agora, o que este diagrama mostra é se o software ágil você fornece incrementalmente em vez de tudo
de uma só vez. Você deve manter a culpa dele em sua mente enquanto progredimos através do resto deste curso.
7. A história do agile: Houve muitas tentativas de melhorar as metodologias de desenvolvimento de software ao longo dos anos , e muitas delas analisaram o trabalho de forma intrusiva. Essas novas práticas não foram longe o suficiente na tentativa de lidar com mudanças nos requisitos para os clientes. Na década de 19, um grupo de software da indústria Fort Leaders se reuniu em uma estância de esqui em Utah para ver você pode definir uma maneira melhor de desenvolver software. O termo desenvolvimentos ágeis de software surgiu a partir desta cavalaria. O termo foi usado pela primeira vez em sua maneira e publicação. O agora famoso manifesto Agile Manifesto Theater foi projetado para promover as ideias de entregar valor comercial regular aos seus clientes e tornou necessário que você se concentre em uma equipe colaborativa e interfuncional para tornar este acontecer.
8. Os de manifeste quatro valores básicos: O manifesto federal é provavelmente o artefato mais importante que podemos olhar quando se
trata de desenvolvimento de software ágil. Não importa o que sua influência na programação extrema Squam quando Se você tem um metodologias de gerenciamento de
projeto, você não está seguindo os valores no manifesto ágil, então você não está fazendo adroll corretamente. Então vamos dar uma olhada nos quatro valores fundamentais. Estes são indivíduos e interações sobre processos e passeios, software de
trabalho sobre documentação abrangente, colaboração com o
cliente sobre negociação de contratos e, finalmente, responder à mudança ao longo seguir um plano para o primeiro núcleo valor. Temos indivíduos e interações sobre processos nas escolas. As pessoas constroem sistemas de software e ainda assim corretamente, eles só para trabalhar em conjunto e ter uma boa comunicação entre todas as partes. Isso não é apenas desenvolvedores de software, mas inclui analista de negócios de Q A, gerentes de
projeto, patrocinadores de
negócios e liderança sênior e qualquer outra pessoa envolvida
no projeto ou produto em sua organização. Processos e ferramentas são necessários, mas eles são irrelevantes porque as pessoas que trabalham nos produtos não podem se comunicar e trabalhar juntos de forma eficiente por um segundo dos valores fundamentais. Tínhamos software de trabalho sobre documentação abrangente. Vamos encarar,
quem lê 100 produtos de página de volta. Eu certamente não. Os usuários de sua empresa eram muito preferidos, então pequenos pedaços de funcionalidade que são entregues rapidamente para que eles possam fornecer feedback. Essas peças de funcionalidade podem até ser suficientes ao ponto de produção para se
beneficiar delas. A documentação antiga antiga é ruim, entanto, quando minhas equipes por que ele está em um projeto eles usavam ferramentas de diagramas visuais para fora do physio para produzir diagramas como diagramas de implantação, esquema de
banco de dados em camadas de software e diagramas de casos de uso. Nós tipicamente imprimimos em três impressões e colocamos na parede para que
fiquem visíveis para todos. Pequenas peças
úteis de documentação lá fora tão valiosas 100 páginas produtos, costas ou não. Nove vezes em cada 10 grandes itens de documentação são inválidos e desatualizados antes
mesmo de terminar de escrevê-los. Lembre-se, o objetivo principal é desenvolver software que dê benefícios aos negócios, não documentação extensa. Prefiro aos valores fundamentais. Temos colaboração com o cliente em relação à negociação de contratos. Bem, o software que você desenvolveu deve ser escrito. Se o envolvimento dos seus clientes Seja bem sucedido no desenvolvimento de software, você precisa trabalhar com ele diariamente. Isso significa convidar para o seu stand ups demo neles regularmente e convidá-lo para qualquer reunião de
design. Só o cliente pode dizer o que quer. Eles podem não ser capazes de fornecer todos os detalhes técnicos, mas é isso que sua equipe, portanto, deve colaborar com eles, entender seus requisitos e entregar para eles. Mas um valor de quatro da chamada final que temos respondendo à mudança ao longo de seguir um plano que seu cliente ou empresa patrocinado pode treinar suas mentes sobre o que está sendo construído. Isso pode ser porque você deu a eles novas idéias do software que você forneceu em uma situação
anterior. Pode ser porque as prioridades da empresa mudaram ou novas mudanças regulatórias
entraram em vigor. A coisa chave é que aqui você deve abraçá-la. Sim, algum código pode ser jogado fora e algum tempo pode ser perdido. Mas se você está trabalhando em pequenas alterações e desta vez perdido, sua mudança de minimizar é uma realidade de desenvolvimento de software, uma realidade que seu processo de software deve refletir. Não há nada de errado em ter um plano de projeto. Na verdade, , você está preocupado com qualquer projeto que não tenha um. No entanto, um plano de projeto deve ser flexível o suficiente para ser alterado
9. Visão geral de metodologia: Agora que entendemos os principais valores do manifesto ágil, eles são comumente usados para sustentar diferentes metodologias, é por isso
que Adroll se torna mais prático. Vamos tomar um nível muito alto. Veja algumas das metodologias comuns que Aaron usou hoje. Este curso não é sobre qualquer metodologia em particular, mas as questões vão tomar um copo de metodologias alguém que estão lá fora bem sucedido
temos Scrum Scrum é um quadro de gerenciamento de projetos leve que é baseado em um interativo modelo de trabalho. Ken Schwab pode ser Door Jeff Suculent e ofertas contribuíram com os desenvolvimentos descritos ao longo dos anos nos últimos anos. Screamers possuem crescente popularidade na comunidade de desenvolvimento de software por causa de sua simplicidade, sucesso
comprovado e melhorar a produtividade e sua capacidade de trabalhar com práticas de
engenharia muito sofridas promovidas pelo nosso frágil metodologias como programação extrema. Então, em seguida, temos programação Extreme ou Ex Pays é também nove programação Extreme foi inicialmente concebido por Ken volta e surgiu um dos métodos
ágeis mais populares e controversos . A programação extrema é uma abordagem disciplinada de fornecer software de alta qualidade mais rápido e enfatiza consistentemente muito engajamento do cliente, saltos
rápidos de feedback, testes
contínuos, continua planejando o trabalho em equipe para fornecer software de trabalho. Cadência de lançamento frequente tipicamente de 1 a 3 semanas em que um scrum é uma
estrutura de gerenciamento de projetos . Exp é mais uma disciplina de engenharia. É muito comum que as equipes adotem scrub, mas emprestar diferentes práticas de engenharia de programação extrema. A receita original de programação Extreme foi baseada em valores simples de garfo, simplicidade, comunicação, feedback, encorajar. Há também 12 práticas de apoio. Estes são os pequenos lançamentos jogo de planejamento, testes de aceitação
do cliente, programação de pares de design
simples, desenvolvimento orientado por
teste, re fator na integração contínua, codificação de propriedade de código
coletivo padrões, metáforas e ritmo sustentável. Como eu já disse, no entanto, este curso não é sobre scrum ou programação extrema, A mensagem importante para você aprender neste curso é o que Pageau em si é tudo sobre. Eu vi algumas equipes acharem que estão fazendo scrum, mas na verdade quando se trata de olhar para os quatro valores principais, se uma mudança vem no projeto e depois tem que ir para alguns conselhos consultivos ser discutido, aprovado sem documentos, mesmo que pareça que você está fazendo ágil, o que em scrum? Na verdade, você não é. Então são os quatro valores fundamentais que eu quero que você se concentre neste curso
10. Papéis em uma equipe de Agile: em equipes antigas fazia parte de um departamento de uma empresa focada principalmente em seus objetivos de
desenvolvimento de software . Cada equipe também deve estar focada em sua visão geral de equipes. Isso significa que uma equipe deve ser muito reativa em fazer o que for necessário para fazer o trabalho . Isso significa que os membros da equipe também podem ter que trabalhar fora de seus conjuntos de habilidades normais. Eles devem ser abraçados e encorajados. Uma equipe adaptativa multifuncional é muito mais provável de ter sucesso. A maioria das equipes, é claro, terá algumas áreas padrão de especialização e ISM especiais, e você também pode ter pessoas em particular conhecimento de domínio ou produto. Mas deve ser flexibilidade e os jogadores da equipe esperavam papéis e responsabilidades. Você também deve ser comum para membros da equipe ter acesso ao negócio como um todo, e eles não devem ser limitados apenas a alguns seletos. Você deve ter pessoas que são encarregadas de garantir que a equipe seguiu o
processo de desenvolvimento , e alguém que coordena a coleta de requisitos com a empresa para a qual é normalmente referido como o proprietário do produto. Se você estiver trabalhando dentro da escória, estrutura, as equipes normalmente terão alguma forma de papel de liderança dentro da equipe em scrum essa pessoa é o mestre scrum em equipes ágeis. Sua pessoa tem como objetivo possibilitar e garantir o sucesso da equipe, o tipo de líderes frequentemente referido como um líder servo. Essa função é totalmente diferente de um lead direto e
transacional em um projeto em cascata. Uma equipe ágil forno deve ser melhorar como uma equipe todos os dias. Quanto maior a organização, as estruturas de grupo mais complicadas podem ficar. Equipes de projetos
cruzados, serviços compartilhados, operações, gerenciamento de
configuração e administração de banco de dados também podem entrar em jogo. Mas o objetivo permanece o mesmo. Encontrar um projeto de software e uma equipe multifuncional capaz de cumprir um plano e capacitar uma equipe para fazê-lo.
11. Conceitos de Missa de agile comum: quando uma equipe precisa ágil, pode ser metade deles para se ajustar a uma nova maneira de trabalhar, especialmente para acostumado a trabalhar sob prêmios para metodologia baseada. Quando uma equipe é confrontada com mudanças, como eles trabalham é comum para desculpas a serem feitas pelos membros da equipe enquanto eles resistem à mudança. Nenhuma equipe como esta, mas na minha experiência, é bastante comum ouvir muitos equívocos diferentes nesta seção irá discutir muitos desses equívocos e por que eles surgem. Sim, Joe está em Hark sem controle de processo. Para ser ágil, você precisa aderir ao manifesto ágil. Mas seguir o manifesto não significa que você está usando um processo desafiador. O manifesto descreve um conjunto de ideias. Existem vários processos e modelos de gerenciamento de projetos que você pode aplicá-lo aos seus
projetos para ajudá-los a se tornarem ágeis. Programação extrema em scrum são dois dos mais populares, mas magra e Cambon também são muito populares. Quando você tenta implementar os itens de manifesto, você Alemanha precisa aplicar perda de senso comum e pragmatismo para esperar que você chegue ao seu objetivo antes de envolver um processo mais formal em torno do como de ágil em oposição ao porquê. E você precisa informar algo como scrum ou programação extrema, que lhe dá um processo mais formal, como histórias, alterações, Standups, demos, retrospectivas, desenvolvimentos orientados para testes e programação em pares. Em seguida, temos ágil é desperdício sem se de planejar este extremos, seu cliente sabe que as torres de todas as suas necessidades com antecedência. Se isso for verdade,
então, por todos os meios, empreende abrangente desde o planejamento. No entanto, na realidade, isso é raro e geralmente menos um desperdício maior de ter tomado um trabalho de desenvolvimento de designer que era, em última análise, desnecessário. Em seguida, temos desenvolvimento ágil não é previsível americano. Dentro da equipe estabelecida e
ágil. Você pode trazer um nível de previsibilidade. É o seu ciclo de vida de desenvolvimento nos negócios À medida que você está fornecendo software de trabalho diretamente aos seus clientes, a frequência dessas versões será definida com as partes interessadas. Em uma situação ideal, você deve ter, código
liberável no final de cada sprint ou iteração. Em seguida, temos ágil é mais rápido e mais barato. Executar uma equipe ágil não significa que você terminará seu projeto mais rápido ou por menos dinheiro. Não é uma poupança directa de dinheiro a esse respeito, o que é ser um julgamento. Ele está agregando valor para o negócio mais cedo que você teve para trabalhar versões de seu código mais rapidamente e o fim de cada iteração de desenvolvimento. Você deveria ter um software de trabalho para demonstrar para o negócio. Você pode não ter todos os requisitos em vigor, mas o que está lá vai funcionar. Isso significa repensar como você planeja sua carga de trabalho em cada situação. Em vez de fornecer fatias horizontais, por exemplo, o acesso a dados camadas sua situação na interface do usuário em uma situação de pescoço, você pode pensar em segmentos verticais. Isso significa que você entregou para encontrar partes de funcionalidade em uma inspiração que pode abranger o trabalho na interface do usuário e uma camada de acesso a dados. É uma mudança de mente. São vistos equipes lutando com. Se eu costumava trabalhar horizontalmente quando eles finalmente obtê-lo, a eficiência de uma equipe aumentou Notavelmente. Estar fora também é ser capaz de responder à mudança. requisitos podem variar, e as empresas podem mudar de ideias em parte para a sua entrega. Lutarei onde você tratar as equipes. Isto é uma coisa muito negativa. Se você quer ser ágil, você deve ser esperado. Um abraço de coisas vai mudar as ferramentas e processos de scrum, por exemplo, projetado para ajudá-lo a reagir a essas mudanças de forma mais eficiente. Então, próximo equívoco temos suas equipes ágeis. Não escreva documentos ou planeie. Praticar seu John em sua equipe não é uma desculpa para evitar planejamento ou documentação. Writing Agile é um ato de fazer o que é necessário no momento de exigir incentiva planejamento
contínuo e documentação, mas somente quando é necessário para uma exigência específica do cliente. Isso permite que as equipes, juntamente com seus clientes, decidam se o plano ou documento agrega valor ao produto. Dependendo do tipo de empresa para a qual você trabalha. Documentação formal pode não ser algo que você pode evitar. Por exemplo, se você trabalha em um ambiente muito regulado por densidade, há muita documentação inicial. Pode ser necessário para provas, uma apresentação a uma entidade reguladora. Se este for o caso na equipe de entrega, precisamos levar esta documentação em consideração. Eu prefiro trabalhar de grandes diagramas em vez de últimos Documentos de imposto. Se você pode obter esses diagramas impressos em seu papel livre e, em seguida, colocá-los em todas as paredes, então você tem algo que você pode se referir em seus standups. Com o lado de planejamento disso, você ainda precisa fazê-lo. Como o início de cada sprint interacional. Você deveria ter uma sessão de planejamento. Quando uma equipe auto aloca histórias para a alteração, o número de histórias que são alocadas será baseado nas estimativas dadas
nas velocidades para as iterações anteriores. O próximo equívoco é que ágil significa que nenhum compromisso é uma crença comum de que as pessoas são ágeis. As equipes não querem fazer promessas de que você tem equipes de desenvolvedores agitando longe até que alguém grite, Estamos feitos. Uma equipe de crianças bem-sucedida deve ser muito transparente sobre o que eles pretendem entregar seus usos. Ao usar metodologias são scrum ou programação extrema, você tem um conceito de um backlog que contém uma revisão. Heil sobre os usuários. Histórias e tarefas foram dadas sprint ou iteração como você para encontrar a carga de trabalho para um sprint. Eles devem ser vistos como um guia para o que a equipe pretende entregar. Uma vez que uma reiteração do Spencer é configurada , ela não será alterada, mas pode ser necessário que você tenha que alterar seu plano parcialmente para sua impressão. Isso poderia resultar em um replantio parcial de que sprints, reiteração ou esperar até o próximo príncipe. Programação extrema não gosta de mudar um sprint uma vez que é. Você voa nele. Isso é mais aceitável e scrum, mas nenhuma lei diz que você também pode o compromisso, se necessário. O que é importante é que existe um nível de confiança entre a equipa e as
partes interessadas da empresa . Em seguida, temos um projetos ágeis nunca vai acabar. Isso pode ser verdade em algumas situações. Ele deve continuar a trabalhar em um projeto enquanto o cliente continua a obter valor comercial . A maioria dos produtos em qualquer indústria tem um ponto de retornos decrescentes. Este é o momento ideal para um produto natural e desenvolvimento. Esta decisão deve vir do negócio, embora para eles que você está entregando valor para trabalhos ágeis para projetos, equipes e organizações de qualquer tamanho, não apenas para pequenos projetos. Isso não significa que você esteja necessariamente trabalhando para todas as equipes, mas o tamanho é realmente um fator. Grandes e complexos projetos e organizações, muitas vezes excelentes candidatos à transformação natural, levantam dificuldades ou impossíveis de conhecer antecipadamente todas as necessidades dos seus clientes. Em seguida, temos ágil são as soluções para seus problemas. Natural é uma mudança na abordagem e cultura que vem com seu próprio conjunto de benefícios e problemas. Se você está trabalhando em uma equipe bem estabelecida, não
tem seguido nenhum processo ágil do que mudá-los não será uma transformação
instantânea. Você precisa fazer isso devagar e ter certeza de que todos têm uma palavra a dizer no processo de tomada de decisão. Se você não fizer isso, você faz resistência de membros da equipe que temem a mudança, o que é uma característica humana perfeitamente normal. Convencer sua equipe não é o maior
obstáculo . Seu maior desafio é garantir que sua equipe de liderança entenda e queira adotar. Ágil como forma de trabalhar. Uma vez que você alcançou isso e teve liderança por no resto da adoção apenas leva tempo e paciência é todo mundo se ajusta. O próximo equívoco é que só há uma maneira de fazer um trabalho. O manifesto original e
ágil consiste nos quatro valores fundamentais. Ele não documenta nenhum detalhe real de implementação lá. Muitas interpretações de ágil que formam diferentes metodologias como scrum proibição de cam de
programação extrema no desenvolvimento orientado por recursos, para citar alguns. Cada estilo tem seus benefícios e fraquezas, e você deve avaliar a sua situação para decidir qual metodologia se encaixa sua equipe
programação extrema desenrolar dois dos métodos mais populares em uso hoje, mas também levando Cambon são muito popular, também. Como sempre, mantemos os manifestos adroll, valores e princípios e fornecemos software de maior valor regularmente aos seus clientes. Você deve ser considerado ágil. Quem finalmente, o último equívoco que temos é Adul Desenvolvimento não requer design inicial. É um equívoco comum. Equipes ágeis só fazem isso à medida que avançam. Isto não é verdade. O que é mais realista é que as equipes ágeis devem garantir que suas decisões aconteçam no último ponto responsável no tempo para atividades de revestimento. É conjuntos de marcas com código é projetado como um desenvolvedor trabalha nele, todos os fatores para um design melhor como eles vão junto. Isto é o que é o design evolutivo. Mais amplo sistema. Um projeto arquitetônico poderia ser quebrado em um ou mais sprints antes do tempo, apenas projetando como você precisa ver, você pode reagir às mudanças nos requisitos de forma mais eficiente quando ele tenta projetar
todo o sistema na frente. Quaisquer decisões de design que você toma muito para ser redundante no momento em que você vem para implementá-las
12. Vantagens e Disadvantages do Agile: como você viu nos vídeos anteriores. O desenvolvimento de software ágil é uma abordagem totalmente diferente do desenvolvimento de software em comparação com o modelo mais tradicional de água para desenvolvimento. Vamos dar uma olhada em algumas vantagens de usar. Agile é uma abordagem. Em primeiro lugar, a satisfação
do cliente pela rápida entrega continua de software útil. Seus clientes nos usuários ficarão satisfeitos porque você continua entregando valor a eles. Software reutilizável. Isso está em um contraste gritante em comparação com a água tradicional para o
processo de entrega do produto . Agora, se seus clientes estão acostumados a cachoeira, eles podem encontrá-lo. Estranho. Justin vai ter um software de trabalho mais cedo. A grande desvantagem da água para as palavras que você entrega grandes pacientes de funcionalidade no
final do ciclo de vida do projeto, fornecendo peças de funcionamento cedo ou mais frequentemente, você está dando aos seus usuários uma oportunidade de obter um retorno sobre o seu investimento mais cedo. Claro, eles podem não ter toda a funcionalidade de que precisam antecipadamente, mas eles poderiam começar a fazer uso da solução para facilitar suas vidas e começar a
perceber os benefícios. Mais cedo a seguir temos pessoas e as interações são enfatizadas em vez de processos e passeios . Tentei seu foco muito nas pessoas e nas interações entre as pessoas, em vez dos processos em turnês. Este é um valor central do manifesto real. A razão por que isso é importante é que este as importações de sua equipe e clientes que acabarão por fazer o seu produto de sucesso em oposição ao que é sempre usar. Continuar a colaboração para em todo o ciclo de desenvolvimento do seu projeto permite que todos os
envolvidos construam um bom relacionamento de trabalho baseado na confiança. Essa relação de trabalho baseada em confiança é crucial na construção de software de forma incremental. Em seguida, temos atenção contínua ao código de alta qualidade. Estamos trabalhando com nosso trabalho. Você está trabalhando pequenas alterações em apenas construir o que é necessário para satisfazer os requisitos para sua aeração, e nada chama. Isso obriga você a manter seu design simples, que é essencial, pois a simplicidade ajuda você a desenvolver
sistemas testáveis e, portanto, mais confiáveis . Os desenvolvedores entendem e escolhem muitas soluções para resolver problemas de negócios. Estas são escolhas que refletem um ofício que equilibra design, uso e suporte. Os desenvolvedores fornecem a assistência técnica da equipe que os vizinhos para sempre manter a qualidade co maior. Os desenvolvedores gostam de usar as tecnologias mais recentes para manter sua implementação direta e limpa sem ter que retrabalhar nenhuma de suas soluções. Algumas dessas técnicas incluem re fábrica. A fábrica é um processo de melhorar o design do código existente sem alterar seu comportamento. Ele fez alterações na estrutura do código. A sala de fatos usa uma rápida sucessão de pequenos passos
bem definidos que poderia ser verificado é seguro ou funcional equivalentes. Re fatoração é muitas vezes feito em conjunto com o desenvolvimento orientado por teste. Onde, Unidade diz, e design simples tornar mais fácil para re fator com segurança. A próxima vantagem é o design simples. Manter seu design simples ou não Repetir código ajuda você a manter um nível de capacidade de manutenção para o seu sistema. Se você projetar seu código para ser modular, então você pode reduzir Coplin entre objetos. Normalmente, um sistema geral, mais robusto graças vantagens. Desenvolvimento orientado por testes. Desenvolvimento orientado por teste é uma maneira de melhorar o design do seu código escrevendo testes de unidade , que expressa o que você pretende os códigos para fazer esse teste passar e continuar re fatoração Para manter o processo de design o mais simples possível, pode ser aplicado em vários níveis,
por exemplo, por exemplo, testes de
unidade e integração. desenvolvimento orientado por testes segue um ciclo rigoroso. Você começa escrevendo um teste falhar, então você implementa que minha solução direta não faça esse teste passar. Em seguida, defina para duplicação no código e remove-o. Muitas vezes é chamado de verde vermelho. Red Factor tornou-se quase um mantra para muitos profissionais de design orientados por testes. Compreender e internalizar esse ciclo é fundamental para ser capaz de usar testes orientados para resolver seus problemas. Graças vantagens. Adotando mudanças nos requisitos, seus clientes ou parceiros de negócios. Queremos mudar sua opinião sobre o software que está sendo construído. Isso pode ser porque você os inspirou com novas idéias da onda suave entregues em uma situação anterior. Pode ser porque as prioridades da empresa mudaram. A coisa chave aqui é que você deve aceitar a mudança. Sim, código pode ser jogado fora e às vezes durar. Se você está trabalhando em ações de seguros, este tempo foi minimizado. mudança pode ser aterrorizante no início para clientes e parceiros. Mas quando ambos os lados se preparam para partir, você não pode ser mutuamente recompensador. Em alguns aspectos, no julgamento é uma idéia simples, mas a realidade é que ela pode significar coisas diferentes para pessoas diferentes, especialmente dependendo de seu papel no processo de desenvolvimento de software. Uma das principais coisas, entanto, é estar aberto à mudança, não apenas para mover-se de maneiras tradicionais de organizar projetos, mas então esse é o seu uso da ágil em si. Em seguida, temos retorno antecipado sobre os investimentos. Outro avanço para lançar recursos cedo é você sair mais cedo. Retorno de seus investimentos. Executar uma equipe de desenvolvimento de software é caro. Você tem desenvolvedores permanentes e testadores, bem como consultores com taxas diárias caras. É também gerentes de projeto de analistas de negócios, bem
como outros custos de software de hardware. Estes são todos os custos do negócio. Ao liberar cedo na geração de receita de seu produto, você pode começar a compensar alguns dos custos iniciais de investimento e desenvolvimento. outro lado,
se você cada vez mais água para abordagem baseada onde você acaba com um big bang implantações depois de um ano ou mais, você já terá gasto uma quantidade significativa de dinheiro para financiar um desenvolvimento sem nada para mostrar para ele até o fim. Em seguida, temos feedback de seus clientes se você liberar mais cedo. Isso significa que você pode começar a solicitar feedback de seus clientes muito mais cedo. Seus clientes podem ser clientes de frente para o público ou patrocinadores de negócios. Eu trabalhei em muitos projetos onde os clientes de negócios especifica requisitos, que ele, em seguida, construir apenas para os clientes querem mudanças. Uma vez que eu vi algo que eles podem usar, isso sempre parece acontecer. É difícil para alguém especificar um sistema sem ter algo para brincar. Você pode usar software de prototipagem para ajudar, mas não há nada como dar-lhes funcionalidade real para começar a usar cedo. Um dos princípios do nosso trabalho é abraçar a mudança nos requisitos. Isso deve ser esperado para fornecer aos seus clientes algo sobre o qual eles podem feedback mais cedo deixar baixo e a oportunidade de fazer alterações sem causar muita interrupção mais tarde. Abaixo da linha do avançado final que temos é a fé de volta dos clientes reais. Depois de começar a receber feedback de seus clientes, você pode começar a incorporar alterações. E novas ideias do feed de volta para o produto são muito mais rentáveis para fazer mudanças no início do ciclo de desenvolvimento do produto do que esperar até o fim. Uma vez que uma grande versão foi alcançada, não é apenas o feedback dos clientes que o ajuda a criar o protesto certo sobre o produto em seus produtos. No início do mercado, você engaja a aceitação do cliente e vê como os produtos serão populares e continua a oferecer melhor qualidade. Tudo o que discutimos até agora tem benefícios comerciais ou culmina no fato de que você deve fornecer um produto de melhor qualidade de cada versão, liberando
comentários insistentes antecipados . Você pode aprender com o desempenho do produto antecipadamente e usar essas informações para criar algo de maior qualidade de produto e desenvolvimento de sistemas, tudo sobre aprendizado contínuo e melhorias. É muito mais fácil de fazer quando você está entregando um produto por ser ágil. Não importa onde nunca. Usando programa extremo em scrum cristal Peixe impulsionado desenvolvimento Lean Cam banda Realmente, se você tem uma estrutura de gerenciamento de projeto, se você ficar com os valores centrais do manifesto ágil, Eu sou rotineiramente para viver um valor mais elevado mais cedo para seus clientes. Monitorar o uso deles não está lá? O feedback pode aplicar esse aprendizado ao desenvolvimento em andamento. Aumente a qualidade à medida que você avança agora para estar dando uma olhada em algumas vantagens, vamos olhar para algumas desvantagens. Em primeiro lugar, é difícil de avaliar. O esforço exigiu o início do ciclo de vida de desenvolvimento de software, uma reclama. Eu tenho ouvido muitas vezes de líderes de negócios e gerentes de projeto é comparado com a água, para? É difícil quantificar o esforço total e o custo para entregar um produto. Por um lado, pude ver o que pensaria. Isto, especialmente eles vêm de um regimento era mundo processo completo. Na verdade, é mais difícil quantificar quanto tempo o total dos produtos vai demorar. Mas uma mitigação para isso é que um produto será entregue incrementalmente, dando-lhes
usa os requisitos mais valiosos em primeiro lugar, que
significa que você reclama para os próximos sprints ou talvez alguns sprints à frente para fornecer oque
significa que você reclama para os próximos sprints ou talvez alguns sprints à frente para fornecer
quantidades de funcionalidade. Vantagens racistas. Pode ser muito exigente nos usos. Tempo Participação ativa do usuário em colaboração com os usos do seu sistema são necessários para o ciclo de desenvolvimento com ágil. Isso pode ser muito gratificante. Garante que você entregue os produtos certos para seus usos. É um princípio essencial da ágil. Para se certificar de que as experiências dos usuários são bem gerenciadas em uma definição de falha não é atender as expectativas de usos. No entanto, esse nível de participação pode ser muito exigente para o usuário e exigir um grande compromisso para a duração desse produto. Já esteve nesta situação muitas vezes em que os usuários de negócios adoram a idéia do que uma piada poderia trazê-los. Mas eu não gosto da quantidade extra de tempo que eles têm que gastar no projeto, eu ainda tenho que ajustar a mesma de suas cargas de trabalho comuns no último dia. Sobrevive jeans olhar é um custo pode aumentar. Testadores são necessários o tempo todo em vez de no final de um projeto. O teste é uma parte essencial do projeto natural Jordan sprints, e é orações que eles servem. Nós mostramos qualidade em todos os produtos sem a necessidade de taxa 11 e
fase de teste imprevisível final do seu produto. No entanto, isso não significa que o teste seja uma necessidade para todo o ciclo de vida de desenvolvimento do produto, e pode aumentar drasticamente o custo dos recursos de sua equipe. Estes custos adicionais iniciais poupa-lhe dinheiro a longo prazo, no
entanto, entanto, vez que as pessoas estão a testar o seu código continuamente. Ter uma combinação de testes manuais e automatizados é a melhor maneira de aumentar a qualidade de seus produtos
13. Está preparado para o Agile: para algumas organizações sabem ser maiores e mais antigas. A resposta para a pergunta que eu prepara para a mudança é provável que não. A ideia de implementar metodologias encoraja a evolução dos requisitos
de negócios em vez de depender de documentação avançada. Empoderar a equipe do projeto auto-organizado em vez de controlar suas atividades diárias na substituição significa que uma documentação sem comunicação cara a cara pode parecer um pouco assustador para alguns funcionários. Esta é particularmente a fase do caso em que eu fiquei confortável com seus encontros normais. Eles rotinas e apenas viver com os problemas em seu código sobre as soluções que irão desenvolvê-lo. Uma grande debilitação ao tentar ágil é que as pessoas dizem que é assim que sempre fizemos . Estes tipos de indivíduos, geralmente muito resistente à mudança, se você está começando sua hesitante no início, você pode achar que dar ágil para tentar em um projeto de doador em sua equipe vai ajudá-los a
familiarizá-los e motivados pela ágil. Se eu tiver que tentar um ou dois projetos ágeis, suas coisas ainda são desconfortáveis trabalhando diretamente com as áreas de negócios, forçando mudanças nos requisitos à medida que o projeto avança e autogerenciando seu trabalho. Pode ser que as abordagens ágeis não sejam adequadas para suas organizações. Cultura de trabalho. Se, por outro lado, sua equipe reage bem a projetos experimentais do que seus pavimentos, o caminho para você se mover mais plenamente para adotar nessas metodologias indo ágil não requer uma mudança de atitude para os gerentes e tradicionalmente, pode
ser mais comum ter controle direto sobre o que os membros da sua equipe estão trabalhando. Mas se ágil, você precisa adotar uma abordagem diferente. estilos gerenciais precisam ser mais como liderança servo, onde os gerentes estão lá para remover quaisquer barreiras do progresso da equipe e incentivar uma equipe a pensar por si mesmos e organizar suas próprias cargas de trabalho. Afinal, os desenvolvedores são pagos muito bem. Ela precisa ter um nível mais realista de confiança que eles vão fazer a coisa certa, não para coisa interessante sobre a dinâmica de equipes auto-organizadoras. À medida que eles
progridem, eles melhoram a motivação contínua para o projeto dos funcionários. Os membros da equipe sabem que sua capacidade contínua é autogerenciada. Seu trabalho depende de sua entrega regular de resultados de negócios de alto valor, adicionais porque eles são os únicos que identificam o trabalho que pode e não pode ser alcançado
na situação. Eles são motivados por sua responsabilidade de alcançar esses resultados. Esta combinação de fatores é reforçada pela situação e orgulho que os membros da equipe Phil quando eles produzem resultados tangíveis, verdadeiramente atender às necessidades de sua organização.
14. Obrigado: Obrigado por assistir “Pode ser que eu dirijo explica”. E eu espero que ele descobriu que a informação estar discutindo a qualidade vai ser útil para você realmente entender sobre um ágil principal para as organizações. Se você gostou do curso será muito grato. Você me segue. E também, se você poderia as pessoas sabem sobre a causa no Twitter sempre que sites de mídia social são absolutamente fantástico em Você também pode deixar comentários aqui deste lado. Então eu penso muito para assistir. Não te vejo de novo em breve.
Stephen Haunts, Trainer, Public Speaker, Author
