Carregado porNeubio Ferreira
Agile Scaling Model - TDC 2012 - São Paulo SP
O documento apresenta uma palestra sobre o Agile Scaling Model (ASM), um framework para implantar e escalar práticas ágeis em empresas. O ASM aborda os principais desafios de escala como tamanho de times, distribuição geográfica e complexidade técnica. Casos de sucesso demonstram como empresas usaram práticas como Scrum, DevOps e XP para melhorar a produtividade e entrega de valor ao cliente.
Mais conteúdo relacionado
![[BPM Day Porto Alegre] Maurício Bitencourt - Como o iBPM e as tecnologias mai...](https://cdn.slidesharecdn.com/ss_thumbnails/2014050608h40bpmdayportoalegremauriciobitencourt-141009090112-conversion-gate01-thumbnail.jpg?width=640&height=640&fit=bounds)
![1º Workshop Incepción en Thoughtworks Chile Febrero/17 [Espanhol]](https://cdn.slidesharecdn.com/ss_thumbnails/espanholworkshopcarolisinception-170216025732-thumbnail.jpg?width=640&height=640&fit=bounds)
Semelhante a Agile Scaling Model - TDC 2012 - São Paulo SP
Agile Scaling Model - TDC 2012 - São Paulo SP
- 1. JORNADA TÉCNICA DATI Agile Scaling Model Palestrante: Neubio Ferreira
- 2. JORNADA TÉCNICA DATI Apresentação Núbio Matos Ferreira Consultor de Engenharia de Software Processos de Desenvolvimento de Software Ágeis Suíte IBM Rational (RAD, RSA, RAM, RTC) Modelos de Qualidade (CMMI e MPS.BR) 2
- 3. JORNADA TÉCNICA DATI Agenda Introdução ASM Fatores de Escala Casos de Sucessos 3
- 4. JORNADA TÉCNICA DATI Chaos Report - Standish Group 4
- 5. JORNADA TÉCNICA DATI Razões para esta melhoria Segundo Standish Group 1º Processos Ágeis Cresce a uma taxa de 22% anual Adotados em 29% no desenvolvimento de novas aplicações Diretamente relacionada ao aumento da taxa de sucesso 5
- 6. JORNADA TÉCNICA DATI Razões para esta melhoria Segundo Standish Group 2º Modernização Projetos que focam na conversão BD/Código Alta taxa de sucesso Ambiente relativamente homogêneo de perfil de profissional 6
- 7. JORNADA TÉCNICA DATI Razões para esta melhoria Segundo Standish Group 3º Pacotes Empresariais Diminuição da taxa de novos Projetos de Implantação ERP e CRM Projetos de Grande Riscos Resultados Questionáveis 7
- 8. JORNADA TÉCNICA DATI Razões para esta melhoria Segundo Standish Group 4º Processos em Cascata Representam quase 50% do número de novas implementações Diminuição da taxa de utilização 8
- 9. JORNADA TÉCNICA DATI Manifesto Ágil – (Interpretação Visual) "Agile" Tradicional Processos e Indivíduos e Interações | | Ferramentas Software Documentação Funcional | | Extensa Colaboração Negociação com o Cliente | | Contratual Responder a Seguir um Mudanças | | Plano Agilidade é um termo relativo 9
- 10. JORNADA TÉCNICA DATI Agile O que é desenvolvimento Ágil de software? Processo Evolutivo Iterativo e Incremental Altamente Colaborativo Disciplinado Focado em Qualidade Software potencialmente utilizável é produzido 10
- 11. JORNADA TÉCNICA DATI Agile Princípios Fundamentais Validação e testes contínuos Colaboração consistente do time Rápida resposta a mudanças Envolvimento constante do cliente Entrega frequente de software funcional Melhoria Contínua 11
- 12. JORNADA TÉCNICA DATI Agile Conceitos Chaves Elimine o desperdício Decida o mais tarde possível Entregue o mais rápido possível Dê “autonomia” a equipe Construa com Integridade Visualize o todo 12
- 13. JORNADA TÉCNICA DATI Realidade do Mercado Como posso implantar e escalar Agile? Como saber se meu time realmente é Agil? 13
- 14. JORNADA TÉCNICA DATI Agenda Introdução ASM Fatores de Escala Casos de Sucessos 14
- 15. JORNADA TÉCNICA DATI Agile Scaling Model (ASM) Framework orientado ao contexto da empresa Efetiva Adoção e Adaptação das práticas ágeis de mercado Endereça os 7 principais desafios de se escalar práticas ágeis Dividido em 3 categorias 15
- 16. JORNADA TÉCNICA DATI ASM Ciclo de vida iterativo incremental Times auto gerenciáveis, pequenos e co-alocados Foco na construção Núcleo Ágil Desenvolvimento orientado ao valor Softwares não muito complexos 16
- 17. JORNADA TÉCNICA DATI Núcleo Ágil Scrum 17
- 18. JORNADA TÉCNICA DATI Núcleo Ágil Extreme Programming 18
- 19. JORNADA TÉCNICA DATI Núcleo Ágil Agile Modeling 19
- 20. JORNADA TÉCNICA DATI ASM Ciclo de vida orientado ao risco Entrega Ágil Disciplinada Nível apropriado de governança Núcleo Foco expandido para a Ágil entrega Times auto-gerenciáveis, pequenos e co-alocados 20
- 21. JORNADA TÉCNICA DATI Entrega Ágil Disciplinada DaD 21
- 22. JORNADA TÉCNICA DATI Entrega Ágil Disciplinada OpenUp 22
- 23. JORNADA TÉCNICA DATI Desafios para escalar Agile Cultu Distribuição r a Complexidade Geográfica Organizacional Tamanho dos Ti m e s Requisitos de Conformidade Com Nível de plexi da So dade Governança lução 23
- 24. JORNADA TÉCNICA DATI ASM Entrega disciplinada com um Agilidade em Escala ou mais fatores que se Entrega Ágil aplicam: Grandes times Disciplinada Distribuição geográfica Conformidade a padrões Núcleo Ágil Distribuição organizacional Complexidade técnica Complexidade organizacional Cultura corporativa 24
- 25. JORNADA TÉCNICA DATI Agenda Introdução ASM Fatores de Escala Casos de Sucessos 25
- 26. JORNADA TÉCNICA DATI Fatores de Escala Distribuição Geográfica Projeto precisa estar disponível eletronicamente para que todos tenham acesso Reuniões através de ligações, videoconferências, entre outros Utilizar ferramentas de colaboração para compartilhar as informações Agendar as reuniões considerando a localização das equipes 26
- 27. JORNADA TÉCNICA DATI Fatores de Escala Tamanho do Time O Plano geral do projeto deve refletir os planos das subequipes Cada subequipe é responsável pelo seu próprio planejamento de iteração As equipes precisam estar cientes das dependências entre as listas itens de trabalho 27
- 28. JORNADA TÉCNICA DATI Fatores de Escala Requisitos de Conformidade O plano do projeto e as atualizações deste precisam ser documentados Registro de Atas Distribuição organizacional Planejamento em várias organizações potencialmente levam mais tempo e exigem maior detalhamento 28
- 29. JORNADA TÉCNICA DATI Fatores de Escala Complexidade técnica As equipes precisam estar cientes das dependências técnicas entre os subsistemas As equipes devem se preocupar além da interação vigente 29
- 30. JORNADA TÉCNICA DATI Fatores de Escala Complexidade organizacional Dependências em equipes ágeis não pode exigir mudanças nas estratégias de todas as equipes envolvidas Adicionar coordenadores entre as organizações podem ser exigido Pode ser necessário oferecer treinamentos para ajudar os membros do time a mudar de comando-controle para auto-organização 30
- 31. JORNADA TÉCNICA DATI Fatores de Escala Fatores Restritivos Exemplos de Práticas Praticas de Gerenciamento: Ciclo de vida Valor/Risco ● Times Grandes Praticas relacionadas a requisitos Visão compartilhada – Garante que todos estão empurrando na mesma direção Conduzir o planejamento, requisitos, testes, documentação, design, baseado em ● Distribuição Geográfica cenários “ponta-a-ponta” Praticas de Gerenciamento de Arquitetura Agile Architecture – implementa aspectos chave das aplicações que determinam ● Complexidade da Solução quais são as decisões corretas de arquitetura Design Evolucionário – Comunique e tome decisões efetivamente 31
- 32. JORNADA TÉCNICA DATI DevOps Práticas: Ciclo de vida orientado ao valor e risco Testes independentes em paralelo Previsibilidade da Arquitetura Previsibilidade dos Requisitos Listas de Work Item Governança de desenvolvimento leve 32
- 33. JORNADA TÉCNICA DATI Agenda Introdução ASM Fatores de Escala Casos de Sucessos 33
- 34. JORNADA TÉCNICA DATI Caso de Sucesso de Times ágeis Empresa de médio Porte Aproximadamente 250 funcionários Localizada em duas regiões de minas 34
- 35. JORNADA TÉCNICA DATI Caso de Sucesso de Times ágeis Não existia processo definido Equipe julgava utilizar RUP Varias equipes desenvolviam o mesmo projeto Não conseguiam estipular data de lançamento do produto 35
- 36. JORNADA TÉCNICA DATI Caso de Sucesso de Times ágeis Existia uma equipe de teste As equipes não sabiam o que as outras estavam trabalhando As integrações eram difíceis e desgastantes 36
- 37. JORNADA TÉCNICA DATI Caso de Sucesso de Times ágeis Ações Consulta e Treinamento com Consultor Nomeação de um responsável pelo Processo Utilização do Scrum 37
- 38. JORNADA TÉCNICA DATI Caso de Sucesso de Times ágeis Ações Adoção de Práticas Ágeis Utilização de TDD Realização de Integrações e Entregas Continuas Utilização do Burndown Chart Equipes Releases Feedback 38
- 39. JORNADA TÉCNICA DATI Nem tudo são flores Equipe Com dificuldades de comunicação Indisciplinada Distribuída Falta de padrões Comando e Controle 39
- 40. JORNADA TÉCNICA DATI Solução Equipe DEVOPS Arquitetura Inicial Integração Contínua Testes Contínuos Implantação Contínua 40
- 41. JORNADA TÉCNICA DATI Solução Equipe Definição de Papeis Definir o que é dar a atividade como pronta Adoção de Práticas XP Coaching com a equipe e o responsável pelo processo Alinhamento continuo entre as equipes distribuídas 41
- 42. JORNADA TÉCNICA DATI Resultado Gerente conseguia estipular datas de lançamento dos produtos Cliente via o retorno sobre o seu investimento diretamente Equipes Motivadas Alinhadas Drástica diminuição de BUG Confiança elevada da equipe e do cliente 42
- 43. JORNADA TÉCNICA DATI Caso de Sucesso IBM Necessidade Melhorar a eficiência de suas equipes de desenvolvimento Solução Criação de um processo de desenvolvimento Agile, mais responsivo e colaborativo 43
- 44. JORNADA TÉCNICA DATI Caso de Sucesso IBM Passos Criou um conselho com foco no início: Estórias de usuário Feedback continuo dos interessados no projeto Iterações curtas com tempo limitadas Escolhendo software IBM Rational Team Concert IBM Rational Asset Manager 44
- 45. JORNADA TÉCNICA DATI Caso de Sucesso IBM Resultados IBM economizou mais de 300 milhões de dólares Aumento de produtividade por desenvolvedor em 15% Redução do número de chamadas de suporte Ampliação de Agile em 80% de suas equipes 45
- 46. JORNADA TÉCNICA DATI Dúvidas 46
- 47. JORNADA TÉCNICA DATI Obrigado Neubio Ferreira neubio.ferreira@gmail.com 47
Notas do Editor
- #6 Uma das melhorias é que a utilização dos Processos Ágeis: A utilização desses processos cresce a uma taxa de 22% anual . Hoje representam 9% de todos os projetos de TI e são adotados em 29% do desenvolvimento de novas aplicações. O instituto conclui que o crescimento da taxa de SUCESSO está diretamente relacionado ao aumento da adoção de metodologias ágeis. Modernização : Esses projetos, que entre outros focam na conversão de código/banco de dados, tem taxa de crescimento anual menor do que a dos processo ágeis. Entretanto tem taxa de projetos rotulados como SUCESSO maior. O instituto conclui que isso acontece devido ao mecanicismo desses processos e de um ambiente relativamente mais homogêneo de perfil de profissionais.
- #7 Uma das melhorias é que a utilização dos Processos Ágeis: A utilização desses processos cresce a uma taxa de 22% anual . Hoje representam 9% de todos os projetos de TI e são adotados em 29% do desenvolvimento de novas aplicações. O instituto conclui que o crescimento da taxa de SUCESSO está diretamente relacionado ao aumento da adoção de metodologias ágeis. Modernização : Esses projetos, que entre outros focam na conversão de código/banco de dados, tem taxa de crescimento anual menor do que a dos processo ágeis. Entretanto tem taxa de projetos rotulados como SUCESSO maior. O instituto conclui que isso acontece devido ao mecanicismo desses processos e de um ambiente relativamente mais homogêneo de perfil de profissionais.
- #8 Pacotes Empresariais : O número de novos projetos de implantação de ERP e CRM diminuiu. Como, segundo o instituto, consistem em projetos de grande risco com resultados questionados, a diminuição de novas implantações contribuiu para aumentar a taxa de projetos rotulados como SUCESSO. Projetos de grandes riscos: Complexos, mudam os processos, mexem em toda a organização Questionáveis pois podemos implantar o ERP mas podemos não obter o ROI deste? Assim o sucesso deste é questionável. Processos em Cascata : Consistem nos métodos tradicionais e já representaram quase 50% do número de novas implementações. Como crescem a 1%, sua utilização relativa diminuiu, contribuindo, assim, positivamente para a taxa de SUCESSO.
- #9 Pacotes Empresariais : O número de novos projetos de implantação de ERP e CRM diminuiu. Como, segundo o instituto, consistem em projetos de grande risco com resultados questionados, a diminuição de novas implantações contribuiu para aumentar a taxa de projetos rotulados como SUCESSO. Projetos de grandes riscos: Complexos, mudam os processos, mexem em toda a organização Questionáveis pois podemos implantar o ERP mas podemos não obter o ROI deste? Assim o sucesso deste é questionável. Processos em Cascata : Consistem nos métodos tradicionais e já representaram quase 50% do número de novas implementações. Como crescem a 1%, sua utilização relativa diminuiu, contribuindo, assim, positivamente para a taxa de SUCESSO.
- #10 “ Traditional” methods sat toward the extreme right of these axes: “Agile” methods swung us hard to the left. Both “extremes” present weaknesses that prove problematic when an organization or projects specific context is considered.
- #11 Desenvolvimento ágil de software é um processo evolutivo (iterativo e incremental), altamente colaborativa, exige disciplina, e é focada na qualidade, no qual software potencialmente utilizável é produzido em intervalos regulares...
- #12 Quando trabalhamos “com” Agiles devemos respeitar e colocar em prática seus princípios fundamentais como: Validação e testes contínuos (falar um pouco das práticas que utilizamos aqui como por exemplo TDD) Colaboração consistente do time (o time trabalha em prol de um objeitvo em comum não em objetivos individuais) Rápida resposta a mudanças (requisitos mudam a todo momento e devemos agir de forma rápida e consciente) Envolvimento constante do cliente (falar da importância relacionada ao cliente estar perto e ver o que esta sendo produzido) Entrega frequente de software funcional (falar de ROI, de valor pro cliente) Melhoria Contínua (relacionada aos feedbacks, entre outros)
- #13 Elimine o desperdiço: Elimine qualquer coisa que não agregue valor ao produto e que não são percebidos pelo cliente. Se um programador implementa mais funcionalidades do que o necessário é um desperdiço.Se um time produz funcionalidades incompletas é um desperdiço. O ideal é perceber o que os clientes precisam para então desenvolver e entregar exatamente o que eles querem. Decida o mais tarde possível Praticas de desenvolvimento que asseguram a tomada de decisão tardia são mais eficazes em dominios que envolvem incertezas. O principal conceito deste princípio é diminuir as incertezas retardando as decisões até que possam serem feitas com base em acontecimentos mais firmes, previsíveis e conhecidos. Decisões tardias tendem a ser mais acertadas porque as melhores decisões são feitas baseadas em fatos, e não em suposições ou especulações. A principal estratégia de atrasar as decisões em um desenvolvimento de um sistema complexo é construí-lo com a capacidade de suportar mudanças. Entregue o mais rápido possível Sem entregas rápidas é impossível haver decisões tardias durante o desenvolvimento. Sem entregas rápidas não haverá feedbacks confiáveis no curto prazo. Entregas rápidas garantem que o cliente vai ter o que ele precisa hoje, e não o que ele precisa amanhã. Em uma organização madura em desenvolvimento de software, tudo isso acontece em um fluxo rápido em resposta a uma necessidade dos clientes. Dê “autonomia” a equipe Construir projetos ao redor de indivíduos motivados. Dando a eles o ambiente e suporte necessário, e confiar que farão seu trabalho. " Esse já é um dos doze princípios por atrás do manifesto ágil. A equipe de trabalho deve ter autonomia para adequar seus próprios processos de engenharia, assumir os seus próprios compromissos e reunir as informações necessárias para alcançar seus objetivos e cumprir as suas metas. Não deixando de lado o processo!!! Construa com integridade Qualidade é inegociável. Entregue qualidade intrínseca e explícita aos seus clientes, se eles perceberem isso, significa que foi uma entrega de qualidade. Integridade percebida e integridade conceitual. integridade percebida significa que a totalidade do produto alcança um equilíbrio entre as funções, usabilidade, confiabilidade, economia e isso encanta o cliente. A integridade conceitual significa que os conceitos centrais do sistema de trabalho em conjunto são facilitados e coesos. Essa última é fator crítico de sucesso para a integridade percebida . Um produto possui integridade percebida quando o cliente o experimenta e diz: Isso! Era exatamente isso que eu queria! Software com integridade possui boas arquiteturas, possuem um alto nível de usabilidade e facilidade de uso, são fáceis de dar manutenção, de adaptar e de estender. Visualize o todo Integridade em sistemas complexos exigem um conhecimento holístico e profundo em diversas áreas. Um dos problemas mais intratáveis com o desenvolvimento do produto é que especialistas em qualquer área (por exemplo, banco de dados ou design) têm uma tendência natural em maximizar o desempenho da parte do produto que representa a sua própria especialidade, ao invés de focar no desempenho do sistema como um todo. Muitas vezes, a integridade do produto como um todo pode ser prejudicado se as pessoas atenderem aos seus próprios interesses especializados em primeiro lugar.
- #17 A camada núcleo de desenvolvimento ágil tem o foco na construção do sistema. Neste núcleo as equipes são co-localizadas, auto-gerenciaveis, possuem menos de 10 membros e trabalham de forma altamente colaborativa. É nesta camada que a maior parte das empresas trabalham e ficam estacionadas, ou seja, não conseguem evoluir e muito menos escalar as práticas e métodos ágeis para o restante da organização. Normalmente as equipes que trabalham com métodos ágeis adotam o framework Scrum, adaptando-o e acrescentando outras práticas ágeis como Extreme Programming, Agile Modeling, entre outros. O núcleo de desenvolvimento ágil é caracterizado pelo ciclo de vida baseado em valores onde software potencialmente implantável é produzido. O núcleo de desenvolvimento ágil Lida com uma pequena parte do desenvolvimento do sistema.
- #18 O foco do Núcleo de Desenvolvimento Ágil é a construção. Embora claramente importante, este não é o modelo completo. Abordagens principais concentrar nos fundamentos, e são caracterizadas por ciclos de vida baseada em valores, onde alta qualidade, software potentialmente implantavel é produzido em uma base regular por uma equipe altamente colaborativa e auto-organizada. O foco é nas pequenas equipes (<10 membros) co-localizados.
- #20 Elimine o desperdiço: Elimine qualquer coisa que não agregue valor ao produto e que não são percebidos pelo cliente. Se um programador implementa mais funcionalidades do que o necessário é um desperdiço.Se um time produz funcionalidades incompletas é um desperdiço. O ideal é perceber o que os clientes precisam para então desenvolver e entregar exatamente o que eles querem. Decida o mais tarde possível Praticas de desenvolvimento que asseguram a tomada de decisão tardia são mais eficazes em dominios que envolvem incertezas. O principal conceito deste princípio é diminuir as incertezas retardando as decisões até que possam serem feitas com base em acontecimentos mais firmes, previsíveis e conhecidos. Decisões tardias tendem a ser mais acertadas porque as melhores decisões são feitas baseadas em fatos, e não em suposições ou especulações. A principal estratégia de atrasar as decisões em um desenvolvimento de um sistema complexo é construí-lo com a capacidade de suportar mudanças. Entregue o mais rápido possível Sem entregas rápidas é impossível haver decisões tardias durante o desenvolvimento. Sem entregas rápidas não haverá feedbacks confiáveis no curto prazo. Entregas rápidas garantem que o cliente vai ter o que ele precisa hoje, e não o que ele precisa amanhã. Em uma organização madura em desenvolvimento de software, tudo isso acontece em um fluxo rápido em resposta a uma necessidade dos clientes. Dê “autonomia” a equipe Construir projetos ao redor de indivíduos motivados. Dando a eles o ambiente e suporte necessário, e confiar que farão seu trabalho. &quot; Esse já é um dos doze princípios por atrás do manifesto ágil. A equipe de trabalho deve ter autonomia para adequar seus próprios processos de engenharia, assumir os seus próprios compromissos e reunir as informações necessárias para alcançar seus objetivos e cumprir as suas metas. Não deixando de lado o processo!!! Construa com integridade Qualidade é inegociável. Entregue qualidade intrínseca e explícita aos seus clientes, se eles perceberem isso, significa que foi uma entrega de qualidade. Integridade percebida e integridade conceitual. integridade percebida significa que a totalidade do produto alcança um equilíbrio entre as funções, usabilidade, confiabilidade, economia e isso encanta o cliente. A integridade conceitual significa que os conceitos centrais do sistema de trabalho em conjunto são facilitados e coesos. Essa última é fator crítico de sucesso para a integridade percebida . Um produto possui integridade percebida quando o cliente o experimenta e diz: Isso! Era exatamente isso que eu queria! Software com integridade possui boas arquiteturas, possuem um alto nível de usabilidade e facilidade de uso, são fáceis de dar manutenção, de adaptar e de estender. Visualize o todo Integridade em sistemas complexos exigem um conhecimento holístico e profundo em diversas áreas. Um dos problemas mais intratáveis com o desenvolvimento do produto é que especialistas em qualquer área (por exemplo, banco de dados ou design) têm uma tendência natural em maximizar o desempenho da parte do produto que representa a sua própria especialidade, ao invés de focar no desempenho do sistema como um todo. Muitas vezes, a integridade do produto como um todo pode ser prejudicado se as pessoas atenderem aos seus próprios interesses especializados em primeiro lugar. AM é uma metodologia baseada em um conjunto de melhores práticas para modelagem eficiente e documentação de sistemas de software, organizadas no mapa de melhores práticas da AM. Tais práticas são amplas, abrangendo desde a disciplina de requisitos até atividades de desenvolvimento orientado por testes, passando por arquitetura, participação intensiva de stakeholders, documentação, modelagem de iterações, model storming, entre outros.
- #21 A camada Entrega Ágil Disciplinada aborda todo o ciclo de vida do projeto, desde a criação da visão do projeto ate a entrega deste para o ambiente de produção. Nesta camada normalmente são adotados Metodo de Desenvolvimento dinamico (DSDM) e OpenUP. Esta camada possui uma abordagem iterativa e incremental que produz soluções de alta qualidade. As equipes nesta camada trabalham de forma altamente colaborativa, são auto-organizaveis e trabalham dentro de uma estrutura de governança enxuta, onde as partes interessadas asseguram que a equipe entende e atende as necessidades dos stakeholders. Nesta camada é trabalhada a visão do projeto, seu compartilhamento com toda a equipe, a criação da Lista de Itens, a construção do sistema orientado a valor e a risco, a arquitetura inicial, entre outros. Para abordar o ciclo de vida de entrega total é preciso combinar as práticas de vários métodos fundamentais, e ele aborda todo o ciclo de vida do projeto. Entrega ágil disciplinada aborda o ciclo de vida de entrega total, desde o início do projeto para a produção. Acrescenta governança, magra adequada para equilibrar a auto-organização. Ele adiciona um ponto de vista orientado a risco e valor, a fim de aumentar suas chances de sucesso do projeto. O foco é nas pequenas (<10 membros) equipes co-alocadas desenvolvimento de sistemas simples. EVOLUTIVO: estratégias ágeis são tanto iterativo e incremental na natureza. Iterativo significa que você está trabalhando de forma não-serial, em um determinado dia você pode fazer alguma análise de requisitos, alguns testes, alguma programação, algum desenho, teste um pouco mais, e assim por diante. incremental significa que você adicionar novas funcionalidades e um código de trabalho para o mais recente construir, até o momento em que o interessado determina há bastante valor para liberar o produto. RISCO e VALOR: principais processos ágeis são muito claras sobre a necessidade de produzir valor visível na forma de software, trabalhando em uma base regular durante todo o ciclo de vida. disciplinados os processos de entrega ágeis dar um passo adiante e ativamente mitigar o risco no início o ciclo de vida - durante o projeto iniciar você deve vir a concordância das partes interessadas sobre o escopo do projeto, reduzindo o risco de negócio significativo, e provar a arquitetura através da construção de um esqueleto de trabalho de seu sistema, reduzindo significativamente o risco técnico. Eles também ajudam com a transição para ágil, permitindo que os modelos de financiamento tradicionais para usar essas etapas antes de se mudar para o financiamento iteração mais fina granulação base que permite ágil.
- #22 Entrega ágil disciplinada aborda o ciclo de vida de entrega total, desde o início do projeto para a produção. Acrescenta governança, magra adequada para equilibrar a auto-organização. Ele adiciona um ponto de vista orientado a risco e valor, a fim de aumentar suas chances de sucesso do projeto. O foco é nas pequenas (<10 membros) equipes co-alocadas desenvolvimento de sistemas simples. EVOLUTIVO: estratégias ágeis são tanto iterativo e incremental na natureza. Iterativo significa que você está trabalhando de forma não-serial, em um determinado dia você pode fazer alguma análise de requisitos, alguns testes, alguma programação, algum desenho, teste um pouco mais, e assim por diante. incremental significa que você adicionar novas funcionalidades e um código de trabalho para o mais recente construir, até o momento em que o interessado determina há bastante valor para liberar o produto. RISCO e VALOR: principais processos ágeis são muito claras sobre a necessidade de produzir valor visível na forma de software, trabalhando em uma base regular durante todo o ciclo de vida. disciplinados os processos de entrega ágeis dar um passo adiante e ativamente mitigar o risco no início o ciclo de vida - durante o projeto iniciar você deve vir a concordância das partes interessadas sobre o escopo do projeto, reduzindo o risco de negócio significativo, e provar a arquitetura através da construção de um esqueleto de trabalho de seu sistema, reduzindo significativamente o risco técnico. Eles também ajudam com a transição para ágil, permitindo que os modelos de financiamento tradicionais para usar essas etapas antes de se mudar para o financiamento iteração mais fina granulação base que permite ágil. Disciplinados os processos de entrega ágeis têm ciclos de vida que são de série no grande e no pequeno iterativo. Minimamente eles têm um ritmo de liberação, que reconhece a necessidade de iniciar as atividades / iniciação, atividades de construção, transição e produção. É muito importante notar que estas não são as fases em cascata tradicional - requisitos, análise, projeto, e assim por diante - mas diferentes &quot;estações&quot; de um projeto. O ponto é que precisamos olhar para além do desenvolvimento ágil de software e considerar as complexidades completos de entrega da solução. Adotando um ciclo de vida completo de entrega, e não apenas um ciclo de vida da construção, é sem dúvida o &quot;0&quot; fator de escala ágil . EXPLICAÇÃO DO FRAMEWORK (resumindo) Fase inicial do Projeto: Nesta fase é criado a Lista de Itens. Fase de Elaboração e Construção: Nesta fase ocorre a priorização dos itens da lista tomando como base requisitos que visam a arquitetura, o lançamento inicial do produto e o financiamento para iniciar o projeto. Feito isso a equipe irá selecionar os itens priorizados na lista de itens, quebrá-los em atividades e durante a iteração (que normalmente dura de 2 a 4 semanas) ira construir o projeto. Terminando a iteração a equipe ira demonstrar aos stakeholders e partes interessadas o que foi desenvolvido e logo após, a equipe irá reunir para verificar o que esta certo e o que esta errado em seus processos apontando o que deve ser feito para melhorá-lo. Após estas reuniões o ciclo se repete. É importante destacar aqui que é provável que bugs das iterações anteriores entrem para serem solucionados na próxima iteração. Fase de Transição: Nesta fase ocorre a transição do software produzido para o mercado ou para o cliente. Fase de Produção: Nesta fase muitas equipes ágeis são responsáveis por apoiar as versões existentes dos softwares que estão em operação. Assim as equipes ficam recebendo solicitações de melhoria e ate mesmo relatórios de defeitos. Deste modo esses pedidos podem ser tratados como exigências a serem priorizadas na Lista de Itens, ou dependendo da gravidade devem ser solucionadas imediatamente. É importante ressaltar, que este ciclo de vida é evolutivo, ou seja, ele irá evoluir e seu desenho será modificado. Esta evolução é natural, pois o próprio processo determina a melhoria continua, sem mencionar na maturidade que as equipes irão adquirir.
- #25 Agilidade em escala contém as disciplinas anteriores, com a ressalva de que um ou mais fatores de escala são aplicáveis. É importante reconhecer que o tamanho da equipe é apenas um dos vários problemas que as equipes ágeis enfrentam em grande escala. Os fatores de escala que uma equipe ágil pode enfrentar são: tamanho da equipe, distribuição física, distribuição organizacional, restrições culturais ou organizacionais, complexidade técnica, e as disciplinas da empresa (tais como arquitetura corporativa, a reutilização estratégico e gestão de carteiras). 3.Agility em Escala - Esta categoria concentra-se na entrega ágil disciplinada onde um ou mais fatores de escala são aplicáveis. Os oito fatores de escala são o tamanho da equipe, distribuição geográfica, a conformidade regulatória, a complexidade organizacional, complexidade técnica, distribuição, organização e disciplina da empresa. Todos estes fatores de escala são intervalos, e não todos eles, provavelmente, ser aplicável a um determinado projeto, por isso você precisa ser flexível quando a escala abordagens ágeis para atender às necessidades de sua situação original. Para enfrentar esses fatores de escala você precisará adequar suas práticas disciplinadas de entrega ágeis e em algumas situações adotar um punhado de novas práticas para lidar com os riscos adicionais que você enfrenta em grande escala.
- #32 Resumão O primeiro passo na escala abordagens ágeis é passar de métodos parciais para um verdadeiro processo de entrega, disciplinado ágil. Principais processos de desenvolvimento ágeis e práticas, das quais há muitos, certamente recebeu muita atenção nos últimos anos. Eles motivaram a comunidade de TI para fazer uma pausa e considerar novas formas de trabalhar, e muitas organizações têm adotado e foi bem sucedido com eles. No entanto, essas estratégias tradicionais (como Extreme Programming (XP) ou Scrum, que a ASM se refere como principais estratégias de desenvolvimento ágeis) nunca são suficientes por si sós, como um resultado organizações devem combinar e adaptá-los para lidar com o ciclo de vida de entrega total. Ao fazê-lo nas organizações mais inteligentes também trazer disciplina um pouco mais a tabela, mais ainda do que o exigido pelo núcleo ágil próprios processos, para tratar de governança e risco. O segundo passo para a ampliação ágil é reconhecer o seu grau de complexidade. Um monte de integrar o conselho ágil é orientado para pequenos, co-localizados equipes de desenvolvimento de sistemas relativamente simples. Mas uma vez que seu time cresce, ou torna-se distribuído, ou você está trabalhando em um sistema que não é tão simples, você acha que o conselho popular ágil não funciona tão bem - pelo menos não sem modificação. IBM Rational defende entrega ágil disciplinado como o mínimo que sua organização deve considerar se ele quer ter sucesso com as técnicas ágeis. Você não pode estar lá, no entanto, ainda nos estágios de aprendizagem. Mas a nossa experiência é que você vai descobrir rapidamente como um ou mais dos fatores de escala é aplicável, e como resultado, precisa mudar a maneira de trabalhar. Vamos explorar cada uma das categorias a ASM escala um de cada vez. Mas uma vez que seu time cresce, ou torna-se distribuído, ou você está trabalhando em um sistema que não é tão simples, você acha que o conselho popular ágil não funciona tão bem - pelo menos não sem modificações, por vezes, significativo. Cada um dos fatores de escala introduz seus próprios riscos, e, quando abordada de forma eficaz pode realmente reduzir o risco do projeto, e para sua equipe de projeto para ter sucesso você vai querer identificar os fatores de escala aplicáveis à situação que você enfrenta e agir em conformidade. Infelizmente, isso é muito mais fácil dizer (OK, neste caso um blog sobre) do que fazer
- #33 A idéia básica por trás DevOps é que a sua estratégia de desenvolvimento e estratégia de operações deve reflectir um outro, que você deve se esforçar para otimizar o processo por inteiro. Isto implica que as equipes de desenvolvimento devem trabalhar em estreita colaboração com a equipe de operações para entregar novas versões sem problemas na produção e que a sua equipe de operações deve trabalhar em estreita colaboração com as equipes de desenvolvimento para agilizar as questões de produção críticos. DevOps tem sua origem no desenvolvimento de software ágil, e é uma explícita aspecto da entrega disciplinada Agile (DAD) estrutura do processo. Como resultado, há um conjunto de estratégias de desenvolvimento ágeis que permitem DevOps eficazes em todo o ciclo de vida de entrega ágil. Estas estratégias incluem: Arquitetura Inicial: Disciplinado equipes ágeis também identificar uma estratégia viável de arquitetura que reflete as exigências de seus acionistas e estratégia global da sua organização arquitetônica (daí a necessidade de trabalhar em estreita colaboração com os arquitectos da sua empresa e equipe de operações). Um dos objetivos é garantir que a equipa está a construir (ou comprar) uma solução que vai funcionar bem com a infra-estrutura operacional existente e começar a negociar as alterações de infra-estrutura (tais como implantação de novas tecnologias) no início do projeto. Outra meta é assegurar que as operações orientadas a requisitos são abordados pela arquitetura desde o início. Implantação contínua . Com esta prática você automatizar a promoção de sua solução de trabalho entre os ambientes. Ao automatizar o máximo de esforço de implantação quanto possível, e executando-o muitas vezes, a equipe de desenvolvimento aumenta a chance de uma implantação bem-sucedida e, assim, reduz o risco para o ambiente de operações. Note-se que a implantação em produção, geralmente não é automático, já que esta é uma decisão importante a ser feita por suas operações / gerente lançamento (s Paralela testes independentes . Para classe empresarial de desenvolvimento ou em grande escala, particularmente quando o domínio ou a tecnologia é muito complexa ou em ambientes regulatórios, a equipe ágil disciplinada vai descobrir que eles precisam apoiar seus esforços de teste de toda a equipe com uma equipe de teste independente executado em paralelo com a equipe de desenvolvimento. Esses problemas geralmente incluem teste de validação de requisitos não-funcionais - como a preocupações de segurança, desempenho e disponibilidade - e cerca de integração de sistemas de produção. Todas essas questões são de importância evidente para os departamentos de operações. Contínuo documentação . Com esta documentação prática de apoio, incluindo operações e documentação de suporte, é desenvolvida durante todo o ciclo de vida em harmonia com o desenvolvimento de novas funcionalidades.
- #35 Uma das melhorias é que a utilização dos Processos Ágeis: A utilização desses processos cresce a uma taxa de 22% anual . Hoje representam 9% de todos os projetos de TI e são adotados em 29% do desenvolvimento de novas aplicações. O instituto conclui que o crescimento da taxa de SUCESSO está diretamente relacionado ao aumento da adoção de metodologias ágeis. Modernização : Esses projetos, que entre outros focam na conversão de código/banco de dados, tem taxa de crescimento anual menor do que a dos processo ágeis. Entretanto tem taxa de projetos rotulados como SUCESSO maior. O instituto conclui que isso acontece devido ao mecanicismo desses processos e de um ambiente relativamente mais homogêneo de perfil de profissionais.
- #36 Uma das melhorias é que a utilização dos Processos Ágeis: A utilização desses processos cresce a uma taxa de 22% anual . Hoje representam 9% de todos os projetos de TI e são adotados em 29% do desenvolvimento de novas aplicações. O instituto conclui que o crescimento da taxa de SUCESSO está diretamente relacionado ao aumento da adoção de metodologias ágeis. Modernização : Esses projetos, que entre outros focam na conversão de código/banco de dados, tem taxa de crescimento anual menor do que a dos processo ágeis. Entretanto tem taxa de projetos rotulados como SUCESSO maior. O instituto conclui que isso acontece devido ao mecanicismo desses processos e de um ambiente relativamente mais homogêneo de perfil de profissionais.
- #37 Uma das melhorias é que a utilização dos Processos Ágeis: A utilização desses processos cresce a uma taxa de 22% anual . Hoje representam 9% de todos os projetos de TI e são adotados em 29% do desenvolvimento de novas aplicações. O instituto conclui que o crescimento da taxa de SUCESSO está diretamente relacionado ao aumento da adoção de metodologias ágeis. Modernização : Esses projetos, que entre outros focam na conversão de código/banco de dados, tem taxa de crescimento anual menor do que a dos processo ágeis. Entretanto tem taxa de projetos rotulados como SUCESSO maior. O instituto conclui que isso acontece devido ao mecanicismo desses processos e de um ambiente relativamente mais homogêneo de perfil de profissionais.
- #38 Uma das melhorias é que a utilização dos Processos Ágeis: A utilização desses processos cresce a uma taxa de 22% anual . Hoje representam 9% de todos os projetos de TI e são adotados em 29% do desenvolvimento de novas aplicações. O instituto conclui que o crescimento da taxa de SUCESSO está diretamente relacionado ao aumento da adoção de metodologias ágeis. Modernização : Esses projetos, que entre outros focam na conversão de código/banco de dados, tem taxa de crescimento anual menor do que a dos processo ágeis. Entretanto tem taxa de projetos rotulados como SUCESSO maior. O instituto conclui que isso acontece devido ao mecanicismo desses processos e de um ambiente relativamente mais homogêneo de perfil de profissionais.
- #39 Uma das melhorias é que a utilização dos Processos Ágeis: A utilização desses processos cresce a uma taxa de 22% anual . Hoje representam 9% de todos os projetos de TI e são adotados em 29% do desenvolvimento de novas aplicações. O instituto conclui que o crescimento da taxa de SUCESSO está diretamente relacionado ao aumento da adoção de metodologias ágeis. Modernização : Esses projetos, que entre outros focam na conversão de código/banco de dados, tem taxa de crescimento anual menor do que a dos processo ágeis. Entretanto tem taxa de projetos rotulados como SUCESSO maior. O instituto conclui que isso acontece devido ao mecanicismo desses processos e de um ambiente relativamente mais homogêneo de perfil de profissionais.
- #40 Uma das melhorias é que a utilização dos Processos Ágeis: A utilização desses processos cresce a uma taxa de 22% anual . Hoje representam 9% de todos os projetos de TI e são adotados em 29% do desenvolvimento de novas aplicações. O instituto conclui que o crescimento da taxa de SUCESSO está diretamente relacionado ao aumento da adoção de metodologias ágeis. Modernização : Esses projetos, que entre outros focam na conversão de código/banco de dados, tem taxa de crescimento anual menor do que a dos processo ágeis. Entretanto tem taxa de projetos rotulados como SUCESSO maior. O instituto conclui que isso acontece devido ao mecanicismo desses processos e de um ambiente relativamente mais homogêneo de perfil de profissionais.
- #41 Uma das melhorias é que a utilização dos Processos Ágeis: A utilização desses processos cresce a uma taxa de 22% anual . Hoje representam 9% de todos os projetos de TI e são adotados em 29% do desenvolvimento de novas aplicações. O instituto conclui que o crescimento da taxa de SUCESSO está diretamente relacionado ao aumento da adoção de metodologias ágeis. Modernização : Esses projetos, que entre outros focam na conversão de código/banco de dados, tem taxa de crescimento anual menor do que a dos processo ágeis. Entretanto tem taxa de projetos rotulados como SUCESSO maior. O instituto conclui que isso acontece devido ao mecanicismo desses processos e de um ambiente relativamente mais homogêneo de perfil de profissionais.
- #42 Uma das melhorias é que a utilização dos Processos Ágeis: A utilização desses processos cresce a uma taxa de 22% anual . Hoje representam 9% de todos os projetos de TI e são adotados em 29% do desenvolvimento de novas aplicações. O instituto conclui que o crescimento da taxa de SUCESSO está diretamente relacionado ao aumento da adoção de metodologias ágeis. Modernização : Esses projetos, que entre outros focam na conversão de código/banco de dados, tem taxa de crescimento anual menor do que a dos processo ágeis. Entretanto tem taxa de projetos rotulados como SUCESSO maior. O instituto conclui que isso acontece devido ao mecanicismo desses processos e de um ambiente relativamente mais homogêneo de perfil de profissionais.
- #43 Uma das melhorias é que a utilização dos Processos Ágeis: A utilização desses processos cresce a uma taxa de 22% anual . Hoje representam 9% de todos os projetos de TI e são adotados em 29% do desenvolvimento de novas aplicações. O instituto conclui que o crescimento da taxa de SUCESSO está diretamente relacionado ao aumento da adoção de metodologias ágeis. Modernização : Esses projetos, que entre outros focam na conversão de código/banco de dados, tem taxa de crescimento anual menor do que a dos processo ágeis. Entretanto tem taxa de projetos rotulados como SUCESSO maior. O instituto conclui que isso acontece devido ao mecanicismo desses processos e de um ambiente relativamente mais homogêneo de perfil de profissionais.
- #44 Uma das melhorias é que a utilização dos Processos Ágeis: A utilização desses processos cresce a uma taxa de 22% anual . Hoje representam 9% de todos os projetos de TI e são adotados em 29% do desenvolvimento de novas aplicações. O instituto conclui que o crescimento da taxa de SUCESSO está diretamente relacionado ao aumento da adoção de metodologias ágeis. Modernização : Esses projetos, que entre outros focam na conversão de código/banco de dados, tem taxa de crescimento anual menor do que a dos processo ágeis. Entretanto tem taxa de projetos rotulados como SUCESSO maior. O instituto conclui que isso acontece devido ao mecanicismo desses processos e de um ambiente relativamente mais homogêneo de perfil de profissionais.
- #45 Uma das melhorias é que a utilização dos Processos Ágeis: A utilização desses processos cresce a uma taxa de 22% anual . Hoje representam 9% de todos os projetos de TI e são adotados em 29% do desenvolvimento de novas aplicações. O instituto conclui que o crescimento da taxa de SUCESSO está diretamente relacionado ao aumento da adoção de metodologias ágeis. Modernização : Esses projetos, que entre outros focam na conversão de código/banco de dados, tem taxa de crescimento anual menor do que a dos processo ágeis. Entretanto tem taxa de projetos rotulados como SUCESSO maior. O instituto conclui que isso acontece devido ao mecanicismo desses processos e de um ambiente relativamente mais homogêneo de perfil de profissionais.
- #46 Uma das melhorias é que a utilização dos Processos Ágeis: A utilização desses processos cresce a uma taxa de 22% anual . Hoje representam 9% de todos os projetos de TI e são adotados em 29% do desenvolvimento de novas aplicações. O instituto conclui que o crescimento da taxa de SUCESSO está diretamente relacionado ao aumento da adoção de metodologias ágeis. Modernização : Esses projetos, que entre outros focam na conversão de código/banco de dados, tem taxa de crescimento anual menor do que a dos processo ágeis. Entretanto tem taxa de projetos rotulados como SUCESSO maior. O instituto conclui que isso acontece devido ao mecanicismo desses processos e de um ambiente relativamente mais homogêneo de perfil de profissionais.
- #47 Uma das melhorias é que a utilização dos Processos Ágeis: A utilização desses processos cresce a uma taxa de 22% anual . Hoje representam 9% de todos os projetos de TI e são adotados em 29% do desenvolvimento de novas aplicações. O instituto conclui que o crescimento da taxa de SUCESSO está diretamente relacionado ao aumento da adoção de metodologias ágeis. Modernização : Esses projetos, que entre outros focam na conversão de código/banco de dados, tem taxa de crescimento anual menor do que a dos processo ágeis. Entretanto tem taxa de projetos rotulados como SUCESSO maior. O instituto conclui que isso acontece devido ao mecanicismo desses processos e de um ambiente relativamente mais homogêneo de perfil de profissionais.
- #48 Uma das melhorias é que a utilização dos Processos Ágeis: A utilização desses processos cresce a uma taxa de 22% anual . Hoje representam 9% de todos os projetos de TI e são adotados em 29% do desenvolvimento de novas aplicações. O instituto conclui que o crescimento da taxa de SUCESSO está diretamente relacionado ao aumento da adoção de metodologias ágeis. Modernização : Esses projetos, que entre outros focam na conversão de código/banco de dados, tem taxa de crescimento anual menor do que a dos processo ágeis. Entretanto tem taxa de projetos rotulados como SUCESSO maior. O instituto conclui que isso acontece devido ao mecanicismo desses processos e de um ambiente relativamente mais homogêneo de perfil de profissionais.