Estilos de Arquitetura e Separação de Responsabilidades para um Design Ágil

Com a grande demanda de profissionais por parte das empresas, muitos deles acabam sendo contratados sem ter o devido conhecimento sobre boas práticas de desenvolvimento de software, infraestrutura de desenvolvimento, protocolos de comunicação, sistemas gerenciadores de banco de dados e muitas vezes até conhecimento básico sobre sistemas operacionais.

Além disso, dentro das empresas existe uma demanda cada vez maior por projetos de software de alta complexidade, com prazos de entrega na maioria das vezes fora da realidade. O que faz com que muitos projetos sejam entregues sem testes, com falhas de implementação, qualidade duvidosa e muitas vezes sem atender ao negócio do cliente.

Como consequência, após implantado, o sistema passa a apresentar sérios problemas como degradação da performance, perda de dados, cálculos incorretos, entre outros problemas, trazendo grandes prejuízos à empresa e fazendo com que os usuários percam a confiança no sistema e por fim os próprios desenvolvedores.

Direcionado para este cenário, o presente artigo visa demonstrar boas práticas de desenvolvimento de software e explicar os princípios fundamentais para se criar um bom design. Veremos também a aplicação de alguns padrões de projeto pouco difundidos, mas que são de extrema importância no dia a dia do desenvolvedor.

Estilos de Arquitetura

Quando vamos planejar o desenvolvimento de um software, geralmente um dos primeiros itens que o arquiteto de software começa a analisar é qual o melhor estilo de arquitetura que se aplica ao
contexto do projeto. Neste ponto ele leva em consideração diversos fatores, como os requisitos do software, custo, infraestrutura e conhecimento técnico da equipe.

Entender o estilo arquitetural adotado para o desenvolvimento traz diversos benefícios para os desenvolvedores e para a empresa como um todo, entre eles: fornecer uma linguagem comum entre os desenvolvedores e os demais envolvidos no projeto.

Por exemplo, quando o estilo de arquitetura é SOA, os desenvolvedores podem até conversar com pessoas de outras áreas, que não possuem conhecimento técnico (como detalhes da linguagem de programação, servidores de aplicação, etc.), sobre o método envolvido na automação dos processos de negócio, que as mesmas entenderão sobre o que é um serviço, governança e, dependendo do usuário, até termos mais específicos, como escalabilidade.

A Tabela 1 apresenta um resumo dos principais estilos de arquitetura.

Estilo de Arquitetura	Descrição
Client-Server	Também conhecida como arquitetura de duas camadas. Este tipo de arquitetura descreve a interação entre um ou mais clientes e um servidor, através de uma conexão de rede. A aplicação mais comum para esse tipo de arquitetura é um Banco de Dados no lado do servidor com a lógica da aplicação representada em Stored Procedures, e o lado do Cliente representado por aplicações conhecidas como Fat-Clients (Clientes Pesados), que muitas vezes contêm a lógica de negócio embutida no front-end. Como exemplo, podemos citar aplicações desenvolvidas com Delphi, Visual Basic, Oracle Forms, entre outros.
Arquitetura baseada em Componentes	Quando utilizamos uma arquitetura baseada em componentes, decompomos o design da aplicação em componentes lógicos com um fraco acoplamento, de forma que cada um deles seja individual e reutilizável, com uma localização transparente e interface de comunicação bem definida. Uma das grandes vantagens desse tipo de arquitetura é que ela promove a reusabilidade dos componentes e facilita a manutenção da aplicação.
Domain Driven Design	De acordo com o próprio criador, Eric Evans, DDD não é uma tecnologia e nem uma metodologia. DDD é um estilo de arquitetura orientado a objetos, focado em modelar o domínio do negócio e a lógica do domínio com o uso de técnicas, práticas e padrões de projeto.
Arquitetura em Camadas	Esse é o estilo de arquitetura mais conhecido e mais utilizado para o desenvolvimento de aplicações. Ele permite a separação dos módulos do sistema em camadas (layers) diferentes. As principais vantagens desse estilo são a facilidade de manutenção, o aumento da extensibilidade, reusabilidade e escalabilidade.
3-Tiers/N-Tiers	Esse estilo segrega as funcionalidades em segmentos separados de maneira similar ao estilo da arquitetura em camadas, mas com cada segmento alocado em camadas físicas (tiers) separadas, conforme veremos em detalhes no tópico “Arquitetura Distribuída”.  Ele é ideal quando o projeto demanda escalabilidade. Para isso, as camadas lógicas (layers) da aplicação são alocadas em máquinas diferentes.  Geralmente, ao mapear as camadas lógicas (layers) para as físicas (tiers), podemos criar um cluster ou um farm na mesma camada física para aumentar a performance e a confiabilidade da aplicação.
Arquitetura Orientada a Serviços(SOA)	SOA já deixou de ser apenas uma palavra no meio de TI para se tornar um modelo consagrado adotado em muitas empresas. Uma arquitetura orientada a serviços nada mais é do que uma aplicação que expõe e consome as funcionalidades do sistema como serviços por meio de contratos e mensagens.  Algumas das características de uma Arquitetura Orientada a Serviços são: a independência da Plataforma, comunicação baseada em serviços entre os componentes de software, integração de múltiplas funcionalidades em um único componente de interface do usuário e a exposição dos serviços por meio de repositórios ou catálogos.
Arquitetura Orientada a Objetos	Ao aplicar esse estilo, o sistema é dividido em objetos individuais, reutilizáveis e autossuficientes. Cada objeto contém os dados e o comportamento pelos quais é responsável. Uma arquitetura orientada a objetos geralmente busca espelhar objetos do mundo real de modo a tornar simples a modelagem da aplicação.

Tabela 1. Estilos de Arquitetura.

Cluster: É um conjunto de computadores interligados que trabalham em conjunto como se fosse um único computador. Estes computadores são utilizados para suportar aplicações que têm necessidade de alta disponibilidade e alta capacidade de processamento.
Farm: Um Servidor Farm, também conhecido como Data Center, é um conjunto de servidores mantido (geralmente) por uma empresa para atender as necessidades computacionais da corporação, como o processamento de grandes volumes de informação, atender aos sistemas corporativos e prover servidores de contingência no caso de um problema no computador principal.
Repositório: Um Repositório é um local onde todos os clientes de um domínio específico publicam seus serviços, de maneira que todos os usuários passam a conhecer os serviços disponíveis e como acessá-los.
Para tanto, um repositório deve ter uma interface bem definida para publicação dos serviços, funções para localização, controle e maneira uniforme de acesso.

