timeBox

Desenvolvimento ágil, aqui no Brasil, virou tema comum em vários blogs e fóruns. Até uma revista especializada nisso nós já temos (Visão Ágil). QUE BOM PRA NÓS desenvolvedores brasileiros. Mas e o mercado brasileiro? E as grandes consultorias de software que empregam boa parte de nós? É….ai a coisa complica um pouco. Colocar em prática princípios de SCRUM, XP, TDD, modelagem ágil e coisa e tal ainda não é muito fácil. Mas isso até tem uma razão de ser. Diretores de TI costumam ler publicações menos técnicas e essas ainda não estão falando muito dos benefícios (ROI) que um modelo de desenvolvimento ágil de software pode trazer. Ainda é preciso fazer esse conhecimento chegar as esferas mais altas do nosso mercado, coisa que já vem acontecendo com outros temas técnicos como BPM e SOA. Hoje em dia acredito que boa parte dos diretores de TI já tem pelo menos alguma ideia do que significa BPM e SOA. Muitos deles já estão inclusive bancando a incorporação de ambos.

No entanto, tenho visto uma certa resistência perante ao uso mais expressivo de técnicas ágeis em equipes que já estão envolvidas em projetos ligados a BPM e SOA. Muitos argumentam que implantar BPM, SOA e Agile , tudo ao mesmo tempo, seria uma quebra de paradigma muito grande e de difícil assimilação.

Humm….será que é isso tudo?

Ok….se você está a séculos desenvolvendo no modelo tradicional (gerente microsoft project/desenvolvimento em cascata/trocentos templates/pouco conhecimento) ai realmente vai ser dureza mudar tanta coisa ao mesmo tempo. De qualquer forma, não creio que nesse seu estado seja possível fazer um trabalho que atenda as expectativas do seu cliente, ainda mais algo envolvendo BPM e SOA. Não tem jeito, ou você começa a evoluir ou você começa a evoluir! Aconselho até a esquecer um pouco esses assuntos (BPM e SOA) e arrumar primeiro a sua casa. Mas se você já trabalha com desenvolvimento iterativo, já pensa em arquitetura, já conhece (de verdade) orientação a objetos, já promove o reuso em seus projetos, já conta com um cliente interessado e conhecedor do processo…cara, continuar tento tudo isso (e mais um pouco) de forma MAIS ÁGIL não vai te fazer mal algum.

O desenvolvimento ágil de software não vai atrapalhar em nada as estratégias do seu cliente ligadas a BPM e quanto a SOA, mesmo tendo que pensar de forma mais corporativa, passando por questões de governança e tudo mais, uma hora você terá de fazer coisas como ”identificar requisitos, modelar, implementar, testar, entregar”.

Essas “coisas” continuam sendo Desenvolvimento de Software.

Já trabalhei em diversos projetos que continham como parte de sua documentação um SAD (Software Architecture Description) normalmente criado a partir de um template do RUP. Sem entrar em muitos detalhes, posso dizer que um SAD serve para documentar aspectos arquiteturais de forma geral, fornecendo varias visões complementares sobre o sistema. A ideia é que esse documento vá amadurecendo ao longo do projeto. O iniciamos de forma tímida e o detalhemos melhor a medida em que a arquitetura for ficando mais estável. Dessa forma, teremos um ótimo guia de entendimento arquitetural para futuras equipes que venham a dar manutenção no sistema.

Ok. Vamos produzir SADs em nossos projetos então!
Mas….
Porque tendemos a achar que esse documento também é muito bom para comunicar (informar, ensinar) a própria equipe envolvida atualmente no projeto sobre a arquitetura do mesmo? Pergunto isso justamente pelas experiências que tive nos projetos em que o usei. Nesses projetos, o principal movitador de criação do SAD era a ideia de disseminar o conhecimento referente a arquitetura do sistema para os membros da equipe de desenvolvimento, que na maioria das vezes, estavam unidos em um mesmo local.

….
Pra falar a verdade, na maioria das vezes a “equipe de desenvovimento” trabalhava remotamente (estratégia “fábrica de código”), então problemas como falha de comunicação, modelagem excessiva e eventualmente atrasos faziam com que a “fábrica” fosse transferida para o mesmo local físico onde ficavam os outros membros da equipe, ou então, os “analistas”, “arquitetos” e demais “especialistas “ acabavam por produzir software de verdade.
….

Nosso relacionamento com o SAD acaba sendo mais ou menos assim:

