A Maldita Comédia

Uncle Bob e o dilema do profissionalismo

2009-06-07T12:52:00.003-03:00

Acredito que seja um video não apenas para a comunidade Ruby / Rails, mas para a comunidade mundial de desenvolvimento de software...

Scrum Gathering Brazil: Impressões

2009-05-15T12:27:00.004-03:00

Scrum Gathering Brazil: Impressões

Saudações!!
Antes de continuar com este post, um esclarescimento: Como sou um dos editores da InfoQ Brasil, não publicarei informações sobre as palestras neste blog, já que MUITA informação será disponibilizada no http://www.infoq.com/br no decorrer dos próximos dias. Fique no aguardo!

Agora voltando às impressões pessoais do evento:

Cara, Scrum Gathering talvez esta tenha sido a principal oportunidade de encontrar a maioria dos caras que formam a comunidade Ágil brasileira! E todos num único lugar!
Durante os dois dias de evento, nos revezamos discutindo, criticando e trocando informações importantíssimas sobre Agilidade e o impacto disso no mundo dos negócios. O perfil do evento possibilitou imensamente o contato, tendo sido realizado no Hyatt Hotel, em são paulo.

Gostei muito do que vi, apesar de alguns absurdos (como apresentado já pelo Rodrigo Yoshima), mas saí com a impressão que precisamos nos focar em discussões mais profundas sobre práticas e incluir, que sabe, mais práticas ágeis no evento.

Fotos do evento por Manoel Pimentel: Scrum Gathering Brazil

E pra aproveitar esse povo todo em são paulo, fomos tomar cerveja!!

Foto por @rodrigoy

Tem tanta gente nessa foto que não tenho nem coragem de começar a escrever os nomes, com medo de esquecer de alguém. Mas vou citar uma pessoa importante: O Martim Fowler brasileiro: Felipe Rodrigues! Veja-o ao lado de Manoel Pimentel: O Martim Fowler Brasileiro

Valeu galera!!! Hooters foi o bicho!

Parabéns Alexandre Magno e Edmilson Miyasaki pela organização!
Até a próxima!!

PS: Tire férias em outubro! Ágiles 2009 vem ai!

Impressões: Agile Weekend

2009-04-30T21:18:00.003-03:00

Senhores!

Bem, o último final de semana estive em Porto Alegre para prestigiar o Agile Weekend, evento promovido pelo Guma-RS, em comemoração de seu quinto aniversário (parabens guma!)

Muita gente apareceu para conferir o evento, inclusive muito mais do que eles imaginavam... o que é um indício de uma demanda extremamente reprimida no sul do brasil por eventos de qualidade e foco em Metodologias Ágeis.

O evento foi muito show!! Imaginem programar um evento para 100 - 150 pessoas, e de repente aparecerem 300 para participar... povo teve que se desdobrar em 5 pra fazer a coisa acontecer... e claro: aconteceu!!

O evento começou com uma apresentação dos organizadores, seguido de uma palestra "motivacional" de Daniel Wildt e Luiz Parzianello, fundadores do Guma. Extremamente divertidos e de improviso eles falaram sobre as origens do Lean e as ramificações que o modelo criou mundo a fora... mostrando que Lean escala e que Desenvolvimento Ágil tem um pai! Detalhe: respondi a uma pergunta e ganhei um livro!! Coisaboua participar de evento em Porto alegre! Já é o segundo que ganho!! Agora vou aprofundar mais meus conhecimentos em Lean... me segura!!

Um show a parte: o coffee break!! Credo! muito bom!!

Bem, pra variar, encontrei o pessoal da Sea Tecnologia (@alegomes, @rwilli e @brunopedroso)... esse povo não deve trabalhar... assim como eles acham que eu não trabalho... somos todos arroz de festa! (e o proximo: Scrum Gathering!)

A próxima palestra foi feita pelo Peleteiro, da Globo.com, falando sobre anti padrões de equipes ágeis. Acredito que tenha sido a palestra com maior intereção com o publico...

Logo depois assisti à apresentação de Fabrízio Mello, falando sobre refactoring em banco de Dados... bem, seguindo as palavras do próprio Fabrízio: Scott Ambler colocou os nomes bonitos na maior parte das funções rotineiras que usamos para desenvolvimento com banco de dados... mas foi bastante produtivo... quer dizer que o que antes era chuncho agora virou Refactoring Pattern!!

No outro dia, conversamos sobre Agile no ensino. O Guma RS está com uma iniciativa muuuuito interessante para levar metodologias ágeis para o ensino, pra evitar que se fale muita porcaria em artigos e teses orientadas por professores que não sabem do que estão falando... gostei!

Ah! O pessoal da SEA apresentou o case de seu trabalho junto à força aérea brasileira, semelhante ao apresentado no último Maré de Agilidade

O Daniel Wildt desabafou todas as suas mágoas numa palestra entitulada "Eu odeio metodos Ágeis"... muito bom!

Pra finalizar, uma mesa redonda com a maior parte dos palestrantes. A discussão girou em torno de contratação de projetos Ágeis... tema já bastante conhecido e abordado, por exemplo, por Jose Papo, inclusive com uma apresentação no último Falando em Agile e que falará sobre o mesmo tema: contratos! )

E foi isso... ótima experiência, voltei completamente renovado para o trabalho...

Parabens aos organizadores!

Bá! Trí legal esse evento!

E pra fechar o dia, claro: Cerveja!!!

I am a Craft Brewer

2009-04-24T21:15:00.001-03:00

I Am A Craft Brewer from I Am A Craft Brewer on Vimeo

aula 2: Teste de Software no CTAI

2009-04-24T19:04:00.003-03:00

Saudações!!

Bem, estou aqui em casa após mais um dia de aulas no Senai CTAI... realmente cansado...

Desta vez, a intenção foi ser o mais didático possível na utilizaç!ao de documentação de testes. Apesar de concordar com o @gchapiewski , algumas coisas não podemos fugir de documentar... mas pelo menos que sejam agregando valor!

Segue abaixo os slides de mais essa aula.

Ctai Teste De Software Aula 2

View more presentations from Victor hugo Germano.

Aula: Teste de Software no CTAI

2009-04-22T20:42:00.006-03:00

Saudações!

Bem, alguns já devem estar sabendo, mas vale lembrar: no momento estou atuando também como professor do Senai CTAI em Florianópolis. Minha primeira ação nesta nova função está sendo no curso: Teste de Software

Pode parecer, mas este não é um curso de teste comum... de tradicionalidade, NADA!

Estou tentando colocar em jogo minha visão do desenvolvimento de software, e de que maneira um processo de testes se encaixa nisso tudo.

