XP Rio

Adiamento da Reunião

2007-04-04T14:54:00.000-03:00

Comunicamos que, em razão do feriado da sexta-feira (dia 06), nossa reunião foi transferida para a quinta-feira seguinte, dia 12/04/2007. Compareçam!

Próxima reunião do XP-Rio

2007-03-28T22:24:00.000-03:00

Assunto: Por que XP não funciona? Venha dar sua opinião e verá que XP funciona.

Data: 05 de abril de 2007, quinta-feira, das 19 às 21 horas.
Local: SENAC - Rua Santa Luzia, 735/7o. andar - Rio de Janeiro, RJ.

Formato:
Essa reunião tem como objetivo fazer uma "mesa redonda" para discutir as razões pelas quais achamos que XP não funcionaria na realidade de cada um, compreender as dificuldades e as razões pela qual a empresa não se adaptaria ao XP. Será uma reunião dinâmica e não teremos palestrantes e ouvintes, todos estarão lá para falar !
Para organizar seguiremos o formato de uma retrospectiva onde cada participante escreverá sua opinião em um Post-it, colaremos num quadro e todos votarão nos pontos mais importantes e os mais votados serão discutidos em seguida.

Será uma retrospectiva da vida profissional !!!

E ainda estaremos sorteando o livro "Agile Retrospectives: Making Good Teams Great", que o grupo recebeu através do User Group Program da O'Reilly.

Precisa se inscrever? Não. A entrada é gratuita e não é necessário confirmar presença.

Apresentação de Scrum no XP Rio

2007-01-05T11:14:00.000-02:00

Na última quarta-feira tivemos, no XP Rio, a palestra de Boris Gogler sobre Scrum.
Boris fez uma ótima apresentação e mostrou que Scrum está alinhado aos valores mais básicos de desenvolvimento ágil, tais como:

* Valorizar as pessoas
* Conficar nas pessoas
* Delegar poder a quem deve executar as atividades de desenvolvimento
* Cooperação entre clientes, desenvolvedores e outras pessoas envolvidas nos projetos de software
* Desenvolvimento iterativo
* Entrega rápida e periódica de produtos prontos e com alta qualidade

Scrum é uma forma simples e eficiente de planejar e gerenciar projetos de software. Seus conceitos são muito semelhantes aos de XP na área de planejamento, embora existam algumas diferenças filosóficas.

Ao final da apresentação, a coordenação do XP Rio sorteou o livro Practices of an Agile Developer, que o grupo recebeu como parte do User Group Program da O'Reilly. O felizardo foi Celestino Gomes, da Ancar, que aparece na foto abaixo com o Boris.

SCRUM no XP Rio. Reuniao mensal 03/01/2007.

2007-01-02T09:21:00.000-02:00

O ano novo chegou e já vai começar agitado, pois amanhã será a reunião mensal do XP Rio. Pela primeira vez teremos um palestrante estrangeiro. E também pela primeira vez teremos uma apresentação sobre SCRUM.

Assunto:
Introduction to Scrum - Agile Software Development and its Principles

Sumário
Scrum is a set of principles combined with a framework that enforces feedback during a project. Scrum helps projects being succesful in uncertain situations. It helps teams to manage the customer and the work so that they can be more productive. Scrum reduces communication issues, and helps teams to be much more productive. It proved that Scrum helps teams to be 2 to 4 times more productive within the first year.

Apresentador
Boris Gloger, Certified Scrum Trainer since 2004, runs projects and organizations with this technology for the last 4 years.
In this talk he will show you the principles and the mechanism of Scrum.

Local: Auditório do SENAC na R. Santa Luzia, 735, 7º andar (Centro, Rio de Janeiro)
Data: quarta-feira, 3/1/2007
Horário: 19:00h às 21:00h
A entrada é gratuita e não é necessário fazer inscrição, nem confirmar a presença.

Ao chegar ao local, caso haja algum atraso e nenhum coordenador do XP Rio tenha chegado ainda, entre em contato com Vinícius Teles pelo telefone (21) 8716-5434.

A palestra será em inglês e não haverá tradução simultânea. Entretanto, pedirei ao Boris para falar lentamente e ficarei à disposição de vocês para traduzir eventuais partes que não ficarem claras.

O Boris está no Brasil apenas essa semana. Portanto, é uma oportunidade única de ter contato com Scrum com alguém que realmente entende do assunto e vem utilizando-o há algum tempo. Essa é uma boa apresentação para você levar seu gerente!

Por favor, compareçam e divulguem tanto quanto possível.

XPRio no O´Reilly Group User Group Program

2006-12-29T08:59:00.000-02:00

Anunciamos com satisfação que o XPRio agora conta com o apoio da O´Reilly. Assim, estaremos recebendo frequentemente livros da editora, os quais serão destinados à composição de uma biblioteca do grupo e oferecidos como brindes em nossas reuniões mensais.
Já recebemos 3 livros, que são:
Agile Retrospectives
Practices of an Agile Developer
Head First Object-Oriented Analysis and Design

Além disso os membros dos grupo passam a ter 35% de desconto na compra de livros nos sites da O'Reilly, No Starch, Paraglyph, PC Publishing, Pragmatic Bookshelf, SitePoint, Syngress ou YoungJin, bastando usar o código promocional "DSUG".

Em contrapartida estaremos elaborando resenhas sobre os livros. Os interessados em colaborar neste sentido basta entrar em contato com os moderadores do grupo.

Aguardem maiores notícias!

XPizza - 4 anos de XPRio

2006-12-23T09:08:00.000-02:00

Uma vez que nossa reunião de dezembro acabou sendo cancelada, estaremos nos reunindo para um XPizza na próxima quinta-feira (28/dez/2006), às 19:30 horas, na Cobal de Botafogo.

Nosso objetivo é celebrarmos o aniversário de 4 anos do grupo. Durante este período tivemos não apenas a oportunidade de discutir os processos ágeis, mas principalmente de fazer amigos e encontrar novos companheiros de trabalho.

Para que tenhamos uma idéia do tamanho da mesa, peço confirmar presença enviando e-mail para carlos.miranda@irq2.com.br.

Qualquer dúvida estou à disposição através do telefone 8122-4219.

XPRio 4 anos: "Lightning XP Talks" na Reunião de Dezembro

2006-11-28T15:53:00.000-02:00

No final de 2002 alguns cariocas ao se encontrarem no XP BRASIL 2002,
realizado em São Paulo, decidiram criar o XPRio. Hoje o grupo já conta
com quase 600 associados, de diversas cidades do Brasil e outros
países.

No dia 11 de dezembro de 2006, segunda-feira, estaremos celebrando 4
anos de XPRio. Iniciaremos com a nossa reunião de mensal de dezembro e
terminaremos no Amarelinho da Cinelândia.

O tema da reunião será "Lightning XP Talks"...
"Lightning Talks" (http://perl.plover.com/lightning-talks.html) é um
formato de evento no qual são feitas diversas apresentações de curta
duração (até 5 minutos), ou seja, "falas-relâmpago". São uma ótima
oportunidade para aqueles que nunca palestraram e ao mesmo exige pouca
preparação, podendo ser usados ou não diversos recursos diferentes de
ppt, como o quadro branco, folhetos ou só um discurso mesmo :)

A idéia é termos uma sessão de 11 apresentações, seguida de um debate
livre sobre os temas apresentados.

Os interessados em participar com uma apresentação devem enviar um
e-mail para xprio-owner@yahoogroups.com informando o tema.
Uma vez confirmados os participantes e temas divulgaremos aqui.

XP Rio on Rails

2006-10-19T02:15:00.000-03:00

Próxima reunião do XP Rio :

XP Rio on Rails - Terça, 24/out/2006 - 19h - SENAC - R. Santa Luzia, 735/7o. andar - Rio de Janeiro, RJ

Assunto
XP Rio on Rails - Como o uso do Ruby on Rails pode turbinar projetos web que usam XP ou outras metodologias ágeis .

Formato
Show me the code! Nessa apresentação não haverá Power Point, nada deslides. Um pequeno site será desenvolvido do zero, durante o período deuma hora, com iterações de 20 minutos. O banco de dados irá evoluir deforma incremental, assim como as demais partes da aplicação.

O que você verá

Principais conceitos do Rails

Forma de persistir dados

Validação de dados em formulários

Evolução incremental do banco de dados com migrations

MVC no Rails

Testes automatizados

Uso de fixtures nos testes

Uso de mocks nos testes

Tudo isso em apenas uma hora? Sim, afinal, trata-se do Rails ! :-)

Data, hora e local
Terça-feira, 24/out/2006 às 19h
SENAC - R. Santa Luzia, 735/7o andar - Centro - Rio de Janeiro

Precisa se inscrever?
Não. A entrada é gratuita e não é necessário fazer inscrição, nem confirmar presença.

Você pode perder essa?
De jeito nenhum. Mas, venha preparado. A produtividade no desenvolvimento com Rails é tão acima do normal, que você pode ter problemas para voltar ao trabalho no dia seguinte. ;-)

Apresentadores
Marcos Tapajós ( Improve It )
Marcelo Alvim ( Improve It )
Vinícius Teles ( Improve It )

"Ágil" no InfoQ

2006-09-20T09:11:00.000-03:00

Uma excelente fonte de artigos e apresentações sobre Desenvolvimento Ágil.

Pesquisa sobre adoção do Desenvolvimento Ágil

2006-09-14T20:59:00.000-03:00

VersionOne publica resultado de pesquisa realizada sobre a atual "situação do desenvolvimento ágil" em empresas de diversos setores.

Agile Business Conference 2006

2006-09-08T11:56:00.000-03:00

Mais uma conferência do mundo "ágil", desta vez para os homens de negócios.

"Ágil" no OOPSLA 2006

2006-09-06T18:55:00.000-03:00

Para aqueles que quiserem acompanhar o que vai rolar de
desenvolvimento ágil no OOPSLA deste ano.

Podcasts

2006-08-28T22:40:00.000-03:00

Ha alguns dias, escutei dois podcasts que podem ser uteis para quem estiver tentando vender a ideia de desenvolvimento agil para suas organizacoes e/ou clientes. O primeiro eh o relato entusiasmado de Bud Phillips, vice-presidente da CapitalOne (http://www.capitalone.com), uma grande instituicao financeira nos EUA. Ele eh uma pessoa de negocios, que ha alguns anos "esbarrou" com XP enquanto estudava Lean na area de negocios. Comecou pelo livro da Mary Poppendieck (Lean Software Development) e depois ajudou a disseminar a cultura agil na CapitalOne. Hoje inumeros projetos la na CapitalOne utilizam desenvolvimento agil com grande sucesso. Eh interessante ver o entusiasmo dele, que eh uma pessoa nao-tecnica, satisfeita com os resultados de TI, apos a adocao das praticas ageis. O podcast esta em http://agiletoolkit.libsyn.com/index.php?post_id=116686.

O outro podcast eh um painel, do qual o Bud Phillips tambem participou, onde diversas pessoas de negocios, de grandes organizacoes, contam suas boas experiencias com a adocao de praticas ageis. Está em http://agiletoolkit.libsyn.com/index.php?post_id=118595.

Alem desses, tenho escutado varios podcasts no site http://agiletoolkit.libsyn.com. Tem sido particularmente interessante ouvir sobre a Agile 2006 (http://www.agile2006.org), que aconteceu nos EUA. Enquanto na Europa eramos aproximadamente 285 pessoas em junho, nos EUA foram 1.111 participantes em julho. Eh incrível o que esta acontecendo por la. O legal eh que nas entrevistas gravadas e nos papos que ouvi la na Finlandia, a tonica eh semelhante: considera-se que desenvolvimento agil nao eh mais nenhuma novidade. Muito pelo contrario, eh algo que ja esta mais do que comprovado de que funciona bem. Isso eh especialmente real nos EUA, onde atualmente ha uma verdadeira febre em torno do assunto. Vide, por exemplo, o numero extremamente elevado de participantes na Agile 2006. Alias, vale notar tambem o numero de patrocinadores, nada menos que 28! No discurso de muitos participantes, desenvolvimento agil nada mais eh que o futuro natural do desenvolvimento de software. Cool! :-)

TDD no III SECOMP Londrina

2006-08-25T18:49:00.000-03:00

Na próxima semana acontecerá o III SECOMP Londrina. Na terça-feira, dia 29, estarei conduzindo o mini-curso "Desenvolvimento Guiado Por Testes no Extreme Programming".
A idéia será entender os conceitos básicos e praticar:
. como são conduzidos os testes no XP;
. testes unitários com JUnit;
. uso de objetos "mock" com EasyMock;
. testes funcionais guiados por dados com FitNesse;
. testes de aceitação com Selenium;
. testes de performance com JUnitPerf;
. análise de cobertura de testes com Emma.

Apesar de não ser no Rio, como sabemos que muitos do grupo são de outras localidades, fica o convite!

Você é um "guerreiro do quadro branco"?

2006-08-21T19:37:00.000-03:00

Em seu site, Scott Ambler convoca a comunidade ágil a compartilhar suas experiências com modelagem em quadro branco, uso de cartões CRC e User Stories, prototipação em papel e afins.

Robert C. Martin on Real-World Agile for .NET Developers

2006-08-16T09:27:00.000-03:00

Nesta entrevista o "Tio Bob" fala do desenvolvimento ágil no mundo C#/.NET.

Reunião de Agosto do XPRio: Refactoring na prática

2006-08-10T18:40:00.000-03:00

No dia 16, próxima quarta-feira, ocorrerá a reunião mensal de agosto do XPRio.

Estaremos selecionando algumas das técnicas de Refactoring do catálogo do Martin Fowler e para cada uma será aplicada a seguinte dinâmica:
- é apresentado o código que contém características ruins ("code smells");
- os participantes sugerem como melhorar o design do código;
- é apresentada e implementada a solução proposta no catálogo;
- são discutidas as motivações e benefícios da aplicação do Refactoring;
- são discutidas abordagens alternativas ou evolutivas.

Será utilizada a IDE Eclipse (e apresentados seus resursos para Refactoring).
Apesar do código ser em Java as técnicas podem ser aplicadas à outras tecnologias.

Palestrantes:
- Carlos Miranda
- Luiz Esmiralha

Local: Auditório do SENAC na R. Santa Luzia, 735, 7º andar (Centro, Rio de Janeiro)
Data: quarta-feira, 16/08/2006
Horário: 19 às 21 horas
A entrada é gratuita e não é necessário fazer inscrição, nem confirmar a presença.

Resultado de pesquisa sobre adoção do Desenvolvimento Ágil

2006-08-07T10:00:00.000-03:00

Neste artigo Ambler divulga o resultado de pesquisa realizada por ele mesmo sobre a adoção do Desenvolvimento Ágil. Contanto com a participação de mais de 4 mil pessoas, podemos ver dados sobre quais processos e práticas são mais adotados e seus efeitos sobre a produtividade, qualidade e satisfação dos clientes.
Vale conferir!

Reunião de Julho do XPRio - Estudo de Caso: Adoção de práticas do XP na equipe de desenvolvimento da Universidade Estácio de Sá

2006-07-03T18:57:00.000-03:00

Dia 11, terça-feira, ocorrerá a reunião mensal de julho do XPRio.

Seguem informações...

Sinopse:
Em maio deste ano a equipe de desenvolvimento da Estácio de Sá iniciou o processo de adoção de práticas do XP. A equipe é responsável pelos diversos sistemas da universidade, grande parte deles sistemas para web, com forte demanda de manutenção.

A adoção de XP na equipe está sendo feita passo a passo, prática a prática.
Inicialmente foram implementadas as seguintes práticas:
- Programação em Pares
- Planejamento Iterativo e Gestão visual

Nesta apresentação vamos discutir os desafios desse processo de adoção, os benefícios alcançados com as primeiras práticas adotas, os problemas e as adaptações que foram necessárias para implantar XP no cenário descrito acima e os próximos passos na implantação do processo.

Palestrantes:
- Jefferson Santos
- Marcelo Tedesco

Local: Auditório do SENAC na R. Santa Luzia, 735, 7º andar (Centro, Rio de Janeiro)
Data: terça-feira, 11/07/2006
Horário: 19 às 21 horas
A entrada é gratuita e não é necessário fazer inscrição, nem confirmar a presença.

XP 2006 - Fotos

2006-06-20T07:03:00.000-03:00

As fotos do XP 2006 estão sendo colocadas no endereço:

http://www.pbase.com/patfig/xp2006

Até o momento, temos dois dias de fotos publicadas, do domingo e da segunda-feira.

Abraços,

Vinícius

XP 2006 - Primeiro dia

2006-06-17T18:54:00.000-03:00

Hoje teve início o XP 2006 aqui em Oulu, na Finlândia.
Ao todo, somos aproximadamente 260 participantes. Obviamente, tem muita gente de todas as partes da Europa, mas com algumas exceções interessantes, tais como França, Espanha e Portugal. Tem também muita gente dos EUA e Canadá e algumas pessoas de países no oriente, tais como Turquia, Israel, China, índia e Nova Zelândia. Eu sou o único representante da América Latina, mas amanhã, serão dois brasileiros, eu e minha esposa, que acabou de assumir o posto de fotógrafa do evento. :-) Como ela é fotógrafa profissional, a combinação não poderia ser melhor. Então, se tudo der certo, amanhã teremos fotos por aqui.

Os tutoriais que assisti hoje foram:

* Effective measurement of the software process
Alberto Sillitti e Giancarlo Succi (Itália)

* Programmers are from Mars, Customers are from Venus: A practical guide to working with customers on XP Projects
Angela Martir, Robert Biddle, James Noble (Nova Zelândia)

Em ambos os casos, algumas idéias interessantes, mas poucas novidades. Conversei com diversas pessoas hoje e a impressão inicial é um tanto óbvia. Os problemas por aqui para quem está usando, ou tentando usar XP, são bem semelhantes aos que temos no Brasil. Considerando os projetos XP em que estive envolvido nos últimos quatro anos, poderia dizer tranquilamente que estamos basicamente no mesmo nível que o pessoal daqui, mas em algumas coisas eu diria que estamos bem melhor. Em relação a diversos países, o Brasil está mais avançado no uso de XP. Na área acadêmica, em particular, eu diria que o Brasil se destaca, já que inúmeras faculdades ensinam XP atualmente e isso não é tão comum por aqui. Até porque, pelo que pude perceber conversando com algumas pessoas, é mais difícil alterar a grade curricular aqui.

No geral, minha impressão é que estamos indo muito bem, embora tenha muito, muito espaço para melhorar e muita empresa com potencial para usar XP no Brasil. Sendo que aí algumas coisas são infinitamente mais fáceis. Por exemplo, falamos uma única língua. Aqui, só na conferência, temos gente falando em torno de 20 idiomas diferentes. E aqui na Europa é bem complicado arrrumar gente qualificada, então a solução frequentemente acaba sendo importar gente de países diferentes, o que naturalmente leva a dificuldades com idiomas, diferenças culturais etc.

A conferência está só começando, mas a sensação que se tem é de que o Brasil tem tudo para crescer muito nessa área e certamente poderá colher muitos benefícios com isso. A propósito, uma coisa que é muito conhecida aqui é o apoio ao software livre, especialmente vindo do governo. Aqui todos parecem conhecer Lula e Gilberto Gil, além dos Ronaldos, Pelé e outros jogadores de futebol. :-) Aliás, o que mais se vê por aqui é gente vestindo a camisa do Brasil e torcendo pelo Brasil na Copa. Hoje almocei com um pessoal do Banco Central da Turquia e eles me disseram que por lá, todo mundo torce pelo Brasil desde criancinha. ;-)

