O Diabo está nos detalhes

O trecho do livro Caindo na Real é chocante para alguns (tipo eu)... Vale a pena refletir... Só é um Problema Quando é um Problema Não desperdice tempo com problemas que você ainda não tem Você precisa realmente se preocupar em escalar para 100.000 usuários hoje se vai levar dois anos para chegar lá? Você tem mesmo que contratar oito programadores se hoje você só precisa de três? Você precisa realmente de 12 servidores top-de-linha agora se dá para rodar em dois por um ano? Apenas se vire As pessoas costumam gastar tempo demais logo de cara tentando resolver problemas que elas ainda nem têm. Não faça isso. Poxa, nós lançamos o Basecamp sem a habilidade de cobrar os clientes! Como o produto é cobrado mensalmente, sabíamos que teríamos um intervalo de 30 dias para dar um jeito. Usamos aquele tempo para resolver problemas mais urgentes e então, após o lançamento, enfrentamos a cobrança. Deu certo (e nos forçou a adotar uma solução simples, sem firulas desnecessárias). Não esquente com uma coisa até que você tenha de fato que fazê-lo. Não desenvolva demais. Aumente hardware e software de sistema conforme necessário. Se ficar lento por uma ou duas semanas não será o fim do mundo. Apenas seja honesto: explique para os seus clientes que você está passando por dores de crescimento. Eles podem não ficar empolgados mas apreciarão a franqueza. Resumo da Ópera: Tome decisões só no momento necessário, pois aí você terá acesso à informação real de que precisa. Entrementes você estará em condições de prestar atenção às coisas que requerem cuidado imediato.

Prazo, Orçamento e Escopo

Ontem escutei algo sobre “Prazo, Orçamento e Escopo”. Foi falado que devemos sempre monitorar esses três pilares, e que eles giravam/refletiam em torno da qualidade, ou seja, se você descontrola um dos pilares você compromete a qualidade.

Hoje iniciei a leitura de um livro que falava sobre o assunto. Achei a abordagem muito interessante. Então fica ai o trecho:

Fixe o Prazo e o Orçamento, Flexibilize o Escopo

Lance dentro do prazo e do orçamento

Aqui vai uma maneira fácil de lançar dentro do prazo e do orçamento: mantenha-os fixos. Nunca jogue mais tempo ou dinheiro em um problema, apenas diminue o escopo.

Existe um mito que diz o seguinte: podemos lançar no prazo, no orçamento e no escopo. Isso quase nunca acontece e quando acontece a qualidade normalmente sofre.

Se não puder encaixar tudo dentro do prazo e orçamento planejados então não aumente o tempo e o custo. Em vez disso, puxe o escopo para trás. Sempre existe tempo para adicionar coisas mais tarde – o mais tarde é eterno, o agora está voando.

Lançar alguma coisa grande que está um pouco menor em escopo do que o planejado é melhor do que lançar alguma coisa medíocre e cheio de buracos porque precisou atingir uma janela mágica de prazo, orçamento e escopo. Deixe a mágica para Houdini. Você tem um negócio de verdade para administrar e um produto real para entregar.

Aqui vão os benefícios de fixar o prazo e orçamento e manter o escopo flexível: Priorização: Precisaremos descobrir o que é realmente importante. O que vai chegar ao lançamento inicial? Isso força uma restrição que o pressionará a tomar decisões difíceis em vez de ficar hesitando. Realidade: Configurar expectativas é a chave. Se tentar fixar o prazo, orçamento e escopo, não será capaz de entregar com um alto grau de qualidade. Claro, provavelmente poderá entregar alguma coisa, mas “alguma coisa” é o que realmente quer entregar? Flexibilidade: A habilidade de mudar é a chave. Ter tudo fixado torna as mudanças difíceis. Injetar flexibilidade de escopo apresentará opções baseadas em sua experiência real de construir o produto. Flexibilidade é seu amigo.

Nossa recomendação: abaixo o Escopo. É melhor fazer meio-produto do que um produto meia-boca (mais sobre isso depois).

Um, dois, três ...

Como um projeto chega a estar um ano atrasado? Um dia de cada vez.—Fred Brooks, engenheiro de software e cientista da computação

Processos Ágeis de Desenvolvimento

A contínua busca por melhoria tem levado a equipe onde trabalho a encontrar novos rumos e retirar dos anos já vividos, experiências que nos façam refletir e agir/reagir. Em setembro, participei de uma palestra junto com alguns gerentes da empresa (Ricardo Fonseca e o Leonardo) que falava sobre "Gestão Ágil de Projetos com Scrum" e isso deu um ponto de partida a um diálogo sobre essa crescente tendência na área de desenvolvimento de software. Atualmente estamos com a mão na massa introduzindo alguns passos/técnicas que são pregados por algumas metodologias.

Hoje tivemos o primeiro diálogo aberto para contaminar toda a equipe de desenvolvimento com a visão de técnicas de desenvolvimento ágil. O Bruno Pedroso, da Sea Tecnologia esteve ministrando uma palestra sobre “Metodologias Ágeis e Extreme Programming” que envolveu pessoas de diversos papéis (Analistas de Negócios, Programadores, DBA´s e Gerentes de Projeto) na Search Informática.

Essas são as fotos do encontro e ficam aqui alguns pontos para se manter em mente: Valores: Comunicação, Coragem, Feedback, Respeito, Simplicidade. Práticas Primárias: Ambiente Informativo, Ciclo Semanal, Desenvolvimento Orientado a Testes, Design Incremental, Equipe Integral, Folga, Histórias, Integração Contínua, Programação em Par, Sentar-se Junto, Trabalho Energizado. Endereço do Fórum AgilDF: http://groups.google.com/group/AgilDF?hl=pt-BR

Gestão Ágil de Projetos com Scrum

Scrum é um processo ágil que está centrado na entrega de maior valor de negocio no menor tempo, ou seja, a cada período curto (duas a quatro semanas) espera-se ter software funcionando e pronto para ser entregue. Para isso são definidas prioridades para a evolução do software e a equipe se organiza para determinar qual é a melhor forma de entregar a funcionalidades de maior prioridade. Aos poucos o software é aprovado pelo cliente e conseqüentemente várias iterações são feitas até o final do processo.

A idéia é fugir de um planejamento exacerbado e trabalhar de forma “Just-in-Time”, onde só se planeja na hora em que se realiza, e se documenta somente o necessário. Isso evitaria milhares de documentos que dão muito trabalho e quase sempre não são utilizados em nada, sem contar com funções que custam caro e em sua maioria nunca são utilizadas.

É um assunto que merece nossa atenção para melhorar essa tão demorada forma de trabalho, onde passamos por um ciclo monstro e um tempo enorme para entregar simples módulos aos clientes.

Tem bastante informação em http://teamware.com.br/ e vai rolar curso aqui em Bsb sobre o assunto.