Blog do Andre Fonseca

Muito tenho escutado neste últimos dias sobre a questão do sucesso ou não do uso de metodologias ágeis.Principalmente com relação a entregas. Primeiro preciso dizer que não sou um doutor no assunto, nem pretendo ser, muito menos um profundo conhecedor, mas considero que tenho uma pequena vivência no assunto que me permite tecer alguns comentários sobre o assunto.

A alguns dias atrás, fiz um workshop sobre metodologias ágeis com o Juan Bernabó na Globo.com. Recomendo fortemente a todos fazerem mesmo que já tenham certo conhecimento sobre o assunto, apliquem nos seus times ou qualquer outro caso.

Durante todo o workshop feito por ele, cujo o objetivo é de apresentar as metodologias principalmente o Scrum, vários jogos, dinâmicas e outras tantas coisas são feita. Entretanto, para mim, o mais interessante  foram as discussões que ocorreram entre as atividades.

Houve um momento que o pessoal colocou os problema encontrados no dia a dia de cada um e suas expectativas quanto ao uso de metodologias ágeis.  A primeira coisa que ficou bastante evidente foi uma expectativa que ao colocar em prático algo ágil todos os problemas desaparecerão, como que por mágica, e que todos serão felizes num ambiente super ideal.

A questão que o curso colocou, e que realmente achei genial, é que Scrum não é uma ferramenta somente de soluções. Ela tem muito mais um aspecto de mostrar os problemas e forma simples e rápida procurar resolvê-los.

Sendo assim, quem não está preparada para ver os problemas, gargalos, etc de sua empresa, ao adotar qualquer coisa no sentido, vai achar que a ferramenta não serve. Isso porque tem a expectativa errada. Verá muito mais problemas do que solução.

Uma outra coisa que o Bernabo falou que me fez mudar a forma de pensar foi que ser ágil não significa não ter problema : a questão é exatamente contrária, evidenciam os problemas e procura-se soluções. Contra medidas nas palavras do Juan.

Enfim, ao vermos a questão ágil não como mais um processo e sim como uma forma de levantar os problemas e buscar contra-medidas, fica claro a razão do sucesso e que simplesmente seguir uma cartilha não é o perfil ideal a buscar.

Já a um tempo desde que fui apresentado a todo o movimento ágil por meio do Guilherme Chapiewski, Alexandre Martins, Evandro Flores… e desde que fui levado a novas tecnologias e linguagens por estes e por outros como Henrique Bastos,  que sempre que conversamos sobre o assunto com o pessoal que ainda não conhece nada sobre o tema, ouço toda vez as mesmas perguntas e frases:  Você usa ágil por ser idealista; você gosta dessas metodologias por ser nerd e gostar desses modismos; Ágil não é para gente que quer ganhar dinheiro? Python é coisa de universidade!  Ruby on Rails é para pequena empresa!

Uma primeira coisa que gostaria de deixar claro: Sou capitalista e gosto de ganhar dinheiro. Não tenho absolutamente nada contra os demais regimes econômicos existentes, nem a políticas, teses sociais e etc.  Sou um cara que acredita no trabalho e que devemos ganhar dinheiro com ele. Só isso.  Sendo assim, como uma empresa,  busco o lucro. E quanto maior minha margem de lucro melhor.

Margem de lucro, quando estudei macro economia na faculdade, em termo simples,  é quanto porcentos de dinheiro que você ganha frente ao custo daquela coisa que você “está vendendo”. De certa forma, vendemos nossas horas de trabalho… de um jeito que prefiro, vendo meu conhecimento para criar software.  Horas soa como operador de máquina. Operário.  Seguindo com o raciocínio,  para maximizarmos nossos “lucros”como desenvolvedores, temos que gerar o maior valor agregado para o nosso cliente com menor esforço possível.

Esforço no nosso caso é arquitetar soluções, criar ambientes, codificar, testar, instalar a solução para o cliente e depois dar a manutenção dele.  Claro que isso pode não aplicar a todos, mas pelo menos algumas das coisa citadas são feitas. Bom, se existir algo que me facilite realizar as tarefas acima e ainda permita que eu gere um alto valor para o cliente, seria sensacional, não ?! É exatamente isso que encontrei a adotar essas “novas” tecnologias (Python e Ruby existem a tanto tempo quanto Java)  e o fato de ser ágil .

Essas linguagens me permitem fazer com menos… Ágil permite eu me livrar de burocracias que não me ajudam e tomam meu precioso tempo.  Enfim, escolhi usar essas coisas pois quero ganhar mais dinheiro com menos esforço. Muitos, com certeza, irão me criticar dizendo que estou fora do ideal da comunidade. Eu gosto de ajudar e contribuir. Faço isso sempre que posso, a questão que o motivo principal que me mostrou valer realmente a pena em aprender coisas novas, investir para me inserir em novas formas de gestão foi o fato de eu ver que isso ajuda a melhorar meu trabalho e a ganhar dinheiro.