Amanhã e mando mais novidades da conferência e, se possível, algumas fotos.

Grande abraço,

Vinícius Teles

JUnit 4.0 em 10 minutos

2006-05-31T12:04:00.000-03:00

Há pouco foi lançada a versão 4.0 do JUnit. Este artigo é uma breve introdução às novidades desta versão.

"Aplicando Extreme Programming onde o cliente não está presente" - Reunião de Maio do XPRio

2006-05-23T10:15:00.000-03:00

Na próxima quarta-feira estaremos realizando a nossa reunião do mês de maio.

Um dos maiores problemas ao decidirmos por adotar XP como um processo de desenvolvimento é termos o "cliente próximo". Ao mesmo tempo sabemos que esta prática é fundamental para o sucesso do projeto.
Por este motivo, estaremos realizando uma mesa-redonda sobre o tema "Aplicando Extreme Programming onde o cliente não está presente".
Para destacar as principais questões envolvidas pelo tema convidamos o Alexandre Dantas, que vem desenvolvendo uma pesquisa sobre o assunto.

Local: Auditório do SENAC na R. Santa Luzia, 735, 7º andar (Centro, Rio de Janeiro)
Data: quarta-feira, 24/05/2006
Horário: 19 às 21 horas
A entrada é gratuita e não é necessário fazer inscrição, nem confirmar a presença.

OBS: Excepcionalmente este mês não realizamos a reunião na segunda terça-feira do mês. A próxima reunião já está confirmada para o dia 13/06/2006, terça-feira, e em breve estaremos divulgando o tema.

Feedback sobre reunião de abril

2006-04-27T12:34:00.001-03:00

Como já sabemos acabou não sendo possível filmar a reunião... tentaremos numa próxima oportunidade. Também não estaremos disponibilizando qualquer material pois, como alguns puderam presenciar, a apresentação foi em sua maior parte programação e execução de testes.

Gostaria de agradecer àqueles que compareceram... mais uma vez foi muito boa a oportunidade de discutir tantas idéias - o difícil é controlar o escopo : )

Seguem algumas fotos...

Reunião do XPRio, 25/04/2006 (terça-feira), às 19h no SENAC.

2006-04-19T16:58:00.000-03:00

Desenvolvimento Guiado por Testes (TDD): condução e automação.

Será apresentada a forma de condução do desenvolvimento de um cartão definido pelo cliente (user story), através da geração inicial de testes de aceitação e da codificação da funcionalidade guiada por testes unitários, incluindo o uso de um mecanismo simples de persistência que permite um feedback rápido.

Serão utilizadas as ferramentas Selenium (www.openqa.org/selenium), JUnit (www.junit.org) e Prevayler (www.prevayler.org).

Palestrantes:
* Carlos Miranda
* Luiz Esmiralha

Local: Auditório do SENAC na R. Santa Luzia, 735, 7º andar (Centro, Rio de Janeiro)
Data: terça-feira, 25/04/2006
Horário: 19 às 21 horas
A entrada é gratuita e não é necessário fazer inscrição, nem confirmar a presença.

Ao chegar ao local, caso haja algum atraso e nenhum coordenador do XPRio tenha chegado, favor entrar em contato com Vinícius Teles (21) 8716-5434.

Eles não vão ler isto...

2006-04-04T14:22:00.000-03:00

"Extreme Programming (XP) introduced the YAGNI (You Aren't Gonna Need It) principle which advises you to not invest time overbuilding software because you likely won't need the extra functionality anyway, and that the time you spent building stuff that you don't need could instead have been invested building stuff that you do need. There's a complementary concept with respect to documentation: TAGRI, They Aren't Gonna Read It. The basic idea is that very little of the documentation which gets created during software development actually gets read by the actual target audience."

Produzindo documentos

2006-03-29T10:03:00.000-03:00

Ron Jeffries trata da abordagem dos processos ágeis em relação a documentação. Quais documentos gerar? Como planejar sua elaboração? Como lidar com o cliente sobre este assunto?

Porque o desenvolvimento ágil funciona?

2006-03-27T18:58:00.000-03:00

Scott Ambler aposta no feedback constante como resposta e explora essa idéia no artigo "Why Agile Software Development Techniques Work: Improved Feedback".

Scrum e XP no desenvolvimento de Games

2006-03-24T09:55:00.000-03:00

"In an industry notorious for release slippage and product bloat, new ways of streamlining the development process are a hot topic. High Moon Studios' Clinton Keith uses Agile as an example in efficiency..."

Feedback sobre a última reunião

2006-03-16T10:26:00.000-03:00

Na última reunião do XPRio foi apresentado o Estudo de Caso "Implantação do Extreme Programming na Ancar". Foi gratificante ver o resultado do trabalho feito pelo Vinícius Teles apresentado pela própria equipe de desenvolvimento da empresa. Pudemos aprender com a experiência vivida por eles na adoção do XP, desde a visão do diretor da equipe até a dos desenvolvedores recém-contratados, os quais esclareceram as dúvidas e discutiram pontos específicos com os demais participantes do encontro. Gostaria de, em nome de todos do XPRio, aproveitar para parabenizar a Improve It e a Ancar pelo trabalho desenvolvido e pela excelente apresentação.
O material usado na apresentação e o texto completo sobre o Estudo de Caso estão disponíveis no site da Improve It.

Seguem algumas fotos do encontro...

Vinícius Teles (Improve It) iniciando a apresentação.

Ricardo Carvalho (Ancar) fala sobre o histórico da empresa e o processo de decisão da adoção do XP.

Participantes do encontro.

Momento de descontração: Bob Esponja - o companheiro da Integração Contínua - é apresentado.

Reunião do XP Rio: Estudo de Caso da Ancar (14/03/2006)

2006-03-13T21:56:00.000-03:00

Reunião do XP Rio, terça-feira, 14/03/2006 às 19h no SENAC.

Estudo de Caso: Implantação do Extreme Programming na Ancar

A Ancar é uma empresa especializada na gestão de shopping centers, que há um ano vem trabalhando com Extreme Programming. Nesta reunião, serão apresentados os resultados obtidos até o momento. É uma excelente oportunidade de conhecer a realidade prática de um projeto XP, interagir com pessoas que estão usando a metodologia há algum tempo e vislumbrar a utilização prática de inúmeras ferramentas e APIs para desenvolvimento em Java, tais como:

- IDEA IntelliJ
- Ant
- CVS
- JUnit
- EasyMock
- Emma
- Prevayler
- Hibernate
- Java Web Start
- Java2D

Palestrantes:

* Ricardo Carvalho (Ancar)
* Celestino Gomes (Ancar)
* Paulo Filipak (Ancar)
* João Venâncio (Ancar)
* Vinícius Teles (Improve It)

A apresentação, bem como o texto completo do estudo de caso em português e um texto resumido em inglês (artigo submetido para o congresso internacional XP 2006) estarão disponíveis para download a partir de 15/03/2006 no site:

http://www.improveit.com.br

Local, Data e Horário
Local: Auditório do SENAC na R. Santa Luzia, 735, 7º andar (Centro, Rio de Janeiro)
Data: terça-feira, 14/03/2006
Horário: 19:00h às 21:00h
A entrada é gratuita e não é necessário fazer inscrição, nem confirmar a presença.

Ao chegar ao local, caso haja algum atraso e nenhum coordenador do XP Rio tenha chegado ainda, entre em contato com Vinícius Teles pelo telefone (21) 8716-5434.

Bancos de Dados nos Processos Ágeis

2006-03-10T12:22:00.000-03:00

Um dos pontos polêmicos (entre tantos) dos processos ágeis é como administrar que o modelo de banco de dados também seja tratado de forma evolutiva. Scott Ambler é um pioneiro neste tema.
O Cutter Consortium publicou uma coleção de 5 artigos do Ambler tratando do assunto e os mesmos podem ser acessados gratuitamente, exigindo apenas alhumas informações para cadastro.
Ainda, Ambler acaba de lançar novo livro, Refactoring Databases: Evolutionary Database Design.

Artigo sobre o livro Agile & Iterative Development

2006-03-10T10:03:00.000-03:00

"Explaining agile development concepts to managers can be a lost cause. Craig Larman's book can help your manager see the light."

Agile Journal

2006-03-09T19:53:00.000-03:00

Novidades no mundo ágil: é só conferir!

Podcasts

2006-03-07T14:28:00.000-03:00

O site IT Conversations disponibiliza Podcasts excelentes, incluindo alguns sobre desenvolvimento ágil. Procure, por exemplo, os podcasts de:

Kent Beck (XP)
Ken Schwaber (Scrum)
Alistair Cockburn (Crystal Clear)
Scott Ambler (Agile Modeling)

São todos muito bons e proveitosos.

Lean Sotware Development: A Field Guide

2006-01-23T10:06:00.000-02:00

Em seu site, Mary Poppendieck está disponibilizando o draft de seu novo livro. Quem quiser acompanhar pode baixar e ler os capítulos conforme disponíveis. Para discutir o conteúdo basta se inscrever no grupo Lean Development.

Livros sobre XP e desenvolvimento agil

2006-01-16T16:35:00.000-02:00

Publicamos a lista de livros sobre XP e desenvolvimeto ágil que pode ser acessada no link:

http://www.improveit.com.br/xp/livros.jsp

Contrato de Escopo Negociavel

2006-01-10T22:09:00.000-02:00

Projetos XP usam contratos de escopo negociável, que já foram discutidos inúmeras vezes no XP Rio. Para facilitar o entendimento da questão, esse artigo apresenta esse modelo de contrato, com detalhes, incluindo um exemplo.

Desenvolvimento Orientado a Testes (com exemplo)

2006-01-10T17:20:00.000-02:00

O artigo sobre desenvolvimento orientado a testes foi colocado no link http://www.improveit.com.br/xp/tdd.jsp onde passou a contar com imagens e uma formatação mais apropriada.

Reuniao do XP Rio de Janeiro: Integracao Continua

2006-01-10T17:19:00.000-02:00

Amanhã, 11/01/2006, ocorrerá a reunião mensal do XP Rio. O tema será:
Integração contínua usando CVS, Ant, JUnit e Emma.

Em projetos XP, os pares integram o código que produzem,
sincronizando-o com o restante da equipe várias vezes ao dia. A cada
integração, o código é atualizado, é feito o build da aplicação e os
testes são executados. A maior parte do processo é automatizada com a
ajuda de algumas ferramentas essenciais tais como CVS, Ant e JUnit. O
Emma, por sua vez, pode ser usado para analisar a cobertura dos
testes e alertar os pares para eventuais partes do código que não
tenham sido cobertas. A apresentação será conduzida por mim e
tentarei fornecer o máximo de exemplos práticos.

Tema: Integração contínua usando CVS, Ant, JUnit e Emma
Local: Auditório do SENAC na R. Santa Luzia, 735, 7º andar (Centro,
Rio de Janeiro)
Horário: 19:30h às 21:00h
A entrada é gratuita e não é necessário fazer inscrição, nem
confirmar a presença.

Lean e XP no One Day Java 2005

2005-11-17T22:15:00.000-02:00

Neste sábado ocorrerá o One Day Java 2005, desta vez descendo a serra para ser realizado na cidade maravilhosa.

Àa 16 horas, estarei apresentando a palestra "Lean Software Development e eXtreme Programming: Entregue valor constantemente, com rapidez, eficiência e confiabilidade".

Fico satisfeito de trazer esta notícia visto que, a exemplo da recente 3a. Semana de Software Livre, sempre tem sido dado algum espaço ao XP em eventos não diretamente relacionaos ao tema. E isso mostra o quanto o interesse pelo processo vem se consolidando.

Reuniao mensal do XP Rio - 09/11/2005

2005-11-08T17:20:00.000-02:00

Amanhã, 09/11/2005, ocorrerá a reunião mensal do XP Rio, na qual
todos os presentes irão participar do Jogo da Comunicação. Esse jogo
é uma forma prática e extremamente divertida de aprender diversos
conceitos sobre XP. Os participantes não precisam ter conhecimentos
técnicos para jogar, nem terão que programar ou fazer qualquer
atividade que demande conhecimento prévio. O material usado é
composto apenas por papel, caneta e outros acessórios. A diversão é
garantida e o aprendizado também. :)
Ao final do jogos, os participantes terão a oportunidade de debater
sobre o que aprenderam, sobre a forma como trabalham atualmente e o
que poderiam adotar para melhorar seus projetos com base nos
conceitos do jogo.

Local: Auditório do SENAC na R. Santa Luzia, 735, 7º andar (Centro,
Rio de Janeiro)
Horário: 19:00h às 21:00h (09/11/2005)
A entrada é gratuita e não é necessário fazer inscrição, nem
confirmar a presença.

Agile vs Lean Software Development

2005-11-04T11:51:00.000-02:00

Este artigo, indicado pelo Daniel Wildt no fórum do XP-RS, compara a abordagem Lean com a dos processos ágeis e preconiza que as empresas iniciem com a adoção do Lean, que pelo seu maior emprego gerencial teria maior aceitação e um retorno mais rápido, mesmo para projetos não-ágeis.

Entrevista com Kent Beck para a Revista Inform

2005-10-31T15:37:00.000-02:00

Na semana passada entrevistei o Kent Beck a pedido da Revista Inform. A entrevista será publicada na edição de dezembro. A entrevista segue abaixo em primeira mão para o XP Rio.

Vinícius: Como o XP se compara a abordagens tradicionais de desenvolvimento de software, tais como PSP (Personal Software Process) do SEI ou o RUP da Rational?

Kent: PSP se concentra em aprimorar habilidades individuais. RUP é uma coleção de práticas que podem ter valor para o desenvolvimento de software. Comparado a ambos, XP é muito explícito sobre a importância dos relacionamentos sociais para se desenvolver software de forma eficaz, além de forçar o lado técnico a ser mais rigoroso que o usual. XP é descrito não apenas por práticas, mas também pelos valores e princípios que motivam essas práticas.

Vinícius: XP e metodologias ágeis em geral têm uma íntima co-relação com princípios Just-in-Time criados e aprimoradas na Toyota. Você acredita que o XP terá, no longo prazo, os mesmos efeitos na indústria de software que o Just-in-Time teve na indústria automobilística?

Kent: Espero que sim, mas mudanças fundamentais como essas levam décadas para se espalhar por uma indústria, portanto, não saberemos a resposta por um tempo.

Vinícius: Você acredita que haveria vantagens para as empresas produtoras de software brasileiras se elas optassem pela adoção do XP para melhoria de qualidade, ao invés de outras abordagens, como o CMM?

Kent: Sim. As práticas do XP são descritas de forma clara, embora cada equipe deva decidir como aplicá-las. Os resultados da utilização do XP podem ser imediatos e substanciais, apesar de as equipes poderem continuar melhorando durante anos à medida que o utilizam. No XP, eu sugiro que as equipes adotem ciclos rápidos de feedback, de modo que possam avaliar rapidamente mudanças em suas práticas de desenvolvimento. Finalmente, enquanto algumas das mudanças propostas pelo XP possam ser aplicadas por um programador sozinho, algumas das práticas corolárias demandam mudanças da parte do cliente, fornecedores e executivos, além dos próprios desenvolvedores.

Vinícius: Qual é o papel dos frameworks em projetos XP e a relação deles com o valor da simplicidade?

Kent: Frameworks são arriscados quando são escritos cedo demais, pois nesse caso serão difíceis de usar. Mediocridade consistente não é um objetivo valioso. Se você estiver trabalhando no estilo XP, você primeiro constrói duas ou mais aplicações e então abstrai aquilo que é comum, fazendo com que aplicações semelhantes sejam construídas mais facilmente no futuro. Depois de muitos anos trabalhando dessa forma, as equipes terão criado frameworks poderosos, mas sem o risco de que eles sejam mais difíceis de utilizar do que o necessário.

Vinícius: Qual é o futuro do JUnit?

Kent: Estamos trabalhando ativamente no JUnit 4, que trará a primeira grande mudança na API. Nosso objetivo é fazer com que escrever testes seja ainda mais fácil e simples para os desenvolvedores. A nova versão também possui novas áreas úteis para aqueles que desejam criar plugins para o JUnit.
Além disso, os testes antigos serão executados sem modificações na nova versão e os testes baseados no novo estilo poderão ser facilmente executados em versões antigas do JUnit.

Vinícius: Quais são os seus planos com a Agitar? O que você está produzindo com eles no momento?

Kent: A Agitar Software produz ferramentas que tornam os testes dos desenvolvedores mais valiosos e mais visíveis. Acredito que o futuro do desenvolvimento de software envolva maior responsabilidade e transparência, de modo que nossos objetivos estão bem alinhados. Eu trabalho com eles planejando e revisando produtos, além de conversar com clientes e potenciais clientes.

Vinícius: Como a documentação se encaixa nas práticas do XP?

Kent: Comunicação é algo crítico para se desenvolver software de forma bem sucedida, e o meio de comunicação deve ser escolhido de modo a maximizar os benefícios e minimizar os custos. Cada equipe encontra uma forma diferente de solucionar suas necessidades de comunicação. Entretanto, uma das premissas básicas por trás do XP é que as decisões perdem valor muito rapidamente no desenvolvimento de software. Por isso, escrever documentos enormes contendo milhares de decisões de análise e design, cada uma das quais vai perdendo valor gradualmente, não é uma atividade valiosa. Equipes normalmente encontram formas de comunicação melhores que essa.

Vinícius: Quais são os pontos negativos do XP que você já tenha notado como sendo os mais nítidos?

Kent: Ele desafia as convicções de algumas pessoas. Para aplicá-lo de forma eficaz, as crenças precisam estar alinhadas com as do XP. Quando pensamentos básicos estão desalinhados com os valores do XP há interferências nos benefícios que podem ser obtidos. Para alguns, isso requer uma grande mudança na forma de pensar e de agir.

Vinícius: Você acredita que o XP possa ser aplicado a projetos que envolvam muitas pessoas? Isso impediria o sucesso da adoção do XP?

Kent: Acredito que o XP possa ser aplicado em muitas escalas diferentes. As verdades básicas sobre a natureza humana e sobre desenvolvimento de software são as mesmas para uma equipe de uma pessoa ou de mil. Grandes organizações que obtiveram sucessos isolados com desenvolvimento ao estilo do XP estão interessadas em obter os mesmos tipos de melhorias em toda a equipe. Acredito que seja positivo para o XP que as companhias queiram que todos as suas equipes mostrem resultados concretos com frequência, que tenham significativamente menos defeitos e que reduzam custos de uma forma geral.

Vinícius: O que você recomenda para empresas interessadas em começar a utilizar o XP?

Kent: Experimente. O processo mais eficaz que encontrei para a aplicação do XP é olhar para as práticas e lembrar momentos nos quais você e a sua equipe fizeram um bom trabalho. Então, aplique aquilo que você já sabe que funciona, mas veja se você consegue fazer algo ainda melhor desta vez. Gerentes têm o direito de demandar visibilidade e responsabilidade de suas equipes. XP é uma forma de prover comunicação clara sobre o projeto. Os outros processos que você mencionou no início da entrevista são outras formas de atingir esse objetivo.

Obrigado pela oportunidade de me expressar para o público brasileiro. Entrem em contato caso tenham mais questões.

Sinceramente,

Kent Beck
Diretor, Threee Rivers Institute

