Casamento e Agilidade

Não, você não leu errado, esse post é realmente sobre casamento, e não estou falando de casar frameworks, metodologias e coisas do tipo, estou falando daquele casamento com noiva, noivo, igreja, aquele que a maioria dos homens, como eu, morrem de medo.

A motivação para esse post surgiu após eu ter twitado a seguinte frase “Ano passado ganhei um Grill da patroa, esse ano foi uma cafeteira! Será que ela está querendo mobiliar meu AP? #Medo #Casório 🙂”. Depois disso eu comecei a receber comentários no facebook de amigas e “amigos” a apoiando, dizendo que já passou da hora, dando dicas presentes futuros, etc. Imaginem a minha situação? Eu precisava provar não só para a patroa como a todas as amigas e “amigos” que casamento é coisa do passado e que estamos descobrindo melhores maneiras de construir um relacionamento!

Mulher? Tem algo mais complexo que mulher? E o casamento então? O número de incertezas é gigantesco, nós nunca sabemos o que as mulheres querem, logo o escopo é totalmente desconhecido, temos que gerenciar expectativas o tempo todo, afinal elas estão sempre esperando mais do que podemos oferecer, isso sem falar na transparência e adaptação constantes que é necessário para termos uma relação saudável.

Meu amigo, eu só conheço uma coisa capaz de lidar com um problema desse tipo e definitivamente não é o casamento.

Casamento é igual Waterfall, funcionou no passado quando as coisas eram mais simples. Tínhamos um padre (Gerente de Projetos), sem nenhum envolvimento com os noivos (comprometido com o time), falava meia dúzia de palavras para colocar medo no time (até que a morte os separem) e ia embora achando que o projeto ia dar certo. Se compararmos o Chaos Report com o índice de divórcios no mundo, os números devem ser bem parecidos.

Tá na cara que aplicar Casamento na relação não funciona, temos que ir para uma abordagem ágil, sem burocracia, com autogerenciamento, sem interferências externas e para isso nós precisamos buscar os valores e princípios da agilidade. Vamos recorrer à bíblia dos agilistas, vamos olhar o Manifesto Ágil.

O Manifesto Ágil aplicado ao casamento

Individuals and interactions over processes and tools

Esse valor deixa muito claro que pessoas e a interação entre elas (sexo) é muito mais importante que processos (metodologias de casamento como civil / religioso) e ferramentas (vestidos de noiva, decoração, festa, etc).

Alguém duvida?

Working software over comprehensive documentation

Esse tá na cara: Assim que o seu software (é melhor ele seja um hardware) parar de funcionar, você vai levar um pé na bunda e nenhuma documentação vai te salvar. Então amigão, pode esquecer toda aquela documentação extensa como certidão de casamento, cartinhas de amor, depoimentos no Orkut e outros tipos de documentações inúteis. O que realmente importa é o soft(hard)ware funcionando o tempo todo. E lembre-se de não deixar o sistema cair. Se algum bug for detectado, vá à farmácia mais próxima, peça um Service Pack Azul e coloque o sistema no ar novamente.

Se alguma mulher falar que não é bem assim, está mentindo!

Customer collaboration over contract negotiation

Eu sei, eu sei, colaborar com mulher é complicado: “Amor, vamos visitar o meu pai”, “Amor, vamos ver o show da Rita Lee”, “Ai, não acredito que você vai me deixar sozinha pra ir jogar futebol com os seus amigos”. Enfim, é muuuito chato paparicar mulher, mas como o manifesto é a nossa bíblia, temos que entender que é melhor colaborar algumas vezes do que assinar aquele contrato de escopo fechado chamado Certidão de Casamento, aonde o escopo vai te transformar numa múmia e que contém cláusulas de quebra que normalmente te causam um baita prejuízo.

Acho que peguei pesado aqui, mas que tem um fundo de verdade, tem!

Responding to change over following a plan

O que vocês preferem? Ter uma vida mais dinâmica ou seguir um plano? Muitos podem falar que seguir um plano dá mais segurança, porém o problema começa a aparecer quando esse plano começa a te levar pra longe dos seus objetivos e muitas vezes você está tão cego seguindo o plano que não percebe que está ficando cada vez mais longe do que realmente busca.

