SCRUM X Prototipação X Documentação

Creio que a maior parte dos problemas que ocorre nos projetos de desenvolvimento de sistemas têm origem na fase de levantamento de requisitos.

Basicamente, existe todo um trabalho para efetivamente realizar o LEVANTAMENTO dos requisitos e uma outra etapa seguinte para DOCUMENTAR estes requisitos. Feito isso, praticamente com base apenas na DOCUMENTAÇÃO, o sistema é desenvolvido.

Outra grande problemática da documentação é a seguinte: Como  conciliar a documentação que será aprovada com o CLIENTE com a documentação técnica que será utilizada pelo DESENVOLVIMENTO? Como atender ambos? Como manter atualizada a especificação nas “duas versões”?

Se olharmos apenas a questão da comunicação verbal, podemos dizer é inerente ao ser humano filtrar as informações, tanto quem transmite, quanto quem recebe. Neste processo, queira ou não, a informação sofre os efeitos da GENERALIZAÇÃO, da DISTORÇÃO e da OMISSÃO.

Sinceramente, na minha opinião, DOCUMENTAR REQUISITOS com fins para a etapa de DESENVOLVIMENTO é esperar o mesmo daquela brincadeira que fazíamos quando criança na escola… a brincadeira do TELEFONE SEM FIO. A qualidade essencial necessária à documentação não é limitada pela metodologia utilizada e sim pela limitação da linguagem da comunicação e todos os problemas inerentes à ela.

A documentação portanto, por melhor que ela seja, será apenas a PONTA DO ICEBERG…

Veja abaixo os problemas mais comuns que podem ocorrer (por melhor que seja a documentação):

#Problemas com Stakeholder:

– Usuários não sabem o que eles querem.
– Usuários que não querem concluir a escrita do conjunto de requisitos.
– Comunicação com o usuário é lenta
– Os usuários freqüentemente não participam nas revisões ou são incapazes de fazer isto.
– Os usuários são tecnicamente poucos sofisticados.
– Os usuários não entendem o processo de desenvolvimento.
RESULTADO: Isto deve levar a situações onde os requisitos do usuário continuam mudando mesmo quando o desenvolvimento do sistema ou produto já se iniciou.

#Problemas de Engenheiros/Desenvolvedores:

– Pessoal técnico e usuários finais têm vocabulários diferentes. Conseqüentemente, eles podem acreditar que estão em perfeito acordo até que o produto final seja entregue.
– Engenheiros e desenvolvedores tentam ajustar os requisitos para um sistema existente ou modelo, em vez de desenvolver um sistema específico que atenda as necessidades do cliente.
– A análise é freqüentemente conduzida por engenheiros ou programadores, ao invés de pessoal com habilidade e conhecimento do domínio para compreender as necessidades dos clientes.
Fonte: wikipedia

SOLUÇÕES

Entre as técnicas introduzidas nos anos 90 para amenizar esses problemas, destaco a PROTOTIPAÇÃO e o SCRUM.

A PROTOTIPAÇÃO sempre foi para mim uma grande ferramenta, pois associada ao SCRUM, possibilitava 2 grandes vantagens:

  • DOCUMENTAÇÃO MUITO MAIS SIMPLES
  • OS CONFLITOS DE ENTENDIMENTO DE REQUISITOS ERAM TODOS RESOLVIDOS QUANDO NA APROVAÇÃO FORMAL DO PROTÓTIPO (OU SEJA: ANTES DE INICIAR O DESENVOLVIMENTO!!!)

Destaco entretanto, um cuidado que devemos ter no SCRUM ao PRIORIZAR e SELECIONAR as tarefas que serão desenvolvidas.

Não irei me aprofundar na questão sociológica da coisa, mas existe uma tal de visão mecanicista e uma tal de visão sistêmica das coisas. A primeira basicamente se preocupa em enxergar apenas as partes, ou seja, o detalhe. Já a segunda basicamente se preocupa enxerga como as partes se “encaixam” umas nas outras, ou seja, a visão do todo.

O ideal, também no desenvolvimento de sistemas, é ter ambas as visões.

Com o SCRUM, é preciso ter cuidado, pois pode corre-se o risco de se enxergar apenas as PARTES e, sem uma visão do TODO, haverá problemas depois para conseguir ENCAIXÁ-LAS umas nas outras…

Como na ENGENHARIA, para se calcular as fundações de uma obra é primeiro necessário saber o que ELA TERÁ QUE SUPORTAR. Analogamente, a estrutura de um sistema vai depender do resultado final que será entregue ao cliente.

Por isso, costumo adotar a seguinte técnica: Associar as estórias e tarefas do SCRUM à protótipos e “COMEÇAR PELO MEIO“:

  • Inicie com a elaboração e aprovação dos PROTÓTIPOS referente às telas e rotinas que geram MOVIMENTOS e TRANSAÇÕES no sistema (“tabelas fato”). Como o nome diz, é DE FATO ONDE TUDO ACONTECE!!!. Sim… são as telas e rotinas MAIS CABELUDAS que devem VIR PRIMEIRO!!! (nada de começar com a tela de cadastro de CLIENTE!!!!).

 

Se você tiver protótipos bem feitos nesta etapa (e que preferencialmente já adiantem o trabalho dos programadores) e aprovados, a estrutura de dados estará definida e, o produto final a ser entregue ao cliente (ou seja, aquilo que ele irá receber: relatórios, consultas, etc), será mera questão de layout e não irá conflitar com os protótipos já aprovados.

Assim, no meu ver são estes PROTÓTIPOS e ESTÓRIAS DE USUÁRIOS que devem ter prioridade no SCRUM. O PRODUCT OWNER e o SCRUM MASTER precisam estar atentos ao priorizar e selecionar as tarefas de cada SPRINT de forma que no final não ocorra RETRABALHO DEPOIS para ENCAIXAR as PARTES.

Era isso pessoal!!! Espero que tenham gostado!!!

Se quiserem aprofundar a discussão do tema, comentem abaixo o post.

Ubirajara Theodoro Schier

Diretor de Desenvolvimento, Scrum certificado

 

 

 

Anúncios

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair /  Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair /  Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair /  Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair /  Alterar )

Conectando a %s