Regras de Ouro do Desenvolvimento Ágil

Prometa para si mesmo, ó neófito pretendente a Agilista, que ao evoluir para um processo de desenvolvimento saudável, sustentável e maduro, você prezará pelas seguintes regras:

1. TRABALHE EM ESPAÇOS FIXOS DE TEMPO

De preferência o menor tempo possível. Lembre=se: o término de um período é sagrado. Nada atrasa a finalização de uma Sprint. Para tanto, é necessário ter em mente o que é uma funcionalidade terminada (pronto mesmo... pronto pronto!!). Requisitos não finalizados não atrasam a sprint, são deslocados para o próximo ciclo.


2. FOQUE NA QUALIDADE

Mais do que isso: não discuta qualidade. Seja preguiçoso: automatize testes para não se preocupar e refazer validações mais tarde. Crie a cultura de inspeção de código. Valorize iniciativas em Integração Contínua. Evite trabalhar fora do horário para que você possa ter a confiança em tudo o que é produzido em seu projeto.


3. VALORIZE AS PESSOAS

Motive-as. Dê desafios e ouça opiniões, faça com que os membros da equipe estejam dentro da cadeia de tomada de decisão. Numa tome uma decisão sobre um projeto sem que um desenvolvedor esteja ao menos ciente do impacto. Utilize a sabedoria das multidões (Wisdom of crowds)


Este será o seu juramento. Levante-se agora, como um Agilista!


(isso que dá assistir filmes do Rei Arthur)

[]s

Mitos Ágeis

Certa vez ouvi um palestrante dizer a seguinte frase: "Para os desenvolvedores, XP é uma opção extremamente sexy". E engraçado como tal afirmação é verdadeira. Explicar para alguém que trabalha em um projeto de software é visivelmente mais fácil do que um patrocinador, ou diretor de empresa.

Como uma forma de dar início a um projeto Ágil, tenta-se adaptar as práticas mais apelativas: Testes automatizados, desenvolvimento interativo e pair programming. Mesmo que os benefícios de tais práticas sejam evidentes, é comum que elas sejam mal interpretadas. Isto porque a aparente facilidade que "automatização de testes" ou "programação em dupla" transmite, é completamente diferente da realidade.

Aplicar testes em projetos de software pode ser um processo muito doloroso, por desafiar os principais hábitos dos programadores e trazer uma aparente queda na produtividade. Principalmente por isso, no momento em que você optar em seguir para o "Mundo Ágil", é muito importante utilizar as práticas em sua essência, ganhando a experiência necessária para seguir na criação de um modelo sustentável de desenvolvimento de sofware. É preciso experimentar os reais benefícios das práticas, ganhando confiança para mudanças mais críticas em sua empresa.

Mais uma vez, Ross Pettit apresenta sua visão no site Agile Journal de como a interpretação errada de práticas pode levar a sérios problemas no desenvolvimento, ou ainda causar a impressão errada à equipe e diretoria.

Mito #1: Nós escrevemos testes unitários, mas não importa se eles passam ou não...
Não existe prática com os benefícios mais evidentes que automatizar os testes de software e integrá-los num ambiente de build automático. Entretanto, poucas pessoas se lembram de que é necessário manter os testes criados. Isto é, os desenvolvedores escrevem inúmeros testes automatizados mas não existe a preocupação em manter todos os testes funcionando no momento do build. Assim, a falha de um teste não se torna um "chamado para os desenvolvedores". Esta característica pode ser reflexo de:

• Pressão para que os desenvolvedores mostrem "código finalizado"


• Desenvolvedores não sentem responsabilidade pelos testes que eles não escreveram


• Testes unitário não são desenvolvidos como uma especificação executável, apenas como informação (talvez cumprindo a requisição por documentação)

Desenvolvimento Ágil não é sobre aparências, mas sobre fatos. Esta falsa impressão de qualidade, com a existência de inúmeros testes unitários que não fucionam, deve ser combatida. Sem o comprometimento em manter o conjunto de testes sempre funcionando, todo este código gerado não passará de lixo. Isto mesmo: lixo