Há ainda os que percebem que o plano está atrapalhando, mas se conformam em continuar com ele, pois a mudança geraria muita dor de cabeça, a burocracia é gigante e por aí vai.

Ahhh, apenas para a sua informação: agora eu estou falando de projetos de software tradicionais e não de casamento, ok? Realidades parecidas, não?

Bom, não posso falar do casamento, mas posso dizer que praticamente todas as pessoas que conheço que escolheram ter uma vida mais dinâmica do que seguir um plano cegamente, estão mais felizes que antes. E você, o que prefere?

E agora? Você ainda acha que casamento é uma boa para o relacionamento? Eu provei acima baseado em teoria, princípios, valores e relatos que casamento não funciona no mundo atual. Que tal considerar implantar agilidade no seu relacionamento? Se você não concorda comigo, apresente-me cases que mostram um casamento que não estourou o orçamento, atendeu todos os requisitos dos stakeholders e que teve zero de turnover 🙂

Espero que vocês tenham gostado desta “brincadeira” e que possam descontrair um pouco neste final de ano que foi tão agitado para todos nós!

Um Feliz Natal e um 2011 cheio de realizações para todos nós,
André Dias

O trabalho já acabou, mas a Sprint ainda não. O que fazer?

É até estranho falar sobre o que fazer quando o projeto está adiantado, principalmente devido ao histórico de problemas e atrasos que o Chaos Report vem apresentando há algum tempo. Pois bem, o cenário está mudando e essas situações já começam a aparecer e como ainda não é uma situação comum, bate aquela dúvida: “O que fazer com o tempo que está sobrando?”.

Apenas para termos um contexto, vamos assumir que estamos falando de uma Sprint com duração de 1 mês e que todo o trabalho foi concluído faltando 3 dias para o encerramento da Sprint.

Formalmente, o Scrum não diz nada sobre isso, então vamos verificar algumas possibilidades que temos:

  1. O primeiro ponto é verificar se realmente não há mais nada a ser feito na Sprint atual. Todas as histórias e tarefas foram realmente concluídas? Todo o conceito de pronto foi implementado? Todos os critérios de aceitação estão passando?
  2. Se o time realmente concluiu todo o trabalho previsto, o próximo passo é colocar o time e o Product Owner (PO) juntos para tentarem identificar se é possível trazer algo do Product Backlog para a Sprint atual. Pode ser uma história pequena, de repente puxar algumas correções de bugs que foram encontrados nas Sprints anteriores, etc. Se o time e o Product Owner encontrarem algo pra ser feito em 3 dias, ótimo, problema resolvido, caso contrário a busca por atividades continua.
  3. Ok, terminamos tudo para a Sprint atual, não há nada pra fazer em 3 dias que vá agregar algum valor, e aí? Bom, eu conversaria com o Time para identificar algumas sugestões de atividades, entre elas poderíamos ter:
    • Realização de treinamentos;
    • Estudo de alguma tecnologia / ferramenta que será usada futuramente no projeto;
    • Realizar melhorias no código atual;
    • Criação de componentes ou ferramentas para aumentar a produtividade / qualidade do time;
    • Liberar o time para realizar projetos pessoais;

    Depois de ter uma lista de sugestões, conversaria com o Product Owner sobre quais dos itens sugeridos ele vê mais valor, afinal ele é o responsável pelo ROI do projeto. Dependendo do relacionamento entre o PO e o time, eu não me surpreenderia se o PO liberasse o time para atuar em projetos pessoais para dar um descanso pra galera.

  4. Por último, e acredito que seja o item mais importante, é discutir na retrospectiva o motivo da Sprint ter terminado antes. Levantar se essa situação é recorrente e se for pensar em aumentar a velocidade do time já que parece estar havendo uma superestimativa das atividades.

Enfim, não é uma receita de bolo, é apenas uma visão de bom senso muito parecida com outras situações que já apliquei em alguns projetos e que se demonstrou muito eficiente principalmente pela transparência.

