janeiro 21, 2005

 

Artigo sobre Pair Programming

Pair Programming Observations by Jeff Langr.

# enviado por Carlos Miranda @ 17:27

janeiro 18, 2005

 

O que é XP?

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.



# enviado por Carlos Miranda @ 19:07

janeiro 15, 2005

 

Primeiro Projeto Scrum

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.

# enviado por Carlos Miranda @ 16:35
 

Integração Contínua

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.

# enviado por Carlos Miranda @ 09:52

janeiro 14, 2005

 

Lançado livro de XP para .NET

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

# enviado por Carlos Miranda @ 10:35

janeiro 12, 2005

 

XP + C#

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

# enviado por Carlos Miranda @ 19:09
 

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

Novo artigo sobre Pair Programming, em Builder Au.

# enviado por Carlos Miranda @ 18:54

janeiro 11, 2005

 

Produtividade do Trabalhador do Conhecimento

> 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:
  1. A produtividade do trabalhador do conhecimento requer que façamos a pergunta: “Qual é a tarefa?”
  2. Ela exige que coloquemos a responsabilidade pela produtividade nos próprios trabalhadores do conhecimento. Eles precisam gerenciar a si mesmos e ter autonomia.
  3. A inovação continuada tem de fazer parte do trabalho, da tarefa e da responsabilidade dos trabalhadores do conhecimento.
  4. O trabalho do conhecimento requer aprendizado contínuo por parte do trabalhador, mas também ensino contínuo.
  5. A produtividade do trabalhador do conhecimento não é – ao menos principalmente – uma questão de quantidade produzida. A qualidade é, no mínimo, igualmente importante.
  6. 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.


# enviado por Unknown @ 11:57

janeiro 07, 2005

 

Agile Business Coach e Business Value Driven Development

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

# enviado por Carlos Miranda @ 17:14