Building Minds - o Blog da OnCast

Em 2003 tive a grande oportunidade de conhecer o uso de testes automatizados. Na mesma ocasião fui apresentado ao XP e ao Lean Software Development por um colega chamado Gustavo Hartmann.

Naquele tempo eu trabalhava em meio ao caos, como muitas empresas brasileiras de software, diga-se de passagem. Triste é saber que ainda hoje, não é difícil de encontrar empresas que atrasam sistematicamente suas entregas e, quando entregam, o resultado normalmente é um produto cheio de defeitos que normalmente são descobertos só pelos clientes. Para resolver este problema, as empresas adicionam um período de testes ao final de cada ciclo de desenvolvimento. O problema é que ao invés de apenas testar, elas começam a corrigir problemas. Estas correções, por sua vez geram outros (d)efeitos colaterais, que enfim fazem com que os prazos estourem.

Ainda não comentamos da qualidade do código gerado em tais ambientes caóticos, um código que muitas vezes nem mesmo os programadores mais experientes querem mexer. Eu particularmente já vi métodos com mais de 400 linhas de código, com dezenas de IF’s aninhados e estruturas procedurais - sem contar as classes com mais de 5000 linhas - detalhe: sem documentação de código e com inúmeros comentários que sujam o código e deixam-no praticamente ilegível.

Soma-se a isto uma arquitetura (se é que se pode chamar isto de arquitetura) totalmente acoplada e sem testes. O resultado desta equação é realmente um desastre. Um custo altíssimo de manutenção. A praticamente impossibilidade de responder as mudanças, e também clientes insatisfeitos.

Infelizmente a equação do caos ainda não está completa. Precisamos mencionar que as estimativas foram feitas pelo departamento comercial, que disse ao analista de negócios o que deveria ser feito. Este, criou centenas de documentos e entregou ao analista de sistemas que projetou o sistema e passou um punhado de diagramas para os programadores desenvolverem o código. Os coitados dos programadores tinham que virar noites trabalhando para tentar minimizar o atraso e quem sabe, conseguir entregar o que os clientes realmente necessitavam. Os gerentes, preocupados em dar visibilidade à direção, não paravam de perguntar: e aí… está pronto?

Em ambientes como este, vale a lei do mais forte. Para ser mais forte, é preciso segurar a informação, diminuindo a colaboração. A pressão torna-se opressão e de maneira alguma, criatividade e inovação podem surgir de tais ambientes.

Felizmente, tive a oportunidade de conhecer o Gustavo. O Gustavo é um cara que não fala muito, mas age. Ele chegou novo no time, em meio ao caos, e não disse que tínhamos que escrever testes, simplesmente começou a escrevê-los. Um belo dia eu achei estranho o que ele estava fazendo e resolvi perguntar. A resposta foi: pensas que vou fazer um código sem escrever um teste antes? Fiquei tão intrigado com aquilo que pedi para que me ensinasse. Logo em seguida peguei o rumo do ágil e comecei a praticar e estudar XP. Percebi que XP foi desenvolvido sobre os conceitos do Lean. Nesta oportunidade, a Mary e o Tom Poppendieck tinham acabado de lançar seu primeiro livro, e o Gustavo - esperto que era - já tinha comprado. Eu mais esperto ainda tomei emprestado. Foi então que percebi que aquilo seria realmente um divisor de águas na minha vida, e foi.

A partir daí, os projetos em que participei tiveram uma performance no mínimo 3 vezes melhor do que os projetos a minha volta. A qualidade do código, dos testes, da documentação e principalmente do relacionamento entre a equipe e os stakeholders melhorou muito.

Hoje, com pelo menos 7 anos de experiência com ágil e no mínimo 4 deles com uma incrível equipe que é a equipe da OnCast, venho experimentando projetos de sucesso, um atras do outro. Graças a um conceito que o Gustavo me ensinou e hoje é fundamental na indústria de software. Graças a uma excelente equipe com a qual tenho o prazer de trabalhar todos os dias. Graças ao meu Deus que me possibilitou conhecer o Gustavo

E por tudo isso, e porque sabemos que o Lean fez a diferença, que resolvemos fazer o Pensando Lean, para que outras empresas possam saber como pensamos e como desenvolvemos software na OnCast e, especialmente, para que aprendam e evoluam e ajudem-nos a criar um indústria de software mais saudável.

Aproveitem o evento…

Samuel Crescêncio Outros

Agile 2010 was for me one of the best, if not - the most outstanding agile conference that I’ve ever participated. Besides having the opportunity to give a talk about the Lean Pyramid Concept, which for me is awesome since it was the first time giving  a speech in English, I was also elected for the Agile Alliance Board of Directors.

Agile Alliance (AA) is for me a very respected organization, which have been helping with the transformation of the whole software industry over the last 9 years. AA played a very important role in my life as a software engineer. Since 2003, when I embraced agile, I’ve been able to transform the environments around me by delivering and helping others to deliver better software. In order to deliver better software though, I needed to improve my knowledge, and I remember how the AA article library helped with that. The AA and the Agile Manifesto also have defined a clear vision of what we know as Agile. I quickly understood that XP, Lean and Scrum followed those principles and values. Studying and applying new techniques coming from theses methodologies and understanding the principles behind them, provided me with a much better capacity to faster deliver high quality software products.