Gostaria de saber se vocês já estão passando por esse tipo de “problema”? Como vocês estão lidando com a situação? É diferente da forma que citei aqui? Quais são os resultados?

Abraços
André Dias

Scrum e PMBOK juntos. É possível?

Hoje, tivemos mais uma reunião do grupo .NET Architects cujo tema discutido foi Scrum vs PMBOK. Foi uma reunião diferente do padrão que estamos acostumados já que não tivemos palestra e optamos por fazer uma mesa redonda para discutir o assunto. Apesar de termos convidados alguns PMPs para a discussão, não tivemos a presença de nenhum e inicialmente a defesa do PMBOK foi realizada por mim e pelo Victor Cavalcante. Durante a discussão, outros membros chegaram e nos ajudaram na defesa e o Giovanni Bassi liderou o lado do Scrum com o apoio de todos os outros membros presentes.

Tivemos aproximadamente 2 horas de discussão onde conversamos sobre os benefícios dos dois modelos, cenários adequados para cada modelo, formas de contratos, etc. Obviamente, as opiniões foram muito divergentes mas a mensagem final que ficou para mim foi "Scrum e PMBOK são complementares porém com algumas práticas conflitantes. Podemos combiná-los sempre que fizer sentido para o negócio e for necessário para garantir o ROI".

IMG_9945

Quando cheguei em casa, eu publiquei um resumo da reunião no twitter, o que acabou chamando a atenção de algumas pessoas, entre elas o Renato Ferracini, vice-presidente do PMI-SP e acabamos iniciando uma nova discussão sobre o assunto através do twitter mesmo. Basicamente, o Renato apresentou uma visão muito alinhada com o que o Ricardo Vargas, presidente mundial do PMI, disse no último Scrum Gathering Brazil. Ele citou os benefícios da agilidade, a possível integração com o PMBOK, porém não abriu mão do comando-controle.

Como eu achei a discussão bastante interessante, eu extraí o conteúdo do twitter e publiquei abaixo para facilitar a leitura. Como vocês verão nas mensagens abaixo, fizemos um convite ao Renato para conversarmos melhor sobre esse assunto no grupo e em breve teremos novidades. Aguardem!!

Até a próxima
André Dias

andrediasbr: Saldo positivo no #DotNetArchitects hoje. Como não tinhamos ninguém para defender o #PMI, eu e o @vcavalcante fizemos esse papel.

andrediasbr: Apesar de não termos nenhum PMP na reunião, acho que a discussão foi válida. Algumas das mensagens que ficaram, foram:

andrediasbr: #PMBoK e #SCRUM são complementares porém com algumas práticas conflitantes. Pode-se combiná-los se fizer sentido para o seu negócio (ROI)

RenatoFerracini: @andrediasbr Pois é, eu tentei participar representando o PMI mas ñ deu. #DotNetArchitects #PMI

vcavalcante: @RenatoFerracini pena que você não pode ir, foi muito interessante.

RenatoFerracini: @vcavalcante Pois é, eu queria participar virtualmente mas soube tarde demais e não responderam minhas perguntas. Mas adoro estes assuntos!

RenatoFerracini: @andrediasbr Você poderia me dizer onde há conflito? Eu conheço bem ambos e não vejo nenhum. #PMBOK #SCRUM

andrediasbr: @RenatoFerracini No #PMBOK eu tenho a figura central do GP gerenciando todo o time. No #Scrum, o gerenciamento é realizado por todo o time.

RenatoFerracini: @andrediasbr Errado. No #PMBOK o GP compartilha o gerenciamento com a equipe. No #Scrum o Scrum Master faz o mesmo sem o "título" de GP.

RenatoFerracini: @andrediasbr O #Scrum dá nomes diferentes a práticas e funções conhecidas mundialmente e tenta vender isso como novo.

andrediasbr: @RenatoFerracini Sim, o GP pode compartilhar o gerenciamento com o time, mas a responsabilidade ainda é dele, o comando é do GP, correto ?

andrediasbr: @RenatoFerracini E se eu tenho alguém comandando, eu perco um dos princípios do Scrum é que ter um time auto-gerenciável.

RenatoFerracini: @andrediasbr É uma questão de atitude, André. Soft skills. Conhecendo sua equipe você pode saber o quanto compartilha e o quanto comanda.