A equipe de modelagem e o arquiteto se reuniam no inicio do projeto e discutiam a arquitetura base do sistema rabiscando modelos em quadros. A partir dai o arquiteto se responsabilizava pela criação do SAD, como base no que foi discutido na reunião e por mantê-lo atualizado durante o desenvolvimento do sistema.
Sempre que alguma nova questão arquitetural surgia, ou era alterada, essa informação era passada por e-mail ou através de reuniões rápidas com a equipe, utilizando uma sala com um quadro pra rabiscar ou mesmo uma baia de algum dos desenvolvedores com algumas folhas de papel. Depois disso, o arquiteto arrumava algum tempo pra atualizar o SAD com textos e diagramas UML mais formais.

Agora me diga. Quem mais alem do arquiteto, teve realmente necessidade de manter um contato continuo com o SAD durante o tempo de desenvolvimento do sistema? Ninguém.
Então, pra que criar esse documento no inicio do projeto e continuar dando manutenção nele enquanto o sistema ainda está sendo feito, se ele não é a forma mais direta, mais viável, de se comunicar questões arquiteturais pra sua própria equipe?
Seu cliente é que pode precisar dele, no final do projeto, como um guia arquitetural para novos desenvolvedores que possam vir a dar manutenção no sistema. Alias, seu cliente é que deve decidir se esse documento deve ou não ser produzido, afinal, quem está pagando é ele.
Então, se seu cliente decidir que é valido ter um SAD (e eu creio que seja) atrase a sua criação o máximo que puder, você não vai precisar dele pra dizer algo as pessoas que trabalham com você. Seja ágil e documente somente o necessário e quando necessário.

Eu acho que não, mas porque muita gente acha o contrário? Porque tantos desenvolvedores querem ser chamados de analista senior ou de gerente de projeto?
Bom, eu não fui o primeiro a perceber isso. De acordo com o Scott Ambler, se formos traçar uma linha de tempo generalizando a carreira da maioria dos desenvolvedores, acabamos com algo mais ou menos assim:

Quando jovem, o desenvolvedor foca seus esforços de aprendizagem quase que unicamente em tecnologias especificas. Normalmente ele se auto-denomina como desenvolvedor JEE, desenvolvedor .NET, ou algo do tipo. Ai ele aplica a tecnologia que ele escolheu em alguns projetos, absorve conhecimentos sobre as inovações que ocorrem nessa tecnologia e continua aplicando o conhecimento sobre ela em mais e mais projetos. Depois disso ele começa a perceber que independente da versão da tecnologia ou até mesmo independente da tecnologia, o que ele faz é aplicar em forma de código os mesmos fundamentos, como por exemplo: divisão em camadas, controle transacional, persistência de dados, controle de estado, etc.
Ai nessa hora a tal tecnologia que ele domina vai e muda novamente, sofre uma reformulação gigantesca ou simplesmente cai em desuso. Por coincidência, nessa época ele já está lá com seus 30, 30 e poucos anos e não tem mais o menor saco pra absorver essas mudanças todas. Pra piorar, o salário dele também não é lá essas coisas e ele ta pensando em casar, comprar apartamento, essas coisas. Sendo assim, ele decide que precisa abandonar o desenvolvimento e partir pra algo com mais lucratividade e menor necessidade de renovação intelectual, o que em muitos casos (não em todos) acaba sendo o tal analista senior e depois o tal gerente de projeto. Justo no momento em que ele tinha mais experiencia e conhecimentos sobre questões relacionadas ao desenvolvimento de software em si. Então outros desenvolvedores jr entram no mercado e a roda continua a girar. O resultado disso acaba sendo o pior possível, pois só quem realmente produz software nesse modelo de mercado é o jr que acabou de entrar na roda.

Mas felizmente, em Fevereiro de 2001 um grupo de metodologistas (pessoas que pensam em como melhorar a forma de se produzir software) tentou dar um basta nesse modelo insano de produzir software através do Manifesto Ágil.
Esse manifesto não só reconheceu o valor de quem realmente desenvolve software como também trouxe a tona diversas outras verdades que pareciam ter sido esquecidas pelo mercado de software. 

Para quem ainda não o conhece, vale pena procurar saber sobre ele e sobre seus tentáculos como as metodologias ágeis, a modelagem ágil, entre tantas outras coisas que com certeza vão fazer você ter certeza de que produzir e entregar software funcionando pode sim ser muito divertido e ainda te livrar da ingrata missão de se tornar um engravatado burocrático, desatualizado, improdutivo, stressado, infeliz…