Falando em Agile: Antonio Carlos Silveira

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

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!

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

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: David Anderson parte 2

Continuando de onde parei, mais David Anderson.

No último post, expliquei o ponto de Como estimular 'Quase Zero' defeitos em uma equipe.

Após isso, o David apresentou sua visão sobre Priorização, seguindo a receitinha que ele apresentou no início da palestra.
Para conseguir priorizar corretamente, primeiro é necessário identificar o seu mercado. Citando Michael Poter, identifica-se 3 players diferentes:

• Líderes em custo: Menores preços, maior abrangência. Não necessariamente com qualidade diferenciada.


• Líderes em diferenciação: Possuem itens que os diferenciam completamente no mercado


• líderes em nichos: Atuação em grupos bastante específicos de clientes

Mas como priorizar? Seguindo o Planejamento Estratégico!

Bastante interessante essa abordagem, e a justificativa é: Por que utilizar aqueles diferenciadores comuns de prioridade. MoSCoW?? Prioridade 1, 2 ou 3?? Não né!! É necessário que esta informação seja o mais próxima da realidade do mercado em que o produto se encontra. Por tanto, ao invés das prioridades mais comuns que usamos para as funcionalidades, tente a seguinte abordagem:

• Commodities: Funcionalidades que todos os demais players tem. São aqueles requisitos básicos para o seu produto. Ex: um editor de textos moderno precisa ter a possibilidade de impressão.


• Diferenciadores: Funcionalidades que os concorrentes não possuem. É o crème de la crème da sua aplicação. Lembre-se: normalmente, não é o mais necessário


• Spoilers: Funcionalidades que os outros têm e que você gostaria de ter também. Que tal extrair uma fatia do mercado do concorrente? Esse é o espírito para esta prioridade


• Redutores de custos: Itens que farão você, como empresa, produzir mais e mais barato!

Assim, podemos pensar que, impreterivelmente, Commodities serão produzidos primeiro no seu projeto. E as demais prioridades sendo alocadas à medida que o projeto avança no tempo. Pense a respeito... vou ter colocar isso pra rodar na empresa... vamos ver no que dá.

Segundo David, variação causa muito desperdício, por tanto, também precisa ser combatido. Entenda variação como falta de pradronização nos processos produtivos, falta de comunicação, objetivos não claros ou conhecimento não compartilhado. Como resolver: simples! Agile Neles!!

Práticas para redução de veriação:

• Pair Programming


• Design, Codificação e testes utilizando Peer review


• Trabalho colaborativo com grupos multidispciplinares


• Análise estática e dinâmica de código


• Ciclos rápidos de Feedback, através de Integração Contínua


• Kanbam!!

Bem... este foi o "resumo" da apresentação do David, que também fez um treinamento de 2 dias com alguns sortudos... recebi ótimas e péssimas referencias sobre o curso... pena não ter ido.


Até mais!

Falando em Agile: David Anderson parte 1,5

Só pra sacanear um pouco... a foto tá meio dificil dever, mas para que vcs saibam: Este é o David Anderson dormindo na palestra do Adail... hehehehe
Deve ser complicado assistir uma palestra em portguês...



momento pré palestras, pós almoço

tomando fôlego para mais várias palestras... e para poder escrever sobre o resto do evento...

Falando em Agile: Snacks time!!!

Aproveitei que nao tinha ninguem pulando em cima da comida pelo ultimo pedaço e tirei uma fotenha... sim, coffee break is good!!!!







[]s

Falando em Agile: David Anderson

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


• TDD


• 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

Falando em Agile: Chegamos

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: Sim, estarei lá!

Saudações a todos! Confesso que estou bastante ansioso para participar do evento Falando em Agile. Quero acompanhar bastante de perto o Guilherme e o Danilo apresentando o case de utilização de Scrum na Globo.com... Big Time!

Bem, este é o primeiro post oficial sobre o Evento... espero que seja bom!

Mais informações à partir de quinta feira!

[]s

Revista Visão Ágil - Edição 05

Saudações a todos!!

Sim, demorou um bocado, mas conseguimos!

Nestes últimos meses conseguimos reformular a revista, tentando apresentar ainda mais conteúdo e qualidade para os leitores e para a comunidade Ágil brasileira.

Com a incrível participação do Felipe Rodrigues, que nos ajudou muito com os seus dons artísticos, apresento a todos vocês: Visão Ágil Edição 5

Nesta edição você vai encontrar:

Artigos:

• Confiança: O caminho para a Agilidade
  
• Lean: A arte de eliminar o desperdício
  
• Os 7 pecados capitais de um time Ágil
  
• As 5 doenças do gerenciamento de projetos - Causa 5
  
