Ferias!

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

TDC 2008: Download das Apresentações

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

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:

1. Vamos falar de Integração contínua e os benefícios da automatização de build
2. Eu? Eu sou o victor! Um pouco sobre mim...
3. Agenda da apresentação
4. 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!
5. 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.
6. 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).
7. 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
8. 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.
9. 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:
10. Valor de Negócio. Perceptível pelo cliente: respostas rápidas às mudanças, alinhamento com as necessidades do negócio e satisfação
11. Trocando em miúdos, é necessário criar um Botão Virtual, que nos possibilite entregar, rapidamente, valor ao cliente.
12. Isto é integração contínua
13. Representação Grafica do processo
14. Citando as principais etapas do processo: Construção, Testes, Inspeção e Feedback
15. 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)
16. 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
17. 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
18. Pra não ficar por menos, algumas ferramentas!
19. 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
20. 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...
21. 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...
22. Como reunir tudo isso?? ora! ferramentas de feedback... segue uma pequena lista...
23. Referencias
24. Obrigado!! Obrigado pela oportunidade
25. 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!

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...

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!

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

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... =)

Scrum Checklist no MindMeister

Estou impressionado!!!
Seguinte a ótima indicação do Rafael Caceres, decobri o MindMeister, ferramenta online para edição de mapas mentais... simplesmente "O" bicho! =)

Então o que fiz? Migrei o Scrum Checklist para a ferramenta! O resultado pode ser visto abaixo ou na página oficial do documento.


Aos interessados em contribuir, é necessário habilitar numa conta no serviço... avisem-me que libero o acesso a vocês... =)


Acesso o Full Link

De uma chance à Qualidade

Aristóteles escreveu que "Qualidade não é uma ação, é um hábito." Mais do que isso, é um estado de espírito. É um ato de consideração e respeito para com aqueles que vão, eventualmente, utilizar o produto ou serviço. É um reconhecimento e a comemoração da integridade, habilidades, valores e eficiencia de seus produtores ou fornecedores. Num nível mais alto, qualidade é a aplicação da Regra de Ouro do trabalho, o reconhecimento de que o produtor É o consumidor, cliente e cidadão; que cada produto e servição são um trabalho de arte, a ser criado com orgulho, polido com amor e recebido com gratidão. A mais forte motivação para produzir itens de alta qualidade e serviços é o prazer gratificante de fazê-lo. Desta forma, qualidade é a consciência e intenção do produtor. É o relacionamento direto entre pessoas, produtos e a sociedade, baseado em funcionalidade, imaginação, arte e amor. Por esta razão, qualidade é a expressão de respeito para consigo mesmo como criador.

O pioneiro do movimento pela Qualidade, W. Edwards Deming, acreditava que a melhorias em qualidade requerem a delegação de responsabilidade para os empregados organizados em equipes encarregados de entregar produtos que estejam de acordo com padrões que a própria equipe criou. Os membros da equipe, no modelo de Deming são desafiados pelos líderes a fazer melhor, e eles são apoiados e recompensados por assim o fazer. Construir responsabilidade pela qualidade em todas as descrições de trabalho permite apresentar claramente que Qualidade é responsabilidade de Todos.

Desperte o interesse pela qualidade nas equipes através do compartilhamento, liberdade e confiança...


Esse livro Organizational Democracy está mudando meus horizontes... credo

Ubiquity ?

Essa versão atual ainda tem alguns problemas, mas o nível da ferramenta é absurdo... multi mashups... recomendado!

Conheça mais sobre o Ubiquity


Ubiquity for Firefox from Aza Raskin on Vimeo

Setembro é Java em Floripa!

Mais um evento!

O GUJavaSC promove este sabado(19) um evento bastante interessante, integrado ao Sun Tech Days. A novidade: os conhecidos!
Entre os palestrantes, duas pessoas que se formaram comigo e um amigo do trabalho.


Mais informações e inscrições: JUGs Mes de Java 2008

Abaixo segue a programação:

