Nivelando por cima

Hoje em dia, entre desenvolvedores, não se fala em mais nada que não seja em Scrum para metodologia de gerenciamento de projeto.  Embora o Scrum não seja uma metodologia  e embora seja utilizável em qualquer tipo de projeto o casamento Scrum-XP veio com toda a força especificamente para área de desenvolvimento.

Não é que eu seja cético em relação a estas ideologias, mas ha pouco sobre como a executar na prática e mais que isso dados que possam ser uteis para convencer outros. Claro que é tudo uma questão de como as pessoas e as organizações pensam, mas , no fim, tudo se resume a uma posição pessoal.

Então, eu tinha algumas duvidas sobre como seria possível integrar essas metodologias .. perdão, ideologias, com o processo de design e definição de arquitetura que é necessária a todo o projecto de software. Muitas pessoas dizem que em XP/Scrum não ha espaço para isso e que o software vai-se fazendo aos poucos. Que não ha espaço para um design anterior à codificação. Isso sempre me pareceu absurdo porque seria como colocar os programadores fazendo tarefas sem saber o objetivo final ou como elas se encaixam.

Depois de assistir uma das palestras do Ken Schwaber para o Google Tech Talks sobre scrum fiquei mais confiante que não sou louco e que realmente é um absurdo começar a programar um sistema sem ter uma arquitetura ou um design. A diferença é que esse design/arquitetura não é implementado todo de uma vez ou antes que a aplicação seja programada. Pela obrigação de entregar algo pronto (  e pronto significa: codificado, testado e documentado) no fim do sprint é preciso ir implementando requisitos funcionais e não-funcionais simultaneamente.  Claro que  usando frameworks já prontos isso pode diminuir bastante  a lista de  tarefas relacionadas a  requisitos não-funcionais .

O próprio Ken explica como o scrum nada mais é do que uma compilação de boas ideias que já existiam antes. Então nada foi realmente inventado e o mérito está na simplicidade do processo e das regras. Como tb o Ken exemplifica é como no Xadrez, as regras são poucas e simples, mas o numero de jogadas ilimitado… ou melhor, limitado apenas pelas capacidades dos jogadores. Dai a segunda frase.

O scrum funciona basicamente como uma panela de pressão booleana. Ou sai algo pronto, ou não sai nada. Não ha meio termo.Assim é fácil saber rapidamente quem é o elo mais fraco na equipe ou na organização, se a organização está pedindo demais, etc… a conclusão é que ou vc participa e leva o sprint a bom termo ou vc está na lista negra de alguem. Não ha como mascarar os defeitos da equipe ou do processo.

Ora isto leva uma grande pressão a quem quiser usar Scrum (XP é  semelhante)  porque  sobre pressão  ou o carvão vira diamante ou vira pó de grafite. A qualidade profissional dos membros da equipe vem à tona rapidamente e mesmo sobre o escopo da máxima do XP que a responsabilidade é da equipe como um todo, é obvio que não tardará a que a equipe elimine o elo mais fraco, por uma pura questão de auto-preservação.

Parece-me então que a dificuldade maior em adotar ou convencer alguém a adotar Scrum/XP está neste problema  (além do problema clássico de não saber como começar).  Ao começar, com pequenas experiências os problemas se tornarão visíveis rapidamente e quem não tem capacidade para aguentar a pressão desiste. Se essa pessoa é quem decide se se usa scrum ou não, então é bom de ver que ela vai deixar de usar.

Outra coisa que achei interessante é que os sprints considerados normais são de 1 mês.  O numero de meses que demora a terminar a lista de tarefas ( o backlog) é proporcional à velocidade. A velocidade por sua vez é a medida de quantas tarefas são prontas por mês , i.e. de quando o backlog diminui.  Ora, isto significa que, no inicio do projeto ninguem sabe quanto tempo será necessário para terminar a lista, mas lá pelo segundo ou terceiro sprint, já se tem uma idéia via projeção linear. Ou seja, depois de 2 meses teremos uma previsão de quando o projeto acabará. Isto é totalmente concebivel para projetos internos , sobretudo os que não são de software, mas para projetos de software com prazo determinado isto é simplesmente naceitável.

A duvida que me resta é se é possível , sequer, utilizar esta técnica simplista em projeto de prazo determinado e especialmente como avaliar o tempo necessário. Alguns poderão dizer que este tipo de projeto é ultrapassado, mas o fato é que isso é uma falácia. Eles existem. E sendo assim, como encaixar os dois paradigmas ?

Anúncios

2 opiniões sobre “Nivelando por cima”

  1. Sérgio,

    Na verdade quando o projeto exige (como a grande maioria deles) um prazo definido, são usadas algumas técnicas de estimativas e planejamento ágeis.

    Se quiser ler mais sobre o assunto, recomendo o ótimo livro “Agile Estimating and Planning”

    Abraços

Deixe uma Resposta

Please log in using one of these methods to post your comment:

Logótipo da WordPress.com

Está a comentar usando a sua conta WordPress.com Terminar Sessão /  Alterar )

Google+ photo

Está a comentar usando a sua conta Google+ Terminar Sessão /  Alterar )

Imagem do Twitter

Está a comentar usando a sua conta Twitter Terminar Sessão /  Alterar )

Facebook photo

Está a comentar usando a sua conta Facebook Terminar Sessão /  Alterar )

w

Connecting to %s