Artigo "Extreme Programming as Nested Conversations"

2005-10-31T11:01:00.000-02:00

Este artigo foca na parte do Jogo do Planejamento (levantamento de requisitos e controle/execução de atividades)... como o próprio autor coloca:

"We’ll look at XP as a series of nested conversations. You’ll see a pattern repeated at each level: explore, plan, define a test, do the work, verify the result.

Nested Conversations in XP

Month scale
Release planning, iterations, release to users

Week scale
Iteration planning, daily work, release to customer

Day scale
Standup meeting, paired programming, release to development team

Hour/Minute scale
Test, code, refactor"

Entrevista com Kent Beck, Cynthia Andres e Tom DeMarco sobre XP Explained 2nd Edition

2005-10-25T11:47:00.000-02:00

Nesta entrevista, Kent Beck fala sobre mudanças na nova edição de Extreme Programming Explained. Além do texto, você também pode escutar toda a entrevista, bem como uma descrição geral do livro apresentada por Bruce Taylor.

Extreme Programming - Visão Geral

2005-10-25T00:46:00.000-02:00

Extreme Programming - Visão Geral

Você colocaria grande parte do seu dinheiro em um investimento que tivesse 70% de chances de dar prejuízo? Talvez não, mas supondo que você seja suficientemente corajoso e decida fazer isso, você acompanharia o seu investimento de perto, ou só se preocuparia com ele de vez em quando?

Essas perguntas têm muito em comum com a indústria de software e talvez você se interesse por elas, se tiver a oportunidade de apreciar alguns números levantados por uma empresa americana chamada Standish Group. Há pouco mais de uma década, ela vem produzindo um relatório chamado The Chaos Report, cujo exemplar do ano 2000, que pesquisou 280 mil projetos de software nos EUA, revelou que 72% deles falham devido a um dos seguintes fatores:

a) Consomem mais recursos que o orçado
b) Consomem mais tempo que o estimado
c) Não entregam o que foi combinado
d) Todas as alternativas acima em conjunto

Infelizmente a letra d) é a regra geral. Além disso, os atrasos normalmente representam 63% mais tempo que o estimado, os gastos normalmente são 45% maiores que o orçado e no geral apenas 67% das funcionalidades prometidas são efetivamente entregues. Destes 280 mil projetos, 23% deles fracassaram tão vigorosamente que foram cancelados ("apenas" 64.400 projetos).

O Standish Group também informa que, pesquisando o grau de utilização das funcionalidades dos sistemas que são colocados em produção, foi descoberto que, tipicamente, 45% das funcionalidades nunca são utilizadas pelos seus usuários e 19% delas raramente são usadas, totalizando 64% de funcionalidades que poderiam deixar de ser produzidas. Por outro lado, o mesmo estudo revelou que 7% das funcionalidades são usadas sempre e outros 13% são usados com frequência. Assim, concluiu-se que o Princípio de Pareto também se aplica ao desenvolvimento de software, onde 20% das funcionalidades costumam gerar 80% ou mais do benefício esperado.

O Manifesto Ágil

Nem todos os que trabalham na indústria de software têm conhecimento destes números, mas praticamente todos percebem, ainda que intuitivamente, que muita coisa é feita de forma errada e ineficaz, gerando problemas que não parecem ter fim. Existem inclusive piadas citando que nós estamos aqui para resolver os problemas que nós mesmos criamos.

Há alguns anos, um pequeno grupo de profissionais veteranos na área de software decidiram se reunir em uma estação de ski, nos EUA, para discutir formas de melhorar o desempenho de seus projetos. Embora cada envolvido tivesse suas próprias práticas e teorias sobre como fazer um projeto de software ter sucesso, cada qual com as suas particularidades, todos concordavam que, em suas experiências prévias, um pequeno conjunto de princípios sempre pareciam ter sido respeitados quando os projetos davam certo. Com base nisso eles criaram o Manifesto para o Desenvolvimento Ágil de Software, frequentemente chamado apenas de Manifesto Ágil, e o termo Desenvolvimento Ágil passou a descrever abordagens de desenvolvimento que seguissem estes princípios, que são apresentados a seguir:

"Estamos descobrindo maneiras melhores de desenvolver software fazendo-o nós mesmos e ajudando outros a fazê-lo. Através desse trabalho, passamos a valorizar:

- Indivíduos e interação entre eles mais que processos e ferramentas
- Software em funcionamento mais que documentação abrangente
- Colaboração com o cliente mais que negociação de contratos
- Responder a mudanças mais que seguir um plano

Ou seja, mesmo havendo valor nos itens à direita, valorizamos mais os itens à esquerda."

O Manifesto Ágil, criado em 2001, descreve a essência de um conjunto de abordagens para desenvolvimento de software criadas ao longo da última década. A mais conhecida delas é o Extreme Programming, também conhecida pela abreviação XP, uma metodologia criada por Kent Beck no final dos anos 90. O XP é composto por um pequeno conjunto de práticas, que giram em torno de alguns valores básicos.

Valores:

- Feedback

Algumas pessoas seriam capazes de caminhar na beirada de um precipício com os olhos fechados, ou colocar a maior parte do seu dinheiro em um investimento com elevada chance de prejuízo sem acompanhá-lo de perto. Entretanto, a maioria das pessoas provavelmente manteria os olhos bem abertos em ambos os casos. Isso é particularmente verdade no caso de equipes trabalhando com XP. Elas acreditam que projetos de software são iniciativas frequentemente caras, arriscadas e com um histórico repleto de falhas, o que as leva a simples conclusão de que provavelmente o projeto em que estão envolvidas também enfrentará falhas e problemas, como é habitual na área de software.
Isso pode ser tratado de forma mais econômica e eficaz se as falhas forem detectadas rapidamente. Normalmente, quanto mais cedo descobrimos um problema, menos prejuízos ele pode causar e maiores são as chances de resolvê-lo de forma barata. Por isso, projetos XP estabelecem formas de encurtar ao máximo a defasagem de tempo entre o momento em que uma ação é executada e o seu resultado é observado. Assim, por exemplo, desenvolvedores procuram entregar novas funcionalidades no menor prazo possível, para que o cliente compreenda rapidamente as consequências daquilo que pediu. Os clientes, por sua vez, procuram se manter próximos dos desenvolvedores para prover informações precisas sobre qualquer dúvida que eles tenham ao longo do desenvolvimento.

- Comunicação

O cliente de um projeto de software tem um conjunto de problemas que deseja solucionar com o sistema em desenvolvimento e possui algumas idéias sobre que funcionalidades podem resolvê-los. Por sua vez, desenvolvedores possuem conhecimento sobre aspectos técnicos que influenciam a forma de solucionar o problema do cliente. Para que os desenvolvedores compreendam o que o cliente deseja e este último entenda os desafios técnicos que precisam ser vencidos, é preciso que haja comunicação entre as partes. Embora existam inúmeras formas de se comunicar idéias, algumas são mais eficazes que outras. Por exemplo, quando duas pessoas estabelecem um diálogo presencial, inúmeros elementos da comunicação colaboram para a compreensão do assunto, tais como gestos, expressões faciais, postura, palavras verbalizadas, tom de voz, emoções, entre outros. Quanto maior a capacidade de compreensão, maiores as chances de evitar problemas como ambiguidades, entendimento equivocados, entre outros. Diálogos são mais eficazes que videoconferências, que são melhores que telefonemas, que são mais expressivos que emails e assim sucessivamente. Conscientes disso, aqueles que trabalham com XP priorizam o uso do diálogo presencial, com o objetivo de garantir que todas as partes envolvidas em um projeto tenham a chance de se compreenderem da melhor maneira possível.

- Simplicidade

XP, assim como outras metodologias ágeis, se baseia em premissas que, frequentemente, representam o inverso do que as práticas habituais da indústria de software sugerem. Ele leva em consideração outros pontos de vista, aparentemente sem sentido, o mesmo que ocorreu há pouco mais de 50 anos quando se iniciou o desenvolvimento do Sistema de Produção da Toyota, também conhecido como Just-in-Time.
No início, o Just-in-Time foi considerado, especialmente pelos americanos, uma idéia absurda, porque se baseava no inverso das práticas as quais a indústria automobilística estava habituada a utilizar. No entanto, o avanço da indústria automobilística japonesa é bem conhecido atualmente e a Toyota é, há décadas, a montadora mais lucrativa do mundo. Parte disso tem a ver com uma filosofia que também norteia as práticas do XP: não produzir mais que o necessário.
A Toyota acredita que o maior desperdício que existe é produzir algo que ninguém irá utilizar. Se você leu atentamente os parágrafos anteriores, deve recordar que 64% das funcionalidades tipicamente produzidas não são utilizadas. Isso representa mais da metade delas e, possivelmente, bem mais da metade do tempo e dos gastos de um projeto típico de software.
O XP utiliza o conceito de simplicidade em inúmeros aspectos do projeto para assegurar que a equipe se concentre em fazer, primeiro, apenas aquilo que é claramente necessário e evite fazer o que poderia vir a ser necessário, mas ainda não se provou essencial.

- Coragem

Costuma-se dizer que a única constante em um projeto de software é a mudança. Clientes mudam de idéia com frequência, mesmo quando fecham contratos nos quais, teoricamente, assumem o compromisso de não alterar o que está na especificação. Eles mudam porque aprendem durante o projeto e descobrem problemas mais prioritários a serem solucionados ou formas mais apropriadas de resolvê-los. Embora isso seja natural, acaba gerando uma preocupação para a equipe de desenvolvimento que, de tempos em tempos, precisa alterar partes do sistema que já estavam prontas, correndo o risco de se quebrar o que já vinha funcionando.
XP não tem uma solução mágica para eliminar esse risco. Ele existe em um projeto XP, como existe em qualquer outro. O que muda é a forma de lidar com ele. Equipes XP acreditam que errar é natural e quebrar o que vinha funcionando é acontece cedo ou tarde. É necessário ter coragem para lidar com esse risco, o que em XP se traduz em confiança nos seus mecanismos de proteção. As práticas do XP são voltadas, entre outras coisas, para proteger o software de inúmeras formas. Equipes XP confiam na eficácia destas práticas e destes mecanismos de proteção e isso é o que as tornam receptivas a mudanças. Assim, ao invés de frear a criatividade do cliente e evitar mudanças, equipes XP as consideram inevitáveis e procuram se adaptar a elas com segurança e com coragem, isto é, com confiança em seus mecanismos de proteção.

Práticas:

- Cliente Presente

Projetos XP procuram contar com a presença do cliente, junto à equipe de desenvolvimento, tanto quanto possível. Isso não significa que ele tenha que estar 100% de seu tempo com os desenvolvedores, mas sim que deve procurar, no mínimo, visitá-los e dialogar com eles inúmeras vezes ao longo do projeto, com a maior frequência possível. Como explicado anteriormente, XP valoriza o diálogo como forma de assegurar maior compreensão entre as partes. Portanto, a presença do cliente permite que os desenvolvedores compreendam melhor o que se espera do software, bem como permite que o cliente monitore de perto o avanço do projeto. Se alguém acha que clientes não têm tempo para dedicar aos desenvolvedores, vale lembrar que clientes de software estão lidando com um investimento arriscado, no qual as chances de prejuízo, como dito antes, são bastante elevadas.

- Jogo do Planejamento

O software é desenvolvimento de modo iterativo e incremental em projetos XP. Ou seja, uma vez por semana os desenvolvedores se reúnem com o cliente para priorizar um pequeno conjunto de funcionalidades que, no conjunto, possam ser implementadas e testadas completamente naquela semana. Terminado esse período, que é chamado de iteração, o cliente tem a oportunidade de utilizar e avaliar o que foi produzido. Com base nos resultados, reúne-se novamente com a equipe e estabelece novas prioridades de acordo com o que acabou de aprender com o software e com aquilo que já imaginava ser necessário produzir ao longo do restante do projeto. Essa reunião semanal recebe o nome de Jogo do Planejamento. Nela, o cliente tem o direito de informar as funcionalidades, também chamadas de histórias, bem como indicar a prioridade das mesmas. Os desenvolvedores, por sua vez, têm o direito de estimar e apresentar suas considerações técnicas. O objetivo do jogo do planejamento é criar um plano para uma semana de trabalho, que seja capaz de gerar (através de funcionalidades) o máximo de valor possível para o negócio do cliente, naquela semana.

- Stand Up Meeting

O stand up meeting é uma reunião rápida (em torno de 10 minutos) realizada no início de cada dia, onde os participantes normalmente ficam em pé (daí a origem do nome), cujo objetivo é atualizar todos os membros da equipe a respeito do que ocorreu no dia anterior e priorizar as atividades do dia que está começando. Ela é uma forma simples de assegurar que as pessoas obtenham feedback rápido sobre qualquer aspecto do projeto, bem como um mecanismo para planejar o que precisa ser feito primeiro, fazendo com que todos relembrem e reavaliem frequentemente o que é mais importante de se fazer a cada dia.

- Programação em Par

Programação em par é uma das práticas mais conhecidas e mais polêmicas utilizadas em projetos XP. Quando é adotada, todo e qualquer código produzido no projeto é implementado por duas pessoas juntas, diante do mesmo computador, revezando-se no teclado. À primeira vista, a programação em par parece impensável, pois dá a impressão incorreta de que consome mais recursos ou eleva o tempo do desenvolvimento. Mas, não é o que acontece.

Companhias aéreas, por exemplo, utilizam co-pilotos, quando na prática, o piloto teria condições de realizar todo o trabalho sozinho. Elas colocam dois profissionais (exaustivamente treinados e relativamente caros) para fazer o trabalho que um só poderia fazer porque acredita-se (e as estatistísticas confirmam) que a chance de duas pessoas errarem seja significativamente menor que a probabilidade de uma única pessoa se equivocar. No caso da aviação, falhas humanas podem ter consequências drásticas. Os custos materiais podem ser elevados e o custo humano pode ser impagável. No caso de software, embora nem todas as falhas tenham o mesmo tipo de consequência que se observa na aviação, no mínimo as falhas costumam consumir tempo e dinheiro.

A programação em par é uma forma eficaz de reduzir a incidência de bugs, pois trata-se de um mecanismo de inspeção de código que opera permamentemente ao longo do projeto. Há muito tempo se pesquisa sobre técnicas de inspeção de código e já se sabe que elas são muito eficazes na redução de bugs. A programação em par nada mais é do que a incorporação da técnica de inspeção de código a tudo o que é produzido no projeto, o tempo todo. Ou seja, é apenas uma técnica comprovadamente eficaz (a inspeção de código) sendo utilizada em seu grau mais elevado, isto é, o tempo todo.

A programação em par ajuda os desenvolvedores a criarem soluções mais simples, mais rápidas de implementar e mais fáceis de manter. Isso ocorre devido à oportunidade de dialogar, trocar idéias e explorar mais alternativas do que os desenvolvedores fariam se estivessem sozinhos. A programação em par também produz um efeito conhecido como pressão do par que faz com que os desenvolvedores tenham maior foco na atividade e faz com que isso se mantenha por mais tempo. Maior foco significa menos dispersões ao longo do dia, o que por sua vez significa que a empresa aproveita melhor o tempo que o desenvolvedor passa com ela.
Uma das características mais marcantes da programação em par é a sua capacidade de disseminação de conhecimento, que ajuda a elevar rapidamente as habilidades técnicas dos membros da equipe. Isso tem efeitos extraordinários no médio e longo prazos, porque quanto mais habilidoso um desenvolvedor é, melhores se tornam as suas soluções. Elas ficam mais claras, mais limpas, mais fáceis de compreender e se acerta mais vezes. Além disso, normalmente se consegue gerar tais soluções com maior rapidez. O efeito cumulativo de inúmeras soluções melhores e mais rápidas ao longo do projeto representa um enorme ganho de produtividade.
O conjunto de características apresentadas acima faz com que a programação em par acelere o desenvolvimento e o torne mais econômico, embora à primeira vista pareça o contrário. Em função da redução de bugs (e consequente redução no tempo de depuração), pressão do par, maior simplicidade das soluções, disseminação do conhecimento, maior confiança nas soluções, entre outros efeitos que a programação em par produz, uma atividade feita em par normalmente é encerrada mais rapidamente que outra feita por um programador solitário e a solução tende a ser melhor.

- Desenvolvimento Orientado a Testes

Observando-se o trabalho de um desenvolvedor, nota-se que boa parte do seu tempo é dedicada à depuração de bugs. Trata-se de uma atividade frequentemente demorada que se repete inúmeras vezes à medida que o desenvolvedor produz mais código para seu projeto. Idealmente, gostaríamos que softwares nunca tivessem defeitos, mas infelizmente, em função da complexidade de cada sistema, esse objetivo dificilmente é factível, levando à necessidade de depuração. Entretanto, o tempo gasto com depuração pode ser reduzido significativamente quando se consegue assegurar que os erros sejam detectados imediatamente, assim que são introduzidos. Quando este é o caso, é mais rápido depurar e compreender o que pode ter causado o problema porque o programador tem, em sua memória, todo o contexto relativo à funcionalidade que está desenvolvendo. Não é necessário relembrar algo que foi implementado meses atrás.
É possível detectar problemas imediatamente desde que tenhamos o hábito de implementar testes automatizados antes de cada funcionalidade, de cada classe e de cada método criados no sistema. Quando isso é feito, criamos um mecanismo automatizado que aponta os problemas assim que eles são inseridos, o que reduz o tempo de depuração, além de servir como um mecanismo para testar o bom funcionamento do sistema a qualquer momento.
Equipes que trabalham com XP se preocupam em criar softwares saudáveis, que funcionem corretamente e permaneçam assim ao longo do tempo, à medida que recebem novas funcionalidades e alterações. Em se tratando de saúde, a prevenção é o melhor remédio e no caso de software não é diferente. Para tornar os sistemas saudáveis, equipes XP investem em testes automatizados, implementados antes mesmo de escrever o código das funcionalidades. Em particular, procura-se criar testes de unidade e testes de aceitação. Os primeiros, verificam se cada classe, ou seja, cada pequeno componente da aplicação, funciona como esperado. Já um teste de aceitação procura assegurar que uma determinada funcionalidade, representada pela interação de inúmeros componentes, está funcionando corretamente. Assim como a programação em par, o desenvolvimento orientado a testes ajuda a criar uma rede de proteção em torno do software, para que ele se mantenha saudável ao longo do tempo.

- Refatoração

Quando deixamos de cuidar de nossa casa, a poeira se acumula, a pia fica cheia de louça suja, as lixeiras ficam entupidas e aquilo que se costumava chamar de lar se transforma em um lugar pouco agradável. Para evitar que isso ocorra, investimos tempo frequentemente para varrer, lavar a louça, arrumar a cama, retirar o lixo, entre outras atividades. Isso nos ajuda a ter mais conforto e permite que utilizemos a nossa casa para o que desejarmos, como por exemplo, convidar amigos para assistir a um jogo conosco.
Assim como a nossa casa, sistemas também se deterioram quando não investimos continuamente na limpeza e na organização dos mesmos. A estrutura de qualquer sistema tende a se degradar ao longo do tempo, à medida em que novas funcionalidades são inseridas, alterações são feitas, erros são corrigidos e mais código é introduzido. Para evitar que a aplicação se transforme em uma casa suja, desorganizada e difícil de manter, equipes XP utilizam a prática de refatoração. Elas alteram pequenas partes do sistema, frequentemente, sempre que encontram uma oportunidade para melhorar o código, tornando-o mais limpo, mais claro e mais fácil de ser compreendido. Tais alterações não mudam o comportamento das funcionalidades, apenas melhoram a estrutura do código. Agindo assim de forma sistemática e com frequência, as equipes investem para que o software se mantenha sempre fácil de alterar, gerando a velocidade de desenvolvimento que os clientes de projetos XP costumam vivenciar e apreciar.