Uma vez que o estilo de arquitetura é definido, o passo seguinte é definir como as funcionalidades do sistema serão divididas, de forma a manter em conjunto os componentes relacionados (alta
coesão), e fazer com que estes possuam o mínimo de conhecimento sobre os outros componentes (baixo acoplamento). Para alcançar o baixo acoplamento e uma alta coesão é importante entender o conceito de Separação de Responsabilidades.


Separação de Responsabilidades (Separation of Concerns)

O termo Separação de Responsabilidades foi criado pelo pai do algoritmo de caminho mínimo, o cientista Edsger W. Dijkstra em 1974, e tem como objetivo dividir a aplicação em funcionalidade distintas com a menor similaridade possível entre elas. Para aplicar com sucesso este princípio, o mais importante é minimizar os pontos de interação para obter alta coesão e baixo acoplamento entre os componentes do sistema. Para tanto, é recomendado, primeiro dividir suas responsabilidades e organizá-las em elementos bem definidos, sem repetição de código ou de funcionalidade.

O tipo de separação de conceito mais difundido é o da separação horizontal, onde dividimos a aplicação em camadas lógicas de funcionalidades, como por exemplo, o protocolo TCP/IP (modelo OSI), que é separado pelas camadas de aplicação, transporte, rede, enlace e física. Neste modelo, cada camada tem sua própria responsabilidade e não precisa conhecer as camadas adjacentes. Voltando ao nosso mundo, em uma aplicação Java EE, as camadas mais conhecidas são a de Apresentação, Serviço, Domínio e Infraestrutura, como ilustra a Figura 1.

Figura 1. Separação Horizontal de Conceitos (Camadas lógicas de uma aplicação).

Podemos também aplicar o tipo de separação vertical, onde dividimos a aplicação em módulos ou funcionalidades que são relacionadas a um subsistema ou grupo de operações dentro de um sistema.
Veja um exemplo na Figura 2.

Figura 2. Separação Vertical de Conceitos.

Separar as funcionalidades de uma aplicação em módulos deixa claro as responsabilidades e dependências de cada funcionalidade, o que ajuda na execução dos testes e na manutenção do
software. Na Figura 2 fazemos um agrupamento por módulos; neste caso a separação foi feita pelos módulos de RH, Contábil e Marketing.

Além disso, podemos utilizar o conceito de separação vertical em conjunto com o conceito de separação horizontal. Veja um exemplo na Figura 3.

Figura 3. Aplicação da Separação de Conceitos Vertical e Horizontal.

Um papel importante da separação de conceitos é o da separação de comportamento, que envolve a divisão dos processos do sistema em unidades lógicas de código reutilizáveis e gerenciáveis. Ao organizar o comportamento, alcançamos os seguintes benefícios:

• Eliminamos a duplicação de funcionalidades;
• Minimizamos as dependências externas;
• Maximizamos o potencial para reuso;
• Restringimos o escopo do trabalho para os limites de cada módulo.

Como vimos, é importante entender a separação de conceitos pois ao modelarmos uma aplicação devemos ter conhecimento das responsabilidades de cada um de seus componentes. Além disso, devemos ter uma ideia de como será feita esta separação e como será feita a distribuição destes componentes na arquitetura disponível pelo cliente.

Para tanto, é preciso levar em consideração outros fatores, como infraestrutura e recursos disponíveis, conforme veremos a seguir, no próximo artigo da série.

Referências

Excelente artigo sobre separação de responsabilidades
http://www.aspiringcraftsman.com/2008/01/art-of-separation-of-concerns/

Biografia de Edsger Dijkstra.
http://pt.wikipedia.org/wiki/Edsger_Dijkstra

Guia de Arquitetura de Aplicações da Microsoft.
http://www.codeplex.com/AppArchGuide

Continuous Delivery, DevOps e Innovation Games na UFSCar

Ano passado, tive a oportunidade de palestrar em eventos importantes como o TDC 2011 em São Paulo, organizado pela Globalcode e no aniversário de 10 anos do evento É Dia de Java, realizado na Faculdade Federal de São Carlos (UFSCar), organizado pelo SOUJava.

Ainda no TDC, participei do painel "O que vem depois do Agile?" com nomes bem conhecidos pela comunidade Ágil. Publiquei um post recentemente sobre o Painel e uma palestra sobre DataGrid e NoSQL com JBoss Infinispan, que em breve publicarei aqui.

O evento É Dia de Java 2011 foi muito especial, primeiro porque foi a celebração de 10 anos do evento, e também porque pude reencontrar grandes amigos como André Fonseca, Vinícius Senger da Globalcode, Fabio Velloso e Bruno Souza do SOUJava e ter a satisfação de conhecer o grande Daniel Wildt.

O evento foi bem bacana, na sexta feira o dia foi reservado para a realizacao de Workshops praticos, no meu caso, fiz um workshop de Innovation Games, uma aborgagem lúdica inovadora criada por Luke Hohmann, para auxílio na criação de produtos, condução de retrospectivas e análise de problemas.

Realizei com a turma, jogos como Product Box, Remember the Future, Speed Boat e como plus (não é um Innovation Game), fizemos uma retrospectiva utilizando a técnica dos 06 Chapéus do Pensamento.

Abaixo uma das Product Box criada por um dos grupos.

No dia seguinte, foram várias palestras, sem falar que o evento estava lotado.

Minha palestra foi sobre Continuous Delivery e DevOps, o feedback foi muito bom, e várias pessoas solicitaram os slides. Sendo assim, aqui está.

Continuous Delivery e DevOps

View more presentations from wrsantos

Parabéns as pessoas que organizaram e participaram do evento na UFSCar e a Globalcode pelo excelente TDC. Esse ano se Deus quiser tem mais.

* Crédito ao pessoal da OCTO por alguns dos slides sobre Integração Contínua.

Diversão Garantida!!!

Continuous Delivery: Case de Sucesso com tecnologias .NET - Deploy em 7000 máquinas com apenas 3 cliques

Em um recente artigo, Maxence Modelin discute de maneira bem detalhada, como a OCTO Technology, criou um fluxo de implantação (Deployment Pipeline), onde com apenas 3 cliques, o deploy de um serviço Windows é feito em 7000 máquinas, de um fornecedor de serviços de hosting, localizado na França.

 A solução descrita, cujo foco envolve o deploy de um serviço Windows, desenvolvido em C#, que se comunica via FTPS com um servidor Java.