The most interesting thing however, is that I recently realized that my goal is not to build software, but just to help people to solve their problems. Sometimes people will need software for that, and I’ll be able to help them solving their problems with software. Although, If I’m able to solve their problems without writing code, it’s certainly much better, easier and cheaper. And I just understood this through a profound reflexion on how the agile movement changed my life.

My involvement with the agile community is just the expression of this desire to help others. I like to share what I know and I like to learn what I don’t know. And now, I want to learn how to help AA, the organization that have helped me to transform my life, to achieve its own mission. Serving the board is certainly going to be a good challenge and also a priceless opportunity to learn from the most brilliant minds in our software industry.

This conference was e really outstanding opportunity to enhancement of my network. I got to know new people and this has provided me a great opportunity to learn. I really learned a lot at this conference, even not attending many sessions.

I arrived in Orlando after a long 10 hours flight, plus more 6 hours waiting connections. As soon as I arrived on my hotel room, I started refactoring my presentation. I had decided to do this 2 days before my departure, stimulated by the feedback that I received from the OnCast folks. I created a whole new flow to explain the the Lean Pyramid Concept which took me till Tuesday morning to finish.

On Sunday I had my first opportunity to meet with the AA board members, followed by nice reception with board members and sponsors. It was really pleasant to meet with a lot of new people at these events..

On Monday morning, I just had a brief opportunity to enjoy the Mary Poppendieck’s workshop about leadership. The most interesting message that I’ve learned at this session was:

“Treat knowledge workers as volunteers!”

Then, on Tuesday I could give my talk and learned a lot from the feedback I received from people who have attended. At the audience I had the illustrious presence of my master - Mary Poppendieck, who also gave me a very important feedback on how to improve my talks. After my session I really felt more relieved, and it was time to start attending some sessions.

The Lean Pyramid on Prezi

I enjoyed the sessions from Gerard Meszaros and Scot Ambler. Both have demonstrated what is important in terms of documentation efforts, when developing software products. Meszaros’ session focused more on what is important before the iteration zero, including steps for product envisioning, product planning and project execution. The Ambler’s session covered also what happens after a product goes to production, what kind of documentation we should keep and specially how to keep this documentation up to date. All the way from concept to cash - in fact. Unfortunately, I still have seen misunderstandings about software documentation, specially from “traditional” companies which are not yet agile. Actually, when developing software products using correctly an agile approach, your software should be much better documented than when using that traditional up-front design, which in turn creates tons of documents that soon will become deprecated and therefore pure waste in your process. We’ve been successfully applying most of the techniques that were presented for several years now, and they have proven to reduce cost of software maintenance over time.

I also had other opportunities to learn from companies that were exposing on the booth area. It was awesome to meet folks from our partner VersionOne and finally get to know people who I’ve been talking to a lot over the last couple of years. It’s good to put a face on a name

Booth Area

This conference has motivated me to create a strategy to make OnCast a real global organization, in order to delivery our services to countries such as from North America and Europe. You can expect to see a slightly different OnCast, with regards to globalization on the next couple of months.

On Friday afternoon, now as a official member of the Agile Alliance Board of Directors, I had my first official board meeting. I’m happy for being able to provide help with the next conference objectives. New things such as the Ágiles 20xx conference series as a program of Agile Alliance are also coming soon. The next board meeting will take place on Sep 30 (my birthday :). I’m looking forward to learn more about how to collaborate with the board.

I believe that the conference organizers have done an outstanding job moving the conference to a completely different venue/location 2 months before the conference. Everything was in place and the conference was really a success. Congratulations for everyone that was committed for that.

For the next conferences though, I would prioritize a more urban city, that could provide more facilities to the attendees to leave the hotel and do some shopping without having to run miles and miles in a expensive cab. Nevertheless, the program, IMHO, would focus a little bit more on technical stuffs, for two reasons: 1 - to provide a way/environment where people could really build new things at the conference, perhaps new testing strategies or things like that; 2 - to reduce the noising that was generated due to a supposed lack of technical sessions which therefore started feelings like “let’s repudiate agile and plan the revolution”. We need to find a way to keep this community growing in a cohesive and innovative way.

All this is for learning and I’m very happy with the results. I hope you had the opportunity to enjoy the conference as I did.

Samuel Crescêncio Outros

Na engenharia civil, você faz um projeto de um edifício, planeja a execução e a executa. E funciona. Não me admira que muitos façam paralelos dessa fórmula para a engenharia de software, se funciona para civil, deve funcionar para para outros tipos de projeto.

Bem, com o passar dos anos, a medida que a idéia de projeto foi sendo inserida na engenharia de software foi se percebendo que não funciona bem assim. Os requisitos mudam o tempo todo, o cliente não tem certeza do que precisa, a equipe tem muitas dúvidas, há muito impedimento, pouco pode ser antecipado. O que é que há de errado?