- Código Coletivo

Em um projeto XP, os pares se revezam, as pessoas se revezam na formação dos pares e todos têm acesso e autorização para editar qualquer parte do código da aplicação, a qualquer momento. Ou seja, a propriedade do código é coletiva e todos são igualmente responsáveis por todas as partes. Com isso, os desenvolvedores ganham tempo, pois não precisam esperar a autorização de um colega para editar uma área do código e há maior disseminação de conhecimento. Além disso, quando diversas pessoas têm a chance de olhar uma mesma área do código, torna-se mais frequente a identificação de oportunidades de melhoria, levando frequentemente à refatoração em áreas que precisam da mesma.

- Design Simples

O design de uma aplicação surge de forma incremental e evolutiva em projetos que trabalham com XP. O objetivo é criar a solução mais simples possível que seja suficiente para implementar as funcionalidades de cada iteração. Qualquer característica que possa ser implementada para dar apoio a funcionalidades futuras, só são codificadas de fato se e quando tais funcionalidades forem priorizadas para uma iteração. Assim, busca-se concentrar os esforços da equipe naquilo que se tem certeza absoluta de que será necessário hoje, por já ter sido priorizado pelo cliente para a iteração corrente. Aquilo que poderia ser útil no futuro, deixamos para resolver no futuro, quando houver certeza da necessidade. Isso levanta a preocupação de que não sejamos capazes de solucionar problemas futuros com rapidez. Entretanto, as demais práticas do XP ajudam a equipe a ter agilidade e segurança, de modo que ela possa esperar o futuro chegar com tranquilidade. Além disso, a prática regular de tentar se antecipar ao futuro não parece ser das mais adequadas quando se observa os padrões da indústria, ou seja, 64% de funcionalidades que tipicamente não são utilizadas, como mencionado antes.

- Metáfora

Metáforas são usadas frequentemente durante o desenvolvimento de sistemas, na medida em que os desenvolvedores criam elementos dentro do computador para simular outros que existem regularmente fora dele, no mundo físico. A lixeira, a mesa de trabalho, janelas, pastas e outros itens que estamos habituados a encontrar no computador, simulam elementos do mundo físico e seus respectivos comportamentos. XP procura explorar ao máximo a utilização de metáforas, para que clientes e desenvolvedores sejam capazes de estabelecer uma vocabulário apropriado para o projeto, repleto de nomes representando elementos físicos com os quais os clientes estejam habituados em seu dia-a-dia, de modo a elevar a compreensão mútua.

- Ritmo Sustentável

Os recorrentes problemas observados nos projetos de software levam inúmeras equipes a trabalharem longos períodos e, por exemplo, fazer horas-extras com frequência como forma de reduzir atrasos e tentar entregar o software em um prazo razoável. Entretanto, sempre que fazem isso, se esquecem de que desenvolvedores são seres humanos que, como tais, sentem fome, se cansam, ficam com sono, perdem a atenção em tais circunstâncias e introduzem bugs. Assim, é comum o tempo extra ser gasto em vão, pois o fato de trabalhar mais não significa que o projeto avançou. Para progredir, é necessário que novas funcionalidades sejam implementadas e finalizadas, sem que haja bugs esperando para serem identificados nas mãos dos usuários.
Projetos XP respeitam isso e seguem a filosofia de que o mais importante não é trabalhar mais e sim trabalhar de forma mais inteligente, em um período de tempo semanal que as pessoas sejam capazes de sustentar sem ficarem esgotadas e sem prejudicarem o trabalho com o déficit de atenção decorrente da fadiga. Existe uma distinção importante entre movimento e progresso. Uma equipe que se movimenta muita, que trabalha muitas horas, que "dá um gás" pelo projeto, mas produz várias coisas erradas não está progredindo. Está apenas consumindo energia. O importante não é se movimentar muito, é se mover na direção certa, de forma inteligente e sustentável.

- Integração Contínua

Quando inúmeros desenvolvedores trabalham juntos em um mesmo projeto, é necessário sincronizar o que estão fazendo e assegurar que o código de um se integre corretamente com o de outro. Esse processo de sincronização recebe o nome de integração contínua em XP e é executado inúmeras vezes ao dia, pois é mais fácil integrar pequenos incrementos de código do que grandes blocos de código implementados ao longo de dias. Quando há pouco a ser sincronizado em cada integração, eventuais conflitos no código são solucionados de maneira mais rápida e problemas não se acumulam uns sobre os outros.

- Releases Curtos

Com o objetivo de receber feedback rapidamente, não apenas da pessoa que atua como cliente junto à equipe de desenvolvimento, mas de toda a comunidade de usuários do sistema, projetos XP procuram criar versões pequenas do software, contendo poucas funcionalidades novas, mas que sejam colocadas em produção com frequência. Isso permite que os usuários tenham acesso ao software rapidamente, de modo que a equipe não corra o risco de investir demais em algo que não esteja correto, ou pior, em algo que não se revele necessário e valorizado pelos usuários.

Encerramento

Trabalhar com Extreme Programming equivale a encarar o desenvolvimento de software de uma forma diferente daquela a que estamos habituados. Trata-se de uma forma mais humana, onde todos - clientes, desenvolvedores e demais interessados no projeto - são identificados como pessoas que falham e que acertam. A estrutura de desenvolvimento criada pelo XP procura ajudar o projeto a explorar o que as pessoas têm de melhor e solucionar suas falhas com rapidez e segurança.
XP procura agir continuamente com priorização para evitar que trabalhos desnecessários sejam executados. Isso ajuda a poupar tempo, recursos e permite gerar maior valor para os clientes. Extreme Programming é a arte de maximizar o trabalho que não será feito. Pois, mais importante que trabalhar muito e produzir muito, é produzir a coisa certa, aquilo que o cliente realmente identifica como sendo valioso para resolver seus problemas, fazendo isso de forma consistente, segura e rápida ao longo de todo o andamento do projeto.

Programação em Par

2005-10-20T13:17:00.000-02:00

Programação em par é uma das práticas mais conhecidas e mais polêmicas utilizadas pelos que adotam o Extreme Programming. Ela sugere que todo e qualquer código produzido no projeto seja sempre implementado por duas pessoas juntas, diante do mesmo computador, revezando-se no teclado.

À primeira vista, a programação em par parece ser uma prática fadada ao fracasso e ao desperdício. Afinal, embora possa haver benefícios, temos a impressão de que ela irá consumir mais recursos ou irá elevar o tempo do desenvolvimento. Entretanto, não é exatamente isso o que ocorre.

O par

Você embarcaria em um avião que não tivesse um co-piloto? Provavelmente não, porque mesmo que você não ligasse para isso, a companhia aérea se preocupa (e muito) com essa questão, de modo que ela nem cogita permitir uma coisa dessas. Mas, para que serve um co-piloto se, na prática, seria perfeitamente possível pilotar um avião com uma única pessoa? Aliás, cada vez mais, é o próprio computador de bordo quem faz a maior parte do trabalho. Então, porque as companhias aéreas fazem questão de ter piloto e co-piloto em 100% dos vôos?

O que aconteceria se o piloto tivesse uma dor de barriga exatamente na hora do pouso, por exemplo? Havendo um co-piloto, isso não seria um problema (a propósito, tomara que eles não tenham almoçado no mesmo restaurante). Acredita-se (e as estatistísticas confirmam) que a chance de duas pessoas errarem seja significativamente menor que a chance de uma única pessoa se equivocar. No caso da aviação, falhas humanas podem ter consequências drásticas. Os custos materiais podem ser elevados e o custo humano pode ser impagável. Por essa razão, entre outras, companhias aéreas colocam dois profissionais (exaustivamente treinados e relativamente caros) para fazer o trabalho que um só poderia fazer tranquilamente.

Isso não é suficiente para garantir a segurança de um vôo, outros mecanismos também são usados e representam papéis essenciais. Porém a utilização de um co-piloto é uma das práticas que colaboram para elevar a segurança dos vôos. Embora pareça inconcebível colocar dois profissionais para fazer o trabalho que apenas um poderia fazer sozinho, como a programação em par sugere, as práticas da aviação são um exemplo de que a utilização de pares também é adotada em outras áreas, nas quais são, inclusive, bastante valorizadas.

A indústria de software

O Chaos Report do ano 2000 (produzido pelo Standish Group), que pesquisou 280 mil projetos de software nos EUA, revelou que 72% dos projetos falham devido a um dos seguintes fatores:

a) Consomem mais recursos que o orçado
b) Consomem mais tempo que o estimado
c) Não entregam o que foi combinado
d) Todas as alternativas acima em conjunto

Infelizmente a letra d) é a regra geral. Além disso, os atrasos normalmente representam 63% mais tempo que o estimado, os gastos normalmente são 45% maiores que o orçado e no geral apenas 67% das funcionalidades prometidas são efetivamente entregues. Destes 280 mil projetos, 23% deles fracassaram tão vigorosamente que chegaram a ser cancelados (são "apenas" 64.400 projetos).

Estamos falando de uma indústria na qual 72% do que se produz falha! Se fôssemos fazer uma comparação grosseira com a aviação, é como se disséssemos que a cada 100 aviões que sobem, 100 descem (um tanto inevitável), porém 72 deles não levantam vôo nunca mais (só uma maneira light de dizer que você iria preferir não estar em um destes vôos). Se olharmos software como um investimento, que é exatamente o que ele representa para a empresa que decide contratar seu desenvolvimento, é como se estivéssemos olhando para uma ação na bolsa de valores que tem 72% de chances de dar prejuízo. Imagine você comprando uma ação com essa característica. Pois isso é o que uma empresa faz atualmente quando decide contratar um projeto de desenvolvimento. Feliz dela, pois só estamos nesse pé porque as coisas andam melhorando. Em 1994, a taxa de fracassos era de 84%.

No ano passado, a Revista Exame mostrou uma reportagem trazendo números do SEI na qual comentava exaustivamente sobre a enorme quantidade de erros cometidos pelos desenvolvedores e a quantidade monumental de dinheiro que as economias de todo o mundo acabam desperdiçando por conta destes erros. A reportagem trazia resultados de pesquisas que indicavam que um programador experiente normalmente insere um erro a cada 10 linhas de código. Eu costumo brincar com isso e dizer que, sendo assim, um programador mais lento é menos arriscado do que um apressadinho. Pois esse último tem uma taxa de inserção de bugs maior.

Estes números demonstram que a indústria de software poderia fazer bom uso de práticas inovadoras que possam ajudar a eliminar tais problemas de maneiras mais eficazes do que se tem observado até hoje. As metodologias ágeis surgiram há poucos anos como uma alternativa a formas mais tradicionais de desenvolvimento de software. Baseadas em práticas que se assemelham muito com as usadas nos processos Just-in-Time criados na Toyota, na década de 50, metodologias ágeis como o Extreme Programming se baseiam em um conjunto de práticas coeso que pode ser eficaz em inúmeros projetos. A programação em par é uma destas práticas e tem grande potencial para resolver diversos problemas que afetam os projetos de software, embora não todos, naturalmente. Um dos principais benefícios da programação em par é a permanente inspeção de código que ocorre durante seu uso.

Detecção de bugs

A programação em par é uma forma eficaz de reduzir a incidência de bugs em um sistema. Isso se deve em grande parte às visões complementares que atuam durante o uso dessa prática. Quando dois desenvolvedores estão programando em par, um deles está com as mãos no teclado e no mouse. O outro está sentado ao lado, olhando para a mesma tela e preocupado em resolver o mesmo problema. Ambos estão trabalhando juntos na solução, embora apenas um esteja com as mãos no teclado. Eles conversam o tempo todo e trocam idéias sobre a solução.

A pessoa que está conduzindo o teclado (condutor) tem um campo de observação diferente do seu parceiro. Quem digita normalmente está olhando sobretudo para a linha que está editando e adjacências. O navegador, por sua vez, tem uma visão mais ampla e olha não apenas a linha que está sendo editada, mas também o restante do código que aparece na tela. Ao fazer isso, ele acaba tendo uma visão complementar que frequentemente revela problemas que o condutor não percebe com a mesma rapidez. Usando uma metáfora para ilustrar essa questão, imagine que uma pessoa está dirigindo um carro, enquanto outra está no carona. A pessoa que dirige tem uma visão geral das redondezas, mas foca a maior parte do tempo no carro adiante. Existe uma preocupação constante em não deixar o carro atingir o que está à frente, e isso exige atenção constante. Já a pessoa que está no carona, também observa que há um carro adiante, mas tem menos preocupação com essa questão. Por isso, acaba olhando mais para as redondezas, vê a paisagem com mais tranquilidade e tem condições de sinalizar problemas que o motorista só detectaria mais adiante. Por exemplo, em função de sua visão complementar, o carona pode alertar o motorista para que mude para outra faixa, visto que aquela na qual se encontram está fechada algumas centenas de metros à frente e o condutor ainda não teve condições de notar isso. Essa visão complementar, quando trazida para o código, permite que o navegador atue mais como um estrategista, olhando para o código como um todo e identificando problemas que passam despercebidos para quem está mais preocupado com a linha que está sendo digitada.

Em 1971, em um livro chamado The Psychology of Computer Programming, Gerald Weinberg mostrou que o olho humano tem uma incrível capacidade de só enxergar aquilo que deseja e, naturalmente, ignorar aquilo que não quer ver. Ele diz o seguinte: "programadores, se deixados por conta própria, ignoram os erros mais gritantes, os quais qualquer pessoa seria capaz de detectar instantaneamente". Isso se deve a um princípio bastante estudado na psicologia chamado dissonância cognitiva. Temos a tendência natural, como programadores, de acreditar que aquilo que escrevemos está certo. Inclusive, somos capazes de reler uma linha de código, que contém um erro de digitação e não enxergá-lo, mesmo depois de ler a mesma linha inúmeras vezes. Trata-se de uma pequena (e desagradável) peça que o cérebro nos prega. Contudo, um pequeno erro que passe despercebido para o condutor normalmente é notado pelo navegador por ter uma visão complementar e não ser afetado pela dissonância cognitiva de seu colega.

Quem trabalha continuamente com programação em par se habitua a corrigir e ter seu trabalho corrigido dezenas de vezes ao dia. A incidência de erros identificados pelo colega costuma ser tão elevada que surpreende quem não está acostumado ao uso da técnica. Depois de um dia ou dois experimentando a programação em par, muitas pessoas se perguntam como alguém as permite trabalhar sozinhas. É o tipo de coisa que não é intuitivo, mas acontece e só é claramente perceptível quando se experimenta a técnica.

Equipes que trabalham em par conseguem reduzir drasticamente a inserção de defeitos em seus códigos. Isso é uma mensagem compartilhada e repetida por todos que estão habituados a essa técnica. Atualmente, existem diversas pesquisas demonstrando este fato, tais como a reportada no artigo "Strengthening the case for pair programming; Laurie Williams, Robert Kessler, Ward Cunningham et al.; IEEE Software, v. 17, n.4, 2000, p. 19-25". Isso isoladamente já é um ponto positivo em favor da utilização da programação em par, especialmente se levarmos em conta os números apresentados anteriormente sobre a indústria de software. Mas, essa é uma daquelas técnicas simples, porém com resultados positivos em inúmeros aspectos e a detecção de bugs é apenas um deles. Esse aspecto, inclusive, não chega a ser novidade. Há muito tempo se pesquisa sobre técnicas de inspeção de código e já se sabe que elas são muito eficazes na redução de bugs. Atualmente, isso já não é mais assunto passível de grandes discussões, pois existe material de sobra mostrando isso. Nesse sentido, a programação em par nada mais é do que a incorporação da técnica de inspeção de código a tudo o que é produzido no projeto, o tempo todo. Ou seja, é apenas uma técnica comprovadamente eficaz (a inspeção de código) que passa a ser utilizada em seu grau mais elevado, isto é, o tempo todo.

Simplicidade

A programação em par ajuda os desenvolvedores a criarem soluções mais simples, mais rápidas de implementar e mais fáceis de manter. Isso ocorre em grande parte devido à oportunidade de dialogar e trocar idéias sobre programas que estejam sendo desenvolvidos. Quando nos deparamos com um problema, buscamos uma solução usando todo e qualquer recurso que esteja a nossa disposição. E, assim que encontramos uma solução, encerramos a busca e a utilizamos. O detalhe é que existem duas grandes categorias de problemas: os convergentes e os divergentes. Os convergentes são aqueles que aceitam uma única resposta certa. Os divergentes são aqueles que aceitam várias soluções. Problemas convergentes são raros. Normalmente são vivenciados pelas crianças no jardim de infância. São fáceis de resolver porque só há uma resposta certa. Os divergentes, por sua vez, são os mais comuns e estão ao nosso redor o tempo todo. Eles aceitam inúmeras soluções, algumas mais eficazes, outras menos.

Quando tentamos resolver um problema sozinhos, normalmente adotamos a primeira solução que encontrarmos, pois isso trata-se de uma característica psicológica conhecida como "tunelamento". Uma vez identificada uma solução, é como se entrássemos em um túnel e não enxergássemos mais nada além daquele caminho. Essa característica é ruim porque a primeira solução encontrada nem sempre é a melhor, a mais eficiente, mais simples ou mais rápida de implementar. Mas, como seres humanos, somos assim e se nos deixarem sozinhos, é exatamente isso que tenderemos a fazer.

A programação em par elimina esse problema. Quando o par se depara com um problema, cada programador começa a imaginar individualmente uma solução para ele. Depois, eles começam a discutir as soluções imaginadas. A partir desse diálogo é comum surgir uma terceira alternativa contendo características das duas anteriores. A conversa continua e de repente têm-se quatro, cinco, seis caminhos diferentes a serem escolhidos. Eventualmente, um deles acaba se revelando mais simples, ou mais rápido ou mais eficiente ou tudo isso em conjunto. Isso é bastante comum quando se programa em par e o efeito é bem perceptível: o par consegue executar a atividade mais rapidamente do que se um desenvolvedor estivesse programando sozinho. Além disso, a solução frequentemente é mais simples e mais fácil de ser compreendida por outras pessoas. A programação em par explora a diversidade de idéias que é rara de ser observada quando se programa sozinho.

Pressão do par

Se um desenvolver trabalha oito horas por dia, engana-se quem pensa que ele realmente produza durante essas oito horas. De modo geral, o aproveitamento de um programador trabalhando sozinho raramente chega sequer a 50% do tempo que passa na frente do computador. Ao longo do dia, ele lida com seu programa, bem como inúmeros emails, instant messages, telefonemas, pessoas interrompendo-o para comentar sobre o jogo do dia anterior e assim por diante. Além disso, mesmo que não houvesse nenhum agente externo para tirar a sua atenção, ele normalmente se dispersa de tempos em tempos por uma razão simples. Programar é uma atividade complexa, que exige muita atenção e lida com uma grande quantidade de variáveis que, com frequência, se comportam de maneiras indesejáveis. De tempos em tempos o programador precisa descansar e refrescar o pensamento pra ser capaz de continuar. Isso por si só já seria suficiente para fazê-lo dispersar-se várias vezes ao dia. Somando-se às inúmeras interrupções por que costuma passar, o desenvolvedor acaba dedicando menos tempo do que se imagina produzindo funcionalidades. Ainda assim, uma boa dose do tempo que consegue dedicar à programação acaba sendo consumido em depuração de erros que ele próprio produziu.

