Skip to content


Porque as metodologias de software ajudam

Ando há alguns anos a programar e apesar de ter gerido o primeiro projecto para um cliente externo em 2001, o que é certo é que passei a maior parte da minha vida de programador a gerir projectos pequenos, ou em que a programação era feita por mim. Traduzindo, durante anos, achei que simplesmente utilizar uma metodologia era overhead a mais.

As coisas mudaram, não tanto por os projectos terem aumentado, mas porque sinto a necessidade cada vez maior de conseguir responder à pergunta “e quando é que isto está pronto?” (é o tipo de coisas que dá jeito saber quando para marcar férias).  Tenho experimentado SCRUM (e se tudo correr bem, vai haver alguns artigos sobre o assunto aqui no blog) e descobri qual é a razão que as metodologias de software (ok, pelo menos as Agile – o que experimentei das outras não se aplicava aos meus casos) ajudam: obrigam a definir o que o cliente quer antes de começar a implementar.

Um cliente tem dificuldade em aperceber-se da complexidade do software, tal como os programadores. Criando a disciplina de nunca começar nenhuma tarefa antes de saber os resultados tem dois efeitos milagrosos: o cliente começa a ter cuidado com o que pede e não se desperdiça tempo de programação. Permite também tornar simples ao cliente acompanhar a evolução do projecto: acesso ao backlog e à gestão de tarefas torna-se simples (no caso de usarem folhas de cálculo, uma partilha no dropbox basta). Resolve-se assim o outro desperdiçador de tempo máximo “mas o que é que vocês estão a fazer?”, que deve ser traduzido por “como é que vocês estão a usar o MEU dinheiro?”.

Resumindo, a principal desvantagem é passar mais tempo na definição antes do início de realização uma tarefa. As vantagens:

  • Optimização mental ao separar uma fase de análise (definição da tarefa) de uma fase de síntese (construção do software).
  • Eliminação de desperdício de tempo e trabalho, graças a uma boa definição das tarefas.
  • Ajudar a tornar os resultados mais geríveis (previsíveis só ao longo de muito tempo).
  • Automatizar, parcialmente, o acompanhamento por parte do cliente.

Posted in Gestão.

Tagged with , , .


3 Responses

Stay in touch with the conversation, subscribe to the RSS feed for comments on this post.

  1. Alcides Fonseca says

    Então e cobras ao sprint ao cliente, ou como adaptas o orçamento ao desenvolvimento do projecto?

  2. mestrejoao says

    Há 3 cenários possíveis:

    1. O projecto é pago em fases, com milestones definidas. Nesse caso é de acordo com esse plano.
    2. O projecto é aberto, mas o cliente quer alguma segurança. Cada sprint corresponde a um contrato e o cliente paga pela implementação daquelas userstories.
    3. O projecto é aberto e o cliente tem experiência larga em gestão e/ou informática. Cada sprint é cobrado como times&materlal.

Continuing the Discussion



Some HTML is OK

or, reply to this post via trackback.