modern-times2

A Sprint e o Futuro da Aplicação

Antes de mais nada:

É importante ressaltar que não sou expert em Scrum e suas (prováveis e diversas) formas de aplicação. Exponho esses pensamentos, primordialmente, como reflexões da forma como já interagi com a ferramenta, e suas características.

O Problema:

Acredito que assim como em muitas da empresas que trabalhem com Tecnologia, o Scrum é utilizado como framework de gestão de projetos, e na empresa onde trabalho não é diferente. Afinal, o desenvolvimento de software é uma pratica, em vezes, nebulosa, extensa e de grande responsabilidade, e a utilizações de frameworks como o PMBok, podem tornar o processo ainda mais burocrático e complicado.

Mas, voltando especificamente ao Scrum, na minha visão, seu grande ponto forte, que é sua capacidade de entrega de pequenos pacotes de trabalho (estórias) em um curto espaço de tempo (sprint), o que torna o andamento do trabalho e sua evolução mais visível pode ser tornar seu grande ponto negativo, quanto a longevidade da solução.

Vejo que o scrum é uma prática que pode “cegar” a equipe, justamente pelo vício da pequena entrega continua, não se atentando a itens “maiores” ou básicos, como questões estruturais ou arquiteturais.

Resumindo:

O foco direciona-se tanto à entrega da funcionalidade e não necessariamente a Melhor Entrega da funcionalidade, que, um erro ou uma má pratica podem ser repetidos várias e várias vezes, em nome da entrega que está sempre logo ali…

E, se a base não estiver sólida, um grande volume de trabalho será feito de maneira desordenada e com crescentes índices de manutenção…

Uma possível solução:

Bom, vamos refletir sobre propósitos: Vejo que a Sprint atua mais como um meio com foco bem claro na execução. Rápida e compassada do que precisa ser feito.

Dessa forma, acredito que uma estrutura auxiliar seria necessária para suprir os integrantes da Sprint com esses insumos de base, ora com novas boas práticas, ora com novas ferramentas.

Resumindo:

Duas equipes ou papeis:

  1. Uma, com a Sprint de Negócio, executando com performance, não se preocupando com pormenores do sistema e questões estruturais
  2. E outra, mantendo padrões e evoluções de tecnologias e componentes para as equipes das Sprints de Negócio, justamente não se preocupem com essas questões e não gerem pausas ou grande fatores de indecisões.

Esquema - Sprint

 

Categories: Filosofando

  • Herick

    Minha opinião, mas penso que, assim como todos os problemas de TI, aqui também não existe bala de prata.
    Vejo o Scrum como excelente ferramenta para deixar todos os envolvidos bastante focados nos problemas da vez (sprint) e botar todos os grandes problemas em evidência, entre outras coisas, ou seja, todos os envolvidos realmente envolvidos. Porém (sempre tem um porém), isso é o mesmo que dizer que a democracia é uma excelente forma de governar com a participação de todos (não precisa disfarçar a coceira ao ler isso). A ferramenta ser boa para dado problema infelizmente não implica na execução de todo o processo de forma satisfatória.
    A falta de visão de longo prazo no projeto não me parece uma falha no Scrum mais do que os problemas de escalabilidade do JSF me parecem um problema do Java, simplesmente estas ferramentas não foram especificadas à prova de corrupção por outras partes inseridas no processo.

    Como dizia minha avó, muito melhor o Scrum do que nenhuma definição de processo, mas pra não focar na folha e perder de vista a floresta, continua sendo de suma importância a atenção a outros “detalhes”, entre eles o contato constante e o feedback do usuário, a proximidade entre quem vende e quem faz, o comprometimento da equipe com o processo e, claro, reuniões periódicas com o objetivo maior de dar visão a todos do Norte do projeto, mesmo que às vezes este Norte mude de direção! Mas enquanto ficamos à espera de outros frameworks que formalizem detalhes como esses, o Scrum pode ajudar a não perder de vista pelo menos o curto e médio prazo.

    • admin

      Grande Herick! kra, Também gosto do Scrum, e acho ele bem bacana, principalmente comparado com o PMBok e sua forma consideravelmente mais burocrática de lidar com projetos. Minha grande preocupação é com o vício numa parte específica de sua prática: A Sprint, ou, no espírito da Sprint, que é imediatista. Fator que pode inebriar os envolvidos muito a questões ditas essenciais à entrega, produzindo anomalias em nome dessa entrega no tempo certo. Por isso defendi uma equipe de apoio, para que essa equipe diminua essas preocupações (e riscos), principalmente, em cenários com desenvolvimento misto, de negócio + arquitetura…

  • http://www.rodrigokono.net Rodrigo Kono

    O controle da arquitetura já possui um backlog. Não acho que o desleixo da base do software está na troca pela “fatura” da entrega rápida.

    Acho que um time imaturo pode ser facilmente cegado na “pressão”de entregar o seu bloco. Apenas bate o martelo mecanicamente e não sabe o que está acontecendo na verdade (e nem quer saber).

    Esse não é um problema do Scrum. Está mais voltado naquele velho conto da qualidade x quantidade. O que entendi que você quis dizer foi algo como: “Scrum mede velocidade, foca na queima de tarefas.. E não tem qualidade nesta correria”.

    []s

    • admin

      Não necessariamente… o que quis ressaltar foi que a Sprint PODE levar os executores a se cegarem, já que a exigência de uma entrega, literalmente cronometrada, aparece com mais evidência. O que pode tornar a execução de algumas tarefas ou procedimentos “perda de tempo” ou preciosismo. Por isso defendi uma divisão de equipes, com uma de base, para dar suporte justamente a estas questões para a equipe de alta performance.