….passei a viajar na idéia de que o espírito Apple de criar seus produtos estava de alguma forma ligado aos valores e princípios pregados pela agilidade.

Pra quem desenvolve software tradicionalmente a algum tempo, só o fato de tomar conhecimento sobre o que diz o manifesto ágil já é algo que desperta. Algo que traz uma vontade imediata de trabalhar daquele jeito.

Quando tomei conhecimento sobre a proposta de produtos e softwares que a Apple segue, senti a mesma coisa. Uma vontade imediata de passar a usar computadores daquela forma, com aquela simplicidade e elegância matadora.

Mas até ai tudo bem. O fato de imaginar coisas, ligações aparentemente inexistentes, conceitos loucos, não é novidade alguma pra mim. rsrsrsrs

Até que hoje, participando do Dev in Rio 2009, assisti duas palestras de pessoas que com toda certeza viajaram nessa mesma questão.
Primeiro veio o Akita com sua palestra sobre ruby on rails (que tem uma comunidade notoriamente interessada em seguir princípios ágeis). E como ele iniciou a palestra?
Com esse vídeo aqui…

Esse pessoal da 37 Signals é tão apaixonado pela plataforma Apple, que chegam a relacionar o sucesso dos seus produtos a inspiração adquirida ao se trabalhar com Macs.

Depois do Akita ainda teve a palestra do Jeff Patton, que relacionou técnicas ágeis com o sucesso na criação de produtos.

Jeff Patton, Dev In Rio 2009

Em determinado momento da palestra, quando ele falava sobre a quantidade, simplicidade e qualidade das features em um produto, o cara puxou um iPhone do bolso e mandou: “Aqui não tem tudo que poderia ter, como muitos reclamam, mas o que tem, é simplesmente magnífico.”

Agile é objetividade, simplicidade, satisfação por estar fazendo algo com prazer, feliz, sem burocracias idiotas, sem documentações em excesso, que só você vai ler enquanto produz, sem gerente-comando-controle, sem terno em pleno Rio de Janeiro, sem diplomas ou certificações pra inglês ver.

Hi, I’m a Mac, and you?

Ok.

Você então projeta sua solução com base em JUnit.
Testa a chamada a interface, verifica que está tudo ok e entrega o produto.
Pra não ficar só em código, você até documenta a interface gerada em uma espécie de contrato. Dizendo como ela deve ser chamada e o que se esperar dela e tal. Tudo bonitinho.

Ai alguém chega pra você e diz que sua entrega não está aderente a metodologia da casa.
Afinal, faltou criar o diagrama de caso de uso e seu respectivo documento word de descrição do mesmo.
Então você entrega o tal caso de uso e algumas semanas depois ele volta pra você num e-mail que diz: Seu caso de uso não está aderente as melhores práticas pregadas pela casa para o mesmo. O fluxo básico está usando de termos técnicos e não representa com clareza uma interação entre o ator e o sistema.

Agora me diga. Qual a utilidade de se fazer um caso de uso numa situação como essa? Onde seu trabalho se resume a produzir um serviço de comunicação com uma ferramenta, o qual será chamado por outros serviços?

Qual a utilidade de se engessar de tal forma a quantidade e qualidade da documentação que deve ser feita?

Não pegou a idéia ainda?
Imagine só. Alguém te convida pra ser padrinho de casamento. Um outro alguém te alerta que você deve ir de terno a um casamento. Gravata, sapato, tudo certinho.
Mas o casamento que te convidaram pra ser padrinho será na praia, ali na areia e tal. Sei lá, a noiva viu um assim numa revista e resolveu que o dela seria assim também!

E ai? Você vai aparecer por la de terno? Gravata no sol de meio dia? Sapato na areia?
Seu bom senso vai te dizer alguma coisa sobre isso, não?

Eu estou falando de ESCOPO NEGOCIÁVEL + DESENVOLVIMENTO ITERATIVO.

Não é raro eu entrar nesse assunto com alguém e ouvir de volta: “ah…muito legal, mas no mundo real não é assim”, ou então, “você está sendo acadêmico demais”.

Eu? Acadêmico? hehe….Vamos pular essa parte e partir pra alguns dados reais de mercado.