Um erro comum das pessoas que entram nessa nova onda é achar que só existe idealismo envolvido que o resto é mal ou desprezível. Dinheiro não é mal, é de fato o que move nosso mundo. Por que não mostrar que ser ágil, usar uma tecnologia aberto para fazer as coisas, usar uma linguagem mais simples, pode ser um meio de aumentar lucro? Pois é exatamente o que acontece.  Usar Git ao invés de CVS ou SourceSafe(exagerei)  é lucro: não pago licença por algo que é muito bom e além disso ganho com recursos que facilitam a vida do time.

Acredito firmemente que é preciso dar um sentido menos utópico as coisas.

Bem era isso… aguardo a opinião de vocês.

Quem lida com desenvolvimento de sistemas o tempo todo, ainda mais quando tem uma certa experiência – ou até é o mais experiente do grupo, sabe que o tempo todo deverá tomar decisões. Decisões estas de natureza diversa: desde uma contratação, uma demissão, quais tecnologias, qual arquitetura, licenças(argh), etc.  Claro, pelo menos no meio que convivo, as decisões de carater mais técnico tendem a ser mais “leves”  e, erroneamente, não é dada a devida importância ou seriedade que o assunto merece. Isso tem impacto direto sobre muitos produtos “estranhos”que acabam sendo entregues que, para o usuário leigo, pode até passar desapercebido porém alguém com perfil mais técnico chega a ser gritante.

Imagine você que seu time está começando um novo projeto. O dono do produto começa a conversar de forma ampla do que ele espera e das interações que ele espera que os usuários terão, etc. Ele aproveita e também fala sobre a quantidade de acesso que ele espera para aquilo, tempos de respostas, etc. Quem é desenvolvedor, assim como eu, nessas horas não consegue escapar de ir já imaginando a arquitetura do projeto, como as coisas vão interagir, etc. Pela experiência que tenho isso pode ser uma armadilha fatal.

Otimizações e arquitetura prematuras, no meu ponto de vista, são uma das maiores fontes de problemas de projetos. Dentro do príncipio Lean (justo necessário) de desenvolvimento, devemos nos ater aos problemas que existem e não aos que existirão. Fazer a coisa de forma a facilitar evoluções sim mas não “dê um passo maior que a perna”. O que vejo são verdadeiro monstros de empilhamento para um requisito de baixo número de usuários, zero de evolução, etc. Um exemplo para facilitar: Imagina que o cliente quer que você faça um site para empresa dele. Esse site será pouco acessado e servirá apenas, num primeiro momento, para ser uma página informativa da empresa. Num futuro, assim que os negócios decolarem, ele irá desenvolver uma mega ferramenta, mas não agora… já vi muito gente fazendo sistemas em mil camadas, com cache, banco de dados oracle mega 3 plus, etc… Sendo que, se fizesse tudo com html estático, funcionaria perfeitamente.

Prefiro que as coisas evoluam organicamente. Isso significa dizer, que a medida da necessidade as coisas vão sendo alteradas para melhor atender. Novamente insisto que também não é para fazer uma parada em html e depois querer com pouco esforço torná-lo dinâmico.  Pense em Darwin: evolução é perpetuação do mais aptos ao ambiente.  Simplificando seria que a medida que nossos sistemas vão crescendo vamos deixando as coisas que funcionam bem dentro daquele contexto de requisitos e vamos alterando ou trocando as coisas contrárias.

Diante de tudo dito acima, fica claro que bom sistemas são aqueles que mudam !!! Não pense que conseguirá fazer uma aplicação mágica que será capaz, depois de  ”pronta”, de se adaptar a todos cenários possíveis. Até porque precisamos de trabalho né . Software não é como um prédio, associação que muitos fizeram e fazem erroneamente . Software está muito mais parecido com algo orgânico que vai crescendo e sofrendo mutações.

Num próximo artigo pretendo trazer a questão do empilhamento e horizontalidade. Essas duas coisinhas que quase ninguém sabe ao certo os seus reais valores e como (e quando) usá-los.

Hoje, pela hora de almoço, estava conversando com Gabriel sobre a questão do TDD (Test Drive Development – Desenvolvimento dirigido por teste).  Conversávamos sobre o fato de hoje isso esta se tornando uma moda e muita gente dizer que está usando a técnica e na verdade não está.

Para os nerds de plantão, existe uma cena do filme Matrix, onde o Neo começa a entender a matrix e com isso controlá-la. Pode parecer que quero “forçar a barra”, porém acredito, sinceramente, que o uso TDD se processa da mesma coisa. Só vamos deslumbrar o seu poder quando passamos a acreditar no processo.  Não adianta somente usar porque agora virou moda… tem que acreditar que a coisa realmente funciona, para então aproveitar todo o poder que essa verdade libera (estou inspirado hoje).