Foram usados os mesmo conceitos da engenharia civil: planejar, alocar recursos e colaboradores para o projeto, executar. Tudo certo, como devia ser, e como sempre funcionou. Mas na engenharia de software não funcionou! Por que?

Muitos clamaram que construir um edifício é diferente de construir software. Que não se pode mudar uma casa dois metros para direita depois que os alicerces já tiverem sido construídos. Que a engenharia civil tem muito tempo de existência e por isto está madura e que por isso funcionam bem projetos na civil e não no software.

É tudo mentira. Engenharia civil e engenharia de software são sim muito parecidos! Depois de ter passado por inúmeros projetos eu percebi que sim engenharia civil e engenharia de software são idênticos em natureza.

É inegável que planejar tudo a priori e executar não funciona em software. O problema é que ninguém percebe que isso também não funciona em engenharia civil. De volta ao primeiro parágrafo: “Na engenharia civil, você faz um projeto de um edifício, planeja a execução e executa”…

“você faz um projeto de um edifício”… Isso vem antes de planejar a execução. Quando se projeta um edifício como o Gate Capital em Abu Dhabi, ou a ponte da baía de Hangzhou na China, ninguém começa a fazer nenhum tipo de alicerce sem ter a ponte bem projetada antes, nem mesmo a execução da obra é planejada. A falha que se há na metáfora da construção civil para software é que criar software é executar, quando na verdade é projetar.

Quando essas duas obras incríveis da engenharia civil foram projetadas (não construídas) todo tipo de desafio apareceu. Os requisitos mudaram o tempo todo, o cliente não sabia o que queria exatamente, a equipe tinha muitas dúvidas, haviam muitos impedimentos, pouco pôde ser antecipado. Esses problemas só terminaram quando o projeto arquitetônico acabou, exatamente como em software. A erro da metáfora da construção civil não está em hipotéticas diferenças entre civil e software, o erro é que software é 99,999% projeto e apenas 0,001% planejar a execução e executar.

Na fase de projeto você sempre pode mudar um prédio 2 metros para a direita, você pode até ver como ele ficaria de cabeça pra baixo no Cad, ver como iria desmoronar e tudo mais. Fazer simulações de resistência das colunas, testar o comportamento de um modelo contra correntes de vento. Idêntico a software.

Em software a execução é feita por scripts automatizados, eles pegam o projeto (que é o código fonte) e transformam na obra final (o executável para produção). Na engenharia civil o projeto é passado para o planejamento de execução, em software este projeto não são documentos como diz os métodos mais tradicionais, mas sim o próprio código fonte.

O erro foi sempre acreditar que os códigos fonte são os tijolos do edifício, quando na verdade eles são as especificações do edifício. A parte com maior apelo público da engenharia civil é a execução da obra, ver aquela estrutura imensa se levantar do chão ou do mar é sempre muito legal. Mas essa parte em software é trivial, um mecanismo automático faz por nós.

A parte criativa do processo de engenharia civil é que é interessante para a engenharia de software. Os arquitetos de edifícios têm os mesmos problemas dos analistas e arquitetos de software: entender o que o cliente quer, fazer um esboço, apresentar, refazer o esboço com os novos insights, apresentar, criar um modelo (código) e apresentar de novo, refinar e refinar até que as expectativas estejam alinhadas. Os engenheiros civis tem os mesmos problemas dos engenheiros de software e testers: verificar que o modelo está ok, testar o modelo contra as intempéries do ambiente (vento, solo, materiais, performance em produção, integração com outros sistemas), refinar, refatorar o modelo, entrar em consenso e negociar alternativas. É tudo idêntico. E depois que você termina o seu projeto, você roda o build para por em produção.

Idêntico.

Rodrigo Machado Outros

I’m pleased to announce that a couple of months ago I was invited by the Agile Alliance Nominations Committee to run for the Board of Directors of Agile Alliance.

After a careful analysis of the opportunity and it’s requirements, I decided to accept the invitation. I’m pretty sure that by serving to the board, I’ll be able to help Agile Alliance to fulfill its mission and vision throughout South America.

This is a very good step of Agile Alliance towards the creation of a more internationalized organization, in order to provide support and efforts to help other agile communities, such as the South America one, to grow sustainably and effectively.

I would like to invite you to revise the list of candidates and to vote on those you think are more appropriated to accomplish the important duty of serving the board.

I’m quoting a message from Phil Brock where you can find the links to review candidate statements and to vote.

Dear Agile Alliance member:

The Agile Alliance is holding its annual election for individuals to serve on the Agile Alliance Board of Directors.
Please take a few minutes to check out the candidate statements.
You may vote for up to six (6) of the six (6) candidates presented.

CLICK HERE TO VOTE FOR BOTH DIRECTORS AND BYLAWS

Additional nominations will be accepted from the floor at the annual member meeting, to be held during Agile2010 in Orlando, Florida - Wednesday evening, August 11, at 6 pm EDT.