Horário	Palestra/Evento
08:30	Cadastramento
09:00	Abertura
09:15	Java na Ponta dos Dedos: A revolução Invisível [Maurício Leal]
10:30	Floggy: Produtividade e Simplicidade na Persistência JavaME [Thiago Rossato, Thiago Leão Moreira e Priscila Lugon]
12:00	Almoço
13:30	Glassfish v3: A nova geração de Servidores de Aplicação modular [Kohsuke Kawaguchi] - Palestra com tradução simultânea
15:00	Intervalo
15:15	Um bate papo sobre o uso de tecnologias Eclipse (RCP, GEF, EMF, SWT, JFace) no desenvolvimento de aplicações desktop. [Eduardo José Pereira]
16:30	A importância do Teste de software para a garantia de qualidade das aplicações Web [Érika Tatiana Hmeljevski]
17:30	Encerramento

Palestrantes

• Maurício Leal, famoso entusiasta de Java ME e gerente de Programas SDN na Sun Microsystems, estará abordando Java na Ponta dos Dedos: A revolução Invisível.
• Thiago Rossato, Thiago Leão Moreira e Priscila Lugon, os criadores do projeto Floggy, um framework para persistência Java ME que recentemente teve um artigo publicado na Mundo Java, estarão falando sobre o Floggy: Produtividade e Simplicidade na Persistência Java ME.
• Kohsuke Kawaguchi, engenheiro senior da Sun Microsystems com inúmeros projetos no java.net, incluindo o famoso servidor de Integração Contínua Hudson, estará mostrando o Glassfish v3: A nova geração de Servidores de Aplicação modular.
• Eduardo José Pereira, que trabalhou para o projeto Eclipse antes mesmo dele ser open source e ter este nome, estará apresentando Um bate papo sobre o uso de tecnologias Eclipse (RCP, GEF, EMF, SWT, JFace) no desenvolvimento de aplicações desktop.
• Érika Tatiana Hmeljevski, que possui uma enorme experiência na área de testes de software e que possui um forte envolvimento com algumas organizações desta natureza, mostrará A importância do Teste de software para a garantia de qualidade das aplicações Web.

Encontro vocês lá!

Agile Readiness Assessment Webinar - 19 de setembro

Divulgação: (From: The Agile Manager)

Please join me on Friday, 19 September for An Agile Readiness Assessment, a ThoughtWorks sponsored webinar.

Taking on Agile can appear to be an overwhelming commitment with no obvious place to start. For one thing, Agile is often a significant departure from how a team is operating, requiring organisational changes, new practices, and stricter discipline. In addition, because there are so many different things to be done - from continuous integration to Story based requirements - it's difficult to know what changes to make first. Finally, organisational constraints such as phase-based governance and shared QA can create questions about the extent to which Agile practices will have an impact, and raise doubts as to whether they can be taken on in the first place.

In this webinar, we'll discuss how to overcome stationary intertia and plot a course to Agile practice adoption.

• How can we critically assess the state of our practices today?
• What goals should we target given constraints and organisational realities?
• How do we prioritise what we should do first?

I hope you can attend on the 19th.

Registration details:
Friday, 19 September 2008
Time: 1:00pm Eastern Standard Time (US-New York, GMT-4:00)
Registration URL: https://thoughtworks.webex.com/thoughtworks/j.php?ED=108081447&RG=1&UID=0

Se alguém conseguir gravar o evento para mim... eu agradeço!
Estarei no Seminário de Qualidade de Software e não poderei comparecer ao webinar (entretanto, aguardem a cobertura do evento)...

cya!
[]s

Scrum Checklist em português

Lá vou eu de novo! Mais uma pequena tradução...

Desta vez, peguei a versão Mapa Mental que o Henrik Kniberg colocou à disposição num post em seu blog.

Usando o FreeMind, ai está a primeira versão:Scrum Checklist_ptBR.mm


clique para ampliar...

Divirtam-se e ajudem a melhorar o documento...

Agile 2009

Quero ir...

E já começaram os preparativos para o Agile 2009:

Agile Toolkit Podcast com Johanna Rothman

Download do arquivo: Agile Portfolio Management and Agile 2009 with Johanna Rothman

Adoro a idéia da criação de OpenSpaces sobre Agile...