Longe de ser uma aula completamente teórica, minha intenção é reconstruir de forma evolucionária e incremental o conceito de teste de software, trazendo um desafio: Trabalhemos conscientemente para a construção da qualidade de software! Eliminemos desperdícios e estejamos prontos para criticar os modelos burocráticos de teste de software. Antes de mais nada, o que importa é Software Funcionando!

Além disso, incorpore ferramentas de teste ao seu dia a dia, reduzindo muitos dos custos atrelados a um processo de softwre.

Seria esta a vitória do Desenvolvimento Ágil na Academia? Difícil de dizer no momento, então vou esperar até o final do curso. =)

Enquanto isso, seguem os slides da aula de hoje:

Ctai Teste De Software Aula 1

View more presentations from Victor hugo Germano.

Quer trabalhar na Audaces? Pergunte-me como!

2009-04-16T20:40:00.003-03:00

Bem, não gosto muito de me repetir... bem por isso que não tenho postado tanto no blog... mas vou abrir uma exceção!

Um dos posts mais visitados neste blog, sem dúvida, foi o anuncio de vagas na Audaces para um projeto no mínimo interessante: Um simulador 3D em Java!

Até colocamos o Eduardo, líder do projeto, para falar no Mês do Java 2008, e aguarde, logo ele falará de novo! Para os que acreditam software 3D não é viável em java... aguarde e confie!

Bem, chegou a hora! Precisamos de mais desenvolvedores!

Procuramos pessoas que sejam apaixonadas pelo próprio trabalho, gostem de aprender coisas novas e estejam dispostas a criar produtos com máxima qualidade! Você gosta de matemática? Gosta de desenvolvimento "ao extremo", e está cansado daquelas aplicações chatas? Adoraria passar o dia inteiro olhando para a Ivy?? Venha ser entrevistado!!

OpenGL, Eclipse RCP, Scrum, TDD, Modelagem 3D, Simulação Física... enfim: DIVERSÃO

Trabalhe Conosco

victor.germano [at] audaces [ponto] com

E então, topa o desafio? Entre em contato!

Fotos do evento: Maré de Agilidade

2009-03-30T13:52:00.004-03:00

Fotos Maré de Agilidade by Manoel Pimentel

Maré de Agilidade

2009-03-28T14:41:00.003-03:00

Bem, pra quem não sabe, estou na Bahia, Salvadô... convidado para o evento Maré de Agilidade

Vim para falar sobre o conceito de Integração contínua.

O pessoal da organização do evento disponibilizou um blog com as informações. Confira! (Slides da minha apresentacao neste blog)

http://maredeagilidade.blogspot.com

até mais!

Somos professionais de software?

2009-02-20T10:22:00.002-03:00

Uncle Bob, sempre pragmático (e porque nao dizer, radical), se apresentou no JAOO com a seguinte palestra: Craftsmanship and Ethics.

O cara levanta uma bandeira muito interessante: não somos profissionais... somos apenas trabalhadores... e isso se deve pela falta de disciplina que NAO temos aos construir código. E ele faz muito bem o seu papel: evangelização (com uma inclinação meio maluca).

Veja o vídeo:Craftsmanship and Ethics

E então, ainda tocando os tambores?

Capital de Risco para projeto Open Source

2009-02-19T10:08:00.001-03:00

Dica super interessante!
Que tal criar um business plan de um projeto curto e opensource, e concorrer a uma grana?
Bem, essa é a ideia de Mark Cuban, que promete criar um modelo de investimento para projetos opensource.

Sua ideia consistem em receber projetos promissores (postados publicamente em seu blog) que esperam ter retorno rápido e consistente. Caso o cara goste, ele vai botar uma grana... e talvez encontrar mais participantes para o projeto.

Leia mais em: The Mark Cuban Stimulus Plan

Regras

1. It can be an existing business or a start up.
2. It can not be a business that generates any revenue from advertising. Why ? Because I want this to be a business where you sell something and get paid for it. Thats the only way to get and stay profitable in such a short period of time.
3. It MUST BE CASH FLOW BREAK EVEN within 60 daysÂ
4. It must be profitable within 90 days.
5. Funding will be on a monthly basis. If you dont make your numbers, the funding stops
6. You must demonstrate as part of your plan that you sell your product or service for more than what it costs you to produce, fully encumbered
7. Everyone must work. The organization is completely flat. There are no employees reporting to managers. There is the founder/owners and everyone else
8. You must post your business plan here, or you can post it on slideshare.com , scribd.com or google docs, all completely public for anyone to see and/or download
9. I make no promises that if your business is profitable, that I will invest more money. Once you get the initial funding you are on your own
10. I will make no promises that I will be available to offer help. If I want to , I will. If not, I wont.
11. If you do get money, it goes into a bank that I specify, and I have the ability to watch the funds flow and the opportunity to require that I cosign any outflows.
12. In your business plan , make sure to specify how much equity I will receive or how I will get a return on my money.
13. No mult-level marketing programs (added 2/10/09 1pm)

Alguma idéia?

[]s
Victor

Succession na InfoqBrazil

2009-02-10T15:24:00.003-02:00

Saudações...

Não sei ao certo se as pessoas que leêm este blog(ou liam - estou muito vagal ultimamente), leêm também o infoq Brazil...

O site gringo começou com uma discussão muito bacana sobre o último assunto de Kent Beck (veja a notícia em inglês).

Bem, repliquei a notícia no site brasileiro, e convido a todos para se juntarem à discussão:Veja a notícia

TOP 25 Most Dangerous Programming Errors

2009-01-13T21:38:00.003-02:00

Saudações a todos!

Voltando de férias esta semana me deparei com um documento MUITO importante para a comunidade de software mundial, resultado do encontro de inúmeras empresas de segurança e autores conhecidos da área em Washington/DC, esta semana.

O encontro visou chegar a um consenso sobre quais seriam os principais erros cometidos no desenvolvimento de software e que possuem o maior impacto na segurança das aplicações web. Bem... a discussão não foi tão intensa, e foi relativamente fácil chegar ao número acima: Os Top 25 (sql injection, code injection, xss e muitos mais).

Bob Martin é o portavoz do documento, e apresenta sua versão sobre a criação. Segue uma pequena parte do texto de introdução:

(January 12, 2009) Today in Washington, DC, experts from more than 30 US and international cyber security organizations jointly released the consensus list of the 25 most dangerous programming errors that lead to security bugs and that enable cyber espionage and cyber crime. Shockingly, most of these errors are not well understood by programmers; their avoidance is not widely taught by computer science programs; and their presence is frequently not tested by organizations developing software for sale.

Leia o Documento Completo

