Small Project Philosophy

Tenho navegado muito entre pequenos e grandes projetos, mas se por um lado é verdade que cada projeto e cada equipe possui suas características e um processo evolutivo próprio, há com certeza nuances comuns entre grandes ou pequenos projetos que somente quem participa deles consegue diferenciar e entender.

Há uma aura diferente conforme o porte das equipes e projetos. Equipes pequenas em projetos pequenos nos permitem uma fluides maior, com uma abordagem ágil e reducionista (*). Permitir-se estabelecer ciclos finitos, com horizonte próximo, com foco e valor, algo que em projetos muito grandes é um desafio além da conta, exigindo maior atenção e energia para tudo, pois tudo, mesmo as pequenas coisas são enormes.

(*) Reducionismo é uma tendência que consistente em reduzir os fenômenos complexos a seus componentes mais simples e considerar estes últimos como mais fundamentais que os fenômenos complexos observados. Não é perder o todo de vista, mas pensar cada parte para integrá-las e chegar ao todo, é o MVP da ciência, especialmente da filosofia.

Atrás de estudos e dados que me ajudem e legitimem nesta abordagem, o Standish Group edita anualmente um relatório chamado Chaos Report, que gera um diagnóstico da evolução de projetos de software, com foco especial em projetos pequenos mundo afora – Chaos Manifesto 2013: Think Big, Act Small! Neste estudo do Standish Group fica claro a proporção destes desafios:

Se por um lado, grandes projetos e grandes equipes podem parecer inevitáveis para algumas empresas e profissionais, é indiscutível que a opção mais saudável é optar por modularizar e gerar serviços. Um grande projeto pode ser racionalmente fracionado e cada módulo transformado em cliente e fornecedor de outros módulos, assim como grandes equipes:

Mas assim como tantos outros paradigmas em cheque pelas metodologias ágeis, carece de bom senso e evolução, mas bom senso não se compra em drágeas na farmácia. Novas alternativas exigem desapego a conceitos mezozóicos de gestão de projetos via processos waterfall, com centralização de comando, traduzindo gestão por controle, certos de que sem controle absoluto não há salvação.

Uma busca pela palavra AGILE no Chaos Manifesto de 2013 gera exatas 59 ocorrências, com passagens excepcionais, como:

Pág 01: “we have seen an increase in the number of smaller projects and agile projects. Further, we have seen a decrease in waterfall projects”;

Pág 03: Os dez maiores fatores de sucesso em pequenos projetos (2º é envolvimento do cliente, 6º são processos ágeis – “The agile process directly addresses user involvement, executive support, and the other success factors”;

Pág 04: “It is critical to break down large projects into a sequence of smaller ones, prioritized on direct business value, and install stable, full-time, cross-functional teams that execute these projects following a disciplined agile”;

Pág 04: “The quick solution is to just say no to large projects, but the more sensible answer is to adopt a small project strategy. Many companies routinely deliver software at half the cost and less than half the defects“;

Pág 10: “Some agile methods, such as XP, have users embedded into the team to improve cooperation. This cooperation builds a rapport with the rest of the team members and provides for mutual empathy.”;

Pág 25: “The agile process is now perceived as the universal remedy for software development project failure … The secret is the trial and error and delivery of the iterative process. Software should be built in small, iterative steps with small, focused teams. The project team delivers functionality in small bites”;

Pág 25: Aos saudosistas do waterfall um alento, é possível desenvolver pequenos projetos com etapas, documentação extensa e especialistas, se este for o seu caso, esqueça tudo o mais e foque no gráfico abaixo:

Pág 28: “… you can optimize for microprojects; in agile terminology this is often called a release”;

Pág 43: “The agile process has built-in quality and is test-driven, which help both small and larger projects. One hour of testing during a steppingstone is equal to 24 hours of testing after the project is complete.”

Finalmente, falando sobre o Centro de Inovação do Standish e seus resultados – “This process is based on iterative development, where requirements and solutions evolve through collaboration among self-organizing, cross-functional teams. The agile process encourages frequent inspection and adaptation, teamwork, self-organization, and personal accountability. The agile process allows for rapid delivery. In theory, it hopes to align development closer to the users’ needs by continuous collaboration and delivery of a concrete product.”

Em certo momento o texto provoca: “Maybe you are not ready to take the full leap to a small project philosophy. Maybe you just do not believe it will work in your organization … ”

Então, boa sorte!