The Board of Directors has proposed updates to the Agile Alliance Bylaws.
You can view the current bylaws here, the proposed bylaws here, and an Executive Summary of the proposed changes here.

CLICK HERE TO VOTE FOR BOTH DIRECTORS AND BYLAWS

Please contact Phil Brock, Agile Alliance Managing Director, with any questions. You can reach me at elections@agilealliance.org.

Thank you very much for taking the time.

Phil Brock
Managing Director
Agile Alliance
“Share the passion to deliver software better every day.”

Samuel Crescêncio Outros

O Agile Brazil 2010 foi sem dúvida o maior evento sobre métodos ágeis já realizado no Brazil.

Mesa de honra na abertura

Fazer parte da equipe de organização deste evento foi para mim uma grande experiência, especialmente por poder comparar esta com minha experiência na organização do Ágiles 2009, evento do qual fui presidente. A equipe de organização foi composta por 14 pessoas e o que mais me impressionou foi que a primeira reunião presencial desta equipe ocorreu no hall do hotel 1 dia antes do evento. Isto demonstra o poder que indivíduos auto-organizados que trabalham em busca de um mesmo objetivo têm, mesmo estando todos trabalhando remotamente. Eu particularmente, só conhecia metade desta equipe. Foi um sentimento muito interessante encontrar as pessoas que eu não conhecia e dar rostos aos nomes. A propósito, trabalhar com estas pessoas foi muito prazeroso e me proporcionou um aprendizado muito grande. Estão todos de parabéns por terem feito um evento desta qualidade.

Comitê de organização

Como organizadores tivemos que trabalhar bastante durante o evento, então não foi possível participar das palestras que gostaríamos. Então, meu feedback sobre o evento parte desta ótica, a de um organizador e não de um atendente.

A missão do Agile Brazil começou para mim no Sábado dia 19/6. Além de agilista e capoeirista eu gosto também de viajar de moto, então aproveitei o evento como desculpa para fazer uma trip de moto para Porto Alegre. Saí de Floripa no Sábado com destino a Orleãns/SC onde passei a noite. No outro dia segui viagem. Consegui escapar da chuva, mas não do frio. Mesmo com equipamento adequado cheguei em Porto Alegre com temperatura abaixo dos 10 graus, ou seja, com muito frio. Mas foi sensacional e uma experiência interessante.

Parada para descançar perto de Torres/RS

Na terça feira tive o grande prazer de ser “O Anfitrião” (visto que sou gaúcho) e levar o David Hussman vulgo “The Dude” para conhecer o mercado público de Porto Alegre. Conversamos muito sobre agilidade, música e idiomas. O Dude já arrísca umas frases em Português. Depois fomos jantar no galpão criolo e comer a autêntica costela de 12 horas (de fogo). Sensacional! A melhor coisa que eu extraí deste momento foi ouvir do Dude que ele gostaria de ver nos EUA um clima e uma comunidade unida como a nossa. Ele disse que na opinião dele, nós como um grupo, deveríamos ganhar o Gordon Pask Award este ano. Foi muito bom saber que estamos construindo estória e melhor ainda saber que eu faço parte dela. Muito gratificante.

Jantar com The Dude

Neste mesmo dia iniciaram os cursos de XP, CSPO e CSM - todos lotados. Só tive feedback concreto do XP, visto que alguns dos ministrantes eram também organizadores. Me parece que foi muito bom e mesmo em 6 (ou mais) instrutores conseguiram se organizar bem, sem nenhuma preparação antecipada. No dia seguinte, houve o curso de Coaching com o Dude. Este eu pude participar e gostei bastante, especialmente pela forma como o Dude apresenta-se a si mesmo e pela forma descontraída e jovial que ele nos conduz a reflexão e ao aprendizado. Penso que este curso foi um tanto quanto curto, e seria melhor se fosse feito em dois dias ao invés de apenas um.

Coaching Agility com The Dude

Após o curso fomos jantar no Parrilla Del Sur Na Brasa e participei da mesa mais comprida da minha vida até hoje (se não me engano 48 pessoas). Foi muito bom ver todo mundo reunido e descontraindo em torno de um mesmo objetivo - comer e beber, além de falar de agilidade é claro

Bom, o dia seguinte era o dia D. O dia de abertura do evento. Consigo imaginar como o Rafael se sentiu pois creio que senti o mesmo na abertura do Ágiles 2009. Uma mistura de emoção, nervosismo, frio na barriga e outras coisas que não te deixam dormir direito. Eu particularmente também estava preocupado pois ainda não tinha terminado de preparar minha palestra, como muitos outros palestrantes que estavam na organização. O Giovanni Bassi era um deles e como estávamos dividindo o quarto de hotel, combinamos de acordar às 5:30 da manhã para trabalhar. Assim fizemos, mas nem assim consegui terminar minha palestra. Resolvi não almoçar para terminá-la no horário do almoço. E felizmente consegui, às 14hs ela estava pronta.