A programação em par produz um efeito conhecido como pressão do par que faz com que os desenvolvedores tenham maior foco na atividade e faz com que isso se mantenha por mais tempo. Imagine que você esteja programando em par e, de repente, resolva olhar seus emails. Trata-se de uma situação embaraçosa. Primeiro, porque há uma pessoa ao seu lado que poderá acabar lendo seus emails (e dependendo do que você ande trocando por aí, isso pode ser bastante constrangedor). Segundo porque você estará interrompendo o seu trabalho e o do seu amigo. Ou seja, há uma responsabilidade compartilhada. Quando um pára, o outro também acaba sendo prejudicado. Normalmente, não gostamos de decepcionar nossos colegas, portanto, quando programamos em par procuramos manter o maior foco possível na atividade para não atrapalhar ninguém. A responsabilidade é maior e isso faz com que o foco também o seja.

Maior foco significa menos dispersões ao longo do dia, o que por sua vez significa que a empresa aproveita melhor o tempo que o desenvolvedor passa com ela. Mas, como fica a necessidade de descansar de tempos em tempos? Quando programam em par, os desenvolvedores se revezam no teclado. Normalmente, a pessoa que está digitando se cansa mais do que o navegador. Sendo assim, de tempos em tempos o teclado troca de mãos, permitindo ao programador que o estava utilizando descansar um pouco, embora continue engajado na atividade, colaborando para a construção da solução. Sendo assim, a programação em par acaba servindo como uma forma de equilibrar a necessidade de trabalhar com o maior foco possível e, ao mesmo tempo, descansar de tempos em tempos.

Recentemente conversei com o dono de uma empresa na qual iniciamos a implantação do XP há pouco mais de um ano. Lá, eles utilizam XP atualmente em todas as suas equipes, todos trabalham em par e utilizam as demais práticas do XP. O dono me disse que o que ele mais gostou no XP foi a programação em par. Quando escutei isso, achei que tivesse escutado errado e pedi que ele repetisse, afinal, não acreditei que a pessoa que estava pagando aqueles desenvolvedores também fosse a mais entusiasmada em ter dois deles "fazendo o trabalho que um só poderia fazer sozinho". Então ele me explicou que em 20 anos de empresa, jamais tinha visto as pessoas trabalhando tanto tempo focadas da forma que via agora. Ele disse que no passado, observava que raramente os desenvolvedores utilizavam mais que metade do tempo que passavam na empresa de forma útil. E isso obviamente não era das coisas que ele mais apreciava, afinal era ele quem pagava. Por outro lado, depois que as pessoas começaram a programar em par, ele passou a notar que de um modo geral as pessoas conseguiam aproveitar no mínimo 75% do tempo que estavam no trabalho de forma extremamente útil. Isso mostra que, ao contrário do que possa parecer à primeira vista, a programação em par não consome mais recursos, pelo contrário. Ela aproveita melhor as pessoas tornando-as mais produtivas.

Disseminação do conhecimento

Uma das características mais marcantes da programação em par é a sua capacidade de disseminação de conhecimento, especialmente em projetos XP, nos quais os desenvolvedores sempre trocam de pares, fazendo com que haja maior compartilhamento de informações ao longo do projeto. Além disso, os desenvolvedores também se revezam no desenvolvimento das funcionalidades. Isto é, hoje estou trabalhando em uma parte do sistema e amanhã posso vir a codificar outra parte completamente diferente, com outro par. Esse revezamento se dá de maneira simples.

Suponha que hoje iniciei o dia trabalhando com João em uma funcionalidade. Na parte da tarde, por exemplo, João vai trabalhar com outra pessoa, em outra parte do sistema. Por sua vez, Patricia vem trabalhar comigo. No início, passo de 5 a 10 minutos lhe explicando o que eu e o João havíamos iniciado. A partir daí, ela pode simplesmente me ajudar a continuar na mesma linha de ação, bem como pode notar que há uma forma mais simples de atacar o problema. Se esse for o caso, ela me explica e com isso a solução está sendo oxigenada com uma visão renovada, não viciada, que muitas vezes acaba reduzindo o tempo total de desenvolvimento. Daí por diante, passamos a tarde desenvolvendo, por exemplo, de modo que na manhã do dia seguinte eu vou trabalhar com outra pessoa e o Fábio vem trabalhar com a Patrícia. Como ela já passou a tarde do dia anterior trabalhando na funcionalidade, eu pude deixar o par tranquilamente, pois ela já conhece o problema tão bem quanto eu. Em resumo, para que o revezamento ocorra de forma adequada, é importante que sempre haja alguém no par que já esteja trabalhando há mais tempo na funcionalidade, para que possa contextualizar a pessoa que está chegando. Isso é fácil de fazer se nós garantirmos que apenas uma única pessoa do par será trocada a cada vez que o revezamento ocorrer. Isso preserva o histórico e permite rotacionar. Entretanto, é essencial que a pessoa que tenha ficado no par, necessariamente saia dele no próximo revezamento. Isso garante que todas as pessoas na equipe tenham a oportunidade de trocar de pares.

O problema mais nítido desta abordagem é o tempo que se gasta para contextualizar a pessoa que está chegando. Esse tempo pode ser grande ou pequeno, dependendo do tamanho da funcionalidade e da frequência de trocas. De modo geral, procuramos assegurar que as funcionalidades sejam sempre quebradas para que fiquem suficientemente pequenas (o que por si só já faz com que a contextualização tenda a ser rápida). Isso é conseguido aplicando certos parâmetros ao jogo do planejamento. Nós por exemplo, trabalhamos com o hábito de assegurar que qualquer história possa ser desenvolvida em par em no máximo três dias. Caso seja estimada em um tempo superior, pedimos ao cliente que quebre a história até que esteja dentro desse parâmetro. Além disso, procuramos rotacionar os pares com frequência para que o um par nunca passe tanto tempo junto, ao ponto de ter que explicar uma quantidade enorme de coisas para a próxima pessoa que estiver chegando no par. Então, de um modo geral limitamos as sessões de pareamento a uma manhã ou uma tarde, porque não se produz tanto assim neste período de tempo. Isso faz com que a quantidade de informações a serem transmitidas seja menor e diminui o tempo de contextualização.

Esse tempo, embora possa parecer um overhead, frequentemente se paga de duas formas: maior compartilhamento de conhecimento e oxigenação da funcionalidade. Cansei de presenciar situações nas quais uma pessoa ingressou no par e, com uma visão ainda não viciada, conseguiu perceber formas melhores e bem mais rápidas de solucionar o problema.

O aprendizado em par é particularmente rico porque ocorre o que é chamado de aprendizado situado. Há um problema para ser resolvido, há uma contribuição clara para o projeto caso ele seja resolvido, existe um contexto bem definido no qual aquele problema se encontra e existe uma pessoa ao seu lado que muitas vezes já conhece a solução. Quando este é o caso, o seu aprendizado é muito rico porque, primeiro, há um grande interesse seu em saber a solução. Nós sempre aprendemos melhor e com mais afinco quando temos um problema real para resolver. Especialmente quando sabemos que a resolução dele irá contribuir de alguma forma para outras pessoas. Nós gostamos de contribuir com as pessoas a nossa volta. Então, na programação em par, existe uma primeira componente fundamental que é a necessidade. E uma segunda que é o desejo de contribuir. Além disso, temos ao nosso lado uma pessoa que sabe resolver o problema e, o que é melhor, ela pode dialogar conosco e explicar. O diálogo é a forma mais rica de comunicação e ele permite que as pessoas recebam feedback facilmente. Desta forma, enquanto seu colega lhe explica algo, você pode fazer gestos ou ter expressões faciais que demonstrem que não está captando a mensagem. Seu colega instintivamente pode captar esse feedback e explicar melhor a solucão. O problema em questão pode ser técnico ou de negócio. Às vezes o seu colega entende melhor o negócio associado àquela parte do código por já ter trabalhado com ele em outro projeto. Eventualmente sabe melhor um determinado aspecto técnico porque teve aulas daquele assunto em um curso que fez e você não. Às vezes é o contrário e você é quem ensina. Na verdade, durante a programação em par, as pessoas naturalmente se revezam no papel de "professor" e "aluno".

Mesmo quando ambos não sabem resolver o problema, é mais rápido pesquisar sobre ele quando se está em par. Ambos podem, por exemplo, compartilhar idéias sobre termos a serem buscados no Google, podem lembrar de livros que têm a disposição, que possa ter a solução, podem lembrar de diferentes pessoas que talvez saibam a solução e possam ser procuradas, entre outras coisas.

A maior disseminação do conhecimento rapidamente eleva as habilidades técnicas dos membros da equipe. Isso tem efeitos extraordinários no médio e longo prazos, porque quanto mais habilidoso um desenvolvedor é, melhores se tornam as suas soluções. Elas ficam mais claras, mais limpas, mais fáceis de compreender e se acerta mais vezes. Além disso, normalmente se consegue gerar tais soluções com maior rapidez. O efeito cumulativo de inúmeras soluções melhores e mais rápidas ao longo do projeto representa um enorme ganho de produtividade. Mas, não é tudo.

Também há a disseminação de conhecimento sobre o negócio, que leva mais pessoas a saberem solucionar questões em qualquer parte do projeto, o que naturalmente aumenta a robustez da equipe. Ou seja, se alguém faltar por qualquer razão, se um desenvolvedor entrar de férias ou se uma pessoa decidir mudar de emprego, isso não impede a equipe de seguir adiante. Naturalmente há uma perda na força de trabalho, mas não há uma situação em que se perca uma pessoa sem a qual o projeto não possa sobreviver. O projeto consegue sobreviver bem a mudanças de pessoal porque muita gente sabe sobre muita coisa. É quase impossível apenas uma pessoa saber sobre um assunto do projeto a tal ponto de comprometê-lo caso não apareça mais.

Isso obviamente é bom para o projeto, mas também é excelente para os desenvolvedores, que podem tirar férias, visitar médicos ou faltar por qualquer razão que se faça necessária, com a tranquilidade de saber que a equipe não terá que importuná-lo. A equipe consegue seguir adiante com ou sem ele. Em muitas empresas, é comum os desenvolvedores terem dificuldades para tirar férias, por exemplo, tamanha é a dependência de um projeto sobre ele. E isso naturalmente é ruim para ele e péssimo para o projeto. Esse tipo de coisas não existe quando se utiliza a programação em par.

Confiança

A programação em par também é uma forma de fazer com que o desenvolvedor tenha mais confiança no código que produz. Afinal, o código foi produzido por ele e mais outra pessoa que o ajudou a revisá-lo. Quando sabemos que mais uma pessoa, ou talvez várias, já olharam para o código no qual trabalhamos e estão de acordo sobre o mesmo, temos maior confiança de que ele realmente irá funcionar. Isso significa que a programação em par reduz o estresse do desenvolvedor. Primeiro, porque várias pessoas conhecem e concordam com a solução, segundo porque nenhum erro cometido no projeto é exclusivo de uma única pessoa. Quando há um erro, não existe um culpado. A responsabilidade é da equipe como um todo, porque várias pessoas tiveram a chance de editar aquele código. Essa capacidade de deixar anônimo o responsável por uma falha, que em outras palavras, significa que toda a equipe é responsável por qualquer falha, é um dos aspectos sociais mais interessantes do XP, porque reduz a possibilidade de brigas e desentendimentos dentro da equipe, além de tornar todos mais compreensivos uns com os outros. Naturalmente o estresse reduz-se e as pessoas convivem melhor dentro do projeto.

Velocidade

O conjunto de características apresentadas acima faz com que a programação em par acelere o desenvolvimento significativamente, embora à primeira vista pareça o contrário. Em função da redução de bugs (e consequente redução no tempo de depuração), pressão do par, maior simplicidade das soluções, disseminação do conhecimento, maior confiança nas soluções, entre outros efeitos que a programação em par produz, uma atividade feita em par normalmente é encerrada mais rapidamente que outra feita por um programador solitário. Existem pesquisas indicando que se uma atividade é feita em 8 horas por um desenvolvedor sozinho, será feita em aproximadamente 4 horas por um par. O que significa que, mesmo no curto prazo, não existem diferenças significativas de
produtividade. Pois, em ambos os caso se estão consumindo basicamente os mesmos 8 homem-hora. A Laurie Williams, por exemplo, tem diversas estudos nessa linha. Eu os respeito, mas os considero pouco significativos em relação ao que ocorre realmente nos projetos, porque os problemas solucionados durante estes experimentos são muito simples. E os problemas que os projetos reais enfrentam são bem mais complexos. Entretanto, quanto mais difícil a situação, quanto mais complexo o problema, maior é o ganho da programação em par.

Pelo que observo nos projetos, pela complexidade daquilo que se busca resolver, não me parece que a programação em par consuma a mesma quantidade de recursos. Parece-me que consome bem menos, porque é exatamente diante dos problemas complexos que a oportunidade de discutir inúmeras soluções mais agrega valor. É exatamente nestes casos que conseguimos descobrir formas mais simples que realmente economizam muito trabalho que, um programador sozinho, eventualmente não imaginaria. Quanto mais complexo o problema, mais importante a capacidade de descobrir bugs rapidamente com o processo permanente de inspeção de código. Quanto mais difícil o problema, maior é a importância da pressão do par para evitar a dispersão. Quanto mais difícil, mais importante é a disseminação do conhecimento para que mais pessoas compreendam os problemas e se tornem cada vez mais habilidosas em resolvê-los.

Programação em par não consome mais recursos, não duplica o número de desenvolvedores necessários ao projeto, nem duplica o tempo de desenvolvimento. Na verdade, por mais paradoxal e contra-intuitivo que possa parecer, a programação em par poupa recursos. Lembre-se, as pessoas erram. Se todos fossem perfeitos, a programação em par possivelmente só serviria para duplicar recursos, elevar o tempo e encarecer o projeto. Mas, a questão fundamental é perceber que as pessoas erram e erram com mais frequência do que se imagina. A programação em par ajuda a reduzir a incidência de problemas e torna os projetos mais produtivos.

Problemas

Programar em par exige que as pessoas envolvidas sejam receptivas, compreensivas umas com as outras, engajadas e, sobretudo, humildes. É necessário aceitar que somos falíveis para que possamos programar em par. Weinberg criou o termo egoless programming, ou seja, programação sem ego. É essencial que o desenvolvedor não veja o código como uma extensão de si próprio. Ele não pode achar que um erro no código significa uma falha sua como pessoa. O código é apenas uma obra que tem vida própria e não representa o caráter e a personalidade de quem o criou. Pois, se o desenvolvedor imaginar que o código representa a si próprio, dificilmente irá buscar problemas e falhas no código. Afinal, ninguém gosta de saber que tem falhas. O código precisa ser visto como algo que não representa a personalidade de seu criador. Isso é mais fácil de se obter quando se programa em par, pois neste caso, o código é a contribuição de várias pessoas e não de uma única.

Pode parecer que desenvolvedores, frequentemente introspectivos e muitas vezes pouco sociais, tenham dificuldades significativas para lidar com a programação em par. Isso realmente acontece com alguns, porém poucos. Aqueles que trabalham com programação em par observam que naturalmente há um pequeno desconforto inicial em muitos casos, mas em quase todos as pessoas se adaptam rapidamente e aprendem a valorizar bastante a programação em par à medida que percebem o benefício dela. Na minha experiência particular tenho notado isso consistentemente, tanto no mercado, quanto no nível acadêmico.

No mercado, tive a oportunidade de trabalhar com algumas dezenas de desenvolvedores com programação em par, em diversos projetos XP e, em todos os casos, os desenvolvedores se adaptaram bem a essa técnica e nenhuma das equipes pensa em voltar atrás. Todas mantém a prática de forma consistente, algumas há quase dois anos. Na UFRJ, onde ministrei curso de XP para a graduação diversas vezes, meu alunos (que de um modo geral são dos últimos períodos) não trabalhavam antes com a programação em par e sempre acabaram se adaptando bem a ela com uma ou outra exceção. As exceções existem, mas são apenas exceções.

Adoção

Apesar de tudo o que foi dito acima, se você acredita que a programação em par não funcionaria no seu caso ou no caso da sua empresa, provavelmente você está certo e não há muito mais o que eu possa fazer aqui. Em todo o caso, antes de jogar a idéia fora, a minha sugestão é que você a experimente por alguns dias. Não durante uma ou duas horas apenas. Tente utilizá-la, por exemplo, durante uma semana, apenas para fazer um pequeno experimento. Imagino o quanto o seu projeto deva ser importante e como você tem pouco tempo, mas experimentar durante alguns dias não fará um mal tão grande assim. No pior dos casos, você realmente terá perdido algum tempo. Mas, se tudo der certo, talvez você descubra uma tremenda oportunidade de melhorar seu projeto e ganhar muito tempo adiante. Tente experimentar, de mente aberta, apenas por poucos dias. Afinal, é sempre fácil dizer que algo não funciona sem experimentar, mas normalmente é muito mais recompensador e instrutivo se dar a chance de experimentar. Porque quando funciona, você ganha alguma coisa nova, mas mesmo se não funcionar, no mínimo você passa a poder dizer que não funciona e que você sabe disso, por ter experimentado. Ninguém vai poder dizer que você não tem autoridade para falar do assunto.

Programação em par é uma técnica que tem várias justificativas, porém só se percebe o seu real valor utilizando. Muitas coisas que acontecem naturalmente durante o seu uso, só são realmente percebidas enquanto se utiliza. A teoria, as justificativas, as pesquisas, os resultados estatísticos, entre outros são interessantes e têm o seu papel, mas o que realmente faz a diferença é experimentar e sentir os seus efeitos. Isso vale mais do que qualquer palavra que você tenha lido até aqui, mais do que qualquer pesquisa ou qualquer coisa que falem com você a esse respeito. E, a propósito, se for possível, experimente não apenas com outro desenvolvedor, mas com vários. Assim, você terá a exata noção do que a programação em par pode fazer por você e um gostinho de uma das partes do XP.

Stand up meeting

2005-10-19T17:12:00.000-02:00

As informações que podem ser compartilhadas em um stand up meeting também poderiam ser transmitidas através de ferramentas. O que ocorre no XP, é que há uma preferência por canais de comunicação mais ricos, o que não significa que os outros canais sejam errados ou não funcionem. Quem trabalha com XP apenas acredita que pode avançar melhor e mais rapidamente dando preferência aos diálogos. Aliás, essa é uma palavra chave na compreensão do stand up meeting.

Trata-se de um diálogo entre todos os membros da equipe, se possível envolvendo também a presença do cliente. Em qualquer diálogo, existem pelo menos duas coisas que são compartilhadas de maneira bastante rica: informações e emoções.

Informações

Em projetos XP, cada membro da equipe tem acesso a toda e qualquer parte do código e, acima de tudo, tem o direito de alterar qualquer parte do sistema, a qualquer momento, sem ter que pedir permissão a ninguém. Essa é uma prática conhecida como Código Coletivo. A parte boa dessa prática é que o desenvolvedor consegue avançar muito rapidamente, pois nunca fica dependendo de outra pessoa, ou da autorização de alguém, para editar uma parte do código. Por outro lado, isso exige muita troca de informações, visto que tudo o que está acontecendo, em qualquer parte do sistema, interessa a todos os membros da equipe.