Todo o controle de riscos existente em uma equipe Ágil estará perdido. Uma vez que os testes não garantem que o código está funcionando, qualquer problema/bug/nova funcionalidade adicionada não poderá ser analisada com confiança.

(...)
Leia o documento completo

[]s

Terceira Edição: Visão Ágil

Saudações!
Mais uma edição da revista Visão Ágil está disponível para download. Nesta edição recomendo os artigos sobre o Scrum Gathering, em Londres, e a cobertura do Evento Java Brasil 2007...

Claro, não poderia deixar de fazer uma propaganda básica: Um artigo meu, tratando sobre Métricas em Desenvolvimento Ágil.

Apesar de já ter escrito neste blog sobre o assunto, resolvi fazer uma pesquisa maior, dando ênfase à aplicação de gráficos ao desenvolvimento, excluindo a idéia de que nós agilistas somos contra qualquer tipo de organização. E apresentando ferramentas para que qualquer um possa apresentar os resultados dos projetos Ágeis uma diretoria.

Aproveitem!
[]s

Transitioning To Agile Process

Yeah! Eles atacam novamente... a edição deste mês do Agile Journal está excepcional! Com o título de Transitioning To Agile Process, a revista traz uma compilação de artigos do tema... tornando-se mais um referência nas leituras obrigatórias...

Um resumo:

Patterns of agile adoption

Mike Cohn descreve dúvidas comuns sobre como prosseguir na adoção do desenvolvimento Ágil: "Começar pequeno" ou seguir o famoso "Arrastão" na empresa? Seguir para práticas técnicas ou conseguir transformar o desenvolvimento em um modelo iterativo?

Entre as vantagens e desvantagens podemos citar:

- O custo de utilizar projetos piloto para testar o movimento Ágil pode ser ótimo para minimizar custos, mas pode não trazer a real visão da aplicabilidade do modelo em um nível macro.
- Um projeto bem sucedido e um equipe satisfeita por ser o empurrão necessário para que novas e vitoriosas iniciativas iniciativas

- Introduzir algumas práticas pode não trazer os resultados esperados, já que todas as práticas são complementares. (nota pessoal: não iniciar refactoring sem testes automatizados)
- É muito mais fácil iniciar no projeto um modelo iterativo de desenvolvimento. Faça o teste: diga para sua equipe: daqui a 4 semanas eu quero uma versão instalável do software...

Mais informações: leia artigo completo

Ainda sobre Patterns in agile, recomendo a leitura do livro: Agile Patterns: A techinal Cluster (leitura obrigatório número 3323)


The Dichotomy of Change

Para mim já é um dos melhores textos do tema... indubitavelmente. Ross Pettit descreve a evolução das fases na adoção Ágil, e resume um processo Ágil para a sua empresa como sendo:

The path of Agile adoption is well trod, but poorly lit. Each organization, each project, presents unique challenges and obstacles. Agile work processes must be specific enough to be understandable, defined enough to be repeatable, malleable enough to change with experience, and flexible enough to accommodate a wide range of operating realities. A sufficient breadth of Agile practices must be brought to bear on a situation or the practices will yield few benefits. The people performing them must master these new practices quickly or the process change will be perceived as providing little value.
(desculpe a falta de tradução, não quis perder o real significado do texto)


Topicos desta edição:

Building an Agile Organization

Patterns of Agile Adoption

The Dichotomy of Change

Moving to Agile: TO DOs for your Pointy Haired Boss

The Challenge of Enterprise Requirements Management: Boosting Business Value with Index Cards

Resolve to Increase Agility

The Shiny New Agile Architect

FEATURED BOOK: The Art of Agile Development by James Shore and Shane Warden

Modifique o layout do Trac

Você já ouviu falar no Trac? Ferramenta muito interessante! Aparentemente um simples sistema de tickets para helpdesk, com os plugins certos você pode facilmente organizar uma equipe Ágil... até mesmo o Jeff Shuterland já referenciou a ferramenta em seu blog. Estamos usando o trac desde outubro na Audaces, e estou cade vez mais impressionado. Além do sistema de tickets existe ainda integração com subversion, subsistema de codeReview....