Uma caracteristica importante da solução, é o uso de uma plataforma de Integração Contínua baseado em ferramentas open-source, bem populares na comunidade Java, ao invés do uso do Team Foundation Server fornecido pela Microsoft.

Entre as tecnologias utilizadas para Integração Contínua, podemos destacar Jenkins como Servidor de Integração Contínua, Maven para gestão do projeto e Nexus para a gestão do repositório.

Para administração do farm de servidores, foi utilizado o software OCS Inventory. Um aplicativo web, responsável por centralizar todas as informações pelos Agentes OCS instalado em cada um servidores do farm. Que por sua vez, através das informações recebidas, efetua o deploy dos pacotes necessários nos servidores, sem a necessidade de uma ação do usuário.

Para monitoração do ambiente, foi utilizado Zabbix.

A cadeia de entrega contínua, se resume a apenas 3 cliques, onde o primeiro deles, começa com a operação de commit no SVN, que inicia o processo de integração contínua orquestrado pelo Jenkins. Que após efetuar o checkout do projeto, executa o script do Maven, que efetua o build, executa os testes, e por fim, armazena os artefatos gerados no Nexus.

O segundo clique, é para criação do pacote OCS, onde um profissional de operações (ops), executa um script shell, que extrai o artifato do Nexus e disponibiliza o pacote pronto para deploy no banco de dados do OCS.

Para o terceiro clique, no contexto da empresa, este último passo é considerado um passo funcional, e não existe razão de ser automático. Quem decide quais máquinas irão receber os pacotes, são os profissionais de operações, através do OCS. Os desenvolvedores tem o mesmo acesso, porém, para fazer o deploy em ambiente de testes.

Para assegurar que tudo ocorreu corretamente, operações utiliza duas ferramentas para feedback, que são o próprio OCS e Zabbix, e um usuário fake. Este usuário fake, é responsável por efetuar o download dos pacotes nas máquinas destino, e verificar se tudo ocorreu conforme o esperado.

A figura a seguir, descreve os softwares e ações realizadas durante o fluxo de implantação.

Um dos fatores imprescendíveis para o sucesso da Implantação Contínua, foi a abordagem DevOps dada ao projeto. Esta abordagem abriu a oportunidade para um compartilhamento das necessidades e visão entre os times de Desenvolvimento e Operações.

Pois com a responsabilidade do deployment a cargo do time de desenvolvimento, ao invés do time de operações, talvez eles nunca teriam a real noção do trabalho realizado.

E você, tem alguma estória de sucesso sobre implementações de Continuous Delivery e DevOps? Comente, discuta, colabore!

Nota: O artigo que o texto destaca é um pouco antigo, mas como esse post era para ser uma notícia na InfoQ Brasil no ano passado, mas como não foi aprovado então resolvi publicar aqui. Espero que curtam! Pois o case foi bem interessante, por se tratar de um case de Continuous Delivery para um aplicativo .NET, utilizando ferramentas open source Java.

Jez Humble on Continuous Delivery and DevOps

In the last year, during the period i have been in France, attending Université du SI, one of the best conferences i've participate in whole life (sponsored by OCTO Technology), i had the privilege of being invited to participate in a very interesting course with Jez Humble,  about Continuous Delivery for DevOps.
After the course, i could make an interview for InfoQ Brazil, but for obvious reasons we translated it to Brazilian Portuguese. And now, here goes the original version. Enjoy!

You wrote a best seller, called Continuous Delivery, What is it all about?

It's about all the stuff that is normally considered somewhat peripheral to software development - configuration, build and deployment management, automated testing, continuous integration, infrastructure and database management. However the discovery that many of us made while working on large agile projects was that this stuff is essential if you want to be able to reliably, repeatably release high quality software.

Actually many of the ideas in the book aren't new. It's really a call to arms to focus on the engineering practices that were always at the heart of agile methodologies, but that somehow got sidelined in many places over the last ten years. Of course several tools like Puppet, Chef, Git and DbDeploy have emerged that didn't exist ten years ago that make much of this stuff much more tractable.

It turns out that the engineering practices - particularly automation of build, test, deployment, and database and infrastructure management - and collaboration between development, testing and operations - are really essential to be able to get high quality software delivered fast. And that, in turn, is central to the ability of organizations to innovate and get new features out of the door quickly and reliably.

What practices do you think are more important?

For developers, you need to start with continuous integration. That doesn't mean installing a CI server and pointing it at your feature branches - it means making sure everyone merges regularly into mainline (and yes, that applies to Git too). In order for CI to be useful, you need automated tests, in particular at the unit and acceptance level. Having a comprehensive, maintainable set of unit tests is almost impossible without doing TDD. Creating maintainable acceptance tests requires close collaboration between developers and testers. Finally, you need to validate every build to ensure it's production ready, which means having the ability to spin up production-like testing environments on demand and run realistic loads against your system. This requires automated provisioning of environments and infrastructure, and automated deployment of your system, including any database changes. All of this needs to be implemented within the context of the deployment pipeline.

These kinds of changes need to be made incrementally, by finding out where the constraints are in your delivery process and removing them one by one. That in turn requires close collaboration between developers, testers and the operations department. More on that later.

We have seen, that some people make some confusion about the term Continuous Delivery, can you explain to us, what's the difference between Continuous Delivery and Continuous Deployment?

Continuous delivery means you can release on demand. I should be able to release the latest good build at the press of a button without having to worry that it's going to break. But when you release is a business decision. Continuous deployment means you actually go ahead and release every good build. Obviously that only really applies in the context of websites or software-as-a-service. But if you can't actually do continuous deployment and release every good build for some reason - say you're working on a user-installed product - you should at the very least be putting every good build into a production-like environment and running realistic acceptance and performance tests against it so that there are no surprises when you come to release it. You can do that on embedded systems, products, pretty much anything that involves software.

Organizations that could in principle do continuous deployment really should aim to. One of the key benefits is organizational. Continuous deployment makes developers care much more about the quality and reliability of what they're doing because if they can push a button to make their changes go live, it connects them with what's going on in production. And it makes the business focus much less on stuffing features into a release when they know they can create some small feature, have it in production in a couple of days' time, and get real feedback on whether it's valuable and whether more effort should be put into it. It is a complete paradigm shift in the way organizations work and they become much more responsive to their customers. Eric Ries writes more about this in his forthcoming book, The Lean Startup