De forma bem humorada, o catálago apresenta a descrição dos erros e como utilizar patterns para mitigar tais riscos. Confira em: http://cwe.mitre.org/top25/

Para constar, os envolvidos:

Robert C. Seacord, CERT
Pascal Meunier, CERIAS, Purdue University
Matt Bishop, University of California, Davis
Kenneth van Wyk, KRvW Associates
Masato Terada, Information-Technology Promotion Agency (IPA), (Japan)
Sean Barnum, Cigital, Inc.
Mahesh Saptarshi and Cassio Goldschmidt, Symantec Corporation
Adam Hahn, MITRE
Jeff Williams, Aspect Security
Carsten Eiram, Secunia
Josh Drake, iDefense Labs at VeriSign, Inc.
Chuck Willis, MANDIANT
Michael Howard, Microsoft
Bruce Lowenthal, Oracle Corporation
Mark J. Cox, Red Hat Inc.
Jacob West, Fortify Software
Djenana Campara, Hatha Systems
James Walden, Northern Kentucky University
Frank Kim, ThinkSec
Chris Eng and Chris Wysopal, Veracode, Inc.
Ryan Barnett, Breach Security
Antonio Fontes, New Access SA, (Switzerland)
Mark Fioravanti II, Missing Link Security Inc.
Ketan Vyas, Tata Consultancy Services (TCS)
Lindsey Cheng, Ian Peters and Tom Burgess, Secured Sciences Group, LLC
Hardik Parekh and Matthew Coles, RSA - Security Division of EMC Corporation
Mouse
Ivan Ristic
Apple Product Security
Software Assurance Forum for Excellence in Code (SAFECode)
Core Security Technologies Inc.
Depository Trust & Clearing Corporation (DTCC)
The working group at the first OWASP ESAPI Summit
National Security Agency (NSA) Information Assurance Division
Department of Homeland Security (DHS) National Cyber Security Division

Ferias!

2008-12-10T14:48:00.001-02:00

Desculpem a demora em responder...
Feliz entrada de anos pra todos! Estou de ferias!

TDC 2008: Download das Apresentações

2008-12-06T10:14:00.003-02:00

Saudações!

Globalcode & VOffice disponibilizaram as palestras do TDC 2008 Floripa. É a change de ver as apresentações... inclusive a minha (novamente...). Confira!

Existem também algumas fotos do evento no picasa (Faltaram as fotos do papo de bar... mas tudo bem... ). Confira tambem!

TDC 2008: Integração Contínua

2008-12-01T21:46:00.004-02:00

Saudações!

Gostaria de disponibilizar a minha apresentação, realizada no TDC 2008 Floripa.

TDC2008 Integração Contínua

View SlideShare presentation or Upload your own. (tags: continuous agile)

Uma pequena transcrição da palestra:

Vamos falar de Integração contínua e os benefícios da automatização de build
Eu? Eu sou o victor! Um pouco sobre mim...
Agenda da apresentação
Tudo começa com as origens: tradicionalmente, o momento de integração era a realização de um grande passo no projeto - juntar tudo - e obviamente que, na teoria, a vida é sempre bela!
Minha percepção desse modelo, inclusive ensinado nas universidades por essas bandas: O Mais puro conto de fadas! Com direito a vestido esvuaçante, sapatinho de cristal e castelo ao fundo.
Como em todo conto de fadas, acreditamos em uma série de premissas, e a principal delas é: nossos clientes estão dispostos a esperar por resultados apenas no longo prazo. Qualidade nunca é importante o suficiente (afinal, se houver tempo, pode cortar os testes).
Mas a realidade é sombria, e extremamente dura com akelas que entram no mercado de trabalho: riscos sempre são subestimados, retrabalho em um Pattern, atrasos uma constante
Precisamos nos preparar para um mundo novo, onde Clientes não podem e não querem esperar por software. E para isso, precisamos eliminar desde as primeiras fases de um projeto riscos com integração de software. É necessário também estar preparado para realizar mudanças rápidas, e responder às interpéries e baixas do mercado. E por último, e conseguirmos reduzir custos de produção, com certeza estaremos mais preparados.
Se conseguíssemos reunir: Velocidade para atendimento de requisições de um cliente, Qualidade para evitar que decisões de hoje não alterem as decisões de amanha, além de recolher informações para a tomada de decisão, chegaremos a:
Valor de Negócio. Perceptível pelo cliente: respostas rápidas às mudanças, alinhamento com as necessidades do negócio e satisfação
Trocando em miúdos, é necessário criar um Botão Virtual, que nos possibilite entregar, rapidamente, valor ao cliente.
Isto é integração contínua
Representação Grafica do processo
Citando as principais etapas do processo: Construção, Testes, Inspeção e Feedback
Construção: normalmente confundido com o próprio termo de Integração Continua. Representa a automatização da construção do sistema, utilizando normalmente uma ferramenta de script (ant ou maven)... (por causa desse slide, o motivo do primeiro slide - essa a automatização em si - integrando todas as ferramentas citadas nessa apresentação)
Pausa para uma reflexão: Esqueca TODA esta apresentação se você não utiliza controle de versões... não caia nesse erro: CONTROLE DE VERSÕES É PRIMORDIAL!!! Saia da idade da pedra! Páre de guardar HD's antigos ou código fonte zipado
Testes: Sim, devem existir! É irresponsabilidade profissional não existir testes unitários automatizados para cada linha de teste! Neste ambiente, não fala-se apenas de testes unitários: aceitação, performance, integração, carga... IC significa mitigar riscos criando um ambiente de testes para garantir que sua base de código é confiável
Pra não ficar por menos, algumas ferramentas!
Inspeção: Tradicionalmente existe um problema em criar equipes independentes de qualidade/teste e desenvolvimento. Imagine o seguinte exemplo - você está lah no bem bom com a patroa e um cara do lado te dizendo "Não cara, não é assim, mais pro lado... isso não estava no roteiro, vc não pode colocar esta perna aí, é para o outro lado...". Para resolver este problema, podemos nos valer de anos de estudo de autores e desenvolvedores e buscar formas de mensurar qualidade de código através de métricas conhecidas, e através de ferramentas
Mais ferramentas: Você se acha bom desenvolvedor? Então execute o CPD no seu código, e depois conversamos! Com estas ferramentas, a própria aceitação dos desenvolvedores será influenciada: não é o zé mané da qualidade falando, é uma ferramenta... normalmente a impressão é melhor...
Imagine aplicar os conceitos de Business Intelligence para software? Cria-se assim a Software Itelligence, tomada de decisão através de dados concretos, acompanhados desde o início do ciclo de vida do produto, para que se possa tomar decisões a respeito do software utilizando cobertura de código, comportamento de testes, avaliação de duplicidade de código, avisos do compilador... muito mais acertivo que os achismos de especialistas...
Como reunir tudo isso?? ora! ferramentas de feedback... segue uma pequena lista...
Referencias
Obrigado!! Obrigado pela oportunidade
Dúvidas...

