Your SlideShare is downloading. ×
0
Agile Scaling Model - TDC 2012 - São Paulo SP
Agile Scaling Model - TDC 2012 - São Paulo SP
Agile Scaling Model - TDC 2012 - São Paulo SP
Agile Scaling Model - TDC 2012 - São Paulo SP
Agile Scaling Model - TDC 2012 - São Paulo SP
Agile Scaling Model - TDC 2012 - São Paulo SP
Agile Scaling Model - TDC 2012 - São Paulo SP
Agile Scaling Model - TDC 2012 - São Paulo SP
Agile Scaling Model - TDC 2012 - São Paulo SP
Agile Scaling Model - TDC 2012 - São Paulo SP
Agile Scaling Model - TDC 2012 - São Paulo SP
Agile Scaling Model - TDC 2012 - São Paulo SP
Agile Scaling Model - TDC 2012 - São Paulo SP
Agile Scaling Model - TDC 2012 - São Paulo SP
Agile Scaling Model - TDC 2012 - São Paulo SP
Agile Scaling Model - TDC 2012 - São Paulo SP
Agile Scaling Model - TDC 2012 - São Paulo SP
Agile Scaling Model - TDC 2012 - São Paulo SP
Agile Scaling Model - TDC 2012 - São Paulo SP
Agile Scaling Model - TDC 2012 - São Paulo SP
Agile Scaling Model - TDC 2012 - São Paulo SP
Agile Scaling Model - TDC 2012 - São Paulo SP
Agile Scaling Model - TDC 2012 - São Paulo SP
Agile Scaling Model - TDC 2012 - São Paulo SP
Agile Scaling Model - TDC 2012 - São Paulo SP
Agile Scaling Model - TDC 2012 - São Paulo SP
Agile Scaling Model - TDC 2012 - São Paulo SP
Agile Scaling Model - TDC 2012 - São Paulo SP
Agile Scaling Model - TDC 2012 - São Paulo SP
Agile Scaling Model - TDC 2012 - São Paulo SP
Agile Scaling Model - TDC 2012 - São Paulo SP
Agile Scaling Model - TDC 2012 - São Paulo SP
Agile Scaling Model - TDC 2012 - São Paulo SP
Agile Scaling Model - TDC 2012 - São Paulo SP
Agile Scaling Model - TDC 2012 - São Paulo SP
Agile Scaling Model - TDC 2012 - São Paulo SP
Agile Scaling Model - TDC 2012 - São Paulo SP
Agile Scaling Model - TDC 2012 - São Paulo SP
Agile Scaling Model - TDC 2012 - São Paulo SP
Agile Scaling Model - TDC 2012 - São Paulo SP
Agile Scaling Model - TDC 2012 - São Paulo SP
Agile Scaling Model - TDC 2012 - São Paulo SP
Agile Scaling Model - TDC 2012 - São Paulo SP
Agile Scaling Model - TDC 2012 - São Paulo SP
Agile Scaling Model - TDC 2012 - São Paulo SP
Agile Scaling Model - TDC 2012 - São Paulo SP
Agile Scaling Model - TDC 2012 - São Paulo SP
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Agile Scaling Model - TDC 2012 - São Paulo SP

565

Published on

Modelo para escalar agile em toda a organização. Este modelo foi criado pela IBM e se chama Agile Scaling Model. Com a adoção deste modelo a IBM economizou 300 milhões de dólares e aumentou a …

Modelo para escalar agile em toda a organização. Este modelo foi criado pela IBM e se chama Agile Scaling Model. Com a adoção deste modelo a IBM economizou 300 milhões de dólares e aumentou a produtividade de cada um de seus desenvolvedores em 15%.

Published in: Technology
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
565
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
0
Comments
0
Likes
2
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide
  • 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. " 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 "estações" 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 "0"  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.
  • Transcript

    • 1. JORNADA TÉCNICA DA TI Agile Scaling ModelPalestrante: Neubio Ferreira
    • 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
    • 4. JORNADA TÉCNICA DA TI Chaos Report - Standish Group 4
    • 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 Group3º 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 AgilePrincí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
    • 17. JORNADA TÉCNICA DA TI Núcleo ÁgilScrum 17
    • 18. JORNADA TÉCNICA DA TI Núcleo ÁgilExtremeProgramming 18
    • 19. JORNADA TÉCNICA DA TI Núcleo ÁgilAgileModeling 19
    • 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
    • 21. JORNADA TÉCNICA DA TI Entrega Ágil DisciplinadaDaD 21
    • 22. JORNADA TÉCNICA DA TI Entrega Ágil DisciplinadaOpenUp 22
    • 23. JORNADA TÉCNICA DA TI Desafios para escalar Agile CultuDistribuição r a ComplexidadeGeográfica OrganizacionalTamanho dosTi m e s Requisitos de Conformidade ComNível de plexi da So dadeGovernanç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 floresEquipe 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
    • 46. JORNADA TÉCNICA DA TI Dúvidas 46
    • 47. JORNADA TÉCNICA DA TI Obrigado Neubio Ferreira  neubio.ferreira@gmail.com 47

    ×