Can you explain to us, the term DevOps, and what that means?

DevOps is kind of an anti-movement, by which I mean it has resisted attempts to pin it down. But fundamentally it's about putting a strong focus on collaboration between everybody involved in software delivery - in particular, developers, testers and operations - and sharing knowledge and techniques between them. Infrastructure-as-code is one example of knowledge sharing - the application of agile techniques such as refactoring and test-driven development to evolving your infrastructure. DevOps is essential to achieve continuous delivery.

Part of the reason people in the movement have resisted (for example) creating a manifesto is to prevent vendors (in particular tool vendors) from appropriating it and trying to own it. Often people are guilty of reaching for tools (even within the movement - myself included) when actually it's the attitude and mindset that makes you successful. That's not to say the tools aren't important - they are. Tools that can't be managed in an automated fashion through an API are especially unpopular within the community.

How do you implement DevOps?

One really good way to start is to get representatives from every part of the organization involved in delivery - development, testing, infrastructure, operations, product management - to get together regularly and have retrospectives to reflect on how to incrementally improve things. In many organizations, you never see people from every department in a meeting together. It just doesn't happen.

Another way to get going is for everyone involved in delivering software celebrate successful releases together. Really implementing DevOps is about change that works up from the people on the ground - it's hard to mandate it. That's one of the reasons senior management has a hard time with it. But it's also the secret sauce - incremental, bottom-up change is usually the most effective and long-lasting.

What skills related to Infrastructure a modern developer should have? And why it is important? Does it make sense, for companies that are not in the cloud?

I think the key element is that infrastructure provisioning and management has to be automated. It should be possible to plug a new server (or workstation) in - power and network - and bring it into the correct state, configure it, and deploy to it in a fully automated fashion. You can do that whether or not you're in the cloud. In fact ThoughtWorks recently did some consulting to automate hardware provisioning and management for one of the cloud vendors. Under the hood, "the cloud" of course runs on real hardware and the same principles apply.


For great companies, that has already an Operation Department, what a developer can do to decrease this gap between devs and ops?

First of all, get to know your operations department. Make friends with them. Invite them along to your retrospectives and showcases. Learn the tools they use. Help them build new ones. Read books like Release It! that talk about how to create production-ready software. Check out the screens they have up that show off production metrics. Get the same screens put up in development rooms (LCD panels are cheap these days). Ask to help out when releases happen. Get involved.


Can you talk about your job at ThoughtWorks?

I'm working on a number of things. On the one hand I am doing a lot of travelling at the moment, going to conferences and talking to our customers. I'm also doing some research and writing, including working on a series of interviews to create some videos about continuous delivery. Finally I'm doing some consulting work to make sure I keep my feet on the ground and stay in touch with the latest developments in the space, and of course to pay my way.

------------------------------------------------

Jez Humble is a Principal at ThoughtWorks Studios, and author of Continuous Delivery, published in Martin Fowler’s Signature Series (Addison Wesley, 2010). He has worked with a variety of platforms and technologies, consulting for non-profits, telecoms, financial services, and online retail companies. His focus is on helping organisations deliver valuable, high-quality software frequently and reliably through implementing effective engineering practices.

[Painel TDC2011] O que vem depois do Agile?

No ano passado, tive o privilégio de participar do TDC 2011, um evento super massa concebido pela Globalcode,  que contou com o o apoio de grandes nomese empresas da Indústria de Software.
Participei de um painel bem bacana, mediado pelos meus amigos Felipe Rodrigues da Crafters, e Victor Hugo Germano.
O tema da discussão foi O que vem depois do Agile?
Segue a descrição oficial.

A adoção da agilidade tem crescido muito no mercado brasileiro e cada vez mais grandes empresas tem aderido ao seu uso. Isso aumenta sua visibilidade, mas também vai exigindo adaptações nem sempre fáceis ou bem recebidas pela comunidade.
A grande pergunta que surge é: Qual é o próximo passo? O que vem depois do Agile?

Abaixo segue o vídeo do painel

TDC2011 SP - Painel (O que vem depois do Agile) - Domingo, 10 de Julho from Globalcode on Vimeo.

Princípios, Padrões e Práticas para um Design Ágil na Java Magazine - Parte 3

Em Janeiro, saiu a terceira e última parte do meu artigo Princípios, Padrões e Práticas para um Design Ágil na revista Java Magazine edição 86.
Na primeira e segunda parte desta série de artigos, publicados nas Edições 80 e 81, abordamos sobre fundamentos de arquitetura de software, padrões de projetos em uma arquitetura distribuída, analisamos como identificar sintomas de um software mal planejado, e como refatorar a sua aplicação para utilizar boas práticas de desenvolvimento OO.

Na última parte desta série, vamos analisar a fundo como funciona um Projeto XP, passando por todas as suas fases, e veremos também como adotar as práticas de engenharia da Extreme Programming para construir um software aplicando as melhores práticas de desenvolvimento OO

utilizando TDD e testes de aceitação.

Abordaremos os valores destas metodologias através do Manifesto Ágil, apresentando de maneira

clara como estes valores estão presentes na Extreme Programming. Analisaremos também, como a Arquitetura do Software é tratada em um projeto ágil e como algumas práticas do XP auxiliam na criação e evolução da Arquitetura. 

Por fim, é apresentado um estudo de caso onde implementaremos uma funcionalidade em um sistema fictício, mostrando desde a escrita da estória pelo cliente até sua implementação utilizando testes de aceite com o framework FitNesse e TDD.

Academia Agile - Do Coaching ao Kanban

 Muitos já sabem que a Globalcode em conjunto com a Fratech  está lançando a Academia do Agile, uma carreira com a carga horária de 108 horas, e composta por 8  cursos que abordam todos os aspectos necessários para formar um profissional ágil.

Código	Nome do curso	Carga Horária	Apostila Demo
AG1	Implantando e liderando equipes Ágeis	12 hs
AG2	Criação de produtos com Requisitos Ágeis	12 hs
AG3	Otimizando a Comunicação através de DDD	12 hs
AG4	Modelagem Ágil de Software	12 hs
AG5	Práticas Ágeis de Engenharia de Software com XP	24 hs
AG6	Gestão de projetos com Scrum	12 hs
AG7	Gestão de processos com Kanban e Lean	12 hs
AG8	Estratégia Ágil para Governança em TI	12 hs
	Resumo da carreira Academia do Agile	108 hs