E então, você foi na apresentação e gostou??? Faça um comentário! Preciso do feedback para poder melhorar...

O evento foi muito bacana! Alta qualidade, pessoas interessantes e muita diversão!

Obrigado Globalcode e VOffice pela oportunidade! Ao final do evento ainda rolou um Papo de Boteco... coisalinda de Deus!!

[]s!!

The Developer's Conference 2008 - aí vou eu!

2008-11-26T00:47:00.002-02:00

Saudações!
Informações de última hora: O Bocão (vulgo Henrique Oliveira) me convidou para falar um pouco sobre Integração Contínua no evento deste final de semana aqui na ilha... e claro, eu topei!

Site Oficial: The Deveoper's Conference - uma realização Globalcode & VOffice

Vou tentar passar a mesma idéia que a apresentação feita no GuJavaSC deste ano, focando bastante no conceito por trás de todo o processo de integração contínua, e apresentando algumas ferramentas. Será uma apresentação rápida, e portanto, nada de muito blablabla ou piadinha... direto ao ponto...

Mais informações na Programação do Evento (sim, eu sei, meu nome não aparece ali... espero que atualizem logo...). A grade do evento está bastante interessante, vale a pena conferir!

[]s

Blogrool... in a roll...

2008-11-18T23:08:00.003-02:00

Saudações, mas uma vez estava sumido, deste de o lançamento do infoqBR (que preciso me dedicar mais a ajudar os demais editores)... mas vamos atualizar com o que tenho lido nos últimos dias:

O post mais comentado dos últimos tempos:

The Decline and Fall of Agile, por James Shore. O cara resolve fazer uma interessante reflexão: estaria Scrum nos levando para o buraco?? Apresentando vários motivos, o post tenta ser super convincente com a opinião de que Scrum está sendo mal interpretado... e eu concordo! Esquecemos o principal: inspect and adapt.
Como não poderia deixar de ser, a comunidade respondeu em peso ao post: (infoQ_br, o Philip Calçado, o Mueller, e muitos outros)
Uncle Bob tratou de jogar os cachorros contra essa idéia, num post bastante agressivo e mostrando o outro lado da moeda: é muito fácil culpar o scrum, virando as costas para o principal: nossa preguiça em produzir softwares melhores
Concordo com ambos! Ambas as posições são baseadas em fatos que vemos muito hoje:

Scrum ampliou a discussão sobre métodos Ágeis
Scrum criou uma indústria de certificação copiando TODAS as demais ferramentas/processos/metodologias
Equipes idiotas ou ingênuas ainda acreditam que Scrum é uma bala de prata
Nem com XP é possível fazer softwares perfeitos!!
São os princípios, e não os métodos, que decidirão sobre a sobrevivência dos projetos

Aconselho acompanhar a discussão em ambos os posts, realmente muito instrutivo.

Depois disso, mais um desabafo: Boris cria um pequeno post criticando "nossa" obcessão por ferramentas de ticketing, spreadsheet ou quadros virtuais de tarefas... segundo ele, sua equipe nem ao menos utiliza estimativas! E o único burndown utilizado é o Feature Burndown (porque, no final, o que realmente importa é o cliente satisfeito com as funcionalidades! )...

Boris chama a atenção para uma necessidade muito mais importante por ferramentas: facilitar a colaboração. Seja com salas de video conferência mais dinÂmicas, um iPhone de tamanho A4 que permita colaboração distribuída, ou um quadro multitouch que nos permita desenhar... essas são as ferramentas que equipes Ágeis precisam!

Ótima notícia: Scrum Gathering 2009 no Brasil!! Cidades que estão sendo consideradas: Recife e São Paulo... informação importante: este não será um evento muito grande, dada a principal característica do evento: a participação! Isso quer dizer apenas os primeiros inscritos terão acesso ao principais autores do mundo para conversar e trocar informações sobre scrum e desenvolvimento ágil... O aXmagno criou uma enquete na lista Scrum-brasil para falar mais a respeito, e selecionar a cidade sede do evento. Confira!

O Rafael Mueller disponibilizou dois vídeos do Google Tech Talk em seu blog: Clean Code Talks!! (tá bom, nao eh esse o nome da palestra, mas nao podia perder o trocadilho)

Por enquanto é isso...

até mais!

InfoQ Brasil: Ready to fly!

2008-11-02T19:51:00.004-02:00

Saudações a todos!

Este fim de semana, novamente, estive em são paulo. Só que desta vez foi para participar do lançamento oficial da versão brasileira do site InfoQ, a qual sou um dos editores.

Iniciamos com a apresentação do Floyd (não o Pink, o Marinescu, CEO e fundador da InfoQ), apresentando a história do site, os valores da empresa e passando a vez para a Fratech, que é a parceira InfoQ no Brasil. Achei demais a apresentação do cara: o site é formado não por jornalistas, mas por especialistas nas áreas, que gostariam de divulgar e trocar informações. Todo o conteúdo é produzido comunitariamente. Do povo para o povo. =)

O evento foi muito bacana, destaques da vez:

Akita: ótima apresentação, o cara é muito fera... aproveitou para falar de Ruby e Agilidade, e de que maneira as comunidades OpenSource, Agile e Ruby se interligam, e como tudo isso é o celeiro de pessoas "acima da média" no mundo da computação. Tenho a apresentação do cara, vou pedir autorização para disponibilizá-la.
Alexandre Gomes: falando sobre SOA, o dono da Sea Tecnologia, pra variar, fez a apresentação mais divertida do encontro. Moral de toda a apresentação: o que importa são os princípios, a evolução contínua e gradativa, e principalmente: as pessoas! (acho que preciso de um mac... pra fazer apresentações que nem as desses caras...)
Painéis sobre Sistemas Distribuídos e Agilidade. Pessoas experientes, ótima discussão!
Lançamento do Livro Scrum e XP direto das Trincheiras, traduzido por algumas pessoas da comunidade (eu inclusive), organizado por alguns na Sea Tecnologia. Veja o resultado!

Participei do Painel sobre Agile, foi divertido, mas gostaria que mais pessoas estivem lá para questionar, criticar e discutir sobre... não tem problema, logo teremos mais!

No final, claro, um pouco de cerveja pra comemorar e aliviar os ânimos!