Mas estamos aki para falar de como modificar o tema padrão do trac...

Passos simples(supondo que vc jah tenha um projeto trac funcionando):

Primeiro Passo:No arquivo /templates/site_css.cs:

 ##################################################################
# Site CSS - Place custom CSS, including overriding styles here.
?>

@import url(/site/cascadeTracMeuTemplate.css);

Segundo Passo: No diretório htdocs crie o arquivo cascadeTracMeuTemplate.css com o seguinte conteúdo(Sim, copie e cole):

body {
 background: #FFFFFF url(background.png) 0 0 repeat-x;
 color: #000;
 margin: 10px;
 padding: 0;
}

form.addnew { clear: right; float: right; margin: -2em 0 4em; }

.nav {
        position: relative;
}
.wikipage { padding-left: 18px; position: relative; left: 2%; width:94% }

/* BARRA MENU */
#mainnav {
         background: #66CCFF url(nav_fundo.png) 0 0 repeat-x;
         border: 1px solid #000;
         font: normal 10px verdana,'Bitstream Vera Sans',helvetica,arial,sans-serif;
         margin: .66em 0 .33em;
         padding: .2em 0;
}
#mainnav li { border-right: none; padding: .25em 0 }
#mainnav :link, #mainnav :visited {
         background: url(dots.gif) 0 0 no-repeat;
         border-right: 1px solid #000;
         border-bottom: none;
         border-left: 1px solid #555;
         color: #000;
         padding: .2em 20px;
}
* html #mainnav :link, * html #mainnav :visited { background-position: 1px 0 }
#mainnav :link:hover, #mainnav :visited:hover {
         background-color: #66CCFF;
         border-right: 1px solid #000000;
}
#mainnav .active :link, #mainnav .active :visited {
         background: #333 url(../topbar_gradient2.png) 0 0 repeat-x;
         border-top: none;
         border-right: 1px solid #000;
         color: #eee;
         font-weight: bold;
}
#mainnav .active :link:hover, #mainnav .active :visited:hover {
         border-right: 1px solid #000;
}

/* LINKS */
:link, :visited {
 text-decoration: none;
 color: #3333CC;
 border-bottom: 1px dotted #3333CC;
}

