Novidades no Java 7

05/05/2011 1 comentário

Entre uma coisa e outra, iniciando os estudos da próxima versão do Java encontrei este post na InfoQ BR sobre as novidades e alguns exemplos.

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

Vale a penar dar uma conferida!

Tags:,

Agile e PMBoK podem viver juntos em um projeto? Acredito que sim!

04/04/2011 2 comentários

Pessoal,

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!

 

Divisão de tarefas em um time ágil: uma tarefa por desenvolvedor ou vários desenvolvedores por tarefa?

12/02/2011 1 comentário

Em nosso ambiente de desenvolvimento geralmente precisamos tomar algumas decisões com relação ao fluxo de desenvolvimento das atividades de nosso backlog. Trabalho puxado ou empurrado, paralelização de atividades, etc.

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

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

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

Slides e Fontes de Palestra sobre BDD e JBehave no RioJUG (reunião de Janeiro/2011)

Amigos,

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!

Os números de 2010

Os duendes das estatísticas do WordPress.com analisaram o desempenho deste blog em 2010 e apresentam-lhe aqui um resumo de alto nível da saúde do seu blog:

Healthy blog!

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

Números apetitosos

Imagem de destaque

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.

1

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

2

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

3

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

4

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

5

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

Behaviour-Driven Development em Java na prática, com JBehave – Artigo na MundoJ de Nov/Dez

29/11/2010 1 comentário

Pessoal,

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…

A história de um projeto (assim como os nossos)

Foi publicado hoje na InfoQ (www.infoq.com) um post de Olivier Mallassi contando a história de um projeto que, segundo ele mesmo, não é “nem mais complexo nem mais simples” que outros.

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

Seguir

Obtenha todo post novo entregue na sua caixa de entrada.