http://www.infoq.com/br/articles/java7coin

Vale a penar dar uma conferida!

Publiquei um artigo na MundoJ 46 falando a respeito de um projeto onde apliquei técnicas e idéias de Agile e PMBoK, visando reduzir essa idéia de que são coisas incompatíveis.

Um resumo rápido:

Atualmente temos visto algumas discussões com a tentativa de provar que metodologia (ou base de conhecimento) X é melhor que a Y, etc. Em alguns momentos chegamos a duvidar do sucesso de algumas práticas e ferramentas, quando na verdade deveríamos entender como tirar proveito da melhor forma possível das ferramentas e idéias de cada mindset.

Neste artigo será apresentado um relato de projeto onde foram aplicadas ferramentas e idéias de Agile e do PMBoK, mostrando como é possível unir dois mundos teoricamente heterogêneos para obter melhores resultados.

Tenho recebido alguns feedback´s interessantes e hoje li um post do Rafael Ramos (http://twitter.com/#!/rsouzaramos) onde demonstra seguir a mesma linha de raciocínio em sua estrada.

Segue o link do post: http://www.gestaoetc.com.br/1028/agile-e-pmbok-e-possivel-unir-os-opostos/

Boa leitura e grande abraço!

Uma escolha importante (que pode ser alterada freqüentemente) é se o time irá atacar um item de cada vez ou se cada desenvolvedor (ou par) ficará responsável por uma única funcionalidade.

Normalmente, prefiro ter mais de um desenvolvedor em uma única tarefa por alguns motivos que considero interessantes. Vou comentá-los abaixo.

Limitação do WIP

Com o crescimento da adoção do método Kanban, muito tem sido falado na comunidade sobre limitar o Work in Progress (WIP). Trata-se de limitar a quantidade de tarefas sendo executadas pelo time, aumentando o foco nas atividades sendo executadas.

Entregas e feedback antecipado

Imaginando 3 atividades de 18 horas cada e um time de 3 desenvolvedores que trabalham 6 horas por dia, se cada um iniciasse uma atividade hoje teríamos as 3 atividades prontas somente no terceiro dia de desenvolvimento (caso não houvesse atraso em nenhuma delas). Até o terceiro dia, não teríamos nada pronto e utilizável para o cliente (apenas aqueles percentuais de conclusão que não servem para nada).

Tarefas sendo executadas em paralelo por três desenvolvedores

As três atividades sendo executadas em paralelo aumentam a necessidade de gerência/liderança.

Por outro lado, se tivéssemos os três desenvolvedores atuando na mesma atividade teríamos tal tarefa finalizada ao final do primeiro dia (ou no segundo dia, em caso de atraso).

Tarefas compartilhadas entre 3 desenvolvedores

Assim, teríamos feedback logo no primeiro dia e o cliente já poderia ver algo efetivamente pronto em um tempo menor. Poderíamos nos beneficiar do feedback recebido para melhorar as próximas atividades.

Vale lembrar que feedback nesse caso não é necessariamente do cliente. Podemos ter feedback sobre a qualidade do código (com as análises de código de um servidor de integração contínua, por exemplo), arquitetura, etc…

Claro que nem sempre será possível agir rigorosamente dessa forma. Nem sempre juntar três grávidas irá nos dar o bebê em apenas 3 meses…

Aumento do caos e interação entre a equipe

Quando desenvolvedores compartilham a mesma tarefa é gerado um caos momentâneo  e isso necessariamente aumenta a interação entre os envolvidos. Um começa a reclamar da classe criada pelo outro, da pitaco nos métodos, pacotes, etc.

Isso é bom! Por mais que no início gere um pouco mais de esforço de liderança para controlar os ânimos e ajuda em algumas decisões, com o tempo o próprio time aprende a resolver seus problemas.

O resultado dessa maior interação normalmente é:

• propriedade coletiva de código
• maior reaproveitamento de código
• código mais padronizado
• peer review
• integração mais freqüente (já que um depende do código do outro)
• redução de ilhas de conhecimento e aquela história de “essa funcionalidade é do Fulano e só ele saberá resolver esse problema”

Um arquiteto/líder técnico atento pode tirar bastante proveito dessa situação. Uma revisão técnica após terminar uma funcionalidade pode evoluir a arquitetura da aplicação e mover a estrutura para uma posição melhor, de mais qualidade, ainda na primeira interação, beneficiando a entrega das próximas funcionalidades.

Claro que nem sempre será possível organizar o time dessa forma. Em alguns momentos precisamos respeitar dependências (mesmo que elas raramente existam de fato).

Um outro fator importante a ser analisado é o Custo/Benefício do Atraso (Cost and Benefit of Delay). Quando não há custo em atrasar o início de determinada atividade, postergar o início pode garantir maiores informações no momento certo, por exemplo. O mesmo pode acontecer ao atrasar a entrega de atividades como falado no exemplo anterior.

Por fim, como sabemos, não há bala de prata, mas compartilhar tarefas entre desenvolvedores é, em minha opinião, uma boa idéia e pode trazer vantagens interessantes.

Aqui, tem um post interessante sobre Benefit of Delay e Last Responsible Moment

Os slides que utilizei na minha apresentação na última reunião do RioJUG (janeiro/2011) já estão disponíveis no meu slide share, aqui.

O código de exemplo utilizado na palestra e no artigo da MundoJ estão no meu gitub, aqui.

Até a próxima!

O Blog-Health-o-Meter™ indica: Mais fresco do que nunca.

Números apetitosos

Um Boeing 747-400 transporta 416 passageiros. Este blog foi visitado cerca de 2,900 vezes em 2010. Ou seja, cerca de 7 747s cheios.

Em 2010, escreveu 6 novo artigo, aumentando o arquivo total do seu blog para 16 artigos.

The busiest day of the year was 14 de abril with 143 views. The most popular post that day was Códigos de exemplo e exercícios em Java.

De onde vieram?

Os sites que mais tráfego lhe enviaram em 2010 foram infoblogs.com.br, google.com.br, pt-br.wordpress.com, qualidadebr.wordpress.com e tectura.com.br

Alguns visitantes vieram dos motores de busca, sobretudo por jbehave, documentação uml, exercicios java, frameworks jbehave de bdd e exercicios de java

Atracções em 2010

Estes são os artigos e páginas mais visitados em 2010.

Códigos de exemplo e exercícios em Java abril, 2010

Java SDK + Eclipse + JBoss Tools + Tomcat (instalação e configuração inicial) novembro, 2009
1 comentário

BDD em Java na prática, com JBehave outubro, 2009
3 comentários

Exemplos de código e Exercícios em Java dezembro, 2009

UML como documentação? dezembro, 2009
5 comentários

Meu artigo sobre BDD em Java com JBehave foi publicado na edição atual da revista MundoJ (edição de Nov/Dez – 2010)!

Tem mais detalhes no site da revista, onde podem pegar também o código-fonte do exemplo criado (aqui).

Criei um repositório no meu github para o projeto, que pode ser visto aqui.

Uma breve introdução do artigo:

As práticas de teste antecipado têm ganhado cada vez mais adeptos nos últimos anos com a crescente utilização de Test-Driven Development (TDD), sendo encorajada pelo eXtreme Programming e outros métodos ágeis. Como evolução ao TDD, Behaviour-Driven Development (BDD) nos permite criar, junto aos clientes, especificações que poderão ser executadas (e automatizadas), utilizando textos simples, em linguagem natural.

Neste artigo, será apresentado o framework JBehave e trabalharemos um exemplo prático de especificação de cenário. Ao final, iremos configurar a ferramenta para utilizar o Português como língua padrão nas especificações, facilitando ainda mais a compreensão.

Espero que ajude! Comentários são bem vindos…

No entanto é uma história bastante conhecida por qualquer um que já tenha passado por alguns projetos de Software (mesmo que em equipes menores que a mencionada no post).

Há entradas no texto para frases e trabalhos que gosto muito, como:

“Adding manpower to a late software project makes it later”, de Fred Brooks

“Software Engineering: An Idea Whose Time Has Come and Gone?”, de Tom De Marco onde ele fala sobre como a famosa frase “You can’t control what you can’t measure” foi mal interpretada…

O artigo é grande mas é uma excelente leitura! Recomendo!

Segue o link: http://www.infoq.com/articles/mallassi-project-story

Muitas empresas pecam na transição de modelos tradicionais para metodologias ágeis simplesmente por apenas converter o antigo em novo, sem reservar tempo para estudar e avaliar os conceitos envolvidos e as diferenças nas formas de pensamento. Assim, acabam por evitar mudanças (as vezes propositalmente, visando evitar conflitos) que seriam essenciais para obterem sucesso na reestruturação que desejam.

Seria algo como: Continuar fazendo as mesmas coisas apenas com uma cara nova, e esperar um resultado diferente… Além de ter mínimas chances de sucesso, ainda contribuem para gerar má fama para os métodos que pensam estar adotando, causando distorções (como as que mataram o RUP, por exemplo)…

Pensemos no Scrum, como exemplo. Imagine uma empresa que possui uma orientação vertical, com gerentes de área/produto, gerente de projeto, líder técnico e equipe (composta por arquiteto, programador jr, pleno e tester, por exemplo) com ordens vindo de cima para baixo, no melhor estilo comando-controle.

Daí, tal organização pensa em implantar Scrum e, cegamente, apenas troca as posições anteriores (ou apenas seus nomes) para algo mais parecido com o que é sugerido pelo framework.

Surgem as seguintes associações:
Gerente de Área/Produto -> PO;
Gerente de Projetos -> ScrumMaster;
Líder Técnico é incluído na equipe.

E daí começam a ter reuniões diárias, planning meetings, retrospectivas, etc. Porém, como o mindset não foi mudado, os principais valores (como equipe auto-gerida, por exemplo) nunca serão alcançados.

A organização continuará vertical e os “recursos” (provavelmente ainda serão chamados assim) estarão subordinados à seus superiores, coisa que poderia ser melhorada com uma organização mais flat onde empowerment poderia aos poucos fazer com que a equipe tivesse mais segurança e aprendesse a tomar decisões importantes por si só.

Como geralmente não há interesse em atrito, os cargos continuam os mesmos e teremos um antes Gerente de Projetos PMP agora atuando como ScrumMaster e ditando como a equipe deve fazer as tarefas, com seu gantt chart debaixo do braço. A equipe continuará não sendo multidisciplinar e independente.

Nada contra PMP´s como ScrumMaster´s (apesar de acreditar que a melhor pessoa para exercer este papel é o Líder Técnico, deixando tarefas mais burocráticas, como contratos, para os Gerentes de Projetos), contanto que estes estejam engajados em entender e exercer ativamente seu novo papel, entendendo que o centro não será mais ele e sim a equipe.

O papel do ScrumMaster, IMHO, é bem claro e já descrito em diversos lugares (como no Scrum Guide, por exemplo), porém na transição para o Scrum acontecem algumas distorções e má associações de papéis, como o que foi descrito acima.

Há material disponível que pode ser bastante útil em transições, auxiliando a associar os papéis e reorganizar a equipe, como este. Além de diversas discussões relacionadas, como esta.

O essencial antes de partir para a implementação de uma nova metodologia é entender seu background, conceitos e formas de pensamento. Entendendo o motivo das coisas estaremos livres de frases como:

• Sim, somos agile. Fazemos reuniões de status todos os dias pela manhã;
• Utilizamos agile, mas não adotamos práticas como Test-First, Integração Contínua, etc. Simplesmente não fazemos mais casos de uso e agora usamos estórias;
• Utilizávamos Scrum e nosso ScrumMaster delegava as tarefas para nós da equipe
• Não fazemos testes automatizados pois temos duas pessoas para teste na equipe

Acredite! Não estou inventando as frases acima. Infelizmente, é verdade! Eu as ouvi…

Atualizei meu repositório no google-code (http://code.google.com/p/exercicios-java-uerj/) com os últimos projetos que trabalhamos em sala (curso de extensão em Java – UERJ/IME). Quem quiser pode fazer o check-out via svn ou download do .rar, na área de específica.

Aos que não fizeram o curso mas acompanham o blog, sintam-se a vontade para baixar, melhorar e opinar…

Grande abraço e, aos que estiveram no curso, parabéns e obrigado pela atenção!

Primeiro passo para um projeto de software falhar: a RFP

- Vamos desenvolver um projeto? Então, escreveremos uma RFP, a entregaremos a algumas empresas e contrataremos a que melhor nos atender (a partir daí, “a que melhor nos atender” pode significar diversas coisas e até, simplesmente, a mais barata).

O problema é que estão negando um princípio muito importante da construção de softwares: Não sabemos o que queremos no início (vide cone da incerteza). Daí, especificamos, no início, algo que pode não ser o mais interessante no final e exigimos que seja feito exatamente daquele jeito.

Em contrapartida, o fornecedor incluirá cláusulas contratuais que bloqueiem (ou ao menos dificultem) qualquer alteração no escopo do projeto, sob pena de multas contratuais. Assim, fazem com que sejam fixados preço, prazo e escopo (logo, a única coisa que pode e vai variar será a QUALIDADE) e, o pior, geralmente não definimos o que será considerado como software de qualidade, no início.

Por exemplo, no que se refere a mudanças no escopo, imagine o impacto que a seguinte frase pode causar no sucesso de um projeto de software (falando de funcionalidades que atendem de forma eficiente e eficaz as necessidades dos usuários e não simplesmente de entregar dentro do prazo e custo definidos – aliás, entregar com prazo e custo dentro do estimado no início é o mais difícil de acontecer):

“Quaisquer alterações no escopo deverão ser apresentadas com no mínimo 30 dias de antecedência e estarão sujeitas a análise do fornecedor”.

Claro que, geralmente, estas alterações serão aceitas pelo fornecedor, desde que o cliente aceite pagar (bem) mais por isso. Afinal, já existem dezenas de documentos definindo o que será feito e tudo deverá ser alterado…

É incrível como, apesar de tanto movimento a favor de melhores práticas e métodos, ainda encontramos diversas empresas com modelos de contratação que não favorecem o sucesso dos projetos de software.

Logo de início, exige-se zilhões de entregáveis que devem ser entregues antes que qualquer linha de código tenha sido escrita. Daí, o que vemos no final são pilhas de documentos mortos desatualizados (ou raramente/precariamente atualizados) e software que não é compatível com o que foi escrito…

De qualquer maneira, alguns pontos que precisamos levantar são:

Estariam os fornecedores preparados/receptíveis para contratos ágeis?

Estariam os clientes e fornecedores preparados para compartilharem os riscos nos projetos de software ao invés de continuarem no “jogo de empurra” onde um quer deixar a culpa para o outro?

É…, sei não viu…

A[]´s e até mais.