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.

Outro dia no meu trabalho estava desenvolvendo em par com o Bernardo Heynemann e comentei com ele que por vezes sentia falta de uma IDE de desenvolvimento pois “ajudava” muito o autocomplete que tinha com Eclipse quando desenvolvia com Java. Na mesma hora ele me “corrigiu”dizendo que um editor de texto é ferramenta mais que suficiente para se desenvolver, desde que, a tecnologia (entenda a linguagem / plataforma) seja boa.  Confesso que fiquei com aquela conversa na cabeça tentando digerir o que ele tinha me dito.

Como assim boa? Java não é uma linguagem boa? Bem nem vou me aventurar por este caminho pois sei que acabará tendo milhões de xiitas de diferente lados querendo me “queima vivo”.  A questão é que quando a coisa é concisa e bem projetada, o uso de uma IDE, que tenha recurso muito bons de completar automaticamente, sugestão, organização de importação, etc, se torna desnecessário, pois as coisas são intuitivas e naturais.  Um bom exemplo sempre ajuda.  Se temos dentro de um biblioteca (api, app, ou qualquer outro nome que queira) métodos e arquiteturas simples que representam bem o domínio do problema que elas pretende resolver, você verá que vai descobrir seu funcionamento de forma natural e errará muito pouco.  Imagine que você tem um boa api de envio de SMS. Ela com certeza terá uma função, interface, método, que enviará o SMS com um nome sugestivo ou parecido a enviaSMS.

Pode parecer idiota mas não são raros os casos que fogem a este bom senso. São muitos que de forma consciente ou inconsciente criar verdadeiros monstros com coisas do tipo:  session_factory.instance(); factory.correct_impl, factory_receive_valor({chave:valor}); executor = Executor.new; executor.processa(factory,out);

De propósito misturei algumas sintaxes para que não caracterizasse nenhuma tecnologia especifica. O que mostrar que algo monstruoso como acima, serviria para imprimir uma mensagem de “Hello World” na console.  Novamente insisto que o exemplo pode parecer óbvio que é exagerado, mas existem coisas ai fora nesse nível.

Voltando a questão da IDE e a conversa com o Bernardo, finalmente caiu a “ficha”: quando se tem algo bem feito, um editor de texto basta. Para botar um tempero na coisa, quero sugerir um teste para meus leitores Javeiros: tentem durante um dia inteiro de trabalho somente usar um editor de texto de sua preferência. Pode ter cor para realçar sintaxe mas nada de sugestão e completar automaticamente.  Sei que alguns conhecido vão rir disso pois já fazem assim com qualquer linguagem que trabalhem, mas desde que Java cresceu muito, muitos esqueceram que existe um javac para compilar as classes e nem sabem mais usá-lo embora sejam considerados senior em suas atividades.

Ai vai mais um aviso: antes que peguem suas tochas e foices para me perseguir e matar, não estou dizendo que vocês são ruim ou fracos, estou dizendo que a tecnologia pode não ter ido para uma direção legal.  Isso também se aplica a outras linguagens. Veja C# ou qualquer outras coisa .NET; C++, etc. Tenta se entender com classpath, compilar as classes em uma pasta, organizar o diretorio de saída, construir um arquivo para fazer um deploy da aplicação (se for web ou enterprise ai a coisa fica ainda pior), na “mão” e ainda ser produtivo. Eu dou a colher de chá no desafio acima para usar o ANT e até o maven.

A um certo tempo atrás, numa empresa onde trabalhei, ganhei o apelido de “leitor de javadoc”. Isso porque sempre que podia olhava o javadoc para ver as explicações das classes, quais métodos, quais recomendações. Para mim, este tipo de inciativa que contribui para uma boa solução. Em python, sempre temos a oportunidade para irmos para interativo e digitar o dict para inspecionarmos algo. Em Ruby  você tem uma documentação tão boa quanto javadoc, etc.

E novamente volto ao ponto inicial da conversa:  sem falsa demagogia ou interesses maldosos, para um bom desenvolvedor usando uma boa tecnologia, um simples editor de texto basta.

Até a próxima pessoal. E aguardo os comentários de vocês com críticas, respostas e opiniões sobre o assunto.

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.

A pouco tempo consegui um brecha com ajuda da minha colega Arlene para implantarmos no projeto que estou trabalhando teste automatizados.  Com a carta de alforria em mãos partimos para pesquisar no mercado qual seria a melhor que se encaixaria em nosso contexto de aplicação.  Para que entenda,  trabalhamos com desenvolvimento de portal usando a ferramenta Lumis (eu trabalho na Lumis!!!).  Portais são aplicações bastante difíceis de serem testadas de forma automática; devido a questão do conteúdo dinâmico e pouco previsível não existe muita margem para que busque por padrões.