Serei um dos revisores do material e para as próximas turmas um dos instrutores desta Academia, mas o que posso garantir é que o material foi feito pelos maiores especialistas na área, meus amigos Felipe Rodrigues da Fratech e Manoel Pimentel editor chefe da revista Visão Ágil.

A primeira turma está com 25% de desconto, pelo preço é uma ótima pedida para quem quer conhecer a fundo as disciplinas do Agile.

Segue alguns dos temas que irá rolar em cada módulo.

AG1- Implantando e liderando equipes Ágeis

• Facilitação
• O que é facilitação
• Abordagem cognitiva para facilitar mudanças
• Um breve passeio pela mente humana
• Estimulando a Neuroplasticidade
• Compreensão do Sistema Límbico
• Técnicas de Facilitação durante as atividades Agile
• Os Seis Chapéus do Pensamento
• Feedback efetivo através da janela de JOHARI
• O Que? Para que? E como causar a mudança com a TOC(Theory of Constraints)
• O desenvolvimento da confiança entre indivíduo
• Planejamento de eventos de facilitação
• Coaching
• Objetivo do Coaching
• Desfazendo mitos acerca do Coaching
• Papéis no processo de Coaching
• Condição Humana
• Missão e Ideal
• Valores e Crenças
• Consciência e Responsabilidade
• Perguntas Eficazes para gerar mudanças
• Motivação (verdades e mentiras)
• Vencendo o Inner Game
• FFA (Force Field Analysis)
• Ganhos e Perdas
• Modelo FARM
• Modelo GROW
• House of Change
• Estrutura das sessões de Coaching
• Liderança
• Gestão do tempo para gerar ROE
• Empatia
• Técnica Pomodoro
• GTD - Getting Things Done
• Covey Planning
• Liderança baseada em Coaching
• Coaching para Equipes
• O Coaching num ambiente Ágil
• O que fazer com impedimentos?
• Projeto de aplicação prática de Coaching

AG2 - Criação de produtos com Requisitos Ágeis

• Definição de escopo
• O produto do ponto de vista de negócio
• As dimensões do escopo (Tamanho, simplicidade e aderência.)
• Processo de aprendizado de escopo
• Estado Lean para o desenho de software
• Requisitos ágeis e os casos de usos?
• User Stories
• Modelando Papéis
• Representando desejos com User Story
• Formato para User Story
• O modelo INVEST
• Usando Temas e Épicos
• Features segundo o FDD
• Representando desejos com Features
• O modelo ARO (Ação Resultado Objeto)
• Aplicando a FBS (Feature Breakdown Structure) da FDD (Feature Driven Development)
• Usando Áreas e Atividades
• Priorização por Áreas, Atividades ou Temas
• Definindo o modelo de Entrega
• Estratégia de entrega em alto nível
• Critérios de Aceitação em diferentes níveis
• DoD (Definition of Done) em diferentes níveis
• Monitoramento de resultados
• Aplicando a TOC na engenharia de requisitos
• Documentação pós-projeto

AG3 - Otimizando a Comunicação através de DDD

• Introdução ao Domain Driven Design
• Sinergia entre Domain Driven Design e os princípios Ágeis
• Uma Linguagem Unificada e abrangente
• Visão Arquitetural do Domain Driven Design
• Arquitetura em Camadas
• Objetos de negócio com Domain Objects
• Ciclo de vida dos Domain Objects
• Mantendo um domínio flexível com Supple Design
• Práticas de suporte
• Refactoring em busca de aprofundamento
• Integrando vários domínios com Strategic Desing
• Delimitando os contextos
• Integração entre contextos diferentes
• Estratégias de integração

AG4 - Modelagem Ágil de Software

• Introdução à Modelagem de software
• Modelagem no contexto da agilidade
• Ciclos de modelagem ágil
• Modelagem em equipe
• Visualização do modelo
• Diagramas simples e práticos com Agile Draw
• Modelagem Ágil e UML
• Resultados da modelagem ágil
• Entregáveis

AG5 - Práticas Ágeis de Engenharia de Software com XP

• Introdução ao Extreme Programming
• Modelo cíclico de entrega
• Ciclo PDCA
• Test Driven Development
• O modelo Test First
• Modelando através dos testes
• Relação custo-benefício dos testes
• Behavior Driven Development
• Especificação executável com BDD
• Casos de negócio
• Ferramentas de BDD
• Relatórios de BDD
• Integração Contínua
• Processo de desenvolvimento com integração contínua
• Repositórios de código fonte
• Integração contínua e os testes
• Servidores de integração contínua
• Principios importantes
• Inspeção
• Pair-Programming
• Inspeção segundo o FDD
• A Inspeção e a Definição de Pronto

AG6 - Gestão de projetos com Scrum

• Abordagens Ágeis
• Imergindo no Scrum
• Conhecendo as fases e ciclo de vida do Scrum
• A FDD (Feature Driven Development) e como combiná-la com o Scrum
• Entendendo a influência Lean
• Engenharia de Requisitos para compor um bom Product Backlog
• FBS (Feature Breakdown Structure) da FDD
• Compondo o Product BackLog com funcionalidades
• Planejamento
• Os papeis do Scrum
• O conceito de Sprint
• Entregas freqüentes de valor para o cliente
• Gerenciando Business Value
• Sprint Planning Meeting
• Desdobramento em tarefas
• Características do Sprint BackLog
• Estimativas
• Apostando no Planning Poker
• Descobrindo a complexidade
• Conhecendo o tamanho das coisas
• Trabalhando com estimativas em horas
• Qual a granularidade necessária para as estimativas
• Desenvolvimento
• Scrum Daily Meeting
• Gestão de Impedimentos
• Métricas e Acompanhamentos
• Foco no Escopo ? Entrega de software funcionado
• KanBan para facilitar a comunicação durante o processo
• Conhecendo o BurnDown Chart
• Entregas
• Sprint Review
• Testes de Aceitação
• Melhoria contínua
• Sprint Retrospective
• Uma breve introdução em TOC (Theory Of Constraints) para o Processo de Mudança 
• Imersão
• Durante todo o workshop será realizado um laboratório prático através da dinâmica de construção.

AG7 - Gestão de processos com Kanban e Lean