Tem muito gente que critica o uso do TDD por justamente se basear em casos onde pessoas que não acreditam no processo e usam por motivos não muito nobres.  Nessas casos o que vejo são, na maioria das vezes, desenvolvedores subvertendo a filosofia, escrevendo testes que não são “profundos”, escrevendo os testes depois, adaptando os testes para passar ( já ouvi histórias de pessoas comentarem o teste), e por aí segue esse terror.

É preciso crer. O começo é verdadeiramente complicado e trabalhoso. Escrevemos toneladas de linhas de código, sem gerar nenhum valor “real” para nosso cliente. Por várias vezes ficamos tentados a deixar os teste de lado e partir direto para implementar por motivos diversos. Mas ao respeitarmos a formúla, o ganho vem com o tempo. Apenas para exemplificar, uma dessas vantagens é a questão de sempre estarmos focado no simples e atender estrictamente o escopo.

Quem nunca se deixou levar, ao implementar, uma aplicação, pela loucura de criar arquitecturas imensas e sem necessidade? Aquelas aplicações (Java) com um amontoado de camadas – DAOs, VOs, Services, etc – que no final vão servir apenas para um site pequeno de noticias que não terá grande modificações após ser colocar em produção.

Voltando para a questão do TDD… Escrever testes antes da implementação faz com que foquemos na necessidade: Criamos a necessidade para podermos supri-las e não contrário – criar soluções para depois ver necessidades.

Ser simples é chave. E TDD é um dos caminhos que nos levam a isso quando falamos em desenvolvimento de sistemas. Além disso, existe já as justificativas de ampla cobertura de testes e de foco na aderencia de requisitos.

Quando realmente usamos o TDD, como já disse antes, criamos a necessidade e a partir daí partimos para criar a solução que a satisfaçam.  Isso faz com que tenhamos um código amplamente testado, justo – evitasse o desperdício em criar solução para necessidades que nem existem ainda, código limpo, etc. Se extrapolarmos então para a questão da evolução de código a coisa fica mais interessante ainda: primeiro modificamos o testes, pois a necessidade é diferente,  e depois modificamos a implementação para passar nos novos cenários de teste. Isso limita nossa área de atuação e nos disciplina a fazer apenas o justo necessário. Sem firulas, sem big to front, sem complexidades adicionais para supostos futuros contextos.

Ainda sobre a vantagem, seria dizer que você, usando TDD e acreditando verdadeiramente,  você está otimizando o uso do sprint e com isso gerando mais valor agregado para o cliente. Pensem nisso na próxima vez que tive seu projeto pela frente.

Jack Milusnk, em seu blog The Agile Buddy Blog, escreveu um excelente post sobre a questão da histórica técnica. Em tomei a liberdade de escrever uma versão (não tradução) em português do texto. Para quem quiser ler o texto original, acesso o post aqui. Comentários com ajuda na tradução e opiniões são bem vindo.