/* TIMELINE*/
dt :link:hover, dt :visited:hover { background-color: #eed; color: #3333CC }

dt em {
        border-bottom: 1px dotted #bbb;
        color: #3333CC;
        font-style: normal;
        text-decoration: none;
}

/* ROADMAP */
.milestone .info h2 em { color: #3333CC; font-style: normal }


/* FOOTER */
#footer {
  clear: both;
  color: #bbb;
  font-size: 10px;
  border-top: 1px solid;
  height: 31px;
  padding: .25em 0;
}

Terceiro Passo: Edite os arquivos site_header.cs e site_footer.cs no diretório templates:

SITE_HEADER.CS
####################################################################
# Site header - Contents are automatically inserted above Trac HTML
?>

--

#########################################################################
# Site footer - Contents are automatically inserted after main Trac HTML
?>

Aprendendo a utilizar Users Stories?

Kelly Waters apresenta um resumo, e um exemplo real, interessante sobre como escrever uma user story. Veja o post completo

I recently described User Stories and the composition of a User Story Card - Card, Conversation and Confirmation.

I'm not really sure if you would consider this example to be good, bad or indifferent - I guess it depends what you're used to - but here is an example nevertheless!

Seminários online

Dicas interessantes para a semana que vem: Webinários!!
Jah participei de alguns, acho que vale a pena... inclusive poderia se tornar um padrão em algumas empresas que esperam dos funcionários alguma formação, e disponibilizam o ambiente de trabalho para o estudo. Lá vai:

Post-Agile Scrum

Thursday, Jan 24, 2008
11:00am to 12:00pm PST (2:00pm to 3:00pm EST) Webinar Presentation
12:00pm to 1:00pm PST (3:00pm to 4:00pm EST) Q&A Followup

Presented by CEO and Senior Consultant: Alan Shalloway.

Today, what is required is helping the entire enterprise become Agile? What is an Agile Enterprise? An enterprise that can respond quickly to customer, environment and internal changes to create a competitive advantage. This requires much more than merely trying to apply practices that work for local teams to the entire enterprise - that approach is too simplistic. This Agile Enterprise-perspective is one of the biggest differences between current Agile practitioners and those going beyond Scrum. This webinar discusses the essential approaches to making an Agile Enterprise: approaches that also create structures that enable Agile teams to work even more efficiently.

Connection details will be sent to registrants via email a few days before the event.

Learn more about and register for the Post-Agile Scrum
Register

-------
Using Scrum for Effective Product Management

with Sinan Si Alhir
Practitioner

Scrum is a process framework that enables lean, agile, and competitive approaches to product management and development. While Scrum is conceptually simple and involves only a few roles, artifacts, and ceremonies, its practices demand discipline and its implementation causes a paradigm shift in product management and development. Many teams and organizations implement Scrum practices, but don't readily absorb its underlying philosophy, and thus don't maximize their return on adoption as they enact its practices.

This session is a introduction to how Product Management can be more effective when using Scrum; how to absorb its philosophy and enact its practices for maximum return. In particular, how Scrum may be used in combination with the Pragmatic Marketing Framework to produce the most positive impact for a product management team.

Register for this event

De onde vem os bugs?

Tyner Blain traz uma explicação bastante convincente sobre os principais motivos para o aparecimento de bug num sistema (leitura obrigatória número 1.43443). Num outro post, Mr. Blain ataca novamente: Você está criando bugs para o seu sistema! Leia "você" como sendo todos os envolvidos num processo de desenvolvimento de software, afinal de contas, programadores são apenas mais um elo na corrente.

Ouça bem as conversas de corredor em sua empresa. Quando se trata de bugs, as seguintes frases são as mais comuns:

1. "Isto não é o que eu queria"
Stakeholders inserem bugs no sistema ao não saberem o que desejam. Uma forma que o desenvolvimento ágil encontrou para isso é: não espere saber tudo de antemão, preocupe-se com o que você deseja agora.

Assim, o desenvolvimento iterativo e a priorização por valor agregado dos requisitos pode ajudar a mitigar alguns problemas de interpretação errada. Ainda caimos no problema da descrição de requisitos: textos que podem ajudar:
User stories by Kelly Waters

Writing valueable requirements

2. "Não foi isso que eu disse"
Analistas de negócio e gerentes de produto inserem bugs ao não interpretarem corretamente o que clientes e stakeholders querem.
By Tyner Blain:
You can improve how you listen, and you can improve how you document what you heard. Make sure that you write complete, consistent and unambiguousrequirements
3. "Não foi isso que eu quiz dizer"
4. "Não é assim que deveria funcionar"
5. "Não foi isso que eles disseram"
6. "Não é desse jeito que eu quero que faça"

Leia o artigo completo

XP funcionaria?

Blz então... postando serio agora..

Saudações!
Na lista de discussão gringa de XP (extremeprogramming) está rolando uma discussão muito interessante sobre a utilização de XP por uma equipe apenas para planejamento. Confesso que achei extremamente interessante. Em seu post inicial Stefan Arentz descreve a utilização principalmente da prática de jogo do planejamento e estimativas... acompanhe o post na íntegra.

Gostaria de chamar a atenção para um reply:

Fonte
John A. Maxwell

> Hmm makes me wonder.. does XP works on a fixed cost project ?

It depends on what you mean by "work". If you mean, will it help you get the most value for the money spent, yes. If you mean, will it let you know as early as possible if you're not gonna meet all of the goals (if that's the case), again, yes.

If you mean, will it cause the impossible to suddenly become possible, no (well, unless it was only very slightly impossible :-). If you mean, will it enable you to delude yourself into thinking you can do too much work in too little time, again, no.