É isso! Parabéns Fratech pelo lançamento do site!

Aproveite mais este canal!!

[]s

Falando em Agile: Antonio Carlos Silveira

2008-10-28T18:09:00.003-02:00

Antonio Carlos Silveira, um dos mais novos gerentes do Yahoo! Brasil, apresentou uma palestra com o tema O Product Owner e o Product Backlog. Pra variar, ele também é um dos caras que já trabalhou na Globo.com, e que ajudou a empresa a utilizar Scrum, tornando-se o maior case de utilização no Brasil. Minha impressão: a melhor palestra do evento

Tudo começa com uma brincadeira muito boa. No dia anterior, o Guilherme Chapiewski apresentou um pouco da atuação dos líderes Ágeis na Globo.com e é claro, mantendo a imagem de uma empresa massa pra caramba!(Foi muito massa a palestra, logo escrevo um pouco sobre ela).

Mas, mantendo seu compromisso principal com a verdade, o Antonio Carlos mostrou como é realmente o trabalho na Globo.com: A competitividade é acirrada!!

A intenção da apresentação era realmente esclarecer o conceito de Product Owner, e o artefato Product Backlog do Scrum. O nome em si não importa, mas os princípios por trás dos papéis e dos artefatos.

Alegoria interessante:

Uma equipe Scrum é formada por:

Darth Vader - Scrum Master - O protetor do processo
Stormtrooper Crew - Equipe - Responsável pela qualidade
Indiana Jones - Product Owner - Vem de uma cultura de chicotada (normalmente um Product Manager)

Tradicionalismo x Agilidade - De onde viemos e Para onde vamos

Tradicionalmente, principal missão de um Product Manager era se antever e prever futuro. Mas Por quê? A fórmula é simples:

Se antecipar aos acontecimentos de um projeto pode reduzir incertezas
Reduzindo incertezas provavelmente diminuirá a quantidade de Change Requests
Como Change Requests são caras, reduzir sua ocorrência certamente diminuirá o custo do projeto

Surge a figura de um Product Manager carrasco, que não se importa com a saúde das equipes que trabalham para ele, e está mais preocupado a cumprir um cronograma custa o que custar.

Não existe, neste ambiente, uma preocupação em adaptar-se à mudança, mas em restringir a mudança. Antecipar-se é o principal foco deste modelo, mesmo que o nosso mundo esteja seguindo na direção contrária. AC atribuí a isso uma espiral negativa dentro das empresas: setores de tecnologia querendo restringir mudanças devido aos custos elevados, e os setores de marketing buscando adaptar os produtos aos mercados.

Este é o principal motivador para o crescimento de métodos Ágeis. Assim, o que queremos é a agir rapidamente a qualquer Request de mudança. Ao invés de criar procedimentos para restringir mudanças, precisamos abraçar as mudanças adaptando-se o mais rápido possível.

O Product Owner

O papel do PO primeiro de tudo é: Ele precisa entender o Cliente Ele precisa responder às seguintes perguntas:

Qual o seu Target ?
Quem é o seu público alvo?
Quais são as personas? (dica do Danilo Bardusco)
Quem se quer atingir?
Por que um cliente gastaria dinheiro com o seu produto?

Além disso também, o cliente é uma Ponte entre os Clientes e o Time, inclusive na hora de buscar mais informações quando seu conhecimento do domínio do problema não é completamente compreendida. Assim, ele facilita o contato entre o Business e o Desenvolvimento.

Existe sempre uma tenção entre este PO e a equipe. Em métodos Ágeis, TUDO é baseado em confiança. E qual o paradoxo desta realidade: estamos num mundo em que confiamos muito poucos uns nos outros, e desenvolvimento Ágil para funcionar precisa muito de confiança.

Espiral negativa da vez:

PO não confia no time, porque normalmente não recebe o que solicita. Assim, o que ele faz? Atola a equipe de solicitações, na esperança de ganhar alguma coisa "do balaio"
A equipe sabe que o PO vai pedir mais do que eles conseguem produzir. Como sair dessa? Estimar cada vez mais tempo para completar as tarefas...

É isso que precisa ser mudado para que um ambiente ágil seja produtivo. Transparência é a palavra de um projeto Ágil. Inclusive, para que se entenda melhor essa alegoria. Imagine um projeto scrum como um barco: Se ele afundar, vai todo mundo pro buraco.

O PO pode ser técnico? Não necessariamente. Primeiramente, o PO precisa entender a equipe: sua capacidade de produção. Precisa entender que não é apenas empurrando trabalho para a equipe que mais software vai ser entregue. O Danilo Bardusco já escreveu sobre isso.

É necessário criar um ciclo virtuoso em que:

O PO entender as necessidades de esclarescimento da equipe.
Estimula a equipe no limite, para que ela consiga se comprometer e produzir o melhor produto. Tendo orgulho do que faz.
Sabe que um número, que a preocupação apenas com produtividade não trará o resultado esperado.
Trás um ponto de vista para a equipe que agregue valor para a equipe

PO: Cria a Visão

O PO precisa pintar uma imagem bonita, para onde todos da equipe queiram seguir. Dois exemplos foram citados: Disney e Mirosoft. A primeira empresa cria uma Visão única, que guia todos da empresa, e é um dos motivadores de seu sucesso:
We create happiness by providing the finest in entrertainment for people of all ages, everywhere

Na criação desta Visão, o Product Owner deve estar preocupado em conquistar a equipe como um todo. E para isso a visão deve ser:

Compartilhada e compreendida por todos
Deve criar o desejo na equipe em fazer parte desta conquista
Deve ser clara e concreta
Deve ser difícil de ser alcançada, mas não impossível

Você é o product owner de um projeto? Qual a visão do seu software? e a equipe, entende essa visão?

PO: Entende o domínio do Problema e da Solução

Deve ser a referência sobre o Domínio do problema. Ele deve ser o ponto focal para a equipe, quando ela estiver em dúvida. E pra isso ele deve ter poder de decisão.

Receita para o fracasso:

Um product Owner que nunca decidiu nada. Criando a "Síndrome para o PO Mensageiro": Se para tomar qualquer decisão o PO precisa se comunicar com alguém para pedir a opinião, o problema está formado. Quais as consequências disso?

Equipe vai desconsiderar o papel do PO, indo diretamente à pessoa que decide.
O Time passa a tomar decisões. Se sentindo no direito de tomar as próprias decisões sobre o produto.

É necessário que o PO imponha respeito à equipe. Tudo que está sendo dito aqui é sobre pessoas, e a interação entre elas. Esqueça ferramentas! O que importa é a relação entre esse as pessoas, a maneira como você interage com elas. Comunicação Oral é o principal! Lembre-se disso: ferramentas não vão substituir o sucesso da interação pessoal entre as pessoas. (Repetitivo? náá)