Falando em Agile - Aí vou eu!

Saudações!
Com a divulgação completa da programação do evento Falando em Agile, o que posso dizer? Eu vou!

Aguardem informações e fotos! Com certeza, farei uma cobertura digna... como feito anteriormente nos eventos ExpoGestão 2008 e o FISL9.0 (pelo menos, é o que dizem...)

[]s

Jay Bazuzi - Palavras de Adeus

Jay Bazuzi, Líder de equipes de desenvolvimento da Microsoft, está se desligando da empresa. Mas não sem antes deixar alguns comentários aos que ficam:

Parting Words for my dear friends

Pontos importantes: A Microsoft não é uma empresa tão preocupada assim com a qualidade do que se produz, seja do ponto de vista da manutenibilidade do código que escrevem quanto à comunicação entre as equipes.

Jay dá algumas regras básicas para nos guiarmos:

• Os códigos com mais clareza ganham.
• OO não é um capricho
• É OK usar o código de outra pessoa
• Planeje a solução de seus problemas imediatamente
• Mais importante: nós podemos fazer melhor.

E ele indica algumas perguntas que devemos fazer a nós mesmos, de modo a criamos um código melhor.

• "Como posso me certificar que este problema foi resolvido (ou eliminado) definitivamente?”
• “Como posso produzir menos bugs?”
• “Como posso facilitar a correção dos bugs que tenho?”
• “Como posso facilitar a resposta às mudanças rapidamente?”
• “Como posso facilitar a construção de um software rápido e eficiente?”

Preocupação com qualidade de código não é para qualquer um... realmente...

1º Seminário Catarinense de Qualidade e Teste de Software

Informação interessante: A Supreme Quality está promovendo um evento importante para a área de qualidade de software nessas bandas de cah (sul do país): 1º Seminário Catarinense de Qualidade e Teste de Software no dia 19 de setembro de 2008

Informações e Inscricao no site oficial do evento


Jah confirmei minha inscrição, e estou ansioso para ver várias apresentações descrevendo como os prestadores de serviço da ilha são ótimos em prover soluções ultra-max-mega catachangas para qualidade de software... (irônico demais??? náááá)...


Prometo participar e gerar alguma polêmica para os palestrantes que esperam apresentar apenas ferramentas, sem compartilhar informações com público... keep in touch boys... wait for my feedback

PS: não, este não é um Post Pago... que me dera...

Ainda não entendeu o que é desenvolvimento ágil?

Bem... então Capitão Vinícius Nascimento vai ensinar...



Pontos altos da entrevista pra mim:

• Não adianta... a maior parte das empresas nunca será Ágil (e o problema está nos gestores)
  
• Desenvolvimento de Software é diferente de Engenharia civil (nunca canso de repetir isso)
• Participação do cliente é fundamental!
• Parece impossível, mas software com qualidade, satisfazendo o cliente e que seja sustentável é possível!!!
  

Mike Cohn

Apresentando um framework para implantar desenvolvimento ágil: Mike Cohn... apresentação demorada, mas bastaaaaante instrutiva... (video + slides)


Succeeding With Agile: A Guide To Transitioning

[]s

Um tanto sumido...

Saudações!!

Bem, tenho andado sumido... mas muita coisa está acontecendo...

- as últimas semanas tem me deixado ocupado trabalhando no novo site do bomdebolaparati.com.br... e espero logo colocar o site no ar

- Estou ajudando no projeto de tradução do Scrum From the Trenches! sim... agora o treco vai! logo mais novidades sobre o ebook

- Mas por que traduzir este livro? Bem, porque fui convidado a participar da equipe de editores do portal InfoQ, na versão em português! heheheh legal neh?!? Veja a notícia do lançamento! A convite do Felipe Rodrigues, vou ajudar na tradução e produção de conteúdo em português da sessão Agile do Site...

Pois é muito trabalho pela frente... e ainda terminando o primeiro projeto de integração contínua da Audaces...

E falando em Audaces:

Quer trabalhar na Audaces?? Pergunte-me como!!

Mike Cohn: Scaling Agile