A minha sessão foi um tutorial onde apresentei o conceito da Pirâmide Lean, que criamos na OnCast para demonstrar como funciona o equilíbrio entre os princípios e prática ágeis distribuídos na hierarquia organizacional de uma empresa. O feedback que recebi foi bem bom. Quem assistiu disse que o conceito é bastante esclarecedor e mostra bem como criar uma cultura que proporcione um fluxo de valor constante. Tive o privilégio de dividir a palavra com Rodrigo Branas, engenheiro de software senior da OnCast onde lidera uma de nossas equipes. O Rodrigo falou sobre Kanban, na verdade apenas uma introdução ao conceito que ele explicaria em detalhes na sua palestra no dia seguinte. Minha sessão serviu também para eu saber se o conceito que criamos está no caminho certo e também para eu melhorar algumas partes que identifiquei como necessárias. Esta mesma sessão será apresentada no Agile 2010 em Orlando este ano.

Quanto a abertura do evento, casa lotada e eu correndo de um lado para o outro. Infelizmente perdi as palavras do Rafael que eu tanto queria ver. Mas foi muito interessante ver todo aquele povo reunido esperando ansiosamente para ouvir o guru Martin Fowler. Gostei da parte em que ele falou de Branching e Configuration Management. Acho um tema fundamental e ainda tenho visto muitas equipes falharem na criação de boas estratégias para Continuous Delivery.

Keynote Martin Fowler

Vale apena resaltar aqui que o pessoal local da equipe da PUCRS fez um excelente trabalho. Na realidade, nos livrou de um árduo trabalho operacional que precisa ser realizado durante a conferência. No Ágiles 2009 não tivemos este privilégio, mas contamos com uma ótima equipe de voluntários que nos ajudou com isso.

Na noite de quinta estávamos todos muito exaustos. Havia uma reunião que eu deveria participar com o David, o Daniel Wildt o Parzianello e outras pessoas que não consegui ir. Precisava fazer algo para renovar as forças. Então decidi dar um treino de capoeira. Em frente ao hotel havia um seminário com uma pista de atletismo e um campo de futebol. Quem via de fora deveria pensar “quem é aquele louco lá de cabeça pra baixo!”. Depois de ativar a endorfina e um bom banho eu estava novo e pude ir para o John Bull Pub onde foi a confraternização do evento. A banda que estava tocando era realmente muito boa. Mas antes dela começar a tocar, tive uma conversa muito interessante com o Klaus, que me contou sua teoria sobre computação soberana e como ele vê uma mudança no mundo digital em favor das redes P2P. Trocamos experiências sobre desenvolvimento de sistemas de alta performance, servidores de tuplas e eu pude aprender bastante com ele.

Pessoal descontraindo no John Bull Pub

No dia seguinte, novamente dormindo pouco, acabei perdendo o Keynote do Kruchten. Pude particpar do Café Kaizen ministrado pelo Rafael e pelo Parzianello. Excelente diga-se de passagem. Eu já conhecia o conceito que o Luiz tinha me apresentado mas nunca tinha visto funcionando. Muito bom mesmo.

A palestra do Rodrigo Branas foi outra grande surpresa. Ele apresentou de uma forma descontraída conceitos muito interessantes que fisgaram a mente de quem esteve presente. De fato, tanto os conceitos da Pirâmide Lean quanto os que o Branas apresentou sobre Kanban são coisas que testamos na OnCast, por isso aprendemos, por isso compartilhamos.

Palestra do Branas sobre Kanban

Agora, o Gran Finalle foi magnífico. Na minha opinião, o Keynote do Klaus foi sem dúvida a melhor parte do evento. Ele reduziu todos os valores do XP para apenas 2: coolness and learning. Ou, aprendizado e ducaralhisse (foi o termo encontrado para traduzir coolnes :D) Ele apresentou a visão dele sobre ser ágil e eu concordo com ela. Houve um ponto paradoxal, onde ele, de certa forma, contrariou o que o Martin disse a respeito de branching. Na verdade ele disse para se possível não usar branching e o Martin disse, se usar, use direito.

Keynote de encerramento com o Klaus

Após o encerramento, distribuição de brindes, etecetera, pousamos para fotos e ainda tivemos energia para fazer uma retrospectiva sobre o evento. De forma geral o evento foi muito bom, alto nível. Encontramos espaço para melhoria é claro, mas nada que desabone a qualidade do evento. Em minha humilde opinião, o programa do evento é a parte em que precisaremos concentrar mais atenção para o ano que vem.

Retrospectiva dos organizadores

A minha missão de volta acabou só no Domingo, quando retornei de POA com um tempo inspirador. Voltei pela rota do sol para pegar um caminho de montanhas e às 20hs cheguei, são, salvo, cansado e com muito aprendizado.

Paradinha para descançar no caminho de volta.

É isso pessoal, até o próximo Agile Brazil.

Samuel Crescêncio Outros

