O pensamento Lean, que foca na redução do desperdício na produção de produtos, foi popularizado a partir dos seus resultados práticos na Toyota, no Japão. O desperdício é muitas vezes sutil e ocorre em escala quase imperceptível ao nosso redor. Por exemplo, Uma torneira pingando uma gota a cada 5 segundos representa mais de 20 litros de água desperdiçados em apenas um dia ou 600 litros por mês.
Arquiteturas Enxutas
Este pensamento da redução do desperdício tem sido estudado e adaptado para o desenvolvimento de software há alguns anos já. O livro emblemático nesta área é o “Lean Software Development” by Mary and Tom Poppendieck. Neste livro, os autores divulgam sete princípios básicos para a produção de software que reduza o desperdício.
Naturalmente, o desenvolvimento de arquiteturas de software pode se beneficiar destes princípios. Adapto as idéias compiladas por estes autores para o dia a dia do arquiteto e do pensamento arquitetural em projetos.
- Elimine gastos desnecessários Uma das fontes de desperdício de gastos arquiteturais é o pensamento especulativo em projeto de softwares. Exemplos clássicos são o projeto de software portáveis, com usabilidade nível WCAG A3 ou com altíssima escalabilidade na ausência completa destes requisitos pelo negócio. Infelizmente muitos arquitetos acreditam que os requisitos de qualidade vem livre de custo. Em verdade, adicionar um atributo de qualidade ao projeto pode impor um alto custo financeiro e temporal ao mesmo, o que pode ofender metas organizacionais de tempo de mercado e competitividade. Por exemplo, uma arquitetura com forneça disponibilidade de 99,9% é 10x mais cara que uma arquitetura que forneça disponibilidade 99%. Um outro exemplo de desperdício é o conceito de complexidade arquitetural acidental, que é a complexidade não inerente a um problema. Por exemplo, quando um arquiteto decide introduzir um mecanismo de comunicação distribuída entre telas e objetos de negócio (e.g. IIOP ou SOAP) em uma aplicação Web que irá operar para 10 usuários ele introduz uma enorme complexidade acidental no projeto, o que em última instância levará a desperdícios. A mensagem é clara. Atenha-se ao estritamente necessário e projete arquiteturas que gerem real valor de negócio. Requisitos arquiteturais especulativos são uma enorme fonte de gasto nos seus projetos e devem ser removidos a todo custo.
- Pratique qualidade contínua Defeitos significam desperdícios. Projetar uma arquitetura com complexidade acidental aumentará a curva de aprendizado e introduzirá inexoravelmente mais defeitos no seu projeto. Arquiteturas com qualidade contínua promovem a redução dos defeitos com a geração da solução mais simples possível que atenda ao negócio, projeto e expectativas do cliente.
- Crie conhecimento Planos são ótimos, mas o conhecimento é obtido através de aprendizado. Em termos arquiteturais, devemos abolir os arquitetos da torre de marfim, que criam planos desconectados da realidade. Arquitetos devem acompanhar o trabalho do time de desenvolvimento no dia a dia, aprender com os resultados e documentá-los no seu “caderno arquitetural”. O documento de arquitetura de software deve ser, portanto, vivo e melhorado continuamente a partir dos resultados práticos das provas de conceitos e casos de uso.
- Adie compromissos imutáveis Arquitetos não devem projetar arquiteturas inflexíveis e que somente são produzidas após meses de labor. Em verdade, arquiteturas devem ser evolutivas e acomodar de forma iterativas cenários de negócio fim a fim. Um cenário de negócio não é um caso de uso, mas em verdade um corte transversal mínimo em vários casos de uso que gere um pequeno valor de negócio. Se um arquiteto projeta uma arquitetura resiliente e flexível que possa acomodar cenários ao longo do tempo, as equipes de negócio podem gerar valor de negócio (código implantado) para os participantes de um projeto em tempo reduzido.
- Entregue rapidamente Steve McConnell e outros autores mostram que desenvolvedores sob pressão introduzem até 40% mais defeitos que desenvolvedores do mesmo nível em ambientes controlados. Defeitos são desperdícios, como dissemos anteriormente. Paradoxalmente, portanto, a chave para isso é respeitar a velocidade do time de arquitetos e desenvolvedores na montagem da arquitetura executável. Meça a velocidade de produção do seu time nas primeiras iterações e a use para planejar o projeto apropriadamente.
- Respeite pessoas Nenhum de nós é melhor que todos nós. Em termos arquiteturais, arquitetos devem buscar a colaboração dos times para projetar as arquiteturas dos seus projetos. O envolvimento e o respeito às pessoas do time é fundamental para produzir arquiteturas mais assertivas, reduzir o retrabalho e portanto reduzir desperdícios.
- Otimize o todo Java, .C#, ERP, MYSQL, SQL Server, Linux ou Windows não são valores de negócio. É por isso que quando vemos arquitetos brigando por posições tecnológicas baseado em preferências pessoais, é sinal que algo vai muito mal no seu projeto. Infelizmente, já vi “arquitetos” recomendarem tecnologias para órgãos do governo e empresas da área privada baseado em posições “religiosas”, com resultados desastrosos em médio prazo. Arquitetos do século XX entregam arquiteturas que são apenas escaláveis, performáticas, amigáveis ou tolerantes a falhas. Bons arquitetos do século XXI, por outro lado, devem pensar no real valor de negócio que eles estão entregando em seus projetos e portanto irão usar tecnologias como meio para atingir os benefícios do projeto. Bons arquitetos projetam arquiteturas que permitem que clientes vendam mais, atendam melhor seus consumidores, reduzam o tempo de entrega de seus produtos ou melhorem os seus fluxos de caixas. Bons arquitetos declaram os objetivos de negócio como metas finais da sua arquitetura e garantem que os seus softwares atendam a estes objetivos, acompanhamento a implantação do software fim a fim. Métodos centrados na monitoração de negócio (BAM e CEP) são importantes aliados para os arquitetos demonstrarem valor de negócio e não apenas demonstrarem pilhas tecnológicas.
Pensamento do dia: “Um homem que ousa gastar uma hora de tempo ainda não descobriu o valor da vida.”, Charles Darwin
No comments:
Post a Comment