If you mean, will it give you a magic wand, to make the people who want more done than time and resources allow stop being unreasonable... maybe. It depends on whether they're prepared to face reality, and even more importantly, on _how_ they're prepared to face it. Further exposition below. (...)

Yep. Welcome to every fixed price contract I've ever heard of. A news flash, though: most of the time, the people applying the pressure _already_ _know_ they aren't going to get everything they ask for. They just don't know any other way to get as much as possible. The logic is simple (albeit incomplete and incorrect): the harder they push, the harder the programmers will work, and the more will get done.

But _your_ side of that is that you have to be honest enough to tell the truth, even when it's not what the person you're talking to wants to hear. Not whine about the truth, but accurately, calmly, and professionally report your progress, how much the customer can expect to get from you every time you sit down to plan an iteration, etc.

There are good reasons why the white book talks about "courage". It's not a joke or "feel good" filler, and it's not easy.



EditNote: Aos finalizar o post, vi que o James Shore também publicou sobre este mesmo post... coincidência?

[]s

WifiArmy

Bem, quando era mais novo adorava RPG. Interpretar vampiros, lobisomes ou pistoleiros num mundo pós apocalíptico foi a diversão de minha adolescência.
Atualmente fico cada vez mais alucinado com as possibilidades que surgirão à partir do console Wii, e principalmente as tecnologias inspiradas no console... imagine-se na seguinte cena:



Show de bola este comercial do XBox né??? Bom seria se fosse verdade....

Bem, talvez seja:

WifiArmy é um projeto baseado na plataforma Android do google (SO para celulares). A idéia é genial: reúna Wifi, googleMaps e alguns nerds representantes da geração Gamers fãs de CounterStrike e Quake e terá um belo exemplar do futuro dos jogos.
Tendo a aplicação em seu celular, ao encontrar alguém próximo que esteja disposto a jogar, utilize a webcam para mandar bala em geral!!! ("Cavera meu capitão!!")

Bem, o vídeo fala por si:

Release Planning e Interações para Gerentes

Mais um podcast de All Shalloway, falando sobre sua experiência apresentando um pouco de Agile para Gerentes - especialmente falando sobre Release Planning.

Fonte: http://www.netobjectives.com/blogs/agile-scrum-management-release-planning-iterations-sqe




File .mp3

BigThink - what is it??

Fonte

Big Green Challange

Saudações a todos!
Foi dada a largada a um concurso, patrocionado pela NESTA (National Endowment for Science, Technology and Arts), que premiará as melhores idéias sobre Redução de emissões de carbono. Os 10 primeiros finalistas receberão 200k Libras (isto mesmo!!! 800.000 reais) para patrocionarem suas idéias. O processo é simples: encontre uma comunidade disposta a ajudá-lo, monitore, investigue, documente e apresente de forma real de que maneira suas idéias poderão ser escaláveis e o quão eficiente é o meio de diminuir emissões de carbono...

Agora, olha o tipo do bigode de um dos "Angels" do concurso:

Dick Strawbridge

With applications now open, I wanted to share some pointers on how to get started and organise your community: 1. Recruit a core team – while it will help to work with a whole community, you are also going to need a few key people to drive the project forward and encourage others. 2. Elect a spokesperson – people are going want to know about what you are doing, so choose someone who is an able speaker and understands the project well. They should be able to inspire your community and engage with other people.(...) More...

Leituras para o Verão

Saudações!!!!
Feliz ano novo para todos!!

Bem, apesar do fraco movimento neste blog no final de ano (realmente a correria foi grande), não parei de verificar o que outras pessoas que respeito estão produzindo. Abaixo segue uma pequena lista de leituras interessantes para você que está se escaldando no verão brasileiro... bem, pelo menos aqui em floripa nós estamos...

• Understanding your Velocity - Kelly Watters
  
• Meansuring Business Value with metrics - Kelly Waters
  
• Test Smarter, not harder - A detailed article - Tyner Blain
• Value Velocity: A Better Productivity Metric? - James Shore
• How to catch up on test automation - Henrik Kniberg

E por último e mais importante: Agile Certification Now!

[]s