Além disso, é obrigação do PO aceitar o que for produzido pela equipe. Para isso:

Deve estar presente para esclarecer dúvidas (deve estar próximo)
Deve avaliar o que for produzido

Aqui, o AC indica um estudo bastante interessante: A universidade de Michigan descobriu (há quase 10 anos), que equipes multiciplinares juntas produzem mais que o dobro do que equipes separadas por salas, predios, etc. Leia a notícia

Nota importante: é o PO que organiza o Release Plan para o produto. Ele que encontrará o melhor momento para lançar uma versão nova do produto.

PO: Responsável pelo ROI

Sim!!! Retorno sobre investimento!

É o foco do PO! Normalmente relacionado a dinheiro. Mas não necessariamente o dinheiro em si. Acima de tudo, ROI deve estar ligado a um objetivo mensurável:

Dinheiro
Audiência
Satisfação do Cliente
Fidelidade

PO: Responsável pelo Product Backlog

Resumindo o que apresentamos acima: O Product Owner tem como função?

Entender o Cliente
É o elo de comunicação entre os Clientes e a Equipe
Entender do domínio do problema e principalmente possui o poder de decisão sobre o projeto
Aprova/Rejeita o resultado do Sprint
Responsável pelo Release Plan
Responsável pelo ROI
Responsável pelo Product Backlog

Lembrando que: Product Backlog é uma lista priorizada (em qualquer mídia) e ordenada com coisas que trarão algum benefício para o usuário.

Como descrever itens do backlog? User Stories!

AC ainda explicou sobre a profundidade na elaboração do Product Backlog, já explicado na apresentação: 10 ways to screw up with Scrum and XP. (Numa imagem muito bonita: 3D, tons pastéis, Estrelinha e um "r" no logo!)

O que define um bom Product Backlog?

Está Planejado adequadamente para os próximos 3 Sprints, ajudando o time a ter uma visão maior sobre para onde estão indo.
Sempre priorizado. Para que a equipe consiga escolher sempre o item mais prioritário
Sempre visível: Isso trás transparência
Deve ser mantido pelo Produtc Owner (não é função da equipe priorizar o Backlog)

Priorização

Foram citados os modelos de priorização:

Kano Model
Benefício Relativo
Modelos Financeiros
- VPL
- TIR
- Payback

Principal Bibliografia Ágil sobre o assunto: Agile Estimating and Planning por Mike Cohn

No Modelo de Kano, deve-se categorizar o product backlog através do valor percebido pelo cliente. Em três categorias:

Must-have: Obrigatórios (Um hotel deve ter cama)
Linear: Quanto mais melhor (Cerveja grátis no quarto do hotel - ótimo )
Exciters: Necessidades não conhecidas (TV de LCD 42'' no Quarto - ótimo, mas não faz tanta diferença)

Para cada item do Backlog, faça duas perguntas:

Funcional: O que vc acha de ter uma Latinha de cerveja de graça no quarto de hotel, quando vc chegar?
Disfuncional: Se você chegar num hotel e não tiver uma latinha de cerveja de graça no quarto, o que vc acha?

No método de Benefício Relativo é necessário, primeiramente, que as estórias estejam estimadas. Após isso, preencha a seguinte tabela:

	Benefício em ter	Penalidades em não ter	SUM(BV)	Estimativa	BV/Est
Funcionalidade 1	1	9	10	2	5
Funcionalidade 2
Funcionalidade 3
Funcionalidade 4

A Ordenação se dá pela coluna BV/EST

Mesmo sendo um método bastante interessante, em sua experiência, Antonio acredita que no final é o chutão que conta. A Utilização de personas pode ajudar bastante.

É isso... Esses relatórios estão ficando bastante extensos... mas espero ter passado a idéia da apresentação... aos que não assistiram...

Antonio: Parabéns pela apresentação!

(Acompanhe as impressões dele sobre o evento, além inúmeras referências)

Tomei a liberdade de adicionar neste blog os slides da apresentação (sem autorização, desculpe!). Aproveite:

Falando Em Agile 2008: Product Owner and the Product Backlog

Lançamento InfoQ Brasil - 01/11/2008

2008-10-27T19:30:00.004-02:00

Saudações!

Este final de semana estarei em São Paulo para prestigiar do lançamento da versão brasileira do site InfoQ, conduzido pela Fratech

Junto com o Manoel Pimentel, vamos tentar passar um overview sobre o material que será possível encontrar no site, tentando - claro, estimular a curiosidade dos participantes a acessarem site, ampliando a comunidade brasileira ligada a desenvolvimento de software como um todo.

Encontro você lá!
[]s

Falando em Agile: A melhor metodologia de todas!

2008-10-27T16:19:00.002-02:00

Por Rodrigo Yoshima, a melhor metodologia de todas!

Se você quer manter sua equipe sempre motivada, estimativas perfeitas e 100% de cobertura de código, Seus problemas acabaram! AR15 Neles!

Falando em Agile: Danilo Sato e Francisco Trindade

2008-10-27T15:49:00.002-02:00

Danilo Sato e Francisco Trindade, ambos brasileiros e consultores da ThoughtWorks, fizeram uma apresentação bastante interessante: Em sua experiência trabalhando só com "bucha" (sim, vida de consultor nessa empresa não é moleza) a intenção era apresentar alguns anti padrões na implantação de métodos ágeis, que normalmente ocorrem. Pode parecer simples, mas Agilidade é uma questão de coragem e atitude.

Adendo: A ThoughtWorks é uma empresa cuja missão é: Revolucionar a Indústria de Software (Otimista? não! Desafiador!)

A apresentação inicia com o Danilo descrevendo um fator crucial na adoção de métodos Ágeis: pessoas . Pode ser um modelo completamente novo, é necessário uma mudança cultural bastante grande, fato normalmente ignorado, o que gera muitos problemas.

Agile Implementation Anti-Patterns

Agile de malandro

Ótima comparação! É a personificação da maior mal entendido relacionado a métodos Ágeis, descrito maravilhosamente no Dilbert:

Neste anti-pattern, apenas os métodos "fáceis" são incorporados, e normalmente interpretados incorretamente:

Agile não se preocupa com documentação, então não escrevemos nenhum documento
Testar é difícil, então só vamos testar os itens mais simples
Refatorar? não... é muito difícil... já sabemos que está funcionando
Entregar software, claro! O cliente pede e logo ele recebe... sem preocupação nenhuma com qualidade já que entregar é o que importa