RenatoFerracini: @andrediasbr O Scrum simplifica isso partindo da PREMISSA que a sua equipe terá apenas profissionais totalmente capacitados (seniores).

andrediasbr: @RenatoFerracini Renato, desculpe mas você está enganado, o #Scrum não tem essa premissa de trabalhar apenas com profissionais seniores.

andrediasbr: @RenatoFerracini Se eu tenho pessoas que não tem skills de auto-gerenciamento, isso é um impedimento e o ScrumMaster deve resolver isso.

RenatoFerracini: @andrediasbr Sim, eu sei. Sou Scrum Master também. Como eu falei, é um tipo de comando.

vcavalcante: @RenatoFerracini discordo desta última afirmação, eu conheço várias equipes que não tem apenas profissionais seniores.

vcavalcante: @RenatoFerracini e trabalham muito bem com scrum.

RenatoFerracini: @vcavalcante Mas não é o que diz o Scrum. Desse jeito se está trazendo RISCOS para o projeto.

vcavalcante: @RenatoFerracini em nenhum momento o Scrum fala que devemos trabalhar somente com profissionais seniores.

RenatoFerracini: @vcavalcante Bom, aí vou ter que procurar nas minhas referências para poder comprovar. Mas até onde eu saiba é sim.

giovannibassi: @renatoferracini Pois é. Premissa do Scrum: times autogerenciados, SEM gerente de projeto. A não ser que vc chame ele seja uma secretária.

RenatoFerracini: @andrediasbr Sempre existe um comando. O auto-gerenciável é apenas no que se refere aos pacotes de trabalho (sprints)…

andrediasbr: @RenatoFerracini Sim, sempre há comando, mas no nível executivo. Nas atividades de desenvolvimento, não há controle no Scrum.

RenatoFerracini: @andrediasbr Concordo plenamente. E é o mesmo que um bom gerente de projetos deve fazer, deixar a equipe se desenvolver…

RenatoFerracini: @andrediasbr … Fica sem trabalhar de papo para o ar sem cumprir prazos para vc ver o que acontece.Se alguém te demite é pq vc É comandado.

andrediasbr: @RenatoFerracini Se eu ficar sem trabalhar, vou comprometer a meta do time. O próprio time vai me cobrar, não preciso de um gerente pra isso

RenatoFerracini: @andrediasbr Quem te demite, é o time ou o seu chefe?

andrediasbr: @RenatoFerracini Quem demite normalmente é o RH, não o GP. Ele apenas cita as razões, da mesma forma que o time scrum faz.

RenatoFerracini: @vcavalcante Ou no Scrum existe algum processo para prover treinamento à equipe?

vcavalcante: @RenatoFerracini o time pode detectar a necessidade de treinamento se isso se tornar um impedimento, ai entra o Scrum Master para resolver.

RenatoFerracini: @andrediasbr … Gerente de projetos do tipo sargentão é ultrapassado há décadas. Lembra "O Monge e o Executivo"?

andrediasbr: @RenatoFerracini Eu sei, mas é um problema já relatado pelo Ricardo Vargas, há varios PMPs "Sargentão" que aplicam o PMBoK de forma errada

RenatoFerracini: @andrediasbr E eu concordo com ele. O RV é CSM, PMP e presidente do PMI. Ele, como eu, percebe que são coisas semelhantes…

RenatoFerracini: @andrediasbr …Muitos PMPs precisam entender que controle não é andar com o chicote na mão! O Scrum ajuda a mudar essa visão.

andrediasbr: @RenatoFerracini Sim, no #ScrumGathering ele disse que acredita em Scrum e PMBoK juntos, só não acredita em times auto-gerenciaveis. 🙂

vcavalcante: @RenatoFerracini mas não dá para usar scrum sem times auto gerenciaveis. Esse fou um questionamento que levantamos para o RV.

RenatoFerracini: @andrediasbr @vcavalcante @giovannibassi Gente, o papo está muito bom, fizemos um chat nesse Twitter agora. Vou tentar responder tudo…