• Cultura e Filosofia Lean
• O que é Lean
• Pensamento Enxuto
• Impactos econômicos do pensamento enxuto
• Tipos de cenários para o pensamento Lean
• Perspectiva de Consumo
• Geração de Valor
• Eliminação das Perdas
• Respeito e Desenvolvimento de Pessoas
• Ferramentas Lean
• Hansei e Kaizen para melhoria contínua
• Poka-Yoke e Jidoka para ajudar a qualidade
• Andon e Kanban como meio de comunicação
• Gestão Lean
• Planejamento e Gestão com pensamento A3
• WIP (Work-In-Process)
• Pull System
• Visualizando o VSM - Value Stream Map
• O que é Lead Time?
• Identificando Restrições
• Resolução de Problemas com The Five Whys
• Aplicando o clico PDCA
• Definindo demanda
• Definindo tamanho
• Definindo capacidade
• Usando o sistema Kanban
• Adoção
• Aplicação em equipes de projetos
• Aplicações de equipes de sustentação
• Lean/Kanban com Scrum

AG8 - Estratégia Ágil para Governança em TI

• Visão Geral do Ecossistema
• Pessoas
• Processos
• Práticas
• Ferramentas
• Parceiros
• Filosofia e Cultura
• Missão, Valores e Propósito
• Introdução ao Enterprise Agile
• Agile Project Management
• Enterprise Scrum
• Engenharia de Software com FDD
• Lean/KanBan para gestão de processos
• Definindo escopo de atuação para Agile
• Planejamento de adoção/implementação de Agile
• Framework de TI
• Gestão de Demandas
• Gestão de Portfólio
• Gestão de Configuração
• Gestão de Mudanças
• Gestão de Serviço de TI
• Planejamento Estratégico
• Gestão Financeira
• Geração de Conhecimento
• Integrações
• Dialogando com ITIL e COBIT
• Gestão Ágil em ambientes PMBoK
• Agile com modelos de certificação
• Convivendo com processos auditáveis por órgãos reguladores

Pelo conteúdo apresentado acima, é fácil entender o porque este curso é a formação mais completa que existe sobre agilidade não só no Brasil, mas talvez no mundo, abordando temas como DDD, FDD, BDD, TDD, Lean, Kanban, XP, Scrum, passando por Coaching, e Governança em TI.

A primeira turma começa agora dia 26/03, as aulas serão intercaladas de 15 em 15 dias com aulas ás sextas e sábados. Nos vemos por lá!

Diversão Garantida!!! 

Perguntas Frequentes sobre Agilidade

Em Julho deste ano, após o mini-curso que dei na Globalcode sobre Scrum + XP, uma das pessoas presentes, meu amigo Orlando, anotou diversas perguntas sobre Agilidade no formato de entrevista e pediu que eu respondesse por email.
Segue abaixo algumas perguntas que achei interessante, e resolvi publicá-las aqui no blog.

O que é ser ágil nos dias de hoje?

Acho que ser ágil nos dias de hoje é saber aproveitar as oportunidades de inovação no seu ambiente de trabalho, percebo que a maioria das pessoas acabam ficando acostumadas com a rotina de seus afazeres e perdem chances de inovar.
Quando digo inovar, digo que existem várias maneiras de você introduzir no seu dia a dia práticas ágeis. Outro ponto importante em ambiente ágeis é a comunicação, para ser ágil a pessoa saber lidar com pessoas, com o cliente, e ter um relacionamento de parceria, não pode ter medo de se expor e ser comprometido.
Comprometido não é trabalhar 250 horas por mês no projeto, é saber assumir responsabilidades e saber responder por elas, não ter vergonha de pedir ajuda na hora de uma dificuldade. É velha a história do porco e da galinha =).

Quais os pontos fracos das metodologias ágeis?

O que vejo como um ponto fraco em metodologias ágeis, pela sua própria natureza lean, ou seja, enxuta. É que fica um pouco difícil a sua adoção em ambientes que haja modelos de governança de TI como o Cobit, por exemplo. É difícil em um ambiente de Governança "certificado", você justificar para o gerenciamento de projeto o uso apenas de quadros e post-its, entende? Isso eu digo principalmente com Scrum e XP.
Neste tipo de cenário, a empresa tende a escolher modelos híbridos baseados no PMBook e RUP. O que no final acabam se tornando processos altamente burocráticos em cascata.
Por isso, que acho que esse é um campo que tem muito a ser explorado, trabalhei cerca de 2 a 3 com RUP, e uma escolha mal feita nos artefatos de projeto acaba comprometendo e muito o rendimento da equipe
Outro ponto fraco é o próprio agilista, que tende a pensar que é o dono da razão, pois a verdade é que Barry Boehm já falava da importância dos métodos iterativos (  que vieram bem antes do movimento ágil ).

Quando não usar?

Bem, independente do lugar que você esteja é muito importante praticar, aplicar os valores do Manifesto Ágil.
Eu não consigo enxergar o uso de métodos ágeis em projetos de implantação de ERP (pacote comprado), principalmente quando a implantação é feita em grandes empresas com diversas filiais. Geralmente, as empresas fornecedoras deste tipo de software já possuem métodos próprios.
Outra ponto, é se a sua empresa desenvolve software e seu cliente esta feliz, o desenvolvedor esta feliz, os projetos estão sendo entregues no prazo, o ROI esta dentro das expectativas, o Time-to-market do seu produto é baixo e a equipe é produtiva, se neste cenário você já não estiver usando ágil, fique onde está.
Se o seu processo de desenvolvimento esta atendendo plenamente você e seus clientes, então não mude. Você já esta no caminho certo.

O que mais dificulta a implantação de uma metodologia ágil numa empresa atualmente?

Com certeza o que dificulta a implantação de métodos ágeis nas empresas é a própria filosofia de desenvolvimento da empresa. Por requerer uma mudança radical na forma de lidar com o desenvolvimento de software, é difícil alcançar uma plenitude na implementação de métodos ágeis e isto pode afetar sua adoção, é difícil as pessoas envolvidas na definição de processos da empresa admitirem que estavam fazendo algo que é não muito produtivo, e que a maneira que elas desenvolvendo software não é a melhor.
Outros pontos que dificultam a implantação de métodos ágeis, ainda alinhado ao primeiro item é a falta de um sponsor, como um diretor, ou outro cargo executivo, se agile não está "vendido" para a alta cúpula da empresa, então pode haver muita resistência por conta da própria TI.
E por fim, a falta de comprometimento da equipe e a falta de conhecimento em métodos ágeis podem dificultar também a implantação.

Só serve para projetos? E a manutenção do sistema?