Sempre que chego em um ambiente de desenvolvimento muito quieto, esses onde todos ficam o dia todo com seus fones de ouvidos (nada contra os fones) sem trocar uma palavra, me dá uma sensação um pouco estranha, de que algo pode estar errado ali. O silêncio e o clima do ambiente de desenvolvimento acabam revelando muito sobre como uma empresa desenvolve seus softwares e valoriza seus funcionários.

O individualismo quase sempre leva a uma estrutura egoísta de trabalho, onde cada um se preocupa apenas com seus próprios problemas, sem se dar conta que estes pertencem a todos e sem fazer idéia do que está acontecendo com o restante do projeto. Desta forma o time não colabora, não busca os mesmos objetivos e acabam transformando o desenvolvimento de software em uma atividade monótona e desmotivante.

Em tempos de fábricas de software, as atividades nunca foram tão individualizadas. Muitas empresas ainda veêm uma equipe de desenvolvimento como um conjunto de recursos, substituíveis facilmente, prontos para seguirem os guidelines, padrões e normas que juntos ajudam a eliminar qualquer forma de inovação que poderia emergir.

A comunicação é a ferramenta fundamental para ter sucesso em qualquer projeto. Através dela é possível transformar complexidade em realidade, unir o time e fomentar a motivação.

Rodrigo Branas Comunicação

Nota: Isso pode não ser viável na maioria dos casos, mas acho interessante pelo fator curiosidade.

Já me deparei algumas vezes em uma situação onde eu tinha uma série de enums que implementavam uma interface. Enums em Java (ainda) não podem herdar métodos, o que faz com que os métodos devam ser implementados em todos os enums, mesmo que o que a gente queira seja a mesma implementação pra todos os casos.

Um exemplo disso é o seguinte: para internacionalizar uma aplicação, por motivos que não vem ao caso, decidimos encapsular as mensagens em enums. Ou seja, teríamos uma interface Message, que todos os enums vão implementar, e cada contexto da aplicação teria seu próprio enum. Declaramos dois métodos em uma mensagem: um get(), que retorna a mensagem diretamente; um get(Object… args), que usa um MessageFormat para colocar os valores dos argumentos dentro da mensagem.

public interface Message {
    String get();
    String get(Object... args);
}

O método para recuperar as strings é o mesmo para todos os enums. Um ResourceBundle (que contém as mensagens carregadas de um arquivo properties) é acessado, e o valor correspondente ao valor do enum é retornado. Um enum típico seria assim:

public enum PersistenceMessage implements Message {
    OPEN("persistence.open"),
    SAVE("persistence.save");

    private String key;

    private PersistenceMessage(String key) {
        this.key = key;
    }

    @Override
    public String get() {
        return Messages.get(key);
    }

    @Override
    public String get(Object... args) {
        return Messages.get(key, args);
    }
}

O problema aqui é que os métodos em todos os enums vão estar duplicados.

Como seria bom se existisse um método de injetar comportamento nestes enums… talvez como os mixins do Ruby…

Acontece que em Java existe um jeito de fazer algo parecido com os mixins de Ruby. Com técnicas de AOP (aspect oriented programming), mas especificamente com ajuda do framework AspectJ, é possível injentar comportamento em classes com as chamados inter-type declarations.

Eu não vou explicar aqui o que é AOP ou como funciona o AspectJ, mas abaixo vai o exemplo de como fazer isso.

O primeiro passo é criar um aspecto para a interface Message, fornecendo os métodos desejados.

public aspect MessageGetter {

    public String Message.get() {
        return Messages.getString(this.getKey());
    }

    public String Message.get(Object... args) {
        return Messages.getString(this.getKey(), args);
    }
}

Como vocês devem ter percebido, eu adicionei na interface de Message o método getKey(), para ter um ponto de acesso à chave. Eu nunca usei AspectJ na prática, então talvez exista uma forma mais elegante de fazer isso. Essa foi a única alteração que fiz na interface, então não vou mostrá-la novamente.

Cada enum agora segue o seguinte padrão:

public enum PersistenceMessage implements Message  {
    OPEN("persistence.open"),
    SAVE("persistence.save");

    private String key;

    private PersistenceMessage(String key) {
        this.key = key;
    }

    @Override
    public String getKey() {
        return key;
    }
}

O método getKey() passou a ser duplicado, mas acredito que seja muito menos grave do que a situação anterior.

Este foi um exemplo extremamente simples, e com certeza não é uma opção para todos depender do AspectJ só para esse comportamento em um projeto, mas acredito que só o fato de ter o conceito de mixins na cabeça seja útil para abrir alguns horizontes na hora de bolar a arquitetura de uma aplicação.

Renato Besen Arquitetura de Software

A OnCast finalmente rende-se a uma forma intuitiva de gestão. Fases em cascata é realmente a melhor solução para atendar às demandas do mercado, tanto emergenciais, quanto grandes projetos que, por terem uma extensa fase de planejamento, conseguem segui-lo à risca.