O diálogo diário permite que cada desenvolvedor descreva brevemente o que fez no dia anterior, eventuais problemas que detectou, soluções interessantes que foram criadas etc. Não é necessário entrar em detalhes. A idéia é que as pessoas saibam o que está acontecendo e quem fez o que. Se um desenvolvedor se interessar bastante por um assunto a respeito do qual outra pessoa trabalhou no dia anterior, ele pode, após o stand up meeting, se reunir com essa pessoa e discutir a solução com maior nível de detalhe. Pode até resolver fazer par com aquela pessoa durante o dia de trabalho que se está iniciando.

À primeira vista, o stand up meeting parece ser demorado. Afinal, se cada desenvolvedor tiver que explicar tudo o que fez no dia anterior, certamente isso pode consumir muito tempo. Entretanto, note que a idéia é fazê-lo diariamente e há várias razões importantes para ser assim. A primeira é que um dia de trabalho é um período relativamente curto. Descrever o que aconteceu em um dia é diferente de descrever os acontecimentos de uma semana, um mês ou um ano. Um dia é muito pouco tempo e normalmente não se produz uma quantidade enorme de coisas interessantes em um único dia. Sendo assim, existe a tendência de que cada desenvolvedor tenha pouco o que dizer se o stand up meeting realmente for conduzido com frequência diária. Apesar de pouco, o que ele tiver a dizer interessa a todos, porque o código é coletivo. De tempos em tempos, haverá alguma coisa realmente muito significativa que tenha sido feita por um par no dia anterior. Nestes casos, o stand up meeting pode acabar tomando mais tempo, porém o valor deste tempo é mais alto devido à utilidade da informação que se está transmitindo.

O stand up meeting é uma prática regida pelo valor da comunicação. Entretanto, é importante notar como também incorpora bem o valor do feedback. A cada dia de trabalho, podemos acertar em diversos pontos do projeto, mas também podemos errar. Equipes XP não esperam ser perfeitas e sabem que erram com frequência. Entretanto, isso não é temido, pois trata-se de um aspecto básico do ser humano: errar. O que realmente tememos é descobrir que erramos tarde demais, porque normalmente o custo de corrigir um erro cresce bastante quanto mais tempo levamos para detectá-lo e corrigi-lo. O stand up meeting é uma oportunidade para que os membros da equipe detectem e discutam problemas que tenha surgido no dia anterior, de modo que se possa priorizar ou não a correção dos mesmos e, de modo que se possam compartilhar sugestões sobre como tratá-los. Quando os problemas são apresentados a todos os desenvolvedores, é comum que surjam várias sugestões e, dessa variedade, surge frequentemente uma forma rápida e simples de solucionar a questão.

Se alguma coisa muito grave é detectada no stand up meeting, o gerente do projeto e o próprio cliente ficam sabendo com bastante rapidez. Pois qualquer problema terá sido detectado há no máximo um dia de trabalho. Assim, o gerente, o cliente e os desenvolvedores podem criar soluções enquanto esse problema ainda não deu origem a outros.

Essa reunião matinal também é uma demonstração da aplicação do valor da simplicidade. Existem muitas formas de se transmitir informações, mas convenhamos, quando as pessoas estão próximas umas das outras, nada é mais simples do que conversar. Usar ferramentas é um caminho, mas isso normalmente envolve aprender a usá-las e a conviver com seus problemas. Além disso, não é necessário passar muito tempo ligado a computadores para saber que eles falham, os sistemas operacionais falham, travam, um dia funcionam e o no outro não e assim perde-se tempo, quando existem soluções mais simples e menos propensas a erros.

O stand up meeting também é um mecanismo para expressar e treinar a coragem dos membros da equipe. Em muitas empresas, os desenvolvedores escondem problemas potenciais com medo de sofrerem uma punição do chefe, do cliente ou de qualquer pessoa com poder na organização. De fato, muitas organizações são regidas pela cultura do medo. O stand up meeting é um espaço aberto onde as pessoas são incentivadas a falar tudo o que está acontecendo e são valorizadas por fazer isso. Trata-se de um aspecto importante porque com a prática, os membros da equipe perdem o medo de revelar os problemas à medida em que percebem que são valorizados por fazer isso. Além disso, os desenvolvedores passam a se expressar mais e com frequência, o que normalmente é ótimo para treinar a habilidade de comunicação. A mesma de que ele irá necessitar, por exemplo, para se comunicar bem com o cliente. Da mesma forma que é necessário coragem para dizer o que realmente está acontecendo, o stand up meeting acaba servindo como uma forma de treinar e desenvolver essa coragem diariamente.

Finalmente, equipes XP costumam utilizar Radiadores de Informações como o Quadro de Acompanhamento Diário. Trata-se de uma tabela, desenhada em um quadro branco, contendo informações sobre todas as histórias da iteração. Nela, colocam-se as estimativas de cada história, quanto tempo foi gasto em cada uma por dia da iteração, que tarefas extras foram executadas etc. É um quadro importante porque gera muita visibilidade para todos os membros da equipe, incluindo o cliente. Com esse quadro, não há necessidade de perguntar nada para o gerente para saber o estado do projeto em um iteração. Basta
olhar para a parede. As informações estão lá. Projetos XP atualizam esse quadro diariamente, sempre nos stand up meetings. Assim, nenhum desenvolvedor precisa preencher uma folhinha dizendo quantas horas trabalhou por dia, por exemplo. Ao invés disso, ele faz algumas marcações simples em um quadro, uma vez por dia, durante o stand up meeting. Todos os desenvolvedores fazem isso durante essa reunião e leva apenas alguns segundos para cada pessoas marcar a sua informação. Quando todos o fazem em conjunto, essa prática tende a se manter de forma mais consistente do que quando realizamos uma atividade dessas sozinhos. Além disso, é um momento de socilização do qual todos participam.

Emoções

É possível transmitir informações através de ferramentas. Porém, emoções também informam e estas são muito difíceis de serem compartilhadas através de ferramentas. Durante um stand up meeting, os membros da equipe conseguem avaliar e sentir como está o clima da equipe. Olhando para cada pessoa, é possível observar se estão satisfeitas com o trabalho que está em andamento, dá para ver se estão cansadas ou energizadas, se estão entediadas ou empolgadas, se estão de acordo com os rumos do projeto etc. Muitas informações importantes jamais são verbalizadas, mas frequentemente basta você olhar para a expressão facial de uma pessoa para saber que ela discorda plenamente de alguma coisa ou para notar que ela está cansada, ou aborrecida. Nestes momentos, um bom coach (bem como qualquer membro da equipe) deve atuar pedindo à pessoa que expresse seus sentimentos. Muitas vezes vivenciei grandes viradas em projetos, viradas extremamente positivas, porque alguém notou um problema na expressão de um dos desenvolvedores.

Há pouco tempo, por exemplo, tínhamos iniciado um projeto em um dos nossos clientes e, em uma reunião dessas, um membro da equipe demonstrava pela expressão facial que não estava muito satisfeito com o rumo das coisas. Ele não disse isso, apenas pareceu insatisfeito pela expressão que fazia. Então perguntei o que o estava incomodando. Ele me explicou que tinha a sensação de que aquele projeto não deveria produzir um software para web, como estava sendo feito. Na opinião dele, pelas características do projeto, faria mais sentido que fosse uma aplicação desktop. Discutimos isso com todos e ficou bastante claro que ele estava coberto de razão. Então, decidimos reverter o que estávamos fazendo e refazer algumas coisas para direcionar o software para desktop. Hoje, passados alguns meses, percebe-se que tomamos a decisão certo. Felizmente descobrimos isso bastante cedo devido à oportunidade de fazer um stand up meeting e interpretar as emoções que estavam no ar e não apenas as palavras verbalizadas. Se tivéssemos continuado no caminho original, talvez tivéssemos chegado à mesma conclusão em algum outro momento. Mas, certamente demoraria mais e o custo de reverter o projeto para desktop acabaria sendo maior. Portanto, emoções também representam um feedback importante que precisa ser levado em conta a todo o momento.

Para finalizar, precisamos compreender que o stand up meeting é uma forma de priorizar o que será feito em cada dia de trabalho. Nós priorizamos para assegurar que estamos fazendo o que é mais importante a cada momento do projeto e isso é feito porque o maior objetivo do XP é entregar um fluxo constante de valor para o cliente. Isso só é possível quando planejamos cuidadosamente o que será feito, isto é, quando escolhemos a cada dia fazer o que mais tenha potencial de gerar valor naquele momento. Sem essa priorização diária, é fácil um desenvolvedor acabar gastando tempo com algo que pode até ser útil, mas não era a coisa mais importante naquele ponto do projeto.

Em princípio, é fácil decidir o que deve ser feito a cada dia de trabalho. Basta olhar para o mural, onde a equipe coloca os cartões contendo as histórias da iteração, e verificar que histórias ainda precisam ser finalizadas. Entretanto, às vezes surgem problemas inesperados no dia anterior. Nesses casos, a equipe usa o stand up meeting para decidir se esses problemas devem ser tratados já no dia que está sendo iniciado, se devem ser deixados para uma iteração futura etc.

A priorização em equipe só pode ser feita de forma adequada quando temos a noção do todo, isto é, quando sabemos o que está acontecendo em cada parte do projeto, com cada pessoa da equipe e não apenas conosco. Pois, algo que eu possa considerar muito sério e prioritário no momento, pode ser absolutamente irrelevante quando somos informados de um problema bem mais significativo que está acontecendo em outra parte do projeto. Nos dias em que isso acontece, talvez faça mais sentido deixar o meu problema de lado e ir ajudar outra pessoa a resolver o problema mais sério que está afetando toda a equipe. Sem stand up meeting diário, é mais difícl notar e atuar rapidamente sobre situações como essas.

Cliente Presente

2005-10-19T17:09:00.000-02:00

Clientes normalmente não podem passar 100% do tempo com a equipe de desenvolvimento, bem como não têm condições (frequentemente) de se dedicar exclusivamente a um projeto em particular. Entretanto, não é essa a proposta da prática. Na verdade, a prática chama-se Cliente Presente e o objetivo dela não é fazer com que o cliente passe 100% do tempo com a equipe, mas sim que ele tenha disponibilidade (a maior possível) para ajudar a equipe sempre que ela tiver dúvidas. A ênfase da prática é fazer com que o cliente seja acessível e compreenda a importância disso para o bom andamento do projeto.

Equipes XP se baseiam no princípio de que o resultado final de um projeto depende não apenas dos desenvolvedores, mas também do cliente e de quaisquer outras pessoas que possam ter algum tipo de contribuição para o projeto. Isso é um ponto de vista compartilhado por muitas pessoas, porém vem sendo ignorado fortemente em diversos casos, especialmente nas grandes corporações, onde é comum se criar uma distância significativa entre o cliente e a equipe de desenvolvimento. Ontem mesmo, após fazermos o XP Game em um evento aqui no Rio, estávamos conversando sobre isso e o Luiz Esmiralha comentou que em uma grande empresa na qua trabalha ou trabalhava (Luiz, me corrija se estiver errado) os desenvolvedores eram proibidos de conversar diretamente com os clientes finais. Não podiam sequer trocar emails. Esse é o outro extremo e não é muito agradável.

Costumo utilizar uma metáfora para ilustrar a importância dessa prática. Suponha que eu esteja acima do meu peso e decida procurar a ajuda de uma nutricionista. Depois de conversar comigo e tomar as minhas medidas, ela me passa uma dieta, recomenda que eu comece a fazer exercícios e retorne em duas semanas. Na nova consulta, ela me coloca na balança e nota que eu não perdi nem 100g. Eu fico completamente aborrecido e começo a achar que aquilo é uma grande perda de tempo. Começo a cobrar explicações quando ela me pergunta:

- Você seguiu a dieta?
- Não. - respondo com a cara mais lavada.
- Hummm... E você fez exercícios?
- Não. - respondo um pouco menos agitado e começando a olhar para o chão.
- Então você consegue identificar alguma causa para não ter perdido peso?
- Bem... Acho estou começando a ter uma idéia... - respondo tentando enfiar a cara no chão a qualquer custo. :-)

Perder peso com a ajuda de uma nutricionista funciona e isso eu sei de carterinha porque perdi 22kg assim. Mas, só funciona quando ambos fazem a sua parte. Por melhor que seja a nutricionista, o paciente não perde nada se não fizer a sua parte, se não tiver disciplina, se não seguir as recomendações. Por outro lado, mesmo o paciente mais disciplinado não perderá peso e poderá até ganhar se for orientado por uma nutricionista incompetente. As duas partes precisam funcionar e bem.

Em desenvolvimento de software acontece o mesmo. O cliente tem um papel essencial que é informar o que precisa ser feito e fazer isso de forma clara. Ainda mais importante, precisa explicar qualquer mudança nas circustâncias do projeto, as quais gerem mudanças naquilo que foi solicitado para a equipe. A qual, por melhor que seja, não tem como produzir um software que resolva o problema do cliente se este não informar adequadamente aquilo que precisa ser feito. Mas, infelizmente esse não é um trabalho que possa ser feito apenas no início do projeto ou com pouca frequência. Trata-se de um trabalho contínuo, que precisa ser realizado ao longo de todo o projeto porque as pessoas evoluem, percebem coisas diferentes, têm dúvidas novas e é importante que o cliente esteja acessível para ajudar. O outro lado da moeda também ocorre. Por melhor e mais acessível que seja o cliente, se estiver trabalhando com uma equipe pouco capacitada, o resultado será ruim. Como mencionei antes, ambas as partes precisam trabalhar bem em conjunto.

A idéia da proximidade física entre equipe e cliente de desenvolvimento tem a ver com o valor da comunicação no XP. Existem muitas formas de se comunicar idéias, tais como diálogo, telefone, email, instant message, entre outras. Entretanto, alguns meios de comunicação são mais ricos que outros. Normalmente, o diálogo é a forma mais eficaz de comunicar, porque os interlocutores têm acesso a vários elementos da comunicação, tais como as palavras verbalizadas, gestos, expressões faciais, postura, tom de voz, entre outros. No conjunto, esses elementos colaboram para que se compreenda melhor as mensagens transmitidas. Já uma comunicação por telefone, por exemplo, é menos rica porque perdem-se todas as componentes visuais. O que há de ruim nisso? Sabe quando você fala alguma coisa e a outra pessoa faz uma expressão de quem não entendeu? Pois é, trata-se de um feedback importante, porque provavelmente fará você explicar melhor o assunto. Por telefone não se consegue observar isso e talvez a pessoa decida não verbalizar sua dúvida. Assim começam as interpretações equivocadas.

A comunicação entre cliente e desenvolvedores pode ser dar pessoalmente ou por email e outras ferramentas computacionais, por exemplo. Estes últimos embora também possam funcionar, são menos eficientes que o diálogo. Portanto o XP procura dar preferência ao diálogo, não porque outros meios de comunicação necessariamente sejam falhos, mas porque acredita-se que dialogar será mais eficiente, gastará menos tempo e irá gerar maior compreensão. E isso é outro fator que nos leva a buscar a proximidade e a participação frequente do cliente.

Novo livro em português: JUnit em Ação

2005-09-28T15:09:00.000-03:00

O livro "JUnit em Ação", de Vincent Massol em colaboração com Ted Husted, acaba de ser publicado em português pela Editora Ciência Moderna. Apesar das péssimas traduções já cometidas pela editora, nesse caso parece que não fizeram feio.
O livro está bem claro e é muito completo, cobrindo não só a API do JUnit, como também situações e exemplos reais de teste usando Stubs e Mocks e cenários de teste em aplicações Web e usando EJB. Imperdível.

Reunião de Setembro: Lean Software Development

2005-09-16T13:45:00.000-03:00

Quarta-feira, dia 21/09/2005, ocorrerá a reunião mensal de setembro do XPRio. Desta vez o tema será "Lean Software Development".

Seguem informações...

