Novidades no Java 7

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!

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

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?

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

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

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:

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.

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

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

Papéis na transição do modelo tradicional para o Scrum

Após acompanhar esta discussão, no grupo scrum-brasil, sobre o papel e as atividades do ScrumMaster (SM), pude perceber algumas opiniões que reforçam o que penso sobre o assunto e tenho visto por aí.

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.

Códigos de exemplo e exercícios em Java

Fala galera!

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!

Errando logo no início com as famosas RFP´s

Enquanto curtia a pequena folga de carnaval (trabalharei segunda e quarta-feira – arghhhh)  parei para conferir os e-mails e li este post:

Primeiro passo para um projeto de software falhar: a RFP

A questão levantada pelo autor é bastante interessante e é uma grande realidade em diversas empresas.

- 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.