Agile proporciona um leque bem variado de métodos, entre eles FDD, Scrum, XP, Lean, Crystal, entre outros. Eu diria que os dois caminham juntos, a questão gira em torno de como você irá administrar e classificar os itens em seu backlog.
A partir do momento que um release do seu produto entra em produção, é natural que novas demandas e até bugs apareçam. Tem empresas que separam equipes para atuar somente em projetos de manutenção e outras equipes para trabalhar somente em projetos de evolução, depende tudo de como o trabalho é priorizado.
Para áreas de serviço, como Infraestrutura, onde a atuação das equipes geralmente é feita sob demanda, é recomendado o uso de quadros Kanban, inclusive atualmente estou fazendo um trabalho neste sentido (Quadros Kanban para áreas de Infraestrutura).

E a arquitetura do sistema, como fica?

Essa é uma questão polêmica e que gera muitas dúvidas para quem está iniciando no mundo ágil, principalmente para as pessoas que estão em transição de um método como o Waterfall para o Ágil.
Quando o time de desenvolvimento vem do Waterfall ou até mesmo do RUP, que é um método que descreve os artefatos necessários para se documentar a arquitetura do projeto e propõe um modelo "big design up front", ou seja, força o time tentar imaginar e fechar todos os modelos no inicio da execução do projeto.
Em processos ágeis isso acontece de forma natural e evolutiva, uma das práticas do XP, o "Simple Design" ou "Design Simples" nos diz para mantermos o nosso design o mais limpo e simples possível, e não tentar imaginar funcionalidades que o sistema possa vir a ter, e preparar o sistema para estes prováveis cenários. Isso foge completamente do modelo ágil de gerir projetos.
Independente do modelo que você segue, o seu sistema obviamente será construída baseada em uma arquitetura, e em toda metodologia é muito importante você fazer o planejamento da sua arquitetura, a diferença é que em métodos ágeis devemos sempre respeitar a maturidade atual do projeto de modo que quando houver mudanças ou adição de novos requisitos do negócio, fique fácil refatorar o sistema, levando sempre em consideração os requisitos de qualidade de serviço (QoS) conhecidos por todo arquiteto,

Como fica o contrato? Não há prejuízos para a produtora, uma vez que o cliente altere constantemente o que foi inicialmente solicitado?

Acredito que não, um dos valores do manifesto ágil diz que a colaboração com o cliente é mais importante do que a negociação de contratos, por que isso? Se olharmos para a maneira como as empresas negociam os contratos de software com as consultorias, veremos que esta é uma eterna luta. Porque as empresas adotam o modelo de "Preço Fixo" e para uma consultoria entrar em uma empresa, ao formular uma RFP ela acaba colocando valores que muitas vezes ela mesma sabe que pode tomar um prejuízo, mas o faz para ganhar o cliente.
Este tipo de contrato é ruim, pois passa a maior parte do risco para o desenvolvedor, se o projeto atrasa, o consultor arca com os custos, o que dificulta (e muito) mudanças de escopo.
Um modelo de contrato que achei muito interessante é o modelo "Money for Nothing, Changes for free" proposto por Peter Stevens em http://agilesoftwaredevelopment.com/blog/peterstev/10-agile-contracts#MFN-cff.

Qual o maior benefício (a longo ou curto prazo) que um funcionário (desenvolvedor, tester, analista, etc.) obtém quando se compromete a seguir uma proposta ágil?

Desenvolvedores geralmente gostam de agile, porque os métodos são voltados para times auto-gerenciáveis. Modelos ágeis dão uma liberdade maior aos membros do time, então acho que o maior benefício é o próprio bem-estar do time. Sem falar dos ganhos da empresa como a melhoria contínua da qualidade, redução do risco de entrega e do time to market, aumento da visibilidade do projeto, entre outros.

Como ser um Scrum Master?

Na minha visão, para ser um Scrum Master é preciso antes de tudo saber lidar com pessoas, isso é fundamental, além disso, precisa ser uma pessoa comprometida e responsável, que entenda os requisitos do negócio e as necessidades do time.
Tem que ser uma pessoa humilde, e que saiba influenciar a equipe de maneira positiva, com uma cultura de colaboração.

Como as empresas do Brasil estão aceitando a XP?

Hoje em dia é moda falar de Agilidade no Brasil, principalmente no meio dos desenvolvedores. O que vejo é que é um assunto muito falado, mas pouco aplicado.
XP tem sido assunto em roda de conversa de desenvolvedores durante muitos anos, e o que acaba sendo feito neste sentido são movimentos individuais de desenvolvedores que aplicam algumas práticas do XP de maneira isolada, principalmente TDD.
Com o advento e a popularidade do SCRUM, pessoas de outras esferas nas empresas estão começando a olhar agile de maneira diferente, e tem havido uma grande aceitação neste sentido, então acho que isso tem sido bom para XP também.

Dê algumas dicas de boas práticas àqueles que estão iniciando (estagiários e estudantes).

A melhor dica que posso dar é a mesma que dou em minhas apresentações quando sou indagado. Que é estudar, e tentar se manter bem informado sobre o que está acontecendo no mercado. É impressionante o que você consegue fazer com os feeds dos websites, busque os melhores sites e agregue-os em ferramentas como o Google Reader ou outro leitor de feed qualquer, isso potencializa muito o conhecimento.
Participe de lista de discussões, veja cases de implantação tanto de sucesso quando de insucesso e buscar ler o máximo que puder sobre o assunto.

Finalize com uma mensagem para aqueles que estão interessados, mas ainda são céticos.

Faça uma prova de conceito, e se possível procure implementar ao menos uma prática ágil. Uma dica que dou é sempre que possível, traga o cliente para o lado do desenvolvimento, se você puder fazer com que seu cliente avalie o produto que você está desenvolvendo semanalmente ou até de 15 em 15 dias, você irá começar a ver os ganhos do desenvolvimento ágil.
Ou ainda, vou ir totalmente contra o que acabei de falar, sempre que olhar para o seu processo atual de desenvolvimento, antes de tentar adicionar qualquer prática ou passo novo (menos a que citei sobre o cliente), exclua uma etapa do seu processo. Monte um gráfico de cadeia de valor dos seus processos, e analise o que você pode excluir de passos do seu processo. Se você fizer isso, você já está no caminho de se tornar um grande agilista!

Scrum + XP = Agilidade eXtrema

Nos dias 07 e 28 de Julho foi realizado no auditório da Globalcode o minicurso Scrum + XP = Agilidade eXtrema, gostaria de agradecer a Globalcode pelo espaço concedido e pela força e também a todos que compareceram, pelo ótimo feedback que recebi.