Scaling Agile Software Development

desculpem o ter deixado este blog no limbo... liferay está me consumindo... =)

HBR Podcast

Sincronismo total...

Este podcast veio muito a calhar com o post anterior...

Retaining Employees When Money Is Tight
Featured Guest: Christina Bielaszka-DuVernay, editor of Harvard Management Update.

DIVIRTA-SE



Link para arquivo

ExpoGestão: Patrick Sweeney

Esta sim, uma Apresentação com "A" maiúsculo...
Vice Presidente da multinacional Caliper, Patrick Sweeney foi o apresentador mais eloquente do segundo dia. Não é por menos, afinal, sua empresa já participou da contratação de algumas centenas de milhares de pessoas ao redor do mundo, e ele já realizou um estudo com 2 milhões de pessoas. Candidatos que passaram por sua empresa.

Como não poderia deixar de ser: mais atrasos...

Um fato bastante inusitado: Ginástica Laboral!!! Ao som de uma música animada, nos alongamos ouvindo a também animada professora... chique demais!!

Sweeney iniciou a palestra com a definição do escopo: O que gestores NÃO devem fazer!! e cerceou sua apresentação em quatro grandes erros que cometemos:

1) Contratar alguém para preencher exatamente a vaga aberta na empresa
2) Preencher apressadamente uma vaga aberta
3) Contratar pessoas que vejam o mundo da mesma forma que você
4) Contratar pessoas com experiências semelhantes

Questão metafísica da vez: Como contratar os melhores e evitar contratar os piores

Patrick nos apresenta uma reflexão interessante:

O que os top performers de sua empresa tem em comum??

Mais a frente falarei de duas características importantes: Resiliência e Otimismo. Falemos então dos erros principais dos gestores:

Contratar alguém apenas para preencher um cargo

Essa até eu sei, e pode ser descrita com a seguinte frase:

"Em Empresas de qualidade, quando um presidente se aposenta, contrata-se um office-boy"

Tá bom, tá bom... não quis dizer que contratar um guri sem experiência para presidente da empresa é a solução. A questão vai muito além, e me faz pensar: Quais são as qualidades que você espera, ao fazer uma contratação? Conhecimentos específicos para um tarefa? O potencial que as pessoas apresentam, e que poderá ser aproveitado pela empresa no futuro?

Patrick indica aqui uma virtude importante: Pense em contratar pessoas com a competência e o carácter que você quer na empresa. Neste caso, o papel de um gestor não é moldar e mudar pessoas, mas investir no potencial de cada uma que o cerca.
Nos trazendo para a realidade, fomos alertados de que Potencial não quer dizer nada! O que importa é o que fazemos com o potencial que nos é apresentado.

Resiliência

Resiliência, na visão do palestrante, é a capacidade de aprender e crescer à partir de experiências negativas. É o atributo social que fará as pessoas entenderem que falhas fazem parte do jogo da vida, e que devem ser incorporadas sem grandes excessos.

Conheci, neste momento, a história do jogador de basquete Muggsy Bogues... cara, que coisa impressionante a persistência do sujeito! =)
Nascido num bairro pobre e violento, Muggsy tinha tudo para ser mais um tiro pela culatra da sociedade americana. Mas ele queria jogar basquete... com 1,60m e muita, muita persistência, Muggsy conseguiu uma vaga numa universidade e uma vaga para jogar na NBA... todas as adversidades, principalmente com pessoas o questionando e humilhando sobre sua altura e origens, não foram suficientes para fazê-lo desistir. Na verdade, tornaram Muggsy mais persistente e implacável em sua força e vontade de jogar basquete.
Quando questionado, em entrevista, se não seria impossível enfrentar Michael Jordan , Muggsy disse, na maior das calmas: "Nada, ele é só um pouco alto".
Louco ou otimista? A verdade é que Muggsy fez história com sua persistência, e seria ótimo ter pessoas como ele em nossas equipes... certo?

Conclui-se que resiliência é a capacidade de obsorver mudanças e tirar o melhor proveito de qualquer experiência... esse tema tem sido tratado em inúmeras edições da ÉpocaNegocios, vale a pena dar um conferida.