• Como construir um Backlog Orientado a Negócio
  

Entrevistas:

• Ian Roughley - Líder do projeto Struts2
  
• Marcio Marchini - CTO da Audaces Automação
  

Comunidade:

• Maré de Agilidade agita o Distrito Federal
  

Leia, comente, divulgue!!!

Um abraço e bom proveito!!

Victor Hugo Germano
Editor - Visão Ágil

O que é Creative Commons

Jesse Dylan entrevistou algumas personalidades como Jimmy Wales e Joi Ito para apresentar um conceito "novo": Creative Commons Ideal...

Simples e supremo...

Cansado de Telas de Cadastro?

Que tal então trabalhar com o que existe mais novo relacionado a Java para Desktop? Melhor ainda, podendo ver a Ivy, nossa modelo, em todos os seus ângulos!

Procuramos pessoas que sejam apaixonadas pelo próprio trabalho, gostem de aprender coisas novas e estejam dispostas a criar produtos com máxima qualidade!

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!

Marketing Viral: Um exemplo prático

1) Tenha uma idéia maluca, ou que anda em moda nos últimos tempos. Por exemplo: vender a própria virgindade

2) Escreva sua história absurda. Faça paracer escrito por alguém sem conhecimento literário acadêmico, talvez um jovem que "tecla" muito no msn

3) Faça um pequeno site. Simples, mas agradável ao olhos que use cores simples mas harmônicas: Ajude um Virgem

4) Crie um perfil no Orkut para para dar mais "confiabilidade" à sua história

5) Mande anonimamente para um de seus conhecidos....

6) Aguarde...

O resultado:
Para "perder virgindade", dono de site pede 5 milhões de acessos


Apareça no site da Folha de São Paulo!


Depois disso, procure emprego em uma agência de publicidade...


[]s

Por que projetos de Software falham?

Saudações!

Estes últimos tempos estive estudando um pouco, e encontrei um post bastante interessante do Kelly Waters descrevendo alguns motivos, pesquisados por ele, que são as razões para que projetos falhem... resolvi traduzir e disponibilizar... pq não?

Fonte: Most IT projects fail! Will yours?

Problemas em Inicialização de Projetos & Planejamento

• Foco do Negócio não claro ou não convincente
• Processo de aprovação Insuficiente ou não existente
• Definições pobres sobre escopo e objetivos do projeto
• Tempo ou dinheiro insuficiente para o projeto
• Projetos com falta de responsabilidades
• Planejamento insuficiente ou otimista demais
• Estimativas pobres
• Prazos irreais; forçar datas finais do projeto em detrimento de melhores estimativas
• Falta de preocupação e consciência nas fases iniciais do projeto

Problemas Técnicos & de Requisitos

• Falta de envolvimento do usuário (resultando em problemas de expectativa)
• Product Owner não determinado, ou não disponível
• Inchaço de escopo; falta de controle de mudanças adequado
• Definição de requisitos pobre ou inexistente; requisitos incompletos ou mutáveis
• Escolhas tecnológicas erradas ou inapropriadas
• Falta de familiaridades com tecnologias; falta de habilidades técnicas necessárias
• Problemas de integração durante a implantação
• Testes pobres ou insuficientes antes do nascimento
• Falta de Quality Assurance para entregas chave
• Fase de correção de bugs imprevisível ou longa demais no final do projeto

Problemas na Gestão de Stakeholders & Equipes

• Atenção não suficiente aos stakeholders e suas necessidades; falha ao gerenciar expectativas
• Falta de suporte de um gestor/executivo sênior; patrocinadores do projeto não comprometidos completamente; falta de compreensão do projeto e sem envolvimento ativo
• Visibilidade do estatus projeto inadequada
• Adoção da negação em detrimento de duras verdades
• Pessoas não dedicadas ao projeto; tentativa de balancear prioridades de mais
• Equipe do projeto com pouca experiência e sem habilidades neessárias
• Falta de autoridade da equipe ou falta de capacidade de tomar decisões
  
• Pouca colaboração, comunicação e trabalho em equipe

Problemas em Gestão de Projetos

• Nenhuma boa prática na gerencia de projetos
• Gerenciamento contínuo fraco; gerentes de projetos treinados inadequadamente ou sem experiência
• Relatórios e acompanhamento inadequados; sem revisar progresso continuamente ou com a atenção necessária
• Gestão de prazos e custos inadequadas
• Falta de liderança e/ou habilidades de comunicação

É triste, mas estes itens acima são confirmados pelo Gatner e Standish Group...


E o seu projeto? Já Falhou? Está fadado ao fracasso?? Descreva seu martírio nos comentários... =)