Lembre-se: Agile é, acima de tudo, sobre disciplina e trabalho duro. Num processo Ágil é muito mais fácil de quebrar a cara. Enquanto num processo tradicional você pode esperar 6 meses por uma versão num software, com métodos Ágeis em 1 ou 2 semanas, você precisa entregar algo.

Caso isso não aconteça, você terá decepções bastante frequentes, já que não existe preocupação com a série de princípios por trás dessa "abordagem ágil".

Agile by the Book

No início da implantação de métodos Ágeis, todos nós buscamos uma receitinha de bolo que nos permita usufruir de todo o proder de XP, Scrum, DSDM, Cristal, etc... E lá está você, implantando todas as práticas do livro eXtreme Programming. Mas isto não será suficiente, já que as práticas de um livro, mesmo que te levem a uma melhoria significativa, não possuem conteúdo . É necessário incorporar toda a filosofia de melhoria contínua por trás das práticas, para que se possa ir além. Receitas de bolo ajudam bastante no início da adoção, mas não devem ser encaradas como dogmas. Os princípios é que são importantes! Os princípios.

Equipes Burrocráticas

Não adianta apenas dizer que "somos ágeis", entregando software em uma semana, se estamos todos presos em silos:

Desenvolvedores escrevem código
Testadores, longe dos desenvolvedores, verificam erros no software
Desenvolvedores não querem interagir com o cliente, ouvir suas necessidades

Desenvolvimento Ágil não é apenas uma mudança de processos, mas sobre mudança de cultura. É uma mudança radical na forma de enxergar o desenvolvimento de software: colaboração, participação, respeito, trabalho em equipe... Fechados em silos, nos esquecemos do principal objetivo com o desenvolvimento de software: entregar software . Assim, trabalhamos em objetivos completamente diferentes: desenvolvedores querem o melhor software O principal fator de sucesso em métodos Ágeis é a multidisciplinariedade . É necessário quebrar o paradigma verticalizado: reuna as pessoas!! Foque no Cliente!!

E a velocidade?

Dar valor demais à velocidade como uma medida de performance, causará comportamentos disfuncionais em sua equipe. Normalmente, a equipe trabalhará para mostrar ao gestor o tão sonhado número mágico , esquecendo-se do foco de projetos ágeis: interação entre as pessoas, satisfação do cliente. Assim, o incentivo será o incorreto!

A intenção da velocidade é apenas uma ferramenta para ajudar na estimativa e previsibilidade. Assim, caso "cair a velocidade" possa ser inaceitável para um gestor, a equipe facilmente deixará de lado práticas engenheiristicas de qualidade, gerando software meia-boca. Alem disso, perde-se o valor de Refactoring para seu projeto, que é fundamental para manter a saúde de um sistema. Importe-se com a qualidade , e não com as burocracias. Isto fará sua aplicação perpetuar.

Definição incompleta de "Pronto"

Vindo de outros modelos, esta definição não é normalmente ligada ao valor de negócio que um software deve gerar. Em métodos Ágeis é necessário além de escrever código, escrever os testes automatizados, alguns de aceitação, gerar um pacote para ser implantado no servidor de aplicação e apresentado no cliente para que ele avalie. Somente neste momento uma funcionalidade é tida como Pronta

Num projeto, é preciso existir esta definição. E ela deve estar bastante clara para todos da equipe. Mais informações.

E o que a gente faz com o cliente?

Na visão do Francisco, ser o cliente é o papel mais difícil. Principalmente pelo fato de que é necessário compreender todo o domínio do problema: a entidade perfeita . Nesta visão, seguir todas as intenções e indicações do cliente/Product Owner guiará o projeto ao sucesso. O problema está em transformar esta persona cliente em o dono da verdade, ou deixá-lo sozinho, sem ajudá-lo a compreender o próprio processo de negócio. Normalmente, para algumas funcionalidades, o PÒ não sabe ao certo como será a solução, e por isso é necessário que a equipe, com o conhecimento de software ajude-o a resolver rapidamente seu problema.

Muitas vezes podemos pensar que Software é o centro do mundo, e deixamos a cargo do cliente dar todas as resposta em como produzir software. É necessário colaboração!!

Big Design Up Front