Otimismo

Esqueça os pessimistas, pois eles só fazem reclamar... e dificilmente você terá grandes conquistas vindas de pessoas pessimistas...
Otimistas é que fazem tudo acontecer, mesmo quando as chances são mínimas... pense nisso...

Preencher muito rápido uma vaga

A verdade: Cadeiras vazias pressionam gestores. Preencher vagas a qualquer custo é um grande erro que os gestores não deveriam se sujeitar...
Uma equação simples:
Quanto tempo dura para você perceber que cometeu um erro numa contratação? E para remover esta pessoa do seu grupo??
Acredita-se que leve entre 6 a 9 meses para isso... no total...
O investimento perdido por encontrar a pessoa errada não justifica a tentativa de arrumar alguém muito rápido....

Outra questão metafísica: Como encontrar pessoas obsecadas por sucesso?

Com certeza, não será fazendo uma busca por 1 mês apenas...
Encontra pessoas com brilho nos olhos, e a vontade de trabalhar duro e apresentar resultados fabulosos! (só faltou dizer "Amén!")...

Contratar pessoas que veêm o mundo da mesma forma que você

É necessário criar e manter uma empresa balanceada em todos os sentidos. Daí a importância em ter pessoas com visões de negócio diferenciadas, o que facilitará a resolução de problemas com uma abordagem mais ampla e consistente.

Mais uma vez: quais características são comuns aos top performers?? Encontre esta resposta, e você com certeza terá uma boa dica para saber o que procurar em novas contratações. Patrick nos dá a visão de que é necessário focar em qualidades e forças para o sucesso. Pessoas que saibam, por si só, aprender, é uma ótima pedida.

Questão: Experiência é realmente necessário? Entre um jovem com gana em aprender e um profissional com 12 anos de experiências... quem você escolheria?
Resposta: Depende... que tal um profissonal com 12 anos de éssimas experiências? seria realmente interessante para sua equipe?
Experiência é muito interessante como uma habilidade de transferência, isto é, a capacidade de mudar de função e continuar exercendo um comportamento adaptativo e vencedor.

Contratar pessoas com experiências similares

Bem... aqui não há muito o que dizer...

Patrick descreve duas perguntas principais para serem feitas durante a entrevista, possibilitando uma visão melhor do candidato:
- Por que você deixou seu último emprego?
- Fale a respeito de uma vez que você falhou. Qual foi sua reação?


Nota para a Palestra: 1000!!
Impossível descrever aqui toda a palestra... mas até que fui longe...

Nota para a organização do evento: -1000000... vergonhoso!!! Colocaram um cara de intérprete para interação com a platéia que era um lixo, mal sabia falar inglês... um absurdo!!!

ExpoGestão: Oscar Motomura

Oscar Motomura

Oriental franzino, mas com muito conhecimento... inicia a apresentação sem uma apresentação formal (cadê o powerpoint??!?!?). O tema: Desafios dos líderes para o futuro

Motomura inicia sua apresentação descrevendo um treinamento que sua empresa costuma fazer: reunir líderes e fazê-los pensar no papel que suas ações tem nos problemas reais da humanidade. Eles nos desafia a discutir por alguns minutos: "Quais são os principais problemas da Humanidade?".
- Algum de vocês citou o aquecimento global?
- Algum de vocês falou sobre violência?

Me chamou muito a atenção uma questão jogada ao ar: "O que nós, como gestores, fazemos para ampliar ou reduzir os problemas da humanidade?"

Um dos principais desafios dos gestores do futuro é conseguir trabalhar o crescimento de suas empresa num ambiente adverso e problemático, e interagir de maneira próativa na diminuição dos males da humanidade.

Qual a nossa aposta para o futuro?

Nova tendência é encarar a Gestão como uma atividade de Design.

Líderes como designers
Designers como líderes

Como você quer atuar em sua empresa: Surfar nas mega tendências ou desenhar o seu próprio futuro?

