Siga-me por email

segunda-feira, 27 de agosto de 2012

SCRUM - Utilize com parcimônia

Há algum tempo vejo os meus alunos que já estão integrado no mercado de trabalho, desenvolvendo softwares e utilizando processos e metodologias dando-me pareceres equivocados sobre SCRUM e processos de desenvolvimento de software.

Isto me motivou a escrever um artigo sobre o assunto!

Quem estiver interessado em ler o artigo basta acessar: AQUI.

Para facilitar, também copie e colei o artigo logo abaixo:

--------------------------------------------------------------------

Utilize com parcimônia


É impressionante a quantidade de empresas de desenvolvimento de software que vem utilizando o SCRUM. Por meio de uma rápida pesquisa na Internet é possível verificar nomes de grandes empresas brasileiras que já estão utilizando o SCRUM, como por exemplo: UOL, Vivo, Petrobrás e outras. Mas será que as empresas brasileiras estão utilizando o SCRUM da forma correta?
Fazemos esta pergunta porque, em sala de aula, toda vez que começo a falar do tópico SCRUM, eu pergunto primeiramente aos meus alunos: “quem trabalha em empresas de desenvolvimento de software e utiliza SCRUM?”. Depois, para aqueles que levantaram a mão, eu pergunto: “qual processo de desenvolvimento de software é utilizado por sua empresa?”; quase todos respondem: SCRUM. Entre outros aspectos da aplicação do SCRUM pelas empresas que merecem atenção (há outros que falaremos em outros posts deste blog), esta confusão de que o SCRUM é um processo de desenvolvimento de software é um dos principais equívocos.
Se você achou o argumento da resposta dos alunos em sala de aula fraco, então, você pode observar que a maioria dos blogs disponíveis na Internet sobre o assunto, escrito por professores universitários ou ainda profissionais da área, também mostram esta confusão de conceito. Veja este post, ou este ou este. Todos contém a frase “scrum é um processo de desenvolvimento de software”.
Para entender melhor o que eu estou dizendo, primeiramente temos que entender (e as empresas também) o conceito de processo de software, o conceito de SCRUM e comparar os dois mostrando as diferenças.
Segundo (SOMMERVILLE, 2009), processo de desenvolvimento de software é um conjunto de atividades correlacionadas que levam à produção de um produto de software e que, de uma forma ou de outra, incluem atividades de especificação de software, projeto (arquitetural, interface…) e implementação de software, validação de software e evolução de software (manutenção).
(PRESSMAN, 2006) traz uma definição muito parecida e diz que um processo de software contém um número de atividades de arcabouço que, de forma genérica, é aplicável a grande maioria de projetos de software e inclui comunicação (que abrange o levantamento de requisitos e outras atividades relacionadas), planejamento (que esta relacionado ao plano de trabalho para o desenvolvimento do software), modelagem (criação de modelos para entender melhor o software que será construído), construção (implementação do código e testes) e implantação (entrega do software ao cliente).
Scrum, segundo definição do scrum.org em seu scrum guide (SCHWABER e SUTHERLAND, 2011), é um framework para suportar o desenvolvimento e manutenção de produtos complexos por meio de eventos, papéis, artefatos e regras, entre eles: um time scrum (equipe auto gerenciável para o desenvolvimento do produto), papel de scrum máster (para garantir o scrum), papel deproduct owner (conhecedor do produto a ser desenvolvido e responsável por ele), Sprint (tempo de planejamento e desenvolvimento do produto de forma iterativa), backlogs (requisitos e funcionalidades referentes ao produto e ao que será desenvolvido na sprint) reuniões de planejamento, revisão e retrospectiva da Sprint (para planejar a sprint e revisar o que foi produzido pela sprint e o que aconteceu na sprint) e reuniões diárias (para sincronizar atividades e criar plano para as próximas 24 horas do desenvolvimento do produto dentro da sprint).
Com as definições em mãos podemos fazer algumas considerações:
1)    Pela definição de SCRUM vimos em um primeiro momento que ele não é um PROCESSO e sim um FRAMEWORK (estrutura de processo). Só por ai já deveríamos descartar que o SCRUM é um processo de desenvolvimento de software.
2)    Ainda pela definição do SCRUM, nada se diz em relação à software, ou seja, a definição diz que o SCRUM serviria para o desenvolvimento de qualquer produto complexo e não necessariamente software.
3)    Verificando o que compõem o SCRUM não é possível encontrar nenhuma atividade de requisitos, projeto ou modelagem de software, implementação, testes ou manutenção. Ou seja, em nada se parece com um processo de software.
Dito o acima, podemos perceber que a utilização do SCRUM como um processo de software é algo completamente equivocado e isto pode gerar produtos de softwares com baixa qualidade.
Além disso, este equívoco colabora para que a preocupação por entender a necessidade do cliente no produto de software desapareça nas empresas e também colabora para que perceber ferramentas importantes como casos de uso, diagrama de classe e ferramentas de teste desapareça dos processos de desenvolvimento de software das empresas com a desculpa de que o uso dessas é burocrático e não está previsto no SCRUM (lógico que não está definido no SCRUM, ele não foi construído para isto).
Mas isto não quer dizer que o SCRUM não possa ser utilizado junto com processos de desenvolvimento de software.
Voltando a definição do SCRUM percebe-se que este propõe uma estrutura de processo para o desenvolvimento de produtos complexos; sendo o software um produto complexo, podemos sim utilizar o SCRUM para tal. Contudo, dentro da estrutura de processos oferecida pelo SCRUM, é necessário “rodar” um processo de desenvolvimento de software baseado em algum modelo prescritivo ou ainda ágil como no caso do XP.
Em prol de produtos de software ofertados com qualidade aos clientes; do alto nível de profissionalização da área de desenvolvimento de software e pela manutenção da concorrência das empresas brasileiras produtoras de software frente à concorrência mundial é importante que as empresas e desenvolvedores de software parem de tirar qualidade do seu processo de desenvolvimento argumentando de forma sofista que fazem isso por serem adeptos de processos ágeis e passem a estudar melhor o que estão aplicando e a entender melhor o que é o processo ágil e o que ele pode trazer de bom e de ruim.
Marcos Danilo Chiodi – docente dos cursos de Administração e Gestão em TI no UniSEB Interativo.

0 comentários:

Postar um comentário