Nossos projetos agora terão um Gerente de Projeto, que irá centralizar a informação e as decisões. O GP irá delegar ao seu critério para seus subordinados. Caso haja algum problema ou descontentamento, os recursos serão ser trocados imediatamente, a fim de preservar o plano do projeto. O Gerente de Projeto irá comandar as alocações e desalocações de pessoal, com seu WBS e gantt chart, além da geração de artefatos, para todo o fluxo descrito a seguir:

• No início do projeto, com tudo formalizado em contrato, para segurança de todas as partes e definição clara de interfaces cliente/fornecedor, analistas de requisitos irão documentar claramente as necessidades do cliente.
• Em seguida, o analistas de sistemas, assessorados por arquitetos de sistemas, transformarão a visão de requisitos em uma visão de sistema. Tudo muito intuitivo!
• Um arquiteto da informação poderá colaborar com a documentação dos requisitos e entregar macro esquemas de tela junto com os artefatos do analista de sistemas.
• Os designers criarão todas as telas, para que tudo fique claro antes da mera programação.
• Os programadores poderão dividir responsabilidades, preferencialmente por módulos dos sistema. Assim ele será conhecedor do todo seu módulo, de fácil controle. Ferramentas case e proprietárias são priorizadas neste momentos, por sua agilidade e suporte.
• Agora só falta testar! Inicia-se a fase de verificação, quando planos de testes confrontam o resultado da programação e se por acaso algum erro for encontrado, é fácil localizá-lo dada a vasta documentação do projeto e às ferramentas de debug. Neste momento, todos os módulos programados são integrados. A equipe de testes deve ser muito pragmática e apaixonada por trabalho repetitivo e braçal em teclado.
• Em paralelo aos testes, com documentação farta do projeto, o produto começa a ser documentado.
• Por fim, e ainda intuitivamente, o software segue para homologação e produção.
• Após em produção, o sistema começa a sofrer manutenções que começam a torná-lo, muito aos poucos, usável.

O que antes era um tripé incerto na gestão de projetos, Tempo, Escopo e Custo, agora mantém-se fixo e a variável que soluciona a equação é a Qualidade:

• Prazo é impossível alterar, já que o projeto inicia com seu fim anunciado à diretoria, à imprensa e ao mercado.
• Redução do Escopo impossibilita um grande evento de lançamento, pois obviamente é feio o sistema estar incompleto, mesmo que a maioria das funcionalidades não sejam utilizadas nos primeiros meses.
• Quanto ao Custo, nem se fala: quanto menor o investimento, maior o ROI. Não há o que argumentar, pois é pura matemática!
• Já a Qualidade, dá-se um jeito! Boas práticas atrapalham o mundo real. Nem sempre é preciso 3 camadas, desacoplamento e automatização de build e testes. Depois da entrega isto pode ser visto… Em um projeto futuro…

A OnCast, que até agora estava melhorando continuamente, finalmente atinge um ponto de maturidade, finalizando o ciclo de aprendizado. Com a adoção do OnCascade, espero em breve poder dar más notícias…

Adriano Campestrini Metodologia, Riscos

A OnCast Technologies anuncia oportunidades para trabalhar com Java!

Estamos com um processo de seleção aberto e convocamos estudantes e profissionais que desejam trabalhar em uma empresa jovem, ágil e inovadora.

Buscamos pessoas que atuem de forma multidisciplinar, em busca de se tornarem profissionais no papel de Engenheiro de Software Java EE, lidando com metodologias ágeis de desenvolvimento (Lean, Scrum e XP), engenharia de requisitos, análise e arquitetura de sistemas, usabilidade, documentação, testes automatizados e, é claro, muita programação.

Se você tem facilidade em aprender novas tecnologias, se comunica bem, sabe que o trabalho em equipe é imprescindível, prima pela excelência e quer crescer profissionalmente, esta pode ser uma ótima oportunidade para você.

Necessitamos pessoas com a seguinte formação: 

- Graduando* ou Graduado em Ciência da Computação, Sistemas de Informação ou Engenharia da Computação.

Competências que nós valorizamos nos candidatos:
- Orientação a objetos;
- Linguagem e APIs Java;
- Design patterns;
- Experiência com desenvolvimento ágil de software;
- Modelagem de banco de dados e SQL básico;
- Conhecimentos em JavaScript OO, Usabilidade e Ergonomia;
- Controle de versão;
- Testes automatizados;
- Ant build script;
- Modelagem UML;
- Frameworks, por exemplo: EJB 3, Hibernate 3, Servlets, Velocity, DWR, GWT, Spring, etc.;
- Conhecimento em Ruby, .NET, PHP e Flex são também desejáveis porém não imprescindíveis;
- Desejável inglês fluente ou no mínimo avançado.

* Candidatos ainda em graduação terão oportunidades de evoluir seus conhecimentos durante o estágio.

Candidatos deverão enviar curriculum para o email: carreira@oncast.com.br

Mirela Rzatki Outros

Nos dias 12 e 13 de Março a OnCast promoveu um curso de teste de usabilidade, com o Ezequiel Blasco. O que mais me chamou a atenção no curso foram algumas heurísticas para avaliar a usabilidade de um sistema.