É papel dos gestores, neste momento, lançar questões impossíveis para discussões. Somente, assim seria possível que algo realmente grande e grandioso fosse feito. Exemplos de como esta abordagem pode:
Magazine luiza: "Como crescemos sem dinheiro?"
Esta foi a questão impossível que motivou todo um movimento de mudança de estratégica da empresa, vendendo na década de 80/90 através de catálogos e vídeos, depois entrando na era digital... bem interessante

Serão estas questões impossíveis que trarão a ruptura cultural para o crescimento da empresa. Insights e inovações surgem da buscam em resporder questões impossíveis.

É importante que esta discussão seja levada A TODAS AS PESSOAS DA EMPRESA. Uma caracteristica mais critica para os lideres será conhecer os padrões e nuâncias das interações humanas

Foi citado o exemplo de um líder de líderes. Cientista americano que coordenava mais de 8 mil outros cientistas, entre eles inúmeros "nobles". DEntre as licoes retiradas do exemplos, podemos assumir que, antes de mais nada, liderança é uma questões de traquejo social, e não poder instituíto. Na tentativa de liderar outros líderes, é preciso:

- Não competir em absoluto com as suas atividades. Estar certo de que você não será um impecilho para o trabalho deles (not control, but freedon drives the growth)
- Ter certeza que todos estejam trabalhando em questões realmente desafiadoras. Desafios são importantíssimos para gerar o comprometimento
- Mantê-los autamente motivados. Aqui, o importante é não fazê-los passar despercebidos! (tal cientista costumava dar presentes inusitados aos seus liderados, como barras de 5kg de chocolate, para que, ao chegar em seus escritórios eles sejam percebidos e possam falar a respeito do presente...)


Outro desafio para novos líderes lideres será "saber de gente". É necessário que, durante uma mudança de estratégia, focar a atenção também na mudança cultural, que possui o mesmo peso.

Preparar-se para o futuro

- Lidar com economia de escala
- Lidar com a complexidade (cultural, economia e ambiental)
- Investir em talentos

Foi tratado o tema Excelência Futura, que passa PRINCIPALMENTE na maneira como a empresa investe, mantém e encontra talentos.
Muitas empresas atualmente possuem reserva de talentos, isto é, um grupo especial de pessoas, que qdo a coisa aperta, eles darão resultado rápido. Motomura cita o "Indice de Excelência Futura", medida criada por eles (ou nao) para determinar o quão preparada a empresa está para o futuro que a aguarda.

É imprescindível que os líderes da empresa estejam livres para pensar no futuro. No Brasil, o que se vê são inúmeros líderes afogados questões operacionais desnecessariamente, quando deveriam estar estudando e vislumbrando os rumos que a empresa deve tomar. O principal reflexo desta realidade é o grande número líderes brilhantes estão cronicamente cansadas.

Manter embriões de novos negócios, através de experiências, inúmeras delas, muitas delas! Somente desta forma poderíamos nos aproveitas de espaços em branco nos negócios (Blue Ocean Starategy)...

Mas o melhor estava reservado para o final... alguma vez vocês se questionaram qual a nossa real intenção em atuar como empresas neste mundo? Motomura nos propôs a segunda reflexão da noite: ele nos instigou a enviar para o planejamento estratégico da empresa a discussão sobre nosso papel neste planeta.

Estamos contribuindo com a nossa visão de negócio para o bem e da humanidade e do planeta?

Ensinamentos interessantes:

Para sobreviver no mercado por muito tempo, é necessário favorecer e desenvolver competências duráveis. Uma vez que conhecimentos ficam obsoletos rapidamente, é necessário desenvolver talentos que permitam o crescimento dos indivíduos e da empresa como um todo. Não é possível manter talentos tendo como base o dinheiro, é necessário mais.. - próximo post falará da palestra do Patrick Sweeney, e tem tudo com isso!

Fui apresentado ao conceito de Felicidade Interna Bruta, como sendo muito mais eficiente que o tradicional PIB...


A palestra finalizou com a idéia de que Ética é a escolha que fazemos para o bem comum...
Simples e direto... credo!!!!

Depois disso um coquetel chique no último nos esperava, com Chopp Opa, Chanpagne e vários croquetes... =)