Blog do Andre Fonseca

A muito tempo venho pensando em uma coisa: O que acontece quando mudamos nosso foco para a direção das pessoas? Se ao invés de focarmos em obter mais lucro, mais dinheiro, mais bens, melhores processos,  equipamentos mais rápidos, a gente simplesmente focasse na pessoa… na pessoa na forma do cliente, na pessoa e sua qualidade de vida, na pessoa que usará aquele novo equipamento, etc.

Existe um grupo de pessoas aqui no Rio, mais especificamente ligados a TI (desenvolvedores, designers, etc)  que proporam exatamente isso:  miraram no ser humano. Isso vem galgado no Small Acts (acesse o link e leia pois vale a pena).  Ao fazermos isso, centra nossas atenções nas pessoas, os resultados foram surpreendentes e nossas ações tem tido repercussões até inesperadas.  São eventos em que, por pura paixão, vamos e levamos toda a nossa “energia” (nenhum de nós ganha dinheiro palestrando, ou fazer qualquer outra coisa afim), são encontros que para muitos parecem organizados e ultra focados como grupos de usuários sendo que na verdade estamos ali para conviver, rever amigos, tomar um chopp e como bons nerds que somos acabamos por falar de tecnologia e similares.

E claro que por vez ou outra surgem boas iniciativas dentro desse encontros e elas, por sua vezes,  em alguns casos viram excelentes projetos e ficam famosas. Mais tudo isso acontece não porque se quer ficar rico ou famoso. Mas porque acreditamos sinceramente nas pessoas e queremos levar essas coisas, que consideramos legais, para as pessoas.

Pode soar para muitos como algo idealista e utópico. De certa forma, olhando friamente e tendo como base o “restante” da sociedade, realmente é.   Entretanto, quando estamos ali fazendo para nós não passa de diversão. Por muitas vezes, me pus “de fora” e fique observando: parecíamos crianças empolgadas.

Insisto que ainda parece um tanto utópico nesse nosso mundo consumista mas quando o foco deixa de ser o lucro, o processo, a empresa e passar ser as pessoas realmente coisas mágicas passam a acontecer. Isso eu falo e qualquer nível de relacionamento. Se pegarmos uma loja e fazermos com que a equipe foque na pessoa e não no dinheiro do cliente veremos vendas aumentar, satisfação do cliente, aumento da propaganda boca a boca, etc. Se pensarmos em ambientes de trabalho, quando temos gerentes “humanos”que focam na pessoas de seus funcionários e não os encara como recurso, todos produzem mais, ficam mais felizes, as coisa fluem sem atritos, etc.  Isso pode ser extrapolado, ouso dizer, para qualquer situação.

Claro que em TI isso não pode ser diferente e ao meu entender possui uma dimensão mais interessante. A maioria das pessoas que trabalham com TI são pessoas que gostam de máquinas. Sim…. elas gostam de máquinas: são seus celulares, seus computadores, seus gadgets, seus video games, e o que mais vier. Poucos são aqueles que gostam de convivência. Isso é algo que para o profissional de nossa área deve ser vencido. Quanto não são os gênios que simplesmente travam quando tem que estar dentro de uma equipe? Quantos problemas temos no desenvolvimento por problemas que nada tem relação com a tecnologia e sim com as relações pessoais da equipe? .

O foco nas pessoas faz que com isso tudo se inverta e verdadeiros progressos se façam. Ao focar na pessoa, os processos se humanizam e passam a levar em consideração essa dimensão. Com isso eles se tornam mais próximos da realidade. Mas factiveis. Softwares são feitos para seres humanos, em sua maioria. E por isso, em sua concepção devem ter o foco no ser humano e não da linguagem, na máquina, etc. Isso que chamamos de experiência do usuário e que vem sendo perseguido pelos grandes players do mercado.

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