Domain Driven Design 1

Recentemente comecei a estudar mais a fundo UML e me foi apresentada a técnica de Domain Driven Design de Eric Evans, que vem a combinar a linguagem de domínio com a linguagem de programação, ajudando a criação da documentação UML e uma codificação mais voltada as expectativas do cliente.

Para tanto, fiz umas pesquisas e encontrei o Livro: Domain Driven Design Quickly na InfoQ:

http://www.infoq.com/minibooks/domain-driven-design-quickly

Com base no que li no livro fiz uma serie de resumos por capítulos, que visam explicar do que se tratam DDD e como podemos utilizar dessa técnica para entregar um software de qualidade e de fácil manutenção.

CAPITULO 1

Domain Driven Design combina práticas de projeto (analise) e desenvolvimento, e nos mostra como o design (documentação) e desenvolvimento podem trabalhar juntos para criar um melhor software. Um bom design vai acelerar o desenvolvimento, enquanto o feedback vindo do processo de desenvolvimento irá melhorar o design.

Nós não podemos apenas sentar e começar a codificar. Até podemos fazer isto, e até que funciona bem para casos triviais. Mas não podemos criar um software complexo com essa metodologia.

É possível criar um software bancário complexo sem um bom conhecimento de domínio (regra de negócio)? De jeito nenhum. Nunca.

Quem é que sabe como o software bancário deve funcionar? O arquiteto de software? Não, ele só usa o banco para manter seu dinheiro seguro e disponível. O analista de software? Não. Ele até que sabe analisar um determinado tema, quando lhe é dado a ele todos os ingredientes necessários. O desenvolvedor? Nem pensar. Quem, então? O sistema bancário é muito bem compreendido pelas pessoas que trabalham no banco, por seus especialistas. Eles sabem de todos os detalhes, todos os possíveis problemas, todas as regras de negocio. É por eles que devemos sempre começar. Eles são detentores do domínio.

Existem dois grandes tipos de diferentes abordagens para o desenvolvimento de software. Um deles é o método waterfall. Este método envolve uma série de etapas. Primeiramente os especialistas em negócios recolhem um conjunto de requisitos que são passados aos analistas de negócios. Os analistas criam um modelo com base nesses requisitos, e passam a documentação para os desenvolvedores, que começam a codificação com base no que eles receberam. É um fluxo contínuo de trabalho. Embora esta tenha sido uma abordagem tradicional em design de software, e tem sido usado com certo nível de sucesso ao longo dos anos, ele tem seus defeitos e limites. O principal problema é que não há feedback dos analistas para os especialistas em negócios ou dos desenvolvedores para os analistas.

Outra abordagem é a utilização de metodologias ágeis, como Scrum. Estas metodologias são um movimento coletivo contra a abordagem waterfall, decorrente das dificuldades de reunir todos os requisitos do software, considerando que normalmente ocorrem mudanças destes requisitos. A realidade é de que é difícil criar um modelo completo que abranja todos os aspectos de um domínio inicialmente. Normalmente um design possuiu diversas regras de negócios, e dificilmente irá prever alguns dos efeitos colaterais negativos ou erros que podem surgir durante o projeto.

Outro problema os métodos ágeis tentam solucionar é a chamada "analysis paralysis", que acontece quando membros da equipe ficam com tanto medo de tomar qualquer decisão de design que eles acabam não fazem nenhum progresso. Embora os defensores ágeis reconheçam a importância da definição de design, não ficam presos ao design inicial. Em vez disso, eles empregam uma grande flexibilidade nas implementações, e através do desenvolvimento iterativo com a participação contínua das partes interessadas do negócio e bastante refatoração de código, a equipe de desenvolvimento começa a aprender mais sobre a regra de negocio e poderá produzir um software que melhor atenda às necessidades dos clientes.

Os métodos ágeis também têm seus problemas e limitações, eles defendem a simplicidade, mas como todo mundo tem sua própria visão de simplicidade pode acabar numa documentação desatualizada. Em razão disto, uma a refatoração contínua feita pelos desenvolvedores sem um design sólido e atualizado irá produzir um código que é difícil de compreender e dar manutenção.

O modelo de Design será moldado durante as entrevistas iniciais de analise com base nas respostas coletadas. Assim acabarão surgindo conceitos essenciais do domínio do sistema a ser desenvolvido. Esses conceitos poderão aparecer de forma desorganizada, mas mesmo assim são essenciais para a compreensão da regra de negocio. Devemos aprender o máximo possível sobre o domínio com os especialistas nas entrevistas. Fazendo as perguntas certas para poder processar a informação da maneira correta para começar a criação modelo de domínio. Este modelo não será completo nem definitivo, mas já é o começo que precisamos.