Para maiores detalhes de como foi o mini-curso acesse o seguinte link no site da Globalcode.

Na apresentação, o intuito foi dar um enfoque teórico e prático de como funciona o Gerenciamento de Projetos Ágeis utilizando XP e Scrum, e no final uma explicação de como combinar as duas.

O que acabou agregando bastante a apresentação foi o próprio público, que iteragiu bastante, com perguntas sobre planejamento e estimativas em projetos ágeis. Foi apresentado alguns técnicas para "vender" Agile em um ambiente corporativo. Conversamos bastante sobre o papel de uma equipe de testes, como escrever os testes de aceite e unitário dentro do TDD, Refactoring, Integração Contínua, priorização dos itens de backlog, User Stories, Débito Técnico, enfim.. três horas pareceu pouco =)


Conforme solicitado pelos colegas, segue a apresentação.

Scrum + XP na prática

Ainda durante a apresentação, demonstrei um vídeo bem engraçado intitulado "O Alpinista", onde fiz uma analogia de um alpinista com gerentes de projeto.. momento bacana para quebrar um pouco o gelo. Segue abaixo o vídeo.



Bom, é isso aí pessoal, obrigado mais uma vez !!!

Scrum + XP = Diversão Garantida !!!

XP - Extreme Programming - Embrace Change Summary

As you may already know, XP is a lightweight methodology created by Kent Beck, for small-to-medium-sized teams developing software in the face of vague or rapidly changing requirements.

To help the understand of the basis, i'm providing a summary and a mind map of the book eXtreme Programming - Embrace Change, by Kent Beck, as you can see below. Enjoy it!

Figure 1: Extreme Programming Mind Map

XP - Embrace Change is a small book, quite fast and easy to read, it took me only two days to finish it.
As Kent Beck said "XP is a philosophy of software development based on the values of communication, feedback, simplicity, courage, and respect."

The Basic Problem

Software development fails to deliver, and fails to deliver value. This failure behind software development has a huge economic and human impact. So it was the reason to find ways to develop software.

First recognize risks and try to address it applying some XP practices, like short release cycles to limit scope, one to four week iterations of features requests from customer, it will give you a fine-grained feedback about progress.
Economics of Software Development

Create a strategy for maximizing the economic value of the project, spending less, earning more (depends strategy), spending later and earning sooner, increase probability that the project will stay alive.

In projects we have to control five variables: cost, time, quality and scope, like PMBoK scope is the best way to achieve control. KEEP FOCUS ON SCOPE.
Cost of Change

The cost of changing a program rises exponentially over time. Figura 2 shows that the longer it takes you to find a defect then on average the more expensive it is to address.

Figure 2 - Cost of Change [Scott W. Ambler, 2006]

To overtake problems related to cost of change, after years of production some factors became clear like a simple design, intensive use of automated tests, refactoring code and design, incremental design, continuous integration.
Learning to drive.

Everything in software changes. requirements, design, business, technology, team members change. The problem
isn't change, the problem, rather, is the inability to cope with change when it comes.

Learn to control the development of software by making many small adjustments, not by making a few large adjustments, kind of like driving a car.


The driver of a software project is the customer. If the software doesn't do what they want it to do,
you have failed. Of course, they don't know exactly what the software should do. That's why
software development is like steering, not like getting the car pointed straight down the road. Our
job as programmers is to give the customer a steering wheel and give them feedback about
exactly where we are on the road.

XP Values

• Communication: Ensured an effective comunication of your team and your organization core values.
• Simplicity: Search for simple solutions.
• Feedback: Work with your customers at your side, seat the team together.
• Courage: Throw code possible whenever itŽs possible (keeping your code simple). Courage to change, to assume your faults.

PUT ALL THESE VALUES IN PRACTICE.

The Four Basic Activities

• Coding: Code is the one artifact that development absolutely cannot live without, it gives you a chance to communicate clearly and concisely.
• Testing: Writing every test you can imagine.
• Listening: Learn to listen your customer, he knows about the business not you.
• Designing: Good design ensures that every piece of logic in the system has one and only one home.

Figure 3 - XP Overview.

The Practices

Primary Practices
------------------------
-Integration

• Ten minute build: Automatically build the whole system and run all of the tests in ten minutes.
• Continuous integration: Integrate and test changes after no more than a couple of hours.

-Whole Team: Create cross-functional teams. Create a team with all the skills necessary for the project to succeed.
-Programming

• Test-First Programming: [TDD] Test -> Code -> Refactor
• Incremental Design: Keep the design investment in proportion to the needs of the system.
• Pair Programming: Help to:

1. Keep each other on task.
2. Brainstorm refinements to the system.
3. Clarify ideas.
4. Lower frustration.
5. Hold each other accountable

-Energized Work: Take care and respect yourself.

-Planning

• Weekly Cycle: Plan work a week at a time, have meeting at the beginning of every week. During meetings, review progress, ask your customer to pick some stories to implement and break stories into tasks.
• Monthly Cycle: Plan work quarter at a time, Identify bottlenecks, Initiate repairs, Plan the theme, pick the stories.
• Stories: Write the stories on index cards and put them on a wall.
• Slack: Include some minor tasks that can be dropped if you get behind in your plan.

The Planning Game:

1. List the items of work that may need to be done.
2. Estimate the items.
3. Set a budget for the planning cycle.
4. Agree on the work that needs to be done within the budget. As you negotiate, don't change the estimates or the budget.

Corollary Practices
--------------------------

-Business Negociated Scope Contract: Try a sequence of short contracts instead of one long one.

• Pay-per-use: Charge for every time the system is used.
• Daily Deployment: Put new software into production every night.

-Incremental Deployment: Find a little piece of functionality and deploy it.
-Programming

• Single Code Base: Keep only one code stream.
• Code & Tests: Mantain Code and tests as permanent artifacts.
• Shared Code: Anyone on the team can improve any part of the system at any time.

-Root Cause Analysis: Eliminate defect and its cause. To find the Root cause, apply Taiichi Ohno's exercise, called "Five Whys":

• Why did we miss this defect?
• Why didn't we know?
• Why isn't she part of the team?
• Why doesn't anyone else know how?
• Why isn't it a management priority?

-Real Customer Involvement: Put your customer at your side.
-Team

• Team Continuity: Keep effective teams together.
• Shrinking Teams: Lean Thinking, reduce the size.

If you like it, buy the book here..