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.
2. JORNADA TÉCNICA DA TI
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 DA TI
Agenda
Introdução
ASM
Fatores de Escala
Casos de Sucessos
3
5. JORNADA TÉCNICA DA TI
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 DA TI
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 DA TI
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 DA TI
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 DA TI
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 DA TI
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 DA TI
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 DA TI
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 DA TI
Realidade do Mercado
Como posso implantar e escalar Agile?
Como saber se meu time realmente é Agil?
13
14. JORNADA TÉCNICA DA TI
Agenda
Introdução
ASM
Fatores de Escala
Casos de Sucessos
14
15. JORNADA TÉCNICA DA TI
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 DA TI
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
20. JORNADA TÉCNICA DA TI
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
23. JORNADA TÉCNICA DA TI
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 DA TI
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 DA TI
Agenda
Introdução
ASM
Fatores de Escala
Casos de Sucessos
25
26. JORNADA TÉCNICA DA TI
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 DA TI
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 DA TI
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 DA TI
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 DA TI
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 DA TI
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 DA TI
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 DA TI
Agenda
Introdução
ASM
Fatores de Escala
Casos de Sucessos
33
34. JORNADA TÉCNICA DA TI
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 DA TI
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 DA TI
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 DA TI
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 DA TI
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 DA TI
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 DA TI
Solução
Equipe
DEVOPS
Arquitetura Inicial
Integração Contínua
Testes Contínuos
Implantação Contínua
40
41. JORNADA TÉCNICA DA TI
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 DA TI
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 DA TI
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 DA TI
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 DA TI
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
47. JORNADA TÉCNICA DA TI
Obrigado
Neubio Ferreira
neubio.ferreira@gmail.com
47
Notes de l'éditeur
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.
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.
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.
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.
“ 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.
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...
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)
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.
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.
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.
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.
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.
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.
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.
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
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.