Trazemos vícios de projetos antigos (tradicionais) para os projetos "Ágeis". Assim, algumas vezes, querendo escrever um pouco de documentação sobre o domínio do problema, criamos complexidades completamente desnecessárias. Precisamos nos questionar não apenas se estamos escrevendo certo o software, mas se estamos escrevendo o software certo. (Pense em YAGNI

Backlog Infinito

Pow, legal esse negócio de User Story. Entao, pensa o PO do projeto: vou escrever todas as coisas possíveis de acontecer com o projeto nessa pilha chamada Product Backlog. Na equipe, isto pode gerar um problema. O trabalho em organizar e manter um PBL pode ser bastante problemático. Preocupar-se com um backlog gigantesco trás mais problemas que soluções. Muito provavelmente itens no final da pilha nem serão implementados no decorrer do tempo, e por isso, a equipe não precisa(deve) se preocupar com o que não está no seu campo atual de visão (Sprint)

Agilidade Estacionada

Desenvolvimento Ágil é sobre mudança! É sobre melhoria contínua! Se você está há 3 meses desenvolvendo num projeto ágil da mesma forma, você não está desenvolvendo de forma Ágil. Preocupe-se com as retrospectivas, elas são o mais importante de todo o processo. É SEMPRE necessário refletir sobre como melhorar. Nem que seja um pouco, nem que seja o mínimo.

Bem... muito boa a conversa com os caras. Realmente muita experiência e bastante vontade de compartilhar essa experiência.

Intenção da apresentação:

Ágil é sobre pessoas! Compartilhe, colabore, ouça e faça! Não apenas nos livros, descubre para a sua equipe como trabalhar melhor!

até mais

Falando em Agile: Chegamos

2008-10-24T07:24:00.004-02:00

Saudações!
Em fim, chegamos ao evento... à primeira vista, tudo ótimo... apenas a demora para chegar ateh aqui me desanimou um pouco (fui muito bem recepcionado pelo trânsito paulistano).

O Evento está localizado no centro de evento Hakka, na Liberdade (coisalinda o lugar, tudo muito bem organizado), mas ainda não encontrei nenhum ninja ou gueixa por perto para tirar uma foto.
Ao chegar no evento, um pouco dos shows do Live8 London... 'chique no último'

Criei um pequeno album para o evento, apresentado aki neste post.... acompanhem as novidades por ali.

Pra começar o evento, a trilha sonora: Queen! Creeedo! Não é qualquer evento que começa com Bohemian Rhapsody!

O Alexandre Magno faz as honras da casa apresentando o evento e sua motivação para a realização do Falando Em Agile. Gostei muito de seu ponto de vista:
"Não sejamos como um adolecente que só gosta de uma banda porque ela é desconhecida... hoje em dia se fala muito em Agile, e por estar 'na moda' ser Ágil, vamos aproveitar esse momento para conseguir a mudança que tanto queremos em nossas empresas"

Hora, se Scrum é a Buzzword do momento, ótimo! Utilizemos esses 15 minutos de fama para divulgar princípios e práticas Ágeis!

Cara, tem muita gente conhecida por aqui... logo coloco mais informações...

Primeira apresentação do dia: DAvid Anderson

Até daqui a pouco!

Falando em Agile: David Anderson

2008-10-24T08:26:00.004-02:00

David Anderson é um dos criadores do FDD, além de ser o autor de livros como Agile Management for Software Engineering e é o bacana por trás do site Agile Management.net.

O título/motivação da Palestra: How to be successful with Agile Teams

David começa fazendo uma rflexão interessante: será mesmo que somos tão espertos assim?
Vivemos numa cultura de desenvolvimento de software em que trabalhar demais é sinônimo de ser bem sucedido, em detrimento inclusive de sua vida social. Fica a dúvida no ar:
"Working harder rather than smarter" (pois é, não precisa ser assim... )
Normalmente projetos de software são sinônimo de trabalhar horas seguidas, sem dormir, resolvendo problemas com o projeto. E claro, normalmente a culpa é da equipe: desenvolvedores desajustados que não sabem trabalhar direito! shame on us!
Não deve ser assim!

Nota interessante: Barry Boehn, estudou "milhares" (sera?) de projetos e concluiu que:
Gerenciamento pobre pode ampliar os custos de um projeto de software imensamente mais rápido que QUALQUER outro fator (!!!)
Significa dizer que, normalmente, gerentes não são os principais responsáveis pelos problemas do time: atrasos, falta de comprometimento, falta de iniciativa, pouca maturidade em resolver conflitos e por aí vai...

Segundo David, um gerente do Starbucks trabalha imensamente melhor que qualquer gerente de software (!!). Pois ele conhece o negócio da empresa, tenta influenciar de maneira benéfica os seus funcionários, e conhece as atividades que são o foco principal do starbucks (seria isso um desafio? Você, gerente, conhece o que a sua empresa faz?)

Receitinha de bolo para um mundo feliz

Como não poderia deixar de ser, foi apresentado uma pequena receita de como criar um ambiente de sucesso para equipes de software. Portanto, segundo David Anderson, para criar equipes realmente eficazes e bem sucedidas você precisa de:

Focar em Qualidade

Reduzindo a quantidade de trabalho "em andamento"

Balancear a demanda de acordo com a capacidade

Priorizar

Se tudo der certo, você ainda ir para o próximo nível de ultra mega maturidade:

Remover a variabilidade no processo

Então vamos lá, explicando os itens:

Focar em Qualidade

Cara, pode parecer que todo mundo sabe disso, mas é mentira!!! Ninguém foca em qualidade, e isso é frustrante! "Ah, nosso projeto é focado em qualidade, mas não se preocupem, logo vocês terão tempo para produzir testes automatizados..." bulshit!
(ok, voltando)

Para os gerentes: Deêm permissão para sua equipe trabalhar com qualidade
Parece estranho? Mas não é... que tal permitir à sua equipe construir softwares sem bugs. Pergunte-lhes o que eles precisam para isso!

Segundo Peter Drucker, todo trabalhador do conhecimento é um executivo! Temos, como desenvolvedores, que tomar muitas decisões, que irão afetar o rendimento de sua empresa!!! Como assim??
Imagine uma equipe construindo um sistema... mas sem testes, e com poucas práticas de qualidade de software. Bem, na hora de desenvolver, um programador toma a decisão de não gerar um teste automatizado para uma funcionalidade nova.

Após 6 meses de desenvolvimento, um problema ocorre no software, em decorrência da decisão do programador. Sua empresa terá problemas! E problemas com dinheiro!!!
Pergunte-se o por que as funcionalidades de um sistema demoram cada vez mais para serem desenvolvidas, e perceberá que, normalmente, existe uma baixa preocupação com qualidade! E o pior: não precisamos testar, afinal de contas, o cliente precisa da funcionalidade pra ontem. Como o Marcio Marchini sempre diz: "pay me now, or pay me later"
Permita aos seus desenvolvedores fazerem a coisa certa. Qualidade não se discute
Chegar ao numero ZERO de defeitos num sistema é impossível, mas QUASE zero é perfeitamente factível. Faça com que seus desenvolvedores e testers tenham orgulho do que eles produzem! Dê uma chance à Qualidade

Crie a mentalidade "Stop the line": No momento em que problemas acontecerem eles devem ser corrigidos!

Introduza a mentalidade Test First em todas as fases de desenvolvimento, inclusive em entrevistas. Que tal criar um Exit Criteria para suas reuniões de levantamento de requisitos?

Crie uma definição de "Done" e defenda isso dentro de sua organização.

Para o primeiro estágio está bom... continua logo..

Reduzindo a quantidade de trabalho "em andamento"

Imagine um malabarista: quanto mais itens ele precisa equilibar ou jogar para o alto, maior é o risco de um acidente. O mesmo ocorre em nossos projetos.
Trabalhar em muitos itens ao mesmo tempo amplia a complexidade do projeto, e por isso existe uma enorme chance de algo dar errado. O Guilherme já escreveu algo a respeito disso em seu blog.

Quanto mais trabalhos InProgress, maior é o índice de defeitos, logo: lute contra isso!

Então, o David apresentou dois gráficos: o primeiro contendo uma equipe que trabalha minimizando a quantidade de trabalhos em andamento ao mesmo tempo, e outra equipe que não faz isso...
Segundo o cara, ele possuí vários outros estudos iguais, mas o resultado é sempre o mesmo: atrasos e um Bug rate monstruoso!!! Com uma equipe focando em qualidade e outra equipe sem essa preocupação, a quantidade de problemas no projeto é, normalmente, 30 vezes maior!!! E ai, vai tentar medir isso em sua empresa? Só a reducao de bug jah justifica pensar a respeito.

Como estimular sua equipe a criar Quase Zero defeitos

Meça a quantidade de trabalho em andamento

Integração Contínua

Crie formas de encontrar e informar sobre defeitos aos desenvolvedores de forma rápida e não burocrática

Crie um sistema kanbam para 'controlar seu desempenho/capacidade"

Bem, vou assitir a palestra do Alexandre Magno agora... logo mais continuo