Com estas limitações em mãos, acabamos nos deparando com a api WebDriver . A um tempo atrás eu já tinha mexido um pouco com o selenium e adorei. Com isso, tentei achar algo que se assemelhasse a ele mas que me facilitasse a vida em relação a portais ( não tem muito como usar ids dos elementos no html, url não fixas, etc) . O webdriver, ao contrário do selenium, não é um javascript que executa dentro de uma página simulando a navegação… o webdriver é realmente um “envelope” em cima do seu navegador.  No caso do Firefox ele é uma extensão, no caso do Internet Explorer (blargh) ele usa as chamadas de control que ele proporciona, e por ai vai. Com isso, os teste ficam mais próximos da realidade de uso do usuário, e a api para escrever  os cenários mais simples.  Veja o trecho:

Pelo exemplo acima fica fácil de ver o quão fácil é criar um teste em webdriver.  Recomendo experimentar

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.

E dando seguimento a serie sobre algumas coisas interessantes sobre o desenvolvimento, vamos para mais um novo capítulo.  [OFF] São tantas histórias vou acabar escrevendo um romance [/OFF].   Após a repercussão do primeiro artigo de mesmo nome, alguns conhecidos me procuraram para dizer que, existiam outras situações que poderia abordar dentro da série.  Uma dessas situações foi sobre estruturas de equipes de desenvolvimento e  com isso, acabei  me lembrando de uma época,  numa dada empresa, em que tínhamos a figura do revisor de códigos. É isso mesmo que você leu, meu amigo …revisor de código.

O revisor de código é o cara que após você ter implementado toda  a solução, antes de você colocar as sua alterações no CVS  (meu deus, antigo), ele vem e verifica se o seu código está bom, onde bom, significa dentro de um padrão que não está em lugar que não na cabeça dele.  Antes que me apedrejem em praça pública,  sei que nem todos são assim, e que em muitos tinha ou tem, regras de estilo bem claras e até automatizadas através de plugins em suas IDEs.

Revisar o código não é uma atividade ruim. Ter premissas de estilo e formatação é algo interessante pois padroniza e pode facilitar qualquer pessoa, que esteja acostumado com os padrões da empresa, ler o fonte e entender.  Essa preocupação, inclusive,  tem sido tema de discussões muito atuais e serve até de argumento para definir o uso ou não de linguagens ( sendo mais específico, são questões como expressividade, legibilidade, etc – suggar sintaxe) . A questão que eu coloco é isso passar o limite do bom senso e do razoável e se tornar uma ditadura sem direito de questionamento.

A própria situação de ter uma única pessoa responsável por zelar pela qualidade do código para mim já é algo péssimo.

Mas então? Qual é o melhor cenário?  O que pode ser feito, já que eu disse que qualidade e estilo são bons, se ter alguém revisando é péssimo?

Alguém aí, por acaso, disse … Programação em par!?!?!? Bingo!!!   Essa, no meu entender, é um bom caminho.  É bom, pois permite a troca, a interação. É bom, pois permite, que a responsabilidade seja de todos e não somente de uma única pessoa. Tira gargalos ( quem nunca ficou parada esperando o revisor ter tempo para ver e validar a implementação).  O time como um todo decide o que é melhor.

Nesse cenário as chances das coisas serem menos impostas e mais consenso são grandes. Não existe um ponto único e sim diversidade de visões.  O time fica aberto e sempre como abertura para melhorar ou experimentar, desde que todos concordem ou pelo menos seu par, que aquilo traz algum valor.

Observem – bem lembrado por um colega – que nem toquei no fato de revisão de tecnologia, arquitetura.  Na velhas e empoeiradas estruturas de fábrica,  tem casos em que além do revisor, tem ainda o grande e todo poderoso arquiteto que decide quais tabelas, quantas classes, como as classes são, qual linguagem, api, framework, qual papel higiênico, que  todos devem usar.  Para mim isso consegue ser pior que o revisor. Pois ele tolhe a inovação, o salto para frente.  não quero dizer com isso, que devemos fazer de nossos projetos um laboratório de novas linguagens e etc… estou dizendo que se existe algo que venha a facilitar porque não pelo menos olhar o que é …

Novamente transferir essa “responsabilidade ” para o time é a melhor coisa.  Pois se discute. Todos tem voz.  A chance de escolher algo interessante é maior… não fica a cargo de um louco que pode ser um tarado por novidades ou um louco que nunca deixará de usar Java 1.3.1 pois sempre funcionou e “não se mexe em time que está ganhando”.

Bem esse era meu recado… aguardo as opiniões de vocês.