Os especialistas conhecem bem sua área de atuação, e conseguem organizar e utilizar seus conhecimentos de uma maneira específica para realizar o seu trabalho, entretanto não sabem a melhor maneira a ser implementada em um software. A mente analítica do designer de software deverá desvendar alguns dos conceitos chave do domínio durante as entrevistas com especialistas de domínio, e assim construir uma estrutura que norteará futuras discussões.

Entendendo as métricas e indicadores para desenvolvimento LEAN

Quando utilizamos uma metodologia de trabalho LEAN com base no Kanban dividimos o trabalho em pequenas etapas, como, por exemplo, em um processo de desenvolvimento de softwares temos as etapas de Backlog (aprovação e documentação), Desenvolvimento, Teste Solicitante, Teste Suporte, Publicação, Finalizar (manualizar e comunicar clientes).

Adotar métricas e indicadores é uma medida eficaz para que as equipes possam entregar software em menor tempo e com melhor desempenho para seus clientes. Existem diversas métricas que serão explicadas na tabela abaixo. Estes indicadores são feitos para times que utilizam o Kanban como ferramenta para gerenciar o seu processo de desenvolvimento.

Além de que, o Kanban em si só já ajuda a limitar e monitorar o trabalho em progresso e consequentemente aumentando a qualidade e a velocidade de entrega do software.

METRICA	DESCRIÇÃO	VALOR AGREGADO	MEDIÇÃO
Inicio ao Fim Lead Time	Da data de registro da ideia até o final do processo de desenvolvimento incluindo tempo que o projeto ficou trancado	Prove uma visão inteira do tempo que demora um projeto desde o tempo de sua concepção até a entrega para o usuário	Desempenho Histórico
Entrega Lead Time	Tempo que o software ficou desde o registro do backlog até a conclusão	Permite a empresa ter uma data de entrega precisa para cada tipo de solicitação	Promessa de Entrega
Processo Cycle Time	Registra o tempo em cada etapa do quadro Kanban	Permite identificar gargalos e verificar as causas de demora de entrega de software	Melhoria de Processo
Solicitações	Verifica o numero de solicitações sendo desenvolvidas durante o mês	Prove uma visão da quantidade de pedidos sendo feitos pelos clientes	Lançamento de versões
Entregas	Numero de entregas de desenvolvimentos realizados por mês	Fornece dados a respeito da quantidade de entrega de novos softwares aos clientes	Lançamento de versões
Capacidade de Trabalho	Quantidade de processos sendo realizados por cada equipe	Quantificar os limites das raias baseados com o trabalho realizado pelas equipes	Métrica de Performance
Acerto de Previsao	Percentual de desenvolvimentos que foram realizados dentro do prazo previsto / orçado	Identifica qual parte do processo precisa ser revista e se está faltando alguma fase do processo	Métrica de Performance
Tempo de Correção	Quantidade de horas gastas resolvendo um erro ou um problema de negocio que impede um trabalho de ser completado	Prove uma visão interna a respeito de quanto um defeito / erro está interferindo nas atividades	Métrica de Performance Melhoria de Processo
Erros Encontrados	Quantidade de idas VS voltas de solicitações sobre um determinado período de tempo	Frequência que um software é desenvolvido sem retornar etapas	Melhoria de Qualidade

fonte:

http://leanagilechange.com/leanagilewiki/index.php?title=Kanban_Metrics_%26_Improvements

Projetos ágeis têm percentuais de erro três vezes inferiores aos realizados por cascata

De acordo com o CHAOS Manifesto (2012), os projetos desenvolvidos utilizando técnicas ágeis, como LEAN Thinking, Scrum, XP, têm 9% de erro, contra 29% dos realizados pela maneira Waterfall.

A grande sacada dos métodos ágeis, é que realizando pequenas entregas contínuas, vamos recebendo o feedback do cliente de logo após as entregas, o que nós ajuda a direcionarmos para o caminho certo. A diferença está em que erramos mais cedo, e portanto podemos ir para o caminho certo e entregar um software de maior qualidade e livre de erro para o cliente.

Já no método cascata, o cliente só vai ver o software quando o mesmo estiver pronto, e caso tenha algo que lhe desagrade, o desenvolvedor só vai ficar sabendo quando for entregar o software como um todo.  Caso tenha algo de errado ou o software não ficou como o cliente necessita, o tempo e a quantidade de código para refatorar será muito maior do que se o problema tivesse sido detectado logo de cara.