Publicado em 27 de Setembro de 2009 por mestrejoao

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.

Etiquetas: , ,
Publicado em Gestão | Comentários (3)

3 Responses to “Porque as metodologias de software ajudam”

  1. João Miguel Neves (jneves) 's status on Sunday, 27-Sep-09 08:54:22 UTC - Identi.ca Says:
    Setembro 27th, 2009 at 9:54

    [...] http://mestrejoao.silvaneves.org/2009/09/27/porque-as-metodologias-de-software-ajudam/ a few seconds ago from Gwibber [...]

  2. Alcides Fonseca Says:
    Setembro 27th, 2009 at 10:19

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

  3. mestrejoao Says:
    Setembro 27th, 2009 at 13:21

    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.

Leave a Reply