Sinopse:
No final dos anos 40 um executivo da Toyota adotou a estratégia de identificar e eliminar os desperdícios do processo de produção. Após décadas de aplicação desta estratégia, nos anos 80 a indústria automobilística japonesa já se destacava no mundo todo. Impressionados pelo excelente desempenho de estratégias como o Just-in-Time, os executivos ocidentais começaram a voltar os olhos para este novo paradigma de condução do processo produtivo.
Nos anos 90, atravé do livro "The Machine that Changed the World: The Story of Lean Production", foi criado o termo "Lean Thinking" para sintetizar os conceitos que levaram a indústria automobilística japonesa do processo de produção em massa (do Fordismo) para o processo de Lean Development.
Em 2003, com o lançamento do livro "Lean Software Development, an Agile Toolkit", Mary Poppendieck (http://www.poppendieck.com/), a partir de sua experiência com a adoção do Lean Development na indústria americana, aplicou o Lean Thinking ao desenvolvimento de sistemas, criando um embasamento teórico consistente aos processos ágeis e ainda sugerindo práticas que auxiliam na tradução dos conceitos Lean em práticas ágeis.

Data: quarta-feira, 21 de setembro de 2005.
Horário: das 19 às 21 horas.
Local: Auditório do Centro de Informática e Telecomunicações do SENAC Rio.
Rua Santa Luzia, 735, 7º andar (Centro, Rio de Janeiro).
A entrada é gratuita e não é necessário fazer inscrição, nem confirmar a presença. Qualquer dúvida no dia, procurem a recepção no 5º andar para esclarecimentos.

Extreme Programming nas ferramentas de desenvolvimento

2005-09-09T18:52:00.000-03:00

Após o Visual Studio anunciar suporte aos processos ágeis, agora a Borland trata do assunto no JBuilder 2006.
Destacando um trecho do artigo:
"JBuilder 2006 brings agile capabilities to larger and more distributed development teams by enabling them to use pair programming techniques through real-time, peer-to-peer collaboration. Using JBuilder 2006, two or more programmers can work together, collaborate on the same design, algorithm, code or test, address difficult challenges and generate new ideas."

AgileCollab: processo ágil para desenvolvimento "offshore"

2005-08-29T10:39:00.000-03:00

Tivemos no fórum uma questão sobre a viabilidade do tema "Aplicando XP em equipes distribuídas geograficamente."... então me deparei com esta notícia da criação de um processo ágil para esta finalidade.
Uma das partes polêmicas seriam como manter o valor da comunicação... a qual eles tratam como: "Communication: customer representative, daily teleconference meeting, online collaboration with web-based tools, documenting discussion threads".

Vídeo de palestra sobre XP

2005-08-16T15:17:00.000-03:00

Este vídeo foi indicado pelo Madson, no XPRecife. Não sei muito sobre o conteúdo, pois não assisti ao vídeo inteiro... mas ao menos é divertido... o palestrante (Facunte) é uma figura!

Reunião de Agosto: Modelagem OO com cartões CRC

2005-08-08T14:35:00.000-03:00

Quarta-feira, 10/08/2005, ocorrerá a reunião mensal de agosto do XPRio.
Desta vez o tema será "Modelagem OO com cartões CRC".

Nosso objetivo será termos uma visão geral de como utilizar os CRC (Class, Responsibility, and Collaboration) Cards na modelagem conceitual de um sistema OO.
Isto será feita através de uma aplicação prática do emprego dos cartões CRC na modelagem de algumas User Stories.

Seguem informações...

Sinopse:
CRC Cards é uma técnica criada por Kent Beck e Ward Cunningham inicialmente para apoiar o ensido da modelagem orientada à objetos (http://c2.com/doc/oopsla89/paper.html). No entanto se mostrou uma técnica bastante útil para, de uma forma dinâmica e interativa, identificar as abstrações chave do sistema, realizar a modelagem OO conceitual e mesmo a modelagem de design OO.
Podendo esta técnica ser empregada por qualquer processo de desenvolvimento OO, a mesma vem sendo adotada principalmente pelos processos ágeis, pela grande convergência existente entre suas características (p. ex., interatividade).
Nesta reunião do XPRio, após uma breve introdução ao tema, estaremos simulando a utilização dos CRC cards na modelagem conceitual de um sistema OO.

Data: quarta-feira, 10 de agosto de 2005.
Horário: das 19 às 21 horas.
Local: Auditório do Centro de Informática e Telecomunicações do SENAC Rio.
Rua Santa Luzia, 735, 7º andar (Centro, Rio de Janeiro).
A entrada é gratuita e não é necessário fazer inscrição, nem confirmar a presença. Qualquer dúvida no dia, procurem a recepção no 5º andar para esclarecimentos.

Pretending to Be Agile

2005-07-15T09:38:00.000-03:00

"Agile is in. Many processes and projects are jumping on the bandwagon and claiming to be Agile, so what are the telltale signs that what you have is a traditional process just pretending to be Agile?"
Este artigo foi publicadp pelo Pete McBreen... aquele do "Software Craftsmanship" e "Questioning Extreme Programming".

Reunião de Julho: XP, uma visão geral

2005-07-11T15:28:00.000-03:00

Na próxima quarta-feira, 13/07/2005, ocorrerá a reunião mensal do XP Rio.
Desta vez o tema será: eXtreme Programming, uma visão geral.

Nosso objetivo será termos uma visão geral do eXtreme Programming em sua versão inicial, com seus 4 valores e 12 práticas originais.
Ainda, aproveitaremos para discutir a evolução proposta para o eXtreme Programming por seu criador, Kent Beck, através da segunda versão do "XP Explained".

Seguem informações...

Horário: das 19 às 21 horas.
Local: Auditório do Centro de Informática e Telecomunicações do SENAC Rio.
Rua Santa Luzia, 735, 7º andar (Centro, Rio de Janeiro).
A entrada é gratuita e não é necessário fazer inscrição, nem confirmar a presença. Qualquer dúvida no dia, procurem a recepção no 5º andar para esclarecimentos.

Kent Beck sacudindo Johannesburg

2005-07-07T18:27:00.000-03:00

Shared values ‘key to software development'
Extreme programmer hits Joburg

Kent Beck divulgará XP na África

2005-06-20T15:17:00.000-03:00

"Kent Beck, one of the founders of Extreme Programming, will be in South Africa later this month. (...)"

Artigos...

2005-06-14T12:13:00.000-03:00

Getting Started with eXtreme Programming: Toe Dipping, Racing Dives, and Cannonballs (Kent Beck & Cynthia Andres)

TDD by Intention?: Can Test-Driven Development and Programming By Intention play together? Or do they annihilate each other, like protons and antiprotons, or XPers and CMMers? (Ron Jeffries)

Seminário Web com Kent Beck

2005-06-06T13:58:00.000-03:00

"On Tuesday June 7th, Kent Beck will discuss his latest insights on eXtreme Programming and Developer Accountability in a webinar organized by Agitar Software."

Reunião de Junho: XP e Software Livre

2005-06-02T12:08:00.000-03:00

Na próxima quarta-feira, 08/06/2005, será realizada a reunião de junho do XPRio.

Nesta, Luiz Esmiralha irá apresentar suas impressões sobre o 6^o Fórum Internacional de Software Livre, com um foco especial na ligação entre XP e o movimento de Software Livre. Serão discutidos temas como modelos de desenvolvimento, colaboração remota, gestão de grandes equipes e propriedade coletiva do código.

Data/Horário: 08 de junho de 2005, das 19 às 21 horas.
Local: Auditório do Centro de Informática e Telecomunicações do SENAC Rio - R. Santa Luzia, 735, 7º andar (Cinelândia, Rio de Janeiro)
A entrada é gratuita e não é necessário fazer inscrição, nem confirmar a presença.

Novo coordenador do grupo

2005-06-02T12:05:00.000-03:00

Comunico que, como uma consequência natural da participação ativa e constante colaboração nas reuniões do grupo, nosso amigo Luiz Esmiralha agora também estará ajudando na coordenação do grupo.

Reunião de Maio: Fatos e Falácias sobre a Engenharia de Software

2005-05-06T18:50:00.000-03:00

Na próxima quarta-feira, 11/05/2005, será realizada a reunião de maio do XPRio.
O tema será o livro "Facts and Fallacies of Software Engineering", escrito por Bob Glass. O autor é presidente da Computing Trends, editora da revista "Software Practicioner" e um reconhecido autor na área de Desenvolvimento de Software.
O livro, cujo título original "Fifty-Five Frequently Forgotten Fundamental Facts (and a Few Fallacies) about Software Engineering" foi encurtado por razões comerciais, trata de fatos e falácias sobre desenvolvimento de software, focando principalmente naquilo que supostamente deveríamos saber mas que frequentemente esquecemos ou ignoramos ao enfrentar desafios em nossa profissão.
Na reunião, serão discutidos alguns fatos e falácias selecionados dentre os mais polêmicos e interessantes.

Data/Horário: 11 de maio de 2005, das 19 às 21 horas.
Local: SENAC - R. Santa Luzia, 735, Auditório do 7º andar (Cinelândia, Rio de Janeiro)
A entrada é gratuita e não é necessário fazer inscrição, nem confirmar a presença.

Entrevista com Scott Ambler

2005-05-06T18:39:00.000-03:00

Neste vídeo Scott Ambler fala sobre desenvolvimento ágil e Agile Modeling, incluindo uma detonada no MDA (OMG).

Kent Beck, Cynthia Andres & Tom DeMarco em entrevista

2005-05-06T18:36:00.000-03:00

"The discussion touches on the principles behind extreme programming, how the roles of programmers and managers are changing, and XP's potential advantages for software development teams."
No final há um link para um gravação MP3 de trechos do "Extreme Programming Explained: Embrace Change (2nd Edition)"

Penrillian & eXtreme Programming

2005-05-05T13:41:00.000-03:00

Nesta entrevista com o diretor da Penrillian, empresa que desenvolve software para o Symbian OS, é revelada a aderência da equipe ao XP, através de práticas como o TDD (SymbianOSUnit). Inclusive tem uma foto dos desenvolvedores trabalhando em par!

Security guru wants access to bug databases

2005-04-24T12:33:00.000-03:00

Este artigo aborda a qualidade do software produzido em projetos XP...
"Cambridge academic Ross Anderson argues that empirical analysis of software bug records will prove whether open source code is more secure than closed source, and show the true value of techniques like peer review and extreme programming".

Novo artigo da Poppendieck

2005-04-21T18:22:00.000-03:00

Artigo que trata de como atingir o objetivo de entregas rápidas e de qualidade, abordando alguns dos princípios do Lean Software Development, como: Eliminate Waste(value stream maps) e Build integrity in.

TDD na Reunião de Abril

2005-04-12T10:10:00.000-03:00

Nesta quarta-feira, 13/04/2005, ocorrerá a reunião de abril do XPRio, quando teremos uma demonstração prática de Desenvolvimento Orientado a Testes (TDD - Test Driven Development).
O Vinícius Teles e o Rafael Walter abrirão um projeto no Eclipse com o intuito de programar um pequeno conjunto de funcionalidades no melhor estilo TDD.
Assim, os participantes terão a oportunidade de observar:

* O TDD utilizando o jUnit
* A utilização de Mock Objects
* O TDD para web utilizando jWebUnit
* A simulação de Mock Objects em funcionalidades web

O desenvolvimento orientado a testes é um dos maiores desafios técnicos do XP.
É comum termos dificuldades quando começamos a automatizar os testes, mas é provável que as maiores dificuldades estejam na falta de exemplos práticos de como utilizar o TDD.
Sendo assim, acreditamos que esta apresentação será uma boa oportunidade para aqueles que desejam adotar o TDD em seu dia-a-dia e fazer isso da forma mais fácil e econômica possível.

Desta vez, não haverá Power Point. Será código do início ao fim, seguindo o modelo utilizado pelo Vinícius nos treinamentos da Improve It.
Assim, esperamos dar continuidade às iniciativas prévias do grupo no sentido de tornar as reuniões mensais mais práticas e participativas.

Embora seja uma reunião do XP Rio, o tema não se limita a XP, portanto é válido para qualquer desenvolvedor de software.
Caso tenham amigos interessados em TDD, convide-os também!

Apresentadores:
Rafael Fraga Walter - Ancar
Vinícius Manhães Teles - Improve It

Data: Quarta-feira, 13/04/2005
Horário: 19 às 21 horas
Local: Auditório do SENAC na R. Santa Luzia, 735, 7º andar (Centro, Rio de Janeiro)
A entrada é gratuita e não é necessário fazer inscrição, nem confirmar a presença.

Lista de Livros

2005-04-09T10:42:00.000-03:00

Colocamos uma lista de livros sobre XP e processos ágeis em geral aqui no Blog. Está na lateral direita categorizada por assuntos. A lista é longa e nos permite observar a grande quantidade de livros publicados sobre processos ágeis, especialmente nos EUA.

Entrevista com Kent Beck

2005-04-08T10:53:00.000-03:00

Nesta entrevista Kent Beck fala sobre o que o pensa do desenvolvimento open source, certificações dos profissionais de TI, seu envolvimento com a Agitar Software, entre outras coisas...

Novos links no Blog do XP Rio

2005-04-06T20:19:00.000-03:00

Para aqueles que estiverem buscando maiores informações sobre o XP e os métodos ágeis em geral, publicamos novos links na lateral do Blog do XP Rio.
Além de sites com inúmeros artigos, novos fóruns foram acrescentados, bem como links para as principais conferências sobre XP.

XP SC

2005-04-06T20:13:00.000-03:00

Foi criado recentemente o XP SC (Extreme Programming Santa Catarina).

Mais uma ferramenta para Processos Ágeis

2005-04-04T18:41:00.000-03:00

Target Process é uma ferramenta para gerenciamento de projetos ágeis que oferece gratuitamente um módulo para o Jogo do Planejamento.
Parece interessante uma vez que gera "burn down charts".
Ou seja, sem abandonarmos o "tradicional" controle via cartões e quadros, é possível alimentar o sistema com informações atuais e obter gráficos que nos permitem acompanhar a convergência do software.

Pesquisa constata fracasso dos projetos de TI

2005-03-31T19:28:00.000-03:00

Este artigo fala sobre pesquisa que afirma que 95% dos grupos de TI não atendem às expectativas dos clientes.

TDD aplicado a .NET

2005-03-31T19:21:00.000-03:00

Este artigo fala sobre TDD (Test-Driven Development) e aborda exemplos práticos com a ferramenta NUnit, para a aplataforma .NET.

Personnel issues cloud software development

2005-03-17T09:28:00.000-03:00

Este artigo cita a abordagem durante sessão na conferência SD West 2005, realizada na última segunda-feira, de como questões pessoais afetam equipes de desenvolviemnto.

M$ e eXtreme Programming

2005-03-10T11:47:00.000-03:00

Artigo que cita suporte ao XP que será dado pela Microsoft:
"(...) in addition to CMMI and Agile processes, Microsoft will support ISO (International Organization for Standardization) and Extreme programming processes."

Reunião Mensal: Extreme Programming Explained, 2nd Edition

2005-03-09T11:16:00.000-03:00

Hoje, 09/03/2005, ocorrerá a reunião mensal de março do XP Rio.

Desta vez, estaremos fazendo uma "mesa-redonda" para discutirmos a segunda edição do livro Extreme Programming Explained, lançado no início deste ano. Além disso, poderemos vir a conversar sobre Componentes e outros assuntos que possam surgir.
Essa segunda edição do livro contém diversas novidades e algumas revisões nos conceitos do XP. Vale à pena conhecer.

Local: Auditório do SENAC na R. Santa Luzia, 735, 7º andar (Centro, Rio de Janeiro)
Horário: 19:00h às 21:00h
A entrada é gratuita e não é necessário fazer inscrição, nem confirmar a presença.
Qualquer dúvida no dia, procurem a recepção no 5º andar para esclarecimentos.

MSF for Agile Software Development

2005-02-24T10:15:00.000-03:00

Está disponível versão beta do guia de desenvolvimento ágil que acompanhará o Visual Studio. Conforme descrito no site, MSF for Agile Software Development é um processo orientado a cenários que encorpora práticas desenvolvidas na Microsoft.

TDD e software embutido

2005-02-15T13:37:00.000-02:00

Este artigo de James Grenning considera as peculiaridades da aplicação do Test Driven Development (TDD) no desenvolvimento de software embutido.

Declaration of Interdependence

2005-02-03T14:13:00.000-02:00

Foi divulgado no fórum Agile Management (http://groups.yahoo.com/group/agilemanagement/) o surgimento de um novo movimento ligado aos processos ágeis. De forma semelhante a da reunião de criação do Manifesto pelo Desenvolvimento Ágil, agora diversos dos gurus do desenvolvimento de software se reuniram para tratar da gerência de projetos "ágil e adaptável".

Segue mensagem...

From: "David J Anderson"
Date: Thu Feb 3, 2005 3:21 am
Subject: Declaration of Interdependence

This past 3 days I've been hosting a group of authors and contributors
to the agile management community to discuss the formation of a new
organization to promote agile and adaptive techniques in the project
management field. We came together because we each felt that the
current traditional project management guidance is underserving the
market in many fields such as software development. Below is the
groups declaration which is a rallying cry to form a new organization
to promote a new paradigm for project management.

Until the new organization is formed (at the next meeting in April),
you won't be able to join. Until then the groups website (see below)
and Sanjiv Augustine's Agile Project Management Yahoo! group will
serve as the home for the organization. I would encourage you to sign
the declaration when it is available on the website.

Here is what Sanjiv wrote on his one group to officially announce the
declartion and the forthcoming agile-adaptive management organization
(name to be finalized soon)...

Sanjiv Augustine wrote...

Similar to the Agile Manifesto meeting of 2001, a group of managers
from different project and product domains (including me, Jim
Highsmith, Alistair Cockburn, David Anderson and Todd Little from
the Agile community) came together recently to discover our common
ground with respect to Agile and Adaptive Management. Six core
values emerged from our collaboration. Together, they form what we
have named, "The Declaration of Interdependence" for
Agile-Adaptive
Management:

- We increase return on investment by making continuous flow of
value our focus.

- We deliver reliable results by engaging customers in frequent
interactions and shared ownership.

- We manage uncertainty through iterations, anticipation and
adaptation.

- We unleash creativity and innovation by recognizing that
individuals are the ultimate source of value, and creating an
environment where they can make a difference.

- We boost performance through group accountability for results and
shared responsibility for team effectiveness.

- We improve effectiveness and reliability through situationally
specific strategies, processes and practices.

©2005 David Anderson, Sanjiv Augustine, Christopher Avery,
Alistair Cockburn, Mike Cohn, Doug DeCarlo, Donna Fitzgerald, Jim
Highsmith, Ole Jepsen, Lowell Lindstrom, Todd Little, Kent MacDonald,
Polyanna Pixton, Preston Smith and Robert Wysocki

There was a tremendous level of consensus and closure on the
Declaration. However, the name Agile-Adaptive has not been
finalized, though it is the name we have for this management
paradigm right now. An organization to support and help propagate
it will be formed shortly. To invite your ideas and enlist your
immediate participation, we are providing two venues:

1. This group will serve as an open forum for all ideas, insights
and discussion regarding Agile-Adaptive Management. All of you are
invited to join in, contribute and help steer. Going forward, the
co-authors of the Declaration are committing to be available on this
group to answer your questions and engage in direct discussion.

2. The website http://www.agileprojectmgt.com will serve as the
primary website for the forthcoming organization. Multiple services
are being planned to support the larger community of managers (i.e.,
you) in applying these values on your projects.

I look forward to your questions, comments and discussion!

Sanjiv Augustine

Director of Technology, CC Pace http://www.ccpace.com
Author, Managing Agile Projects, Prentice Hall 2005
http://www.agilepm.com
Moderator, Agile Project Management Discussion Group
http://groups.yahoo.com/group/agileprojectmanagement
Co-author, Declaration of Interdependence for Agile-Adaptive Management©

Webinar Series archive

2005-02-02T14:53:00.000-02:00

Esta página disponibiliza seminários WEB que foram realizados com gurus do mundo do desenvolvimento ágil.

Artigo sobre Pair Programming

2005-01-21T17:27:00.000-02:00

Pair Programming Observations by Jeff Langr.

O que é XP?

2005-01-18T19:07:00.000-02:00

Lendo um novo artigo do Ron Jeffries, Practice: That's What We Do , me deparei com um trecho bem interessante, no qual ele descreve como ele entende o que é XP. Entre outras coisas, ele diz: "(...) XP não é o tipo de coisa que se possa fazer ou deixar de fazer(...). Para mim, XP é uma série de noções (notions) que guiam minhas ações. (...)".
Segue abaixo todo trecho ao qual me refiro:

Just Do It
There has been a long period in XP where the discussion has been around what you have to do to "be XP". Early on, I thought, and others of us thought, that you had to do all the practices to be doing XP. For the past three or four years, though, I've been saying that there is no meaning to the phrase "doing XP". XP is not the kind of a thing that can be done or not done. XP is an understanding that one has, to some extent.

There's a commonality to the understanding that is XP: many of us think of ourselves as "doing XP", or being members of the "XP community". We can talk to each other, and often we can even communicate. And yet each individual's understanding of what XP "is" is different. I believe that is as it should be.

To me, XP is a set of notions that inform my actions. Those notions have been learned, primarily through doing, primarily through making mistakes and being corrected. As I do things, as I make mistakes, and get corrected by other objects in the universe, I learn how to understand situations and how to choose actions that are likely to give me the outcomes that I want. I believe that to a fairly large extent, I "have" XP; I've got it; I get it; I grok it.

Unfortunately, of course, to a fairly large extent, I still don't have it. That leads me to say and do things which are deplorably stupid. The good news is that these are usually opportunities to learn, because the universe has ways of letting me know when I screw up. (I call some of these ways "friends". Others of them just seem like things that happen.)

All this is just to say that when it comes down to functioning in the world, we learn by doing. Reading, listening, thinking ... these can give us ideas. But it's turning the idea into action that counts.

Primeiro Projeto Scrum

2005-01-15T16:35:00.000-02:00

Neste artigo, Jeff Sutherland conta os motivos e como foi aplicado, em 1993, o primeiro projeto Scrum. Para isso, aborda os problemas que a empresa enfrentava e as propostas de solução que formaram este processo ágil.

Integração Contínua

2005-01-15T09:52:00.000-02:00

Como sabemos, uma das práticas do eXtreme Programming é a Integração Contínua, na qual o código produzido é constantemente integrado e testado, oferecendo um feedback contínuo sobre a integridade do sistema após a união de todas as partes desenvolvidas até o momento. A página aqui indicada oferece diversos links para materiais sobre a Integração Contínua.

Lançado livro de XP para .NET

2005-01-14T10:35:00.000-02:00

eXtreme .NET: Introducing eXtreme Programming Techniques to .NET Developers

XP + C#

2005-01-12T19:09:00.000-02:00

Dois artigos sobre a aplicação de XP na plataforma Micro$oft:
Improve the Design and Flexibility of Your Project with Extreme Programming Techniques
Get Your Customers Involved in the Testing Process with Functional Tests in Excel

Visão crítica sobre a programação em par

2005-01-12T18:54:00.000-02:00

Novo artigo sobre Pair Programming, em Builder Au.

Produtividade do Trabalhador do Conhecimento

2005-01-11T11:57:00.000-02:00

> From: Marcos Eduardo Engelmann> To: xprio@yahoogroups.com>
> Sent: Friday, January 07, 2005 5:33 PM

> Com respeito, ao aumento de produtividade, tu falaste que às vezes as ações
> para aumentar a produtividade em trabalhadores de conhecimento, baseadas em
> cima de uma administração de "fábrica", produtos em série, acabam reduzindo
> a produtividade. Mencionou também o termo crescimento orgânico.
>
> Na tua opinião qual o tipo de ação poderia ser adotado para aumentar a
> produtividade em uma empresa de conhecimento? Como comprovar este aumento?
> Teríamos como traçar um paralelo, ações que deveriam ser aplicadas para
> trabalhadores manuais X ações que poderiam ser aplicadas em trabalhadores do
> conhecimento?

Sua pergunta é tão boa e tão importante que não consegui escrever pouco.

Ao invés de dar as minhas opiniões sobre isso, prefiro trazer a de outras pessoas bem mais capacitadas que eu e comentar as mesmas. Começando por Peter Drucker:

"O trabalho na produtividade do trabalhador do conhecimento mal começou. Em termos de trabalho real nela estamos, no ano 2000, mais ou menos onde estávamos em 1900, há um século, em termos da produtividade do trabalhador manual. Mas já sabemos infinitamente mais a respeito da produtividade do trabalhador do conhecimento do que o sabíamos da produtividade do trabalhador manual. Sabemos até muitas das respostas, mas também conhecemos os desafios para os quais ainda não conhecemos as respostas e nos quais precisamos trabalhar.
São seis os fatores que determinam a produtividade do trabalhador do conhecimento, a saber:

A produtividade do trabalhador do conhecimento requer que façamos a pergunta: “Qual é a tarefa?”
Ela exige que coloquemos a responsabilidade pela produtividade nos próprios trabalhadores do conhecimento. Eles precisam gerenciar a si mesmos e ter autonomia.
A inovação continuada tem de fazer parte do trabalho, da tarefa e da responsabilidade dos trabalhadores do conhecimento.
O trabalho do conhecimento requer aprendizado contínuo por parte do trabalhador, mas também ensino contínuo.
A produtividade do trabalhador do conhecimento não é – ao menos principalmente – uma questão de quantidade produzida. A qualidade é, no mínimo, igualmente importante.
Finalmente, a produtividade do trabalhador do conhecimento requer que ele seja visto e tratado como um “ativo” e não como um “custo”, e que os trabalhadores do conhecimento queiram trabalhar para a organização.

Cada um desses requisitos – com exceção talvez do último – é quase o oposto daquilo que é necessário para se elevar a produtividade do trabalhador manual (DRUCKER, 1999, p.116)."

"(...) a pergunta crucial na produtividade do trabalhador do conhecimento é a primeira: “Qual é a tarefa?” Também é a que apresenta mais diferenças em relação à produtividade do trabalhador manual. No trabalho manual a pergunta-chave é sempre: “Como deve ser feito o trabalho?” No trabalho manual a tarefa é sempre dada. Nenhuma das pessoas que trabalham com a produtividade do trabalhador manual jamais perguntou: “O que o trabalhador manual deve fazer?“, mas: “Como é a melhor maneira de fazer o trabalho?” (...) Mas no trabalho do conhecimento a pergunta-chave é: “Qual é a tarefa?”Uma razão para isso é que o trabalho do conhecimento, ao contrário do trabalho manual, não programa o trabalhador. O operário na linha de montagem de carros que instala uma roda é programado pela chegada simultânea do chassis do carro numa linha e da roda na outra. O agricultor que ara um campo em preparação para o plantio não desce do trator para dar um telefonema, participar de uma reunião ou escrever um memo. O que deve ser feito é sempre óbvio no trabalho manual.Mas no trabalho do conhecimento, a tarefa não programa o trabalhador. (...)Os engenheiros estão constantemente sendo afastados de sua tarefa por terem de redigir um relatório ou reescrevê-lo, serem solicitados para uma reunião etc. (...)O primeiro requisito em se tratando de trabalho do conhecimento é descobrir qual é a tarefa, de forma a possibilitar a concentração nela de trabalhadores do conhecimento e eliminar tudo o mais – pelo menos o que for possível. Mas isto requer que os próprios trabalhadores do conhecimento definam qual é ou deveria ser a tarefa. E somente eles podem fazê-lo (DRUCKER, 1999, p.118)."

Esse ponto levantado por Drucker tem a ver com o processo de priorização. Trabalhadores do conhecimento, incluindo os desenvolvedores de software, se envolvem com uma infinidade de atividades diferentes, as quais evoluem e mudam dinamicamente ao longo do tempo. Para obter a máxima produtividade, é necessário que eles saibam priorizar e concentrar o máximo de esforços naquilo que mais pode fazer diferença para a organização ou seu projeto a cada dia de trabalho. Note que os diversos ciclos de priorização do XP atacam exatamente esta questão!

Outro ponto a ser destacado é que as atividades não são estruturadas, nem bem programadas. E a forma de executá-las evolui dinamicamente com o tempo. Poucas atividades do conhecimento possuem uma resposta única, uma melhor forma. Exatamente por isso as pessoas evoluem e podem fazer exatamente a mesma tarefa de formas absolutamente distintas em momentos diferentes. Porque, por exemplo, algo foi aprendido. Uma das maiores tragédias nesta área é a insistência em criar cronogramas extremamente detalhados em projetos de software. Aqueles onde você encontra inúmeras pequenas tarefas listadas no Project. É uma tragédia, porque não é razoável tentar estruturar um trabalho que não é estruturado e que evolui dinamicamente com o tempo. As pessoas não fazem idéia da incrível quantidade de distorções que este hábito simples, intuitivo e extremante recorrente (embora ineficaz) de quebrar o projeto em milhões de tarefinhas, gera nos projetos.

Note que o XP aborda isso de maneira bastante diferente e dinâmica. Primeiro, não há o papel do cronograma tradicional, com as divisões de tarefas. Segundo, as próprias tarefas são decididas pelos desenvolvedores diariamente e sofrem alterações naturais ao longo das iterações nas reuniões de stand up meeting, por exemplo. Mas, estas alterações não geram a necessidade de editar o cronograma, porque ele nem sequer existe no formato tradicional de quebra de tarefas.

"Quando a Terceira Onda rompe através da nossa sociedade, o trabalho torna-se menos, não mais, repetitivo. Torna-se menos fragmentado, com cada pessoa fazendo uma tarefa um tanto maior e não menor. O tempo flexível e o ritmo próprio substituem a velha necessidade do comportamento da sincronização em massa. Os trabalhadores são forçados a enfrentar com mais freqüência mudanças em suas tarefas, bem como uma desnorteante sucessão de transferências de pessoal, mudança de produto e reorganizações.
O que os empregadores da Terceira Onda precisam cada vez mais, por conseguinte, são homens e mulheres que aceitem responsabilidade, que compreendam como o seu trabalho combina com o dos outros, que possam manejar tarefas cada vez maiores, que se adaptem rapidamente a circunstâncias modificadas e que estejam sensivelmente afinados com as pessoas em volta deles. (...)
A firma da Terceira Onda exige pessoas que sejam menos pré-programadas e mais criativas. (...)
Tais pessoas são complexas, individualistas, orgulhosas das maneiras como diferem umas das outras. Elas tipificam a força de trabalho desmassificada necessária para a indústria da Terceira Onda. (...)
Elas procuram significado juntamente com recompensa financeira (TOFFLER, 2001, p.378)."

A palavra significado representa outro fator crucial do trabalho do conhecimento. Normalmente, sentimos enorme satisfação quando criamos algo útil, que possa fazer diferença na nossa vida e na de outras pessoas. O dinheiro é importante, mas um desafio que represente a criação de algo novo e útil também motiva muitas pessoas a realizarem um trabalho do conhecimento. Por exemplo, amanhã, o Luiz fará uma apresentação no XP Rio. Ele não ganha dinheiro algum para fazer isso? Então, por que faz? Certamente, entre outras razões que possa ter, esta o fato de poder contribuir com uma comunidade pela qual tem estima.

"É claro que, no trabalho manual, a qualidade também é importante. Mas a falta de qualidade é uma restrição. É preciso haver um certo padrão mínimo de qualidade. (...)Mas na maior parte do trabalho do conhecimento a qualidade não é um mínimo, nem uma restrição, ela é a essência da produção. Ao julgar o desempenho de um professor, não questionamos quantos alunos pode haver em uma classe, mas quantos deles aprendem algo – e esta é uma pergunta de qualidade. (...)Portanto, a produtividade do trabalho do conhecimento precisa visar, em primeiro lugar, a obtenção de qualidade e não a qualidade mínima, mas ótima ou máxima. Só então pode-se questionar: 'O que é o volume, a quantidade de trabalho?' (DRUCKER, 1999, p.117)."

No XP, existem os direitos dos clientes e do desenvolvedor. Entre as do desenvolvedor encontra-se realizar um trabalho de alta qualidade. Freqüentemente as pessoas me perguntam se isso, na verdade, não deveria ser um dever. De fato, é um dever, mas por mais paradoxal que possa parecer, na prática não é nem mesmo um direito em inúmeros projetos nos quais as restrições de tempo (entre outras) são tão severas e mal abordadas, que o desenvolvedor freqüentemente se vê obrigado a fazer coisas horrendas no software na tentativa desesperada de entregar alguma coisa. E, até onde eu saiba, desenvolvedores gostam e muito de ver algo bem feito e se aborrecem quando têm que fazer as coisas de qualquer jeito e depois ficar depourando e corrigindo.

Segundo Cockburn (2002, p.63), "existem três tipos de recompensa que podem manter a motivação intrínseca de uma pessoa: orgulho no trabalho, orgulho de realizar e orgulho da contribuição."

Aqui, Alistair Cockburn reforça o ponto acima sobre qualidade, na medida em que ela permite obter um maior orgulho sobre o trabalho e normalmente torna o produto final mais útil, o que aumenta o orgulho com a realização e a contribuição.

"Você não pode dizer [ao trabalhador do conhecimento] para fazer alguma coisa porque você é o chefe e você diz que precisa ser feito. Você não pode dizer isso a [ele] porque ela não dá a mínima para hierarquia. Você não pode impor sobre [ele] objetivos que não fazem sentido para [ele]. (...) Sobretudo, você não pode estruturar o trabalho [dele] de uma forma que não lhe dê a oportunidade de crescer. Crescimento é essencial para [o trabalhador do conhecimento], tão essencial quanto o contra-cheque. Você não pode mais esperar que [ele] trabalhe sem desafios significativos, da mesma forma que não pode esperar que [ele] trabalhe sem salário.O status quase equivalente entre desafio e pagamento é único em trabalhadores do conhecimento. Eles são diferentes dos operários de colarinho azul que nossos pais gerenciavam há uma geração. O erro fácil e burro na gerência de trabalhadores do conhecimento é se esquecer que eles são diferentes e assumir que regras básicas desenvolvidas no chão da fábrica um século atrás se aplicam a eles (DEMARCO, 2001, p.28)."

Neste ponto, DeMarco chama atenção para o aspecto de crescimento. O trabalhador do conhecimento precisa evoluir e sentir que está evoluindo. Isso significa ter desafios sempre (e a oportunidade de abordá-los de forma viável, com prazos coerentes, por exemplo), oportunidade de aprender novas coisas e oportunidade de ensinar e interagir com outras pessoas.

"Nunca foi intenção do Taylorismo tratar o trabalho do conhecimento. O trabalho do conhecimento simplesmente não é como o trabalho de uma fábrica. Não existe linha de montagem e nunca existirá, não existem muitas regras fixas, valores são mais subjetivos, medidas mais duvidosas, julgamento é extremamente importante. (...) Trabalho do conhecimento é menos parecido com as atividades que Taylor estava estudando e mais parecido com a tarefa que ele próprio estava fazendo quando estudava os trabalhadores manuais. Isso envolve invenção, abstração, articulação e a gestão habilidosa de muitos relacionamentos humanos. (...)Para estabelecer uma forma padronizada de executar qualquer atividade do conhecimento, você acaba focando na mecânica da atividade. Mas a mecânica da coisa é uma pequena parcela e tipicamente não muito significativa em relação ao todo. A forma como o trabalho é executado dentro dos nós do diagrama de trabalhadores não é nem de perto tão importante quanto estabelecer quão ampla e rica são as conexões [entre os trabalhadores] (DEMARCO, 2001, p.108)."
DeMarco reforça que para a produtividade do trabalhador do conhecimento, uma questão fundamental é a quantidade de relacionamentos que uma pessoa desenvolve. Quanto maior for a sua rede de relacionamentos, maiores as chances de que ela consiga realizar suas atividades, na medida em que as atividades freqüentemente são complexas e dependem da interação entre várias pessoas. Cultivar esses relacionamentos e expandi-los é um fator essencial. Sobre isso, é bom dar uma olhada na obra de Daniel Goleman sobre Inteligência Emocional.

Referências:
DRUCKER, Peter. Desafio gerenciais para o século XXI. 1. ed. São Paulo: Pioneira, 1999. 168 p.TOFFLER, Alvin. A terceira onda: a morte do industrialismo e o nascimento de uma nova civilização. 26. ed. Rio de Janeiro: Record, 2001. 491 p.COCKBURN, Alistair. Agile software development. 1. ed. Boston: Addison-Wesley, 2002. 278 p.DEMARCO, Tom. Slack: getting past burnout, busywork, and the myth of total efficiency. 1. ed. New York: Broadway Books, 2001. 227 p.

Agile Business Coach e Business Value Driven Development

2005-01-07T17:14:00.000-02:00

De acordo com Chris Matts: "Business Value Driven Development is essentially XP using Behaviour Driven Development with an explanation of where the Stories come from in the first place."
Conheça estes conceitos:
Agile Business Coach
Business Value Driven Development

Peopleware x CMM

2004-12-28T15:21:00.000-02:00

Ultimamente venho trabalhando intensamente na finalização da minha dissertação de mestrado e para tanto tenho catalogado informações de diversos autores. Hoje encontrei algumas citações importantes sobre CMM feitas por Tom DeMarco (http://www.systemsguild.com/GuildSite/TDM/Tom_DeMarco.html) e Tim Lister (http://www.systemsguild.com/GuildSite/TRL/Tim_Lister.html) na segunda edição de Peopleware (1999). Como muitos de vocês devem saber, a primeira edição de Peopleware (1987) é um dos mais importantes clássicos da área de desenvolvimento de software. A segunda edição traz alguns capítulos adicionais nos quais encontrei as citações abaixo sobre CMM:

"Those wonderful folks who brought us the Big-M Methodology(a) back in the 1980s have not been idle. Their latest offering, the Process Improvement Movement, is newer, bigger, better, glitzer, and more ambitious... But it's also the same old stuff. Your local Process Improvement Program is Big-M Methodology, reborn. This time, it takes 'one-size-fits-all' to the extreme: not just one-size-fits-all at your company, but one-size-fits-all worldwide." p.186

"the great triumph of standards (b) in the modern world is almost entirely the success of standard interfaces. A standard for a screw thread or a AA battery or a tape cassete says a lot about the final product - how it interfaces with its corresponding parts - but nothing about the process for building that product." p.188

"When process improvement becomes the goal, the scary projects get put onto the back burner. It's those scary projects, unfortunately, that are probably the ones worth doing." p.189

"One of the strongest justifications for the CMM is that it will raise quality and productivity while decreasing risk. (...) Organizations become more and more averse to risk as they 'mature'. An organization under the gun to demonstrate increased CMM level is not going to go looking for real challenge. (c)" p.190

"The paradox of the CMM is that **process improvement is good**, but **process improvement programs** aren't, or at least they often aren't." p.188

"The Key Process Areas, as identified by the SEI, will be useful to you in building proficiency; they define sets of skills that ought to be on any good software manager's wish list. Focus on the KPA skills, but do whatever you can to turn off the institutional score-keeping(d)." p.192

Como não estou reproduzindo o capítulo completo aqui, acredito que seja interessante alguns comentários para fornecer um pouco mais de contexto:

a) "Big-M Methodology" é uma expressão que foi introduzida na primeira edição de Peopleware e se refere à metodologias burocráticas e pesadas que, às vezes, as empresas impõem sobre as equipes de desenvolvimento. Na segunda edição, ele explica que isso foi elevado a um nível muito mais amplo (mundial) através da introdução dos programas de melhoria de qualidade na área de software. É importante compreender o contexto histórico. As bases do CMM foram publicadas em 1988, com os "avanços" do SEI e a publicação do artigo "Characterizing the Software Process: A Maturity Framework" de Watts Humphrey na IEEE Software. Por essa razão, a primeira edição de Peopleware (1987) não levou em conta o CMM, mas a segunda edição (1999) trouxe o assunto à tona.

b) Em Peopleware e Slack (DeMarco), busca-se com freqüência mostrar onde os padrões são úteis e onde são contraproducentes. Em resumo, são ótimos para definir o formato final de um produto que prediza interfacear com outros (por exemplo, filmes para máquinas, formatos de CD, DVD, fita etc), mas péssimos para definir **como** tais produtos devam ser produzidos. Notar que o CMM tenta padronizar o COMO.

c) Os autores levantam o fato de que frequentemente a busca pelo CMM torna as empresas preocupadas em assumir riscos e, portanto, correr o risco de que os projetos saiam de linha e, eventualmente, a organização não possa mais ser caracterizada em determinado nível do CMM por conta disso. O problema é que o projetos mais inovadores e que mais podem gerar retorno normalmente são também os mais arriscados.

d) Finalmente, os autores mostram que as KPAs do CMM contém informações extremamente úteis e louváveis, mas os programas de melhoria de qualidade são extremamente perigosos, em parte por tentarem padronizar o COMO (one-size-fits-all) e, em parte por criarem um clima de medo nas organizações e aversão à risco, entre outras razões citadas no livro.

Para aqueles que tiverem uma oportunidade, sugiro fortemente a leitura da segunda edição de Peopleware. Os conceitos são extremamente alinhados à cultura do XP.

XPRio comemora seus dois anos com XPGame...

2004-12-18T16:56:00.000-02:00

Neste mês o XPRio completou dois anos de existência e a celebração ocorreu durante a reunião mensal de dezebro. Nesta foi realizado o XPGame. Além de todos se divertirem enquanto exercitavam o Jogo do Planejamento - vivenciando os conceitos de iteração, priorização, valor de negócio e velocity - ainda tivemos tempo para um lanche e um bolinho comemorativo : )

Lançando Blog do XPRio!

2004-12-18T11:06:00.000-02:00

Após 2 anos de existência como um fórum de discussões no yahoogroups, sempre com suas reuniões mensais e centenas de associados, o XPRio agora apresenta um novo espaço de comunicação em torno do tema Extreme Programming e desenvolvimetno ágil de um modo geral... em breve, muitas notícias.