Mais uma vez, devido a uma outra troca de e-mails,  vi um outro assunto super legal que gostaria de dividir com vocês.  A um certo tempo atrás, no blog do Calcado, li um artigo sobre o fato de objetos não serem atributos + funções. Neste artigo, o Calcado, mostra que os objetos ao invés de possuírem atributos e funções, eles na verdade possuem estados e comportamentos.  Reproduzindo um trecho do artigo :

Objetos não possuem propriedades + funções, eles possuemestado + comportamento. Você provavelmente vai usar atributos (i.e. variáveis de instancia) e funções (de instancia também) para implementar isso mas é um detalhe de implementação, não algo que deva ser exposto [sic]

Uma outra coisa que penso é que além disso que ele comentou, uma outra dificuldade que vejo no pessoal que está “montando” a arquitetura de sistemas, é definir como será a interação entre objetos.  Quem nunca ficou horas pensando onde colocar determinado método – “o método calcular preço  é da loja ou do produto?“; nome do método,  se deveria expor dados por get e set, etc .  Essa dúvidas vem da nossa visão equivocada da troca de dados entre objetos.

Se considerarmos que objetos não possuem métodos ou funções( função me parece tão modular e não OO) e sim “portas de entradas”.   Essas portas são como caixas de correio por onde enviamos e/ou recebemos mensagens com pedidos ou informações.  Para ficar mais fácil de entender,  imaginemos a situação de uma grande rede de lojas.  Esse grande rede possui diversas lojas, que possuem diversos produtos e clientes.  De cara, podemos dizer que temos 3 entidades :  Cliente, Produto e Loja.

Agora a pergunta: como você implementaria a lógica de obter preço – o cliente vai na loja, pega um produto e quer saber o preço.  Tenho certeza que alguns diriam que colocariam um método getPreco na classe de produto.  Outros fariam um PrecoControlador que pegaria o custo do produto e faria a operação de cálculo pegando a margem de lucro da loja, custo da loja e por seguiria…. Outros inventariam a classe preço que diante a loja e produto se calcularia….  De novo fazendo assim ainda estamos pensando em objetos como conjunto de funções e atributos e esquecendo da troca de mensagens.

Uma forma que vejo mais simples e mais expressiva de fazer (logo fica mais claro para entender o sistema) seria de perguntar para a loja o preço. Sendo assim, o cliente teria um produto e perguntaria a loja o preço. A loja consulta sua tabela de preço e responde.

Cliente  – pega produto —  > Produto

Cliente — informa o produto a loja –> Loja

Loja — consulta tabela –> Tabela

Loja — responde ao cliente –>

Fica bem elegante não… Mas se ainda não conseguiu ver:

class Andre  extends Cliente

…

Produto lapis = new Lapis();

double preco = lojaAbobrinha.qualEhOPreco(lapis);

..

Abobrinha extends Loja

…

double qualEhOPreco(Produto produto)

minhaTabelaPreco.qualPrecoAtual(produto);

Quem for fazer a manutenção do código,  só de ler, já começa a entender oque está acontecendo e começa deduzir as demais interações.

Pessoal, hoje li no blog Agile Buddy do Jack Milunsky um interessante e pequeno artigo em que ele reflete sob qual seria um bom dia da semana para começar e terminar o sprint.  Eu tomei a liberdade de escrever uma versão em português para vocês. Caso queiram ler o original cliquem aqui

Primeiro, que fique claro que o tamanho dos sprints sempre devem ser consistentes.De qualquer jeito, experimente 1 fazer sprints com duração de 1, 2 ou 3 semanas mas uma vez que acha o melhor cenário adote-o e siga-o. Isto é importante para definir um ritmo na empresa. Entretanto, a questão é quais dias são os melhores para começar ou terminar o sprint. Até agora, eu tenho sido um fã de começar na segunda e terminar na sexta-feira. Me parece ser uma cadência natural e os dias acabam por se tornar pontos de transição lógica.

Porém, nesta semana, houve uma discussão no forum de desenvolvimento Scrum, e um número razoável de pessoas disseram ser a favor de começar não na segunda e sim na terça; terminar na quarta e não sexta. Os motivos para isso foram os seguintes :

1 – Existem muitos feriados na segunda e sexta que acabam por interromper o ciclo e com isso o ritmo.

2 – Se tiver algum problema no sprint e ele termina na sexta, isto possívelmente forçará o time de trabalhar no final de semana – algo normalmente evitado pela comunidade ágil.

3 – Sexta feira acaba sendo um dia não muito produtivo pois o pessoal tende a se dedicar a demos, restropectivas, etc.

Pelo aprendizado, eu preciso experimentar isso.

Qual tem sido sua experiência?

Jack

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.