Costumo dizer que A analogia da casinha de cachorro de Steve McConnell para ilustrar como os projetos pequenos não são necessariamente representativos da dos problemas que o senhor encontrará em projetos maiores.
As pessoas que escreveram alguns programas pequenos na faculdade às vezes pensam que escrever programas grandes e profissionais é o mesmo tipo de trabalho, só que em uma escala maior. Não é o mesmo tipo de trabalho. Posso construir uma linda casinha de cachorro no meu quintal em poucas horas. Ela pode até ganhar o primeiro prêmio no concurso de casinhas de cachorro da feira do condado. Mas isso não significa que eu tenha o conhecimento necessário para construir um arranha-céu. O projeto do arranha-céu exige um tipo de conhecimento totalmente mais sofisticado.
Há uma passagem semelhante em Desenvolvimento rápido, que citei em Seguindo as instruções da lata de tinta.
O que acontece se o senhor não seguir as instruções? Se o senhor estiver pintando uma casinha de cachorro em uma noite quente de terça-feira após o trabalho, talvez tenha apenas duas horas para fazer o trabalho e o Totó precisa de um lugar para dormir naquela noite. O senhor não tem tempo para seguir as instruções. Talvez o senhor decida pular as etapas 1 a 3 e aplicar uma camada grossa em vez de uma fina na etapa 4. Se o tempo estiver bom e a casa do Totó for de madeira e não estiver muito suja, sua abordagem provavelmente funcionará bem.
Nos meses seguintes, a tinta pode rachar por ser muito grossa ou pode descascar das superfícies metálicas dos pregos onde o senhor não aplicou o primer, e talvez seja necessário repintá-la novamente no próximo ano, mas isso realmente não importa.
E se, em vez de uma casinha de cachorro, o senhor estiver pintando um Boeing 747? Nesse caso, é melhor o senhor seguir as instruções ao pé da letra. Se o senhor não remover a camada anterior, incorrerá em penalidades significativas de eficiência de combustível e segurança: uma camada de tinta em um 747 pesa de 400 a 800 libras. Se o senhor não preparar a superfície adequadamente, o vento e a chuva que atacam a tinta a 600 milhas por hora cobrarão seu preço muito mais rapidamente do que um vento suave e uma chuva na casinha do Fido.
A lição subjacente é a mesma: o que funciona para projetos pequenos pode ser um desastre total em uma escala maior. Ser um engenheiro de software competente significa escolher estratégias apropriadas para o tamanho do projeto em que o senhor está trabalhando. O senhor está trabalhando em uma casinha de cachorro, um arranha-céu, um avião a jato ou o ônibus espacial?
Talvez por isso eu tenha ficado tão entretido com o A postagem mais recente do blog de Steve. Ele documenta a construção de um forte para seus filhos. Não se trata de exatamente uma casinha de cachorro, mas está perto disso. Ao longo do caminho, Steve aplica suas consideráveis habilidades de estimativa de software e planejamento de projetos ao projeto. (Lembre-se, este é o cara que literalmente escreveu os livros sobre esses assuntos). Também é um projeto pequeno, portanto, nossas chances de sucesso são as melhores possíveis.
Sempre que faço um projeto de construção física como esse, tento prestar atenção em quais atributos do projeto são semelhantes aos projetos de software e quais são diferentes. As comparações tornam-se mais desafiadoras pelo fato de meus projetos de construção serem recreativos, enquanto tento fazer comparações com projetos de software comerciais. Na primeira metade do projeto, nenhuma boa semelhança me chamou a atenção. Mas quando o projeto começou a demorar muito mais do que eu esperava, comecei a ver cada vez mais semelhanças entre minhas estimativas sobre o forte e os problemas que as pessoas enfrentam com estimativas de software.
Como foi?
Os dias 3 a 6 foram mais ou menos como os dias 1 e 2, ou seja, houve muitas pequenas tarefas que acabaram se tornando tarefas de tamanho médio, houve pequenas tarefas que eu simplesmente não havia previsto e a maioria das coisas demorou mais do que eu havia planejado. No final do sétimo dia (meu dia de reserva), eu tinha terminado as tarefas que havia planejado para o terceiro dia e tinha começado um pouco o quarto dia, ou seja, eu tinha terminado o deck, não tinha começado as grades ou a estrutura, e tinha uma parede do forte emoldurada, mas isso era tudo.
Meu plano original previa cerca de uma semana em tempo integral e, em seguida, mais duas semanas para finalizar as pontas soltas, como pintura, instalação de acabamentos e assim por diante. Terminei o forte cerca de 6 semanas depois de tê-lo começado, portanto, fiquei cerca de 100% acima do cronograma planejado e acabei com um esforço 2 a 3 vezes maior do que o planejado originalmente.
Steve foi submerso nos detalhes imprevisíveis. Isso reflete completamente minha experiência em projetos de software. Muitas vezes, não é possível nem mesmo começar a estimar com precisão quanto tempo algo levará até que o senhor comece a fazê-lo. Pelo menos parte dela. É por isso que muitas equipes recorrem ao técnicas de desenvolvimento ágil e iterativoparte de cada iteração envolve explorar todas essas incógnitas e transformá-las em incógnitas um pouco menores para a próxima iteração. Quanto mais rápido a iteração for feita, mais rápido o, mais nos aproximamos de uma estimativa precisa e mais trabalho realizamos ao longo do caminho. Planejamos fazendo.
Esse é sem dúvida o meu post favorito no Blog do Steve até o momento. Faça leia o post completo para saber todos os detalhes sangrentos de como as coisas deram errado. É um exemplo de livro de histórias de como um avalanche de pequenos problemas pode se transformar em uma bola de neve com um enorme atraso no projeto, mesmo que o senhor seja Steve McConnell. E mesmo que o senhor esteja construindo apenas um casa de cachorro forte.