andrediasbr: @RenatoFerracini Eu também acredito em Scrum junto com PMBoK, Scrum com CMMi, Scrum com XP .. Mas não dá pra afirmar que não há conflitos.

RenatoFerracini: @vcavalcante Eu acredito q isso funciona em um cenário q permite respostas lentas como essa. O ideal seria agir de forma mais pró-ativa, né?

RenatoFerracini: @vcavalcante Identificar a necessidade de treinamento ANTES que isso se torne um impedimento.

RenatoFerracini: @vcavalcante Mas aí que está, vc não precisa usar o Scrum exatamente como dizem esses "dogmas". Adapte-o à sua necessidade!

vcavalcante: @RenatoFerracini tudo bem, foi a conclusão que eu cheguei na reunião de hoje, podemos juntar mas teremos que ADAPTAR o SCRUM e o PMI.

RenatoFerracini: @vcavalcante Exatamente! Nada está pronto e garantido 100% hoje. O PMBOK é revisado a cada 4 anos por conta disso. E o Scrum, tem revisões?

vcavalcante: @RenatoFerracini até hoje não teve, até porque é um processo muito novo e além disso é um processo muito simples.

vcavalcante: @RenatoFerracini estou gostando muito desta conversa, você não quer participar de um encontro nosso para debatermos melhor?

RenatoFerracini: @vcavalcante Pode ser sim, mas onde vcs fazem? Eu tinha visto em algum lugar que não era em São Paulo… Aí fica mais difícil…

vcavalcante: @RenatoFerracini é em na Unip da Cidade Universitária, dá uma olhada aqui: http://bit.ly/a6POY

RenatoFerracini: @vcavalcante Legal, dá para ir sim. Me mantenham informado que na próxima eu apareço.

andrediasbr: @RenatoFerracini Renato, mas a ultima revisão do PMBoK foi justamente para incorporar práticas ágeis, correto?

RenatoFerracini: @andrediasbr Não, André. O PMBOK é revisado sempre. O que acontece é que agora tivemos um foco maior no que se chama de ágil…

RenatoFerracini: @andrediasbr …mas o planejamento iterativo já existia há tempos, a segunda versão já falava em Rolling Wave Planning

RenatoFerracini: @andrediasbr A última versão foi bem mais além do que incorporar práticas dos agilistas. É uma melhoria contínua mesmo.

andrediasbr: @RenatoFerracini Sim, na verdade o conceito de iteração está descrito no paper original do Waterfall, mas eu nunca vi um PMP trabalhar isso.

RenatoFerracini: Para @andrediasbr @vcavalcante @giovannibassi RT @corneliusficht: Thushara writes World is bigger.Its bigger than SCRUM. http://ow.ly/15Rl60

andrediasbr: @RenatoFerracini Renato, qual a visão do PMI sobre os PMPs atualmente? Vocês acham que eles estão prontos para liderar projetos ágeis?

RenatoFerracini: @andrediasbr Claro que sim! Muitos já estavam há anos, mas devido a alguns maus exemplos parece que não. Mas não é a certificação q diz isso

RenatoFerracini: @andrediasbr Sou adepto do ágil desde 2006, e foram amigos PMPs que me levaram para esse "lado negro" da força. Então há PMPs ágeis sim…

RenatoFerracini: @andrediasbr @vcavalcante @giovannibassi Gente, vou sair do "chat" agora, mas terei o maior prazer de continuar essa conversa outro dia.

andrediasbr: @RenatoFerracini Ok Renato, foi um grande prazer participar deste "chat" com você. Espero continuarmos esse bate-papo em breve.

RenatoFerracini: @andrediasbr Com certeza, vamos conversar sim! Abraços!

TechEd Brasil 2009 – Slides e Recursos da Palestra

Ontem, durante o primeiro dia do TechEd Brasil 2009, fiz uma apresentação onde falei bastante sobre os métodos ágeis, focando principalmente em SCRUM e Extreme Programming e também mostrei como o Visual Studio Team System pode nos ajudar tanto com a práticas de engenharia quanto com as práticas de gerenciamento dos projetos ágeis.