Se você ainda não é um membro do grupo de desenvolvimento SCrum do yahoo, você deve considerar se juntar rapidamente. Existe, no fórum, uma verdadeira fortuna de informação que a todo tempo muda de mão e, você pode muito nas interação que acontecem ali. Inclusive, recentemente  houve um intenso e caloroso debate sobre a questão das histórias “técnicas” (talvez aqui fosse melhor o termo – backlog técnico;<em>technical stories</em>

A questão acima foi se um débito técnico deveria ou não aparecer no backlog do time. Se eles aparecem no backlog, significa que coisas técnicas podem ser priorizadas pelo P.O. (product owner – dono do produto). Isto não parecer ser uma boa ideia pois, o PO, na maioria dos casos, irá dar mais valor para as funcionalidades e <em>features</em> do sistema dele em detrimento a parte técnica. Um exemplo disso, histórias técnicas, seria : “Instalar o Cruise Control”; alterar o banco de dados de MySQL para Oracle, configuração do VMWare etc. A maioria dos grandes pensadores e formadores de opinião do fórum, argumentaram que histórias técnicas de forma alguma deveriam aparecer no backlog. Mas tudo que precisa de recurso de desenvolvimento deveriam aparecer no backlog.

Se der uma olhada na definição vind do guia do Scrum (scrum guide no scrum.orgs), encontrará o seguinte:

“O backlog do sprint consiste nas tarefas que o time deve realizar para incrementar o backolog do produto na direção do status pronto… Isto é, todo o trabalho que o time identifica como necessário para atingir o objetivo do sprint.”

Então, qual é a resposta correta?

Minha resposta é que depende… depende do contexto. Por exemplo, se a definição de pronto leva em conta ter testes unitários, testes de aceitação automatizados, etc, então estes itens não precisam estar explicitamente identificados no backlog. Isto é, coisas que são feitas pelo time e não existe negociação. Assim, as estimativas precisam incluir o tempo necessário para completar todos estes elementos que fazem parte do conceito de pronto.

Naquelas situações, onde um dos membros sugere – “Como membro da equipe de desenvolvimento, eu quero que os testes unitários existentes devem ser executados pelo Cruise Control ( integração contínua) de modo que eu sei quando algo quebra”. Bem, esta é uma história bem escrita e que define bem a necessidade, mas ela não tem nenhum valor final para o usuário (PO), pelo menos não diretamente. Neste caso específico, eu sugiro o seguinte:

Este tipo de história, definitivamente, não pertence ao backlog do produto, mas pode ser uma tarefa que existiria no backlog do sprint. Alguns amantes de XP poderiam dizer que não faz sentido por trabalharem sempre no nível de histórias, para o planejamento, enquanto que o Scrum fala mais em tarefas.  Se o time estiver trabalhando com tarefas, este tipo de atividade – histórias técnicas – devem aparecer no backlog e ter o esforço estimado. A maioria das pessoas de XP vão dizer que é isso é micro-gestão.

Se você ainda não é um membro do grupo de desenvolvimento SCrum do yahoo, você deve considerar se juntar rapidamente. Existe, no fórum, uma verdadeira fortuna de informação que a todo tempo muda de mão e, você pode muito nas interação que acontecem ali. Inclusive, recentemente  houve um intenso e caloroso debate sobre a questão das histórias “técnicas” (talvez aqui fosse melhor o termo – backlog técnico;<em>technical stories</em>A questão acima foi se um débito técnico deveria ou não aparecer no backlog do time. Se eles aparecem no backlog, significa que coisas técnicas podem ser priorizadas pelo P.O. (product owner – dono do produto). Isto não parecer ser uma boa ideia pois, o PO, na maioria dos casos, irá dar mais valor para as funcionalidades e <em>features</em> do sistema dele em detrimento a parte técnica. Um exemplo disso, histórias técnicas, seria : “Instalar o Cruise Control”; alterar o banco de dados de MySQL para Oracle, configuração do VMWare etc. A maioria dos grandes pensadores e formadores de opinião do fórum, argumentaram que histórias técnicas de forma alguma deveriam aparecer no backlog. Mas tudo que precisa de recurso de desenvolvimento deveriam aparecer no backlog. Se der uma olhada na definição vind do guia do Scrum (scrum guide no scrum.orgs), encontrará o seguinte:”O backlog do sprint consiste nas tarefas que o time deve realizar para incrementar o backolog do produto na direção do status pronto… Isto é, todo o trabalho que o time identifica como necessário para atingir o objetivo do sprint.”Então, qual é a resposta correta? Minha resposta é que depende… depende do contexto. Por exemplo, se a definição de pronto leva em conta ter testes unitários, testes de aceitação automatizados, etc, então estes itens não precisam estar explicitamente identificados no backlog. Isto é, coisas que são feitas pelo time e não existe negociação. Assim, as estimativas precisam incluir o tempo necessário para completar todos estes elementos que fazem parte do conceito de pronto.Naquelas situações, onde um dos membros sugere – “Como membro da equipe de desenvolvimento, eu quero que os testes unitários existentes devem ser executados pelo Cruise Control ( integração contínua) de modo que eu sei quando algo quebra”. Bem, esta é uma história bem escrita e que define bem a necessidade, mas ela não tem nenhum valor final para o usuário (PO), pelo menos não diretamente. Neste caso específico, eu sugiro o seguinte:Este tipo de história, definitivamente, não pertence ao backlog do produto, mas pode ser uma tarefa que existiria no backlog do sprint. Alguns amantes de XP poderiam dizer que não faz sentido por trabalharem sempre no nível de histórias, para o planejamento, enquanto que o Scrum fala mais em tarefas.  Se o time estiver trabalhando com tarefas, este tipo de atividade – histórias técnicas – devem aparecer no backlog e ter o esforço estimado. A maioria das pessoas de XP vão dizer que é isso é micro-gestão.

Conversando que a gente se entende

Um dos grandes problemas atuais de TI que encontro é a questão da comunicação. Quando esta falha,  tudo falha… mesmo se as outras partes envolvidas estejam “bem feitas”. Sem comunicação, não existe um troca eficiente, a interação entre os membros se perde, há desinformação, entre outros efeitos… sem comunicação não existe possibilidade de time, existe apenas um amontoado de gente trabalhando num mesmo projeto ou atividade.

Antes de mais nada, gostaria de dizer que, quando falo em comunicação,  estou tratando em seu significado mais amplo : comunicação são as conversas, os emails, os quadros de aviso,  as reuniões, os post it na parede… Enfim, ela é tudo que visa a troca de conhecimento ou ideias e informações.  Ao dar bom dia a uma pessoa que trabalha com você, você está se comunicando; ao enviar um mensagem via mensageiros instantâneos (gtalk, msn, yahoo, etc) você está se comunicando.  Muito apenas consideram a parte formal  da comunicação e esquecem que a parte informal é de suma importância.  Se este “bom dia” não acontece, você como líder, pode estar em apuros.

Do pouco que já rodei por aí, já presenciei e participei de diversas situações onde uma comunicação falha, acabou com toda a equipe.  Um dos casos que gosto de citar é de uma empresa onde trabalhei que, o pessoal não tinha uma boa interação e as raras vezes que essa acontecia era para “sacanear”alguém. Isso gerou um desconforto tamanho na equipe, que aos poucos, as pessoas que eram o alvo das brincadeiras ou que não se sentiam confortável com aquilo foram ficando insatisfeitas. Resultado: projeto ruim,  projetos atrasados, etc. Antes que alguém pergunte: “Será possível que um problema pessoal interfira tanto no resultado? Cade o profissionalismo ?”. Não pode esquecer que somos seres humanos e não vulcanos ( momento start trek) … Nossas emoções influenciam diretamente nosso desempenho, ainda mais a nós que somos latinos.

pessoas não conversam

Continuando a história… a comunicação que a principio não tinha nenhuma relação com o desenvolvimento em si, estava causando muitos problemas. Infelizmente não houve solução, as pessoas saíram, e a equipe dissolveu-se.

Bem , se algo que não tem ligação com o dia a dia de projeto já causou um estrago como na história acima, imagine quando falamos de comunicação que fala exatamente do projeto? Se ela for mal feita, o projeto corre sério risco de não dar certo.

Outra história que conto, é de um ex chefe meu que tinha a mania de não expor com clareza o que ele queria, nem explicar de forma clara os requisitos das funcionalidades que eram para ser feitas.  Nas muitas vezes que discuti com ele, exatamente por causa disso, sempre repetia uma frase: “Ainda não sei ler mente, mas quem sabe com o tempo”.  Um requisito mal explicado é pior  ou igual pior que um requisito não dito. Não foram poucas as vezes que o pessoal da equipe acabou implementando funcionalidades incoerentes com o desejado pelo cliente; foi obrigada a refazer tudo por não estar de acordo “como deveria ser” (como se soubessémos por leitura de mente); e por essa estrada o dia a dia seguia.

Mas os problemas não estão somente na parte verbal da comunicação. Acredito, na minha pouca experiência, na maioria  dos casos os grandes problemas estão nas outras comunicações que acabam  esquecidas.  Com a moda de adoção de metodologias ágeis, a questão da comunicação ganhou uma certa importância, mas maior parte dos casos que vejo e ouço de meus amigos, há uma preocupação com a interação verbal, mas esquecem das não verbais (avisos, emails,  alertas, etc) . Pode parecer até uma contrasenso em nossa era, mas parece que estamos cada vez mais nos comunicando pior!  Documentos mais escritos, pouco domínio da lingua, entre outras coisas, dão margem para interpretações equivocadas e com isso perda de tempo por parte do time com implementações incorretas, por exemplo.

afogado em post its

Não sou a favor de um revisor de português para cada empresa, mas sou sinceramente a favor de pessoas que usem bem o meio de comunicação delas.  Não adianta querer escrever um livro para explicar algo por email, nem um frase.  Tem que se dosar, e procura tirar o melhor de cada. Além disso, essa comunicação não verbal, tem que ser intuitiva, leve, fluidica e permitir uma interação entre a mensagem e o espectador.  Gramática correta, ortografica correta, coerencia e coesão,  sintaxe … tudo isso facilita a leitura e deixa a coisa direta e clara.  Canso de ver aberrações em emails de pessoas de cargos de relevancia que no final acabam indo para lixeiras contendo um aviso importante por erros de escrita grosseiros ( erros de uso de “mim”, “amostrar” ao invés de mostrar, falta de pontuação, estrangerismo em excesso – os jobs file executam em multthreading com forks de flocks vibration poles – e por ai vai ). Fazer o simples, escrever simples, “famoso feijão com arroz”, funciona na maioria dos casos.

Por isso que quadros de post its podem ser excelentes ferramentas, mas cuidado para não abusar da coisa.  Ter a preocupação de pensar nas cores, letras, tamanho de fonte,  são coisa extremamentes válidas e garante um bom retorno no objetivo de comunicar, porém isso sempre fica num segundo plano e na maioria dos casos ignorado.

Bem amigos, enquanto não tivermos evoluído o suficiente para termos telepatia e ler mentes, ou algo parecido, vamos depender, e muito, da comunicação.  Por isso trate-a com carinho em seus projetos e dedique um tempo para trabalhá-la de forma a ser a melhor coisa o possível e verá que os ganhos vão pagar cada sacrificio feito nesse sentido.

Esses dias li um e-mail numa lista de discussão que participo onde a pessoa perguntava como ela deveria fazer para documentar um projeto que ele desenvolveu sozinho. Ainda segundo ele, a ideia é de permitir que num futuro próximo um novo desenvolvedor possa trabalhar no sistema sem traumas e com uma curva de aprendizado rápida.

Antes de tentar responder a pergunta, acredito seja necessário entender a diferença entre análise e documentação.  Muitas pessoas que trabalham com  criação de softwares, acabam confundindo documentar com analisar.  Essa dúvida é normal pois muitas “ferramentas” e “métodos” também se apresentam como opção de documentação, ou o contrário : coisas que deveriam ser usadas para documentar são usadas para fazer análise ( e até acabam com uma má fama sem terem culpa disso – puro mal uso). Um exemplo disso, no meu ponto de vista, é o uml : Muitos usam a UML com o propósito de analisar e modelar. Ela até foi criada com esse intuito pois, quando foi concebida  era bastante custoso codificar e alterar o código feito (lembre-se dos cartões perfurados, cobols da vida, etc) mas hoje isso já não é válido (com linguagens modernas, codificar é rápido e alterá-lo mais ainda). Voltando, UML, no meu ponto de vista, é muito mais documentativa do que modelagem.  Seus diagramas tem um ótimo apelo de representar graficamente um sistema e como diz um ditado: “Uma imagem vale por mil palavras”.

Um outro mito a ser desfeito, insisto, no meu ponto de vista, é de que documentar não agrega valor. Por mais que ninguém diga isso, por mais que ninguém escreva isso, por mais que ninguém assuma isso, muitos de nós considera o ato de documentar como uma atividade secundária, e com isso, delegamos para que outros façam ou, em piores casos, nem o fazemos. A questão que ninguém escreve um sistema para si e, na maioria dos casos, não fazemos isso sozinhos.  Outro ponto é que, possivelmente, não ficaremos para o resto de nossa vidas com aquele projeto, passaremos para outros desafios e aquele sistema deverá ser cuidado por outro pessoa que não necessariamente participou da equipe que o desenvolveu. Tal fato, implica em ter que forma esse pessoa de forma que ela possa dar continuidade ao aplicativo sem comprometer a qualidade dele (estou assumindo que seja aqueles projetos onde temos testes automatizados, linguagens bem expressivas, etc). Logo, tendo todo esse contexto em mente, fica fácil mostrar que documentar, no mínimo, é evitar dores de cabeça futuras.

Mas, enfim, como documentar?

A pergunta poderia ser redigida da seguinte forma para ter mais sentido para nós : Como podemos documentar sem que isso seja uma atividade secundária e agregue mais valor ao sistema? .  A maioria das linguagens modernas oferecem recursos, bastante interessantes, que podem responder essas perguntas. Em Java, nós temos o recurso básico do JavaDoc (comentários em formato especiais que são colocados no código fonte. Depois, através de ferramenta exportamos para um html), em .NET (csharp) temos algo parecido, e por ai segue. Embora isso já seja algo que ajude, considero insuficiente como documentação pois, quem irá ler não terá uma visão do funcionamento ou do comportamento do sistema.

Nesse contexto de comportamento e funcionamento que entram a ajuda primordial dos teste automatizados. Um efeito secundário dos testes automatizados (tanto os teste unitários quando os testes de comportamento) é de, se bem escritos e de grande abrangência,  eles acabam sendo uma boa fonte de consulta para o entendimento da aplicação.  Existe, inclusive, frameworks de teste de comportamento (Behavior Tests) que permitem que se escrevam de forma literal facilitando ainda mais o seu uso como documentação, como por exemplo o Cucumber (Ruby), Pyccuracy ( espero ter escrito certo – Python), etc.

Por fim, eu pessoalmente, acredito que um bom diário de bordo também ajuda bastante. Um diário de bordo, consiste, em algo parecido com um blog ( pode até ser um blog), em que vou escrevendo o dia a dia do desenvolvimento tentando retratar as decisões não técnicas e situações vencidas pela equipe de forma que a pessoa que irá trabalhar com o sistema no futuro tenha também uma visão do por que de certas escolhas, do sentimento da equipe naquele momento, etc.

Recentemente li um artigo do Martin Fowler (já tinha lido, mas praticamente o reli com outros olhos)  onde ele discute a questão do design e da análise dentro do mundo ágil, mais precisamente o XP (Extreme Programming).  No artigo, cujo título é “Is Design Dead?”, Fowler discorre sobre vários tópicos e tenta ver se é realmente um fato que com a adoção de  metodologias ágeis, o uso de padrões, análise prévias e design se tornaram práticas mortas

Dentro do times ágeis, existem diversas premissas que devem ser adotadas para que se possa colher todas as vantagens que ele oferece.  Algumas das mais famosas são:

• Faça o justo necessário:  não faça aquém nem além do que deve ser feito na iteração
• Refatoração : sempre que puder melhore o código
• Foco nas tarefas que agregam valor na visão do cliente
• Fazer o simples e depois evoluir o código de acordo com a necessidade.

Fazer o justo necessário é de focar em gerar valor para o cliente. Aqui a principal mensagem está em evitar tarefas que no final não geram retorno. Exemplo: o tme que gasta horas para criar um modelo de dados;  times que gastam considerável soma de tempo para escrever  bibliotecas para fazer algo que não esteja ligada a funcionalidade que o cliente deseja  naquela iteração (api de log, api de para ler o xml de configuração, api para tratar string, etc). Nesta ideia também se encaixa a questão de evitar tarefas que não agregam valor para o produto.

A Refatoração constante do código significa mais que simplesmente rescrever trechos de código e sim, uma busca constante por simplicidade, qualidade e por programas legíveis. Uma coisa que os mais novos sempre erram é de ter uma visão simplória do que venha ser Refatorar : não é simplesmente acerto de escopo de variável,  comentar, etc.  Refatorar, em XP principalmente é “alma do negócio”.

Quando se diz – ” Fazer o simples e evoluir“, você está comunicando ao seu time que é desejável que façam coisas simples. A medida da necessidade do projeto, os modelos, arquiteturas, etc., vão evoluindo e ganhando os recursos necessários para resolver os problemas.  Dentro da refatoração existirá, também, o espaço necessário para a melhora.

Fazer ou não fazer análise em projetos ágeis ?

Diante do que disse antes, principalmente de evitar atividades que não agreguem valor, os mais puristas, diriam que fazer analise ( estudo, diagramas, etc para entender a arquitetura e quais seriam os requisitos técnicos)  é algo que não deve ser feito. Iriam além estes mesmo: afirmaria que tal prática é ultrapassada e que de nada server.

Bom, eu discordo. E se me perguntassem isso, responderia:  - “Depende ! “

Se estamos falando de um sistema simples, cujos os requisitos são extremamente claros,  fazer analise pode ser um passo a mais que poderia ser retirado. Ou então, considerado como um história de documentação que deve ser tratado no backlog ( mas com baixa prioridade de acordo com a visão do cliente). Porém se estamos falando de sistemas cujo o processo a ser gerido é complicado  e/ou com regras de negócios complexas, uma fase, por menos que seja, de análise ajudaria até melhor entender os requisitos. O problema está que muitas equipes de desenvolvimento tornam o resultado de uma analise uma verdade absoluta e imutável.  Bem, isso não pode ser verdade pois o cliente vária vezes nem ter certeza do que quer e ao longo das entregas que começa a desenhar melhor sua necessidade e desejo.

Analisar previamente ajuda a diminuir riscos e a nortear, de certo modo, a visão do time na hora de implementar.

Entretanto, ao realizar uma analise, podemos pensar como um rascunho do Niemeyer de um prédio novo. Serve apenas para ter um impressão inicial não muito clara do que iremos realizar.

Quem usa XP não adota padrões?  Não define arquitetura?

Esta aí outra coisa que não gosto e nem concordo em ouvir.  Bem, os padrões não são ruins, são as pessoas que abusam do direito de usá-los.  Já vi gente fazendo um site para 10 pessoas (coisa interna de uma empresa) cujo o escopo é limitado e quase nunca evolui, colocando milhões de camadas, milhares de DAOs, VOs, etc.

Muitos poderiam dizer, principalmente os defensores mais ferrenhos, que devem sempre fazer as coisas simples.  Minha resposta : no final, caso faça algo descendente, é bem possível que “esbarre” num padrão.

Outra coisa que não concordo é a questão de não se discutir arquitetura… Para um projeto pequeno, você pode se dar ao luxo de não pensar nisso, pelo menos, num primeiro momento, mas para projetos grandes, tem que pensar nos componentes pois isso influirá diretamente na forma que time irá implementar as coisas. Novamente reforço que, quando sugiro usar padrões, não é pegar o livro e fazer tudo que está dizendo ali. Nada nos impede de adaptar a sugestão para nossa realidade.

Rebeldia  e revolução a parte, sempre vou dizer que o melhor caminha continua sendo o do meio. Ficar com o melhor de todos os mundos é o paraíso a ser desejado.

Muito sem tem dito, hoje, sobre a questão da gestão de projetos. Nisso, incluo a famosa atual discussão da aplicação de metodologias ágeis, que antes eram práticas aboninadas, frente aos sucessivos fracassos que as gestão waterfall (gestão de atividades em cascatas cuja a imagem mais forte são os gigantescos cronogramas em gráficos de Gantt). Embora exista, de uma certa forma, um guerra entre os padrões – ora um diz que é melhor por um motivo, ora outro diz que não é nada disso, ambos mostram casos de sucessos e erros dos outros e por ai vai – existe pontos bastante comuns  em seus discursos, como por exemplo: foco na satisfação do cliente, busca por altos rendimentos – produtos entregues mais rápido, com maior qualidade, etc.

Ninguém está errado em querer focar em agradar seu cliente, muito menos na busca por maximizar seus lucros ( vender mais e gastar menos para realizar, etc). A questão que gostaria de discutir é a mensagem vinculada que vem sendo dita por ambos que remete a querermos trabalhar sempre próximos de nossos limites (alta disponibilidade, entregas super rápidas, e outras coisas parecidas)

Não é errado quere maximizar os trabalhos. O problema está em sempre querer usar e fazer as coisas no limite ( para cima ou para baixo)

Outro dia  conversando com um amigo,falvamos da situação atual onde temos empresas onde tudo é maior, melhor, alto, etc. Empresa, que devido a uso de alguma metodologia “bala de prata” , as entregas são super rápidas,  projetos com alta tecnologias,  sistemas com as últimas novidades, e (ufa!) por ai seguem.  Tudo feito no limite, tudo é SUPER (quando digo limite falo do fato de todos terem desempenhos fora do comum). Se me permitem a brincadeira, é  verdadeiro local de trabalho de sobre humanos, pois trabalhar sempre no limite máximo é algo bem difícil para nós mortais. É como se tivéssemos “pessoas” correndo a velocidades de provas de 100m durante uma maratona. Para seres humanos comum é algo que dá para fazer nos primeiros 200m mas depois não dá… simplesmente não dá.  A gente acaba “abrindo o bico”

Não seria nenhuma surpresa se numa empresa como esta surgissem pessoas tendo crises de estresse (com variações agudas como por exemplo sindrome do pânico), pessoas com saúde comprometida, um número razoável de pessoas acima do peso, pessoas fumantes, etc. Considerando que ainda não temos super -homens por aí, ao não ser nos filmes e novelas (ehehehehe), mais cedo ou mais tarde algo deve acontecer.

Alguns pensam que podem correr um maratona mantendo a velocidade de corredores de 100 m. Simplesmente não dá e acabam que não completam todo o percurso.

Existe um preceito budista, no qual eu acredito que é : ” O melhor caminho é o do meio” . Diz alguns historiadores que Buda ( na época o princípe Siddhartha Gautama ) em seu caminho para a iluminação começou tentando seguir pelo caminha dos homens santos hindus fazendo jejuns, e se submetendo a sofrimentos como forma de purificar.  Foi quando num dia de meditação percebeu que o caminho não estava no limite e sim no meio termo.  Não podemos deixar ir sem regra alguma mas também não podemos colocar todas as restrições. Devemos buscar o equilibrio para nos tornar sustentáveis na caminhada da iluminição.

Equilibrio

Antes que comecem a dizer que estou ficando maluco e escrevendo coisas sem nexo algum, vamos traçar a correlação dos preceito budistas e trabalho.

Me assusta um pouco o fato de que atualmente, muitos tentem vender o uso de metodologias ágeis como um forma de aumentar o rendimento da empresa. Isso, num primeiro momento pode soar até inocente, mas para um empresário, isso irá soar como aumentar lucro.  A questão que quem está mostrando a idéia esquece de dizer que é verdade que melhora a qualidade e a velocidade do time de desenvolvimento (na maioria dos casos) mas isso não é para ser usado como motivo para aumentar a carga de trabalho da equipe e sim permitir um equilibrio maior. Tal equilibrio significa fazer menos horas extras, ter uma jornada de trabalho mais leve e que permita as pessoas irem para suas casa felizes e ainda com energia para conviver com suas famílias, ou então, realizarem outras atividades como esportes, estudos, etc. O mais engraçado disso que relendo o manifesto agil e alguns textos mais antigos sobre o assunto notei que, eles sempre carregam uma mensagem de foco no humano… na visão do profissional não como recurso e sim como individuo e trabalhador criativo que tem necessidades a serem atendidas.

Outra palavra chave que quero adicionar a nossa equação é : SUSTENTABILIDADE. Modelos que andam no limite não são sustentáveis… pois trabalhar sempre na modalidade de capacidade total significa maximizar também os desgastes.  A natureza mostra que devemos sempre buscar uma velocidade de cruzeiro, ou seja,  um rendimento tal que possamos andar bem mas sem tocarmos as fronteiras do recurso ou pessoa. Sustentabilidade também tem relação com pensar no futuro. Por isso, sempre querer inovar em tudo, pode acarretar em não ser sustentável no médio nem no longo prazo.  Viver trabalhando com as  últimas novidades ou com padrões, que ainda não estão totalmente difundidos no mercado, é buscar um vida dificil  para o Rh. Pois as pessoas que lá estão hoje, por gostarem de novidades, logo mudaram o foco de seu interesse para outras coisas e aquele sistema ficará, lá, legado a ninguém pois, ainda não existem profissionais disponiveis no mercado com o tal conhecimento.

Por isso, volta a frase:  ” O melhor é o caminho do meio”.  Temos sim que tentar aumentar nosso tempo de resposta a projetos, ajudar as empresas a ganhar dinheiro, entretanto é importante também garantir a sustentabilidade do processo e das pessoas.