Archive for December, 2007

Globo Vídeos em Flash!

Wednesday, December 19th, 2007

Globo Vídeos Flash PlayerNem acredito que finalmente o Globo Vídeos mudou para Flash! Desde às 05:53 da manhã de hoje toda a nova infraestrutura de Flash Vídeo da Globo.com está em produção e funcionando muito bem, obrigado. Com isso nós nos igualamos aos maiores players do mercado como YouTube, Yahoo! Video, Metacafe e blip.tv.

Muitas pessoas sempre me perguntavam porque a Globo.com usava Windows Media ao invés de Flash. Não posso entrar nos detalhes dessa decisão mas só para deixar as coisas mais claras, não era uma decisão técnica e sim de negócio. Como usuário do Globo Vídeos eu também sempre estive muito ansioso para que os vídeos fossem em Flash mas infelizmente não era possível. Agora, com todas as arestas aparadas, finalmente estamos disponibilizando vídeos numa tecnologia mais moderna e com muito mais qualidade de imagem do que a versão anterior (e vai melhorar!). Além disso agora passamos a atender também os usuários de Linux e Mac.

O mais legal dessa história toda é que todo o projeto foi implementado em menos de um mês! Esta primeira fase do projeto durou exatamente 4 semanas, desde estudar Flash até a migração de toda a infraestrutura, re-programação do site, produção de vídeos no novo formato, confecção do player e etc. Utilizar um processo de desenvolvimento ágil como Scrum foi essencial para organizar/planejar o trabalho e também possibilitou essa façanha de fazer uma quantidade de trabalho considerável em 4 semanas.

2008 promete. Muitas novidades virão por aí!

Certified Scrum Master!

Monday, December 10th, 2007

Curso de ScrumNa última semana tive a oportunidade de assistir ao treinamento de Scrum da Sprint iT. O instrutor foi ninguém menos que Boris Gloger, que foi o primeiro Scrum Master treinado pelo Ken Schwaber em pessoa!

Nem preciso dizer que o curso foi sensacional – fora o fato de ter me tornado o mais novo Scrum Master do pedaço! O Boris têm uma didática excelente e tive a oportunidade de tirar várias dúvidas que vinham me perturbando há algum tempo. Apesar de já ter lido alguns livros sobre Scrum esse treinamento conectou vários conhecimentos na minha cabeça e eu me sinto agora com uma visão clara como cristal de como tudo funciona.

Para ter uma idéia melhor de como é o treinamento você pode ler dois posts do José Papo resumindo a agenda e dando suas opiniões em seguida.

O curso é cheio de surpresas e eu não vou contar nada aqui para não estragar a experiência. Mas o ponto é que através de exemplos extremamentre simples e didáticos a mensagem é transmitida. É impossível não sair da sala no fim do dia extremamente motivado a mudar!

WUFF!

Cronogramas não funcionam

Tuesday, December 4th, 2007

Gantt ChartUma vez participei de um projeto que tinha um cronograma gigantesco tentando prever alguns meses de trabalho. Como de costume esses mega-projetos estão descritos em um também gigantesco Gantt Chart (se você não sabe do que eu estou falando veja a imagem ao lado).

O software que estávamos desenvolvendo era super específico e estavamos lidando com uma série de variáveis desconhecidas. Por exemplo, uma das partes do projeto era fazer integração com um sistema em C utilizando um protocolo não muito bem documentado baseado em HTTP. Para esta tarefa o gerente de projeto estimou “5 dias”. Quando eu perguntei como ele fez para estimar 5 dias sem nem mesmo saber exatamente como funciona o protocolo HTTP, a resposta foi a tradicional: “ah, eu chutei o valor pra cima porque não tinha muita certeza”. Como assim chutou pra cima? De onde ele tirou que isso é “para cima”? (só de curiosidade, no fim das contas a integração levou 3 semanas…)

Assumir que coisas deste tipo levarão tempos pré-determinados não funciona. O que esse gerente fez é tão tosco quanto um exemplo que tem no livro do Ken Schwaber: “para cada 4 classes, 3.5 designers completarão uma tarefa em 16 horas”. Acredite, esse é o tipo de “técnica” que os gerentes de projeto CMM Level 5 Certified utilizam para definir esses cronogramas malucos.

Além disso para poder fazer esse tipo de cálculo considera-se que as pessoas conseguem fazer uma determinada quantidade de trabalho por dia. Aí eu pergunto: isso leva em conta um dia de trabalho de um profissional bem treinado, bem qualificado, bem supervisionado, totalmente consciente, sem problemas pessoais, começando de manhã após um copo de café expresso? Ou seria um dia de trabalho de uma pessoa qualquer?

É por isso tudo que esses projetos sempre atrasam!

O que é preciso enxergar é que o processo de desenvolvimento de software não é uma linha de produção, não é executado por robôs e por isso não se pode determinar exatamente o que acontecerá durante um longo período de tempo. Além disso o processo envolve muita criação e não se pode garantir que os produtos finais sempre serão os mesmos ainda que aplicado o mesmo método de trabalho. Veja, produzir um carro, por exemplo, envolve uma série de atividades encadeadas e repetidas. Se você produzir 8.000 carros todos passarão pelo mesmo processo de fabricação e no fim do processo você terá 8.000 carros idênticos fabricados na mesma quantidade de tempo. Mas se você entregar o mesmo projeto de software para 8.000 programadores diferentes é totalmente possível que no final você tenha o mesmo problema resolvido de 8.000 formas diferentes e em prazos totalmente diferentes dependendo do nível de conhecimento, linguagem/tecnologias adotadas e etc.

No projeto que estou trabalhando atualmente fazemos diferente. Não definimos um prazo de entrega para o projeto inteiro mas sim a data de entrega dos Sprints (as iterações do Scrum). Fazendo análise e desenvolvimento de forma incremental os riscos são bem menores e é muito difícil alguém não levantar uma bandeira amarela antecipadamente caso uma estimativa esteja totalmente fora da realidade como a que eu citei. Mesmo não tendo muita flexibilidade nas datas de entrega acho que as pessoas se sentem mais confortáveis assim porque sempre estamos entregando alguma coisa e não atrasamos. O máximo que já aconteceu foi cortar a última história do Sprint (que voltou para o backlog e acabou nem entrando no Sprint seguinte), mas mesmo assim eu sinto que as pessoas ficam mais satisfeitas.

Sempre que esse papo vem á tona alguém pergunta: e como eu controlo o projeto? Quer ver um exemplo: sabendo que a nossa equipe faz Sprints de 15 dias nossos clientes decidiram que nós deviamos desenvolver determinadas funcionalidades chave para que agora no fim do segundo Sprint possamos fazer um release em produção de um software novo. Além disso eles participam ativamente das reuniões de planejamento dos Sprints e decidem quais tarefas serão feitas por nós. Quer mais controle que isso?!?

Por isso tudo que eu acredito que os cronogramas não são eficientes. Em alguns casos já é difícil planejar um Sprint de 15 dias, imagina projetos de meses ou anos? Fico me perguntando se esse projeto desse Gantt Chart (aquela imagem do início – achei no Google Images) foi entregue na data certinha que está especificada alí… Eu duvido!