Durante a palestra Utilizando metologias ágeis com VSTS: Scrum e XP, YES WE CAN! (ALM204), foram apresentadas várias demos onde o pessoal pôde ver um pouco sobre Integração Contínua, Código Padronizado, TDD e também como gerenciar o Kanban e visualizar gráficos como o Burndown dentro do VSTS.

Abaixo vocês podem visualizar os slides apresentados na palestra, além de links para baixar todas as ferramentas utilizadas.

Recursos Utilizados:

Máquina Virtual com Team Foundation Server e Visual Studio Team Suite

Template de Processo de Scrum da Conchango

Ferrameta para TaskBoard da Conchango

taskboard scrum

Abraços

André Dias

Existe Gestão de Custo no Scrum?

Recentemente, tenho participado de discussões envolvendo metodologias de gerenciamento de projetos e muito frequentemente a discussão acaba tomando o rumo das comparações, principalmente entre metodologias ágeis e metodologias tradicionais, ou sendo mais direto, comparando Scrum e PMBOK.

Como eu conheço apenas um dos lados, já que os únicos contatos que tive com o PMBOK foram através de gerentes PMPs, resolvi comprar um PMBOK para dar uma olhada e formar uma opinião mais realista sobre o assunto, ainda não recebi o livro, mas já comecei a dar uma lida nas Áreas de Conhecimento do PMBOK na internet e vi que temos algumas que não são cobertas pelo Scrum, por exemplo, o Gerenciamento de Custo.

Se formos olhar a definição do Framework Scrum na Scrum Alliance, realmente não encontraremos nada relacionado a Gerenciamento de Custo, então podemos afirmar que o Scrum não cuida desta prática formalmente, porém vamos analisar outros pontos:

Vamos assumir que um projeto possa ter custos indiretos, tais como aluguel, energia e computadores e também custos diretos, como despesas com viagens, hotel, taxi, refeições, telefone, salários dos colaboradores, etc. Vamos assumir também que o aumento descontrolado destes custos afeta consideravelmente a saúde do projeto e vamos assumir ainda que a empresa tenha uma área financeira / contábil que cuide de todas as receitas e despesas e que saiba, por exemplo, por quanto o projeto foi vendido, qual é o custo que o time está gerando para desenvolvê-lo e também tenha conhecimento sobre o percentual de rentabilidade que a empresa espera deste projeto.

Se em algum momento a área financeira perceber que a meta de lucratividade está sendo afetada, ela vai levantar a bola para alguém e no caso de projetos Scrum, provavelmente será para o Scrum Master. E o Scrum Master como um bom facilitador vai tentar negociar com o time para chegarem a uma solução.

Neste ponto a brincadeira começa a ficar interessante: o Scrum Master joga o problema na mesa e diz “Time, precisamos gastar menos! O que vocês sugerem?”. Se tivermos um time verdadeiramente Scrum várias sugestões devem surgir, como por exemplo, “Podemos parar de fazer hora extra”, “Podemos diminuir o número de viagens do PO ao cliente”, “Podemos reduzir nossos salários 🙂” e por aí vai. Porém alguém pode dizer também “É verdade, podemos fazer tudo isso, porém nós nos comprometemos a aumentar a velocidade do time trabalhando mais horas por dia para atingir a meta, e se não fizermos isso não vamos cumprir a meta do projeto”.

Pronto, temos um conflito, o como dizemos no Scrum, temos um impedimento, onde a área financeira quer diminuir o custo do projeto para manter o % de lucratividade exigida pela empresa e essa decisão pode afetar a entrega do projeto. E como todos sabem, impedimento é um trabalho para o Scrum Master, ou seja, é de responsabilidade dele discutir com os executivos, falar com o setor financeiro, com o time e encontrar uma solução que mantenha tanto a saúde financeira da empresa quanto a saúde do projeto equilibrados.

Diante disso, podemos dizer que sim, existe Gestão de Custo no Scrum, mesmo que de forma indireta e que o Scrum Master é o responsável por essa área de conhecimento no processo.

Abraços
André Dias

Chaos Report 2009, novas informações, velhos problemas!

Hoje eu tive acesso à versão atualizada do Chaos Report, para quem não conhece é aquele relatório famoso, sempre apresentado em palestras de gerenciamento de projetos e metodologias, que mostra taxas de sucessos e de falhas dos projetos.

Nos últimos anos, eu tenho participado ativamente de discussões sobre processos, metodologias, ferramentas de ALM, boas práticas de desenvolvimento, padrões, arquiteturas, qualidade, testes, enfim, nunca vi uma preocupação tão grande em fazer software da forma correta como nos últimos tempos, e eu tinha certeza que arrebentaríamos nas novas pesquisas, porém para a minha surpresa, o Chaos Report 2009 diz que pioramos em relação aos outros anos.

caos-report2009

Como podemos ver nos dados acima, tivemos:

  • 32%  Sucesso (no prazo, dentro do orçamento e com escopo completo)
  • 44%  Mudaram (atrasaram, estourou o orçamento, e/ou reduziram escopo)
  • 24%  Falharam (cancelados ou nunca usados)

Segundo o relatório, nós estamos piores do que estávamos em 2004, no entanto, eu tenho vivido uma experiência bastante diferente da que o Standish Group divulga, com vários projetos com sucesso, algumas mudança e apenas uma falha e aí deixo as seguintes perguntas para vocês:

  1. Será que nada que fizemos nos últimos anos ajudou a aumentar o índice de sucesso dos projetos?
  2. Será que realmente estamos piorando ou será que o método de medição deste órgão está falho?
  3. Qual a experiência de vocês?

Abraços
André Dias

Metodologias Ágeis na Microsoft

Várias pessoas já me perguntaram quais processos/metodologias/frameworks nós usamos na Microsoft para o desenvolvimento de softwares.

Não é segredo para ninguém que muita coisa na MS é feita utilizando o MSF (Microsoft Solutions Framework), principalmente no time de consultoria. Nos times de produtos, a coisa é mais aberta e cada time pode escolher como vai desenvolver o seu produto e neste cenário encontramos um pouco de metodologias ágeis (XP / Scrum) e, obviamente, MSF.

MSF Scrum Alliance

O mais bacana é que tenho visto cada vez mais pessoas dentro da MS falando sobre métodos ágeis, temos várias listas de discussões internas sobre o assunto e em uma destas listas encontrei um post fantástico onde uma gerente de projetos da Microsoft comenta a sua experiência da transição do modelo waterfall para o modelo ágil.  

O post é um pouco grande, mas é bem engraçado, podemos ver algumas fotos do ambiente de desenvolvimento (o físico) além de aprender algumas dicas e lições. Enfim, é um post muito interessante e recomendo a leitura dos relatos da Sara Ford: http://blogs.msdn.com/saraford/archive/2009/03/16/how-i-learned-to-program-manage-an-agile-team-after-6-years-of-waterfall.aspx 

Abraços
André Dias

Lançamento do Portal InfoQ Brasil

Vamos juntos fortalecer a Comunidade Brasileira de Desenvolvimento de Software.

Evento de lançamento do InfoQ Brasil. Participe! Inscreva-se!

No dia 01 de Novembro de 2008 a InfoQ Brasil deverá ser disponibilizada ao público. O intuito é Fortalecer a Comunidade Brasileira de Desenvolvimento de Software e para celebrar este momento, nada melhor do que um encontro com os editores e alguns experts sobre os assuntos abordados no portal.

Nesse evento teremos profissionais consagrados no mercado falando sobre os tópicos mais importantes abordados no portal. A grade irá abordar assuntos como Java, .NET, SOA, Ruby, Agile e Arquitetura. Todas as palestras terão um formato de painel, expondo o que há de mais recente em cada Queue.

Acesse e veja a grade de palestras…

Evento Encontro Ágil 2008

11 de Outubro de 2008
IME-USP – Rua do Matão, 1010
Cidade Universitária – São Paulo

O Encontro Ágil é um evento gratuito que reunirá, por um dia inteiro, alguns dos principais nomes brasileiros do desenvolvimento ágil de software.

Dia 11 de Outubro está reservado para discussões, trocas de experiências e palestras de especialistas em Programação eXtrema, Scrum e nas metodologias mais produtivas do mercado.

Conheça os profissionais que já usam métodos ágeis. Junte-se ao grupo que está revolucionando a maneira de produzir software. Participe das discussões mais atuais do mercado, tire suas dúvidas e descubra como as técnicas ágeis podem ajudá-lo a aumentar a produtividade da sua equipe e a qualidade do seu software.

Tudo isso, no Encontro Ágil 2008. Não perca!

Abraços
André Dias

O Custo de um Bug

Quem já não ouviu do gerente de projetos que tempo no cronograma para testes é bobagem? Teste unitário então? “Ah, isso é coisa daquele povo da eXtreme Programming, não precisamos disso! Vai consumir mais tempo e encarecer nosso projeto.”.

É! Eu já ouvi isso, e ouvi pessoas dizendo que ferramentas de ALM (Application Lifecycle Management) são bobagens também. Que tal perguntarem o que a Dell acha disso? Isso mesmo, a Dell! Ela conseguiu um ROI de “apenas” 225% em “apenas” 6 meses de implantação do Team System . Quem quiser consultar mais detalhes desse caso de sucesso acesse ROI CASE STUDY MICROSOFT VISUAL STUDIO TEAM SYSTEM DELL

Bom, já vimos que há pessoas que acham que testes são caros, ferramentas, como o Team System, são caras, vamos tentar entender quanto custa um simples bug no seu sistema. Vamos lá.

Cenário 1 : Bug encontrado durante o desenvolvimento
Este cenário é o ideal. O desenvolvedor escreve o código, cria os testes unitários, verifica que alguns métodos estão com erros, os corrige e pronto. Desde que ele termine dentro do prazo, o meu custo adicional é zero.

Cenário 2 : Bug encontrado durante a fase de homologação
Desta vez o desenvolvedor também foi cuidadoso, no entanto, ele não testou uma integração do código que ele acabou de desenvolver com outro código já existente. Isso vai gerar erro de integração. O testador vai identificar o erro, registrá-lo, colocar os passos para reprodução e outras informações necessárias, esse bug será triado por um team leader, que encaminhará para um programador que precisará entender o que é esse bug, tentará reproduzi-lo para depois corrigir e só então gerar uma nova build para ser publicada. Ah, o testador terá que verificar se o bug foi realmente corrigido.

Bom, estimando isso em horas, podemos colocar 2 horas para o testador, mais 3 horas do desenvolvedor e do team leader. Se assumirmos uma valor médio de R$ 40,00 por hora, já temos um prejuízo de R$ 200,00 com apenas um bug.

Você deve estar pensando naquela sua planilha lotada deles né? Acertei? Que coisa!

Cenário 3 : Bug encontrado em produção
Dessa vez vamos falar do pior cenário, o cliente achou o bug. Primeiro que você vai ouvir um monte de abobrinha do cliente, e com razão. Você vai ter que dar um suporte telefônico pra ele, tentar entender o que ele está dizendo, dificilmente você terá um cenário igual ao dele, você perderá tempo montando o cenário, depois que conseguir reproduzir o bug irá registrá-lo, o programador terá que entender, corrigir, gerar uma build, ir pra teste, publicar no cliente, testar novamente. Ufa!!! Nessa brincadeira, você perdeu tempo do gerente do projeto, analista de negócio, team leader, programador, testador e do implantador.

Assumindo duas horas pra cada recurso, que ainda é pouco, e um valor médio, dessa vez ,de R$ 50,00 por hora, afinal gerente e analista ganham bem 🙂 A brincadeira ficou R$ 600,00. Bugzinho caro né?

Vamos fazer uma continha simples agora. 15 bugs por mês no cenário 2, mais 2 bugs do cenário 3 e no final de um ano temos um gasto com bugs em apenas um projeto de R$ 50.400,00.

Resumindo:
Bugs em um ano de projeto: R$ 50.400,00
Licença do Team System: Menos de US$ 15.000,00 (se for parceiro, pode ser até free)
Ver seu cliente feliz com o sistema sem bugs e renovando contratos: não tem preço

Impressionante como a implantação do Team System e os testes unitários no cronograma ficaram baratos de repente.

Um grande abraço
André Dias