Como não trabalho diretamente com design de interfaces, resolvi refletir e aplicar as heurísticas no que interessa para um desenvolvedor de software.

1. Visibilidade do estado do sistema - quando lemos um código fonte, é importante que saibamos o que está acontecendo. Alguns exemplos de coisas que podem ferir esta heurística: métodos onde o nível da abstração é muito variado (e.g. manipulação de uma string e acesso ao servidor no mesmo método); magia negra, ou seja, pequenos truques que parecem funcionar mas ninguém sabe o porquê;  muitas suposições, o programador pode considerar certas coisas implicitamente, mas isso pode não estar claro para todos; variáveis/classes/pacotes com nomes não auto-explicativos, e etc.
   Em resumo, eu considero sempre o bom conselho da PEP 20 que diz “Explicit is better than implicit“. Se alguma coisa prejudica a visibilidade do sistema, ela deve ser bem documentada e justificada. Se muitas dessas coisas acontecem em um mesmo software, está na hora de considerar uma nova arquitetura para ele.
2. Simetria entre sistema e mundo real - este ponto se refere as metáforas e modelagem utilizadas em um software. Se espera que um software reflita pelo menos superficialmente o domínio, o que dá origem a técnicas como o DDD. Considere por exemplo um software de gerenciamento de projetos Scrum onde não se tem um conceito de Sprint. Alguma coisa deve estar errada, não?
3. Controle e liberdade do usuário - Se uma classe é muito fechada, a reutilização dela é prejudicada. Obviamente é importante ter um balanço entre nenhuma configuração e muita configuração. É interessante fazer com que o sistema tenha um fallback para uma configuração padrão, mas devemos tomar cuidado para não limitar demais as coisas, pois isso gera duplicação de código.
4. Consistência e padrões - Se uns métodos tem nomes em cammelCase e outros separados com underscore, nunca se sabe o que esperar do sistema. Não ter um padrão de código e arquitetura induz o programador a erros, já que o nosso cérebro é basicamente uma máquina de identificar padrões.
5. Prevenção de erros - existem aqui duas possibilidades. Primeiro, se o erro pode tratado, faça, mas não esqueça da heurística 1: o erro deve ser comunicado, bem como a sua solução. Caso não seja possível tratar, quebre cedo. Não existe nada mais frustrante do que entrar no fluxo de trabalho, e descobrir que ele não vai poder ser concluído por que ocorreu um erro aconteceu lá no início.
6. Reconhecimento ao invés de lembrança - esta heurística se refere a intuitividade do código. Um bom código parece natural de ser utilizado, nada é forçado, e você é capaz de utilizar mesmo se ficar 3 meses sem encostar nele. Se toda vez que você precisa usar algo (uma biblioteca, um framework, etc.) é necessário ler o tutorial/ajuda, bem… é um mau sinal.
7. Flexibilidade e eficiência de uso - para exemplificar esta heurística, considere o framework Ruby on Rails. Ele é extremamente eficiente de se usar, pois otimiza a codificação para os casos mais comuns. Digamos que 80% das pessoas vai utilizar o sistema de template X, com o banco de dados Y e o framework de teste Z. Nesse cenário, é muito mais prático ter estes três componentes pré-configurados, e o 20% que precisar utilizar algo diferente mergulha mais fundo no sistema, e faz as alterações necessárias. Assim, além de eficiente, o framework é flexível.
8. Estética e design minimalista - esta heurística vai ao encontro da filosofia Unix de desenvolvimento, que diz: “faça apenas uma coisa, e faça bem”. Outro conceito que descreve a heurística é o “Single Responsibility Principle“.
9. Recuperação de erros - o programador deve ser capaz de identificar qual o erro e ter informações para poder tratar o mesmo. Sair do programa com uma mensagem “exit with code -1” não é muito útil para ninguém.
10. Ajuda  e documentação - este talvez seja um ponto polêmico, mas depende muito de situação para situação. Muitos consideram que documentação de código é igual a código duplicado. Bob Martin no livro Clean Code sugere que devemos evitar o mínimo de mistura de linguagens em um arquivo (e.g. um arquivo com Java, Html, JavaScript e Inglês é terrível de manter, pois temos que mudar a sintaxe em que o cérebro está trabalhando em um curto espaço de tempo). Por outro lado, se estamos criando uma biblioteca que vai ser usada por terceiros, é importante ter a documentação dos métodos com exemplos de uso, edge cases, etc. Só não podemos esquecer que a documentação possui um custo para ser mantida, assim como o código.

Lembrando que essas são apenas as minhas reflexões sobre o assunto, e assim como no design de interfaces são apenas heurísticas, ou seja, não necessariamente um código precisa atender a todas elas para ser bom. A medida dessas heurísticas é fuzzy, e temos que encontrar um balanço para entregar o software funcionando, que afinal é o objetivo primordial de todos os desenvolvedores.

Eu gostaria muito de conhecer a ótica de outras pessoas sobre os pontos aqui tratados, portanto sintam-se livras para colocar suas opiniões nos comentários.

Renato Besen Arquitetura de Software