BT

Disseminando conhecimento e inovação em desenvolvimento de software corporativo.

Contribuir

Tópicos

Escolha a região

Início Notícias Brian Marick: O que está faltando no Agile Manifesto

Brian Marick: O que está faltando no Agile Manifesto

Favoritos

Em seu keynote na conferência de Práticas de Desenvolvimento Ágil, Brian Marick descreveu valores que estão em falta no Manifesto Ágil. Sua opinião é de que o Manifesto era essencialmente um documento de marketing, visando conseguir que as empresas dessem uma chance para a agilidade. Agora que grande parte desse objetivo foi alcançado, um extenso conjunto de valores são necessários para ajudar os times a concretizar as promessas do manifesto.

Os valores são o que nos mantêm no caminho reto e estreito perante a tentação. Os times que têm fortes valores interiorizados irão se manter fiel as boas práticas ágeis — e obter bons resultados ágeis — enquanto os times sem valores para orientação vão estar à deriva.

As idéias que Brian expressou em seu keynote são as mais recentes evoluções de um tema que ele compartilhou no 2007 XP Day Toronto, e mais tarde escreveu sobre isso. Naquele tempo, ele tinha uma lista de 4 novos valores que pensou serem necessários:

Habilidade
Não existe nenhum substituto para desenvolvedores e testadores qualificados. A habilidade vêm de praticar e aprender os fundamentos do desenvolvimento de software.

Disciplina
Acontece que praticar bem agilidade requer um pouco de disciplina. Inicialmente é mais rápido não refatorar o código ou mesmo deixar de escrever os testes. Inicialmente é mais fácil e mais rápido, mas a longo prazo isso só irá atrasar você. É preciso disciplina para agir dessa forma toda vez.

Facilidade
Fazer com que as coisas que fazemos frequentemente sejam mais fácil. Brian descreve como isso se relaciona com o conceito de habilidade. Da mesma forma que uma casa é adaptada pelos seus habitantes a fim de tornar sua vida mais fácil e mais confortável, o código também pode, e os nossos ambientes de trabalho podem ser modificados de forma a torná-los mais fáceis para 'viver'.

Alegria

Agora, eu poderia dizer que um empregado feliz é um empregado produtivo, e que a falta de alegria em um projeto é como um canário ciscando em uma mina de carvão: um grande sinal de que algo está errado e é melhor você prestar atenção. Talvez isso seja verdade. Eu certamente gostaria de acreditar. Mas, fundamentalmente, eu não me importo. Acho que alegria é sua própria desculpa. Nós merecemos isso. Mais que isso, as pessoas que nos rodeiam merecem isso.

Naquela época, Brian estava preocupado com onde a falta destes quatro valores nos levaria.

Eu acho que a Agilidade está sofrendo hoje, porque estes valores fundamentais não foram escritos e foram muito facilmente esquecidos. Como Agile está indo para empresas maiores e menos para as mais aventureiras, estes valores não documentados estão indo por água abaixo. Se isto continuar, temo que Agilidade será a moda da década que não muda nada. Isso seria triste.

James Shore recentemente manifestou preocupações semelhantes sobre o movimento ágil sendo prejudicado pelos times que estão implementando agilidade pobremente.

Mais recentemente, Brian acrescentou mais alguns valores na sua lista, incluindo: coragem, ser reativo, feedback rapido e visibilidade que aumenta o nível de exibicionismo.

Coragem
Esta é a coragem de fazer o que é melhor para o time, para o projeto ou mesmo para o negócio, apesar das pressões no sentido contrário. Brian compartilhou um exemplo que ele diz ser de Ken Schwaber, de um scrum master que desmontou os cubículos da equipe, para que eles pudessem ter o espaço de equipe que eles queriam. Quando confrontados com a 'política de mobílias' eles deixaram claro que iriam sair se os cubículos fossem restaurados.

Ser Reativo
Brian considera que apesar do mau significado que a palavra "reativo" tem, ela é totalmente adequada para um time ágil, e os seus membros a serem reativos em certas maneiras. Quando codificando, algumas vezes é melhor escrever código e então reagir sobre quão bem ou não esse código funciona. Quando tomamos as decisões, esperando até o último momento pela resposta pode ser visto como uma abordagem reativa.

Feedback Rápido
Tomando uma abordagem de desenvolvimento de funcionalidade-por-funcionalidade, em vez de uma abordagem infra-estrutura primeiro, é uma forma de obter feedback rápido. Pessoas de negócio raramente são capazes de dar o seu feedback em relação à infra-estrutura crua (Ei, muito bomo design do seu banco de dados!), mas negócios facilmente são capazes de dar feedback útil em funcionalidades prontas. Outro exemplo ainda mais rápido de feedback é visto no test-driven design.

Visibilidade
Fazendo o maior número de informações tão visível quanto possível tem sido considerada uma das melhores práticas entre os praticantes de agilidade há muito tempo. É a motivação por trás dos 'grandes mapas visíveis' e 'disseminadores de informação'. Isto nào só é útil para manter todos informados, quanto pode ajudar a emergir problemas rapidamente de forma que estes serão tratados naturalmente.

Basta fazer os maus hábitos ficarem bastante visíveis. A pressão da visibilidade constante fará você colocar estes hábitos a parte, e — ao longo do tempo — aquilo que você faz de bom se tornem hábitos, mas desta vez bons. E, ao longo do tempo, esta coleção de mudanças pode formar bons membros de equipe e grandes equipes, exatamente da maneira que o produto cresce sem problemas a partir de algo pouco funcional para algo que realmente da orgulhoso.

O texto do keynote de Brian pode ser encontrado aqui.

Como o seu time aplica, ou não aplica, estes valores? A lista do Brian está completa ou existem outros valores que orientam os times ágeis que deveriam ser considerados? Deixe um comentário e compartilhe seus pensamentos.

Avalie esse artigo

Relevância
Estilo/Redação

Conteúdo educacional

BT