A décadas que o Standish Group vem divulgando o CHAOS Report, um conjunto de estatísticas sobre os resultados obtidos em milhares de projetos ao redor do mundo.
Só pra exemplificar, os dados de 2003 revelam que 34% dos 13.522 projetos pesquisados atingiram o sucesso, ou seja, foram entregues dentro do prazo, custo e ESCOPO FECHADO previsto inicialmente. Do restante, 15% foram cancelados e 51% tiveram prazo e/ou custo aumentados consideravelmente.

Com base nas funcionalidades que foram entregues nos projetos ditos de sucesso, foi perguntado aos clientes dessas funcionalidades, qual o grau de uso que eles estavam tendo sobre elas. A média das respostas foi a seguinte:
7% sempre são utilizadas, 13% frequentemente, 16% as vezes, 19% raramente e pasmem….45% nunca são utilizadas!

É isso aí, a maior parte estourou prazo/custo ou foi cancelada e dos que tiveram sucesso, quase a metade das funcionalidades não serve pra nada NO MUNDO REAL. Legal né???

Imagino que depois de ler isso em 2004, quem passou o ano anterior perdendo contratos ou gastando uma nota com hora extra, deva ter olhado com outros olhos essa questão de escopo negociável + desenvolvimento iterativo.

O problema de negócio que queremos resolver via software é que deve ter o escopo fechado.
As fronteiras que a solução sistémica não deverá ultrapassar é que devem ser delimitadas.

Agora, qual a real complexidade ou até mesmo necessidade dos X possíveis casos de uso, histórias, ou seja lá o que for, inicialmente imaginados pra resolver os problemas (de negócio) contidos no escopo (de negócio) de um projeto?
Não tem como responder isso com precisão ! Nem com ponto de função nem com qualquer outro ponto que seja.

Bem vindo(a) ao mundo real

Não, eu não estou fugindo do tema desse blog e relatando um desfecho comum para os engarrafamentos de 1 hora no aterro do flamengo ( o tempo normal pra atravessa-lo é de 5 min).

Quando se desenvolve software para uma grande corporação, não é raro se deparar com essa situação ai do diálogo. No papel do policial normalmente está algum membro da EIB (Equipe de Infra-estrutura Básica) e na pele do motorista está algum desenvolvedor com a inevitável missão de submeter um sistema (ou pedaço de um) à aprovação da EIB.

Uma EIB normalmente é composta por um conjunto de pessoas, onde cada uma tem uma aptidão específica, como administração de banco de dados, ou arquitetura SOA por exemplo. Muitas vezes uma EIB é até composta por um conjunto de equipes menores, cada qual com sua especialidade. Mas enfim, a função dessa galera de infra é dar apoio as equipes de desenvolvimento de software, criando diretrizes e convenções corporativas, as quais devem ser seguidas pelas equipes de desenvolvimento.

Existem duas formas de se trabalhar essa questão “EIB vs equipes de desenvolvimento”:

1 – Colocando uma contra a outra nessa estratégia de BLITZ CORPORATIVA, onde o pessoal de EIB apenas gera um mar de documentos-diretrizes, envia esse “manual de trânsito” para as equipes de desenvolvimento e marca uma data (normalmente ao final de alguma entrega importante) para revistar (ops!) digo….analisar, o trabalho da galera de desenvolvimento.

2 – Promovendo a comunicação e a humildade (valores da modelagem ágil) entre ambas as partes. Isso se faz inserindo as pessoas de EIB em determinados projetos de desenvolvimento por algum período de tempo, fazendo com que elas compartilhem sua maturidade profissional nas áreas em que se especializaram. Assim, as diretrizes corporativas passam a ser amadurecidas, repassadas e colocadas em prática em um cenário real. De quebra, ainda se cria um ambiente amigável e colaborativo entre as partes. Isso funciona! Dia desses estava conversando sobre isso com o Gustavo Serafim e ele diz estar tendo bons resultados com essa abordagem.

Ah! não posso deixar de dizer isso. Um grande risco de insucesso que se corre usando essa segunda abordagem, é colocando pessoas com pouca ou nenhuma habilidade de comunicação na EIB. Para isso funcionar é preciso ter profissionais bons tecnicamente mas que sejam sociáveis também. Já imaginou a pessoa ser apresentada como nova especialista XPTO pra apoiar o projeto durante algumas semanas, daí após essas semanas sem falar um “ah” ela manda um “manual de trânsito” por e-mail e some?

Aos que comentaram meus posts por lá, peço desculpas. Pois perdi seus comentários quando tentei fazer com o iWeb coisas que ele não se propõe a fazer.

Sejam bem vindos

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.

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.

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…