Durante um único dia de trabalho de uma equipe ágil temos alguns instantes que fazemos a reunião em pé do XP ou o encontro diário do Scrum. Esta mini-reunião é um ponto de sincronização do status do projeto (é uma inspeção no ciclo da iteração). O Scrum sugere que essa reunião tome o tempo máximo de 15 minutos. Dentro de um dia de trabalho de uma equipe ágil, fora desses poucos minutos preocupados com o gerenciamento a equipe trabalha no sentido de fazer incrementos de software funcionar de maneira “atômica”, isto é, um pequeno requisito é capturado e rapidamente transformado em software funcionando. Isso é o ciclo ágil de um dia. Assunto que tratarei na próxima edição da MundoJava.
Uma caracterísca marcante do ciclo ágil de um dia é que ele é não precisa ser gerenciado no nível macro, isto é, ele não pode ser tomado como base para o andamento do projeto como um todo. Somente com software funcionando e usuários felizes é que você pode dizer que o projeto andou. Este ciclo ocorre de maneira muito rápida e quem gerencia é o próprio desenvolvedor. Essa responsabilidade é uma cultura auto-organizável que faz parte do cerne do gerenciamento ágil. Gerentes de Projeto e Coordenadores não devem interferir no trabalho que é responsabilidade técnica dos desenvolvedores.
Os pontos que defendo aqui são práticas ágeis essencialmente constantes na metodologia XP e no TDD. Infelizmente essas práticas não são adotadas na maioria das equipes que tive contato. Um padrão muito comum nas equipes são práticas fantasiadas de Unified Process (ou RUP) que seguem um formato “Casos de Uso – UML – Codificação – Teste”, seguindo basicamente um processo em cascata numa escala menor. Este modelo dá a entender que requisitos estão em Casos de Uso (geralmente em documentos Word), o projeto ou arquitetura está no modelo UML (uma abstração intermediária), o código simplemente é algo que o computador compreende e, ao final, testes baseados no Caso de Uso são aplicados.
Primeiramente, gostaria de deixar claro que esta pode ser uma maneira de você implementar uma funcionalidade específica de um usuário com certo sucesso, porém, esse tipo de desenvolvimento não deve ser sequêncial e nem mesmo ser um padrão para todas as funcionalidades e nem para todos os projetos. Se a funcionalidade é simples e a expectativa do usuário está clara, documentos de Casos de Uso e modelos UML podem ser descartados. Porém, existem outras maneiras de você alcançar este mesmo objetivo! O próprio RUP não prega este tipo de prática.
Este anti-pattern causa uma cegueira técnica. O fato de sempre ter Casos de Uso, UML, Código e Testes em cascata leva a equipe a acreditar que todos os requisitos estão em casos de uso, temos que modelar tudo e codificar é uma atividade pouco criativa, assim como os testes. Porém, se verificarmos que estatisticamente somente um terço dos requisitos estão em casos de uso [Cockburn], que modelamos somente o que precisa ser modelado [Yoshima] e que todo o processo de desenvolvimento de software é uma atividade criativa (inclusive os testes [Fowler]), vemos que este padrão é muito questionável e muito dispendioso.
Você pode utilizar Casos de Uso para capturar requisitos e utilizar UML para analisar um problema. A culpa não é dessas ferramentas! O maior problema desse padrão é não conversar mais com os usuários depois que o Caso de Uso está escrito, roubando sorrateiramente a comunicação entre a equipe técnica e o cliente durante o desenvolvimento. Refinamentos surgem o tempo todo! A equipe precisa durante o desenvolvimento ligar para o cliente e tirar dúvidas! É comum que durante a codificação novos requisitos não capturados emergam. Requisitos capturados, modelados, codificados e testados podem não ser o que o usuário queria de fato, pois artefatos como Casos de Uso e modelos UML são propensos a muitas imperfeições (são abstrações e não são naturalmente executáveis).
Vejo que o padrão “Caso de Uso – UML – Codificação – Teste” é uma má influência do processo Waterfall, que declaradamente é uma péssima prática para desenvolvimento de software. Esse pensamento seqüencial é ainda mais danoso quando tentamos encaixar este padrão dentro da divisão e especialização de trabalho do Taylorismo, comum em fábricas de software. Nesse cenário, um analista de negócios escreve Casos de Uso, um analista de sistemas desenha o modelo, um programador codifica e um testador testa. Essa equipe muitas vezes utiliza artefatos para se comunicar (e logicamente, cada passo geralmente é controlado por um Gantt Chart). Antes de prosseguir, veja a citação de Kent Beck a respeito do Taylorismo:
“Especialização e rigorosamente dividir e conquistar serviu para produzir mais carros de maneira mais barata. Na minha experiência esses princípios não fazem sentido como estratégia para desenvolvimento de software. Nem para o negócio e nem para o lado humano eles fazem sentido.” Kent Beck
A base da divisão do trabalho é que é possível quebrar um determinado processo em partes menores gerenciáveis, e se cada parte for otimizada, o processo como um todo é otimizado. A especialização diz que determinado recurso efetuando uma tarefa várias vezes torna-se ótimo para esta tarefa. A questão é que para desenvolvimento de software, nem sempre a soma “Casos de Uso + UML + Código + Testes” geram algo do agrado do usuário se ele não estiver envolvido em todo o ciclo. Isso nos mostra que esses passos não são mensuráveis. Além disso, um analista de negócio não se tornará um analista de negócio melhor se ele escrever muitos Casos de Uso, assim como acontece com um Analista de Sistemas ou Programador.
Desenvolvimento de software não é um processo mecânico. Todas as metodologias atuais pregam um trabalho coletivo, em constante comunicação, entrosamento e principalmente uma visão holística sobre o projeto (o todo, e não as partes). Se apegar a rígidos papéis e responsabilidades é péssimo sob qualquer aspecto para uma equipe que desenvolve software.
Oi Rodrigo,
posso fazer minha estréia em seu (agradável) espaço? Claro, vou “chatear”!
Acho forte chamar aquela seqüência de “anti-pattern”. Não é. Concorco contigo, as ferramentas são mal utilizadas pra caramba! Mas isso não transforma a série “caso de uso-uml-código-testes” numa prática ruim.
Você mesmo destaca o risco: “O maior problema desse padrão é não conversar mais com os usuários depois que o Caso de Uso está escrito, roubando sorrateiramente a comunicação entre a equipe técnica e o cliente durante o desenvolvimento.”
Oras, que tal incentivar as conversas ao invés de condenar o uso daquela seqüência?
Mas, como notei em outras oportunidades (e fóruns), seu maior problema é outro: é com a “especialização”. Me permita deixar aqui um contraponto:
…”conhecimento, por definição, é especializado. Com efeito, as pessoas realmente detentoras de conhecimentos tendem ao excesso de especialização, qualquer que seja seu campo de atuação, exatamente porque sempre se deparam com muito mais a aprender.
“A organização baseada em informações exige, em geral, muito mais especialistas do que as empresas tradicionais do tipo comando e controle” – Peter Drucker (1988).
Quando falamos em especialização, desde o final do século passado, não estamos chorando de saudades de Taylor, Ford e seus asseclas. Estamos falando em trabalhadores do conhecimento, aquele *lado humano* das organizações (*negócios!*) baseadas em informações.
Coloquei o destaque acima pq o Beck fala em negócios e “lado humano” como se fossem coisas distantes. Estranho.
Bom, sei que não vou convencê-lo assim. Nem era minha intenção. Que os papos continuem. Mas que a gente siga aprendendo!
De novo, parabéns pelo blog. Abraços,
Paulo Vasconcellos
UML e Casos de Uso são FERRAMENTAS que podem ou não ser utilizadas no processo de verdade que é caputarr requisitos e comunicar projeto.
“1/3 dos requisitos estão em casos de uso ”
Que seja o necessário para uma iteracao! Casos de uso ou User Stories são apenas um primeiro passo para definição de requisitos. Se esse passo não resultar em algo reproduzível e mensurável como especificações executáveis, não serviu de nada..
Acho que o comentario acima se equivocou quanto as palavras de Beck, ele não fala de lado humano e negocios como se fossem coisas distantes, mas que especialização e principalmente dividir e conquistar não fazem sentido no processo de desenvolvimento de sw, seja no aspecto humano ou de negocio.
Pingback:Débito Técnico » Blog Archive » Só Agilidade funciona
Acredito que o problema não seja do modelo “Casos de Uso + UML + Código + Testes” e sim da falta de comunicação. Acredito que obrigatoriamente em projetos corporativos que os requisitos devam estar documentados e preferencialmente validados pelo usuário, seja em Casos de uso ou qualquer outro documento. Uma vez capturado um requisito, e somente quando este for identificado, é importante analisar o impacto no projeto e na arquitetura do software, vejo a UML com uma boa linguagem para comunicar e permitir a avaliação de incrementos nos requisitos / funcionalidades. Quando entendida a necessidade e a modificação necessária para aquele projeto ai sim, podemos desenvolver e testar ou vice versa, criar os testes e desenvolver, vai da cultura. Lógico, não estou falando de requisitos como logos, posição de elementos na tela ou coisas deste tipo, mas sim de regras de negócio, restrições de segurança ou funcionalidade, que potencialmente impactam no modelo.
Mesmo no processo ágil com micro interações, voce deve avaliar o requisito, como irá faze-lo, testar e executar (ou executar e testar), este micro “waterfall” é necessário, não faz sentido pensar em como atender um requisito se o mesmo não existe ou criar testes sem propósito.
Att,
Raphael
Raphael… é um anti-pattern sim. Nenhuma metodologia defende o uso de um mesmo padrão para o desenvolvimento de todas as funcionalidades.
O que você quer dizer com projetos corporativos? Todos os projetos são corporativos. Se eu escrevo uma classe de teste ou um teste de aceitação isso é documentar requisitos. Se eu desenho rascunhando um protótipo de tela em papel A4 junto com o cliente isso é um documento de requisitos. Se ele fez isso junto comigo não precisa de aprovação.
Nenhuma metodologia de desenvolvimento prega “validação de requisitos”. O que existe são validações de requisitos através de software funcionando. Software funcionando é o melhor artefato para levantamento e validação de requisitos.
Não vejo a alteração de requisitos como essa mudança cataclísmica que você falou. Equipes ágeis não temem mudanças (veja o princípio da coragem do XP). E além disso, não vejo aonde a UML vai ajudar muito nessa análise que você falou. Talvez uma boa suite de testes seja mil vezes melhor para detectar quebras no código do que um modelo UML. Avaliar impacto pode levar ao “Change Prevention Anti-Pattern”.
Equipes ágeis criam testes para documentar requisitos. Testes são documentos de requisitos. Isso não é criar testes sem propósitos. Existe ambiquidade entre requisitos e testes. Se você têm os testes não precisa ter os documentos de requisitos.
Grande Rodrigo,
Apesar de não estar 100% familizarizado (ou convencido) das práticas do Scrum, sou um adepto convicto da Agilidade e de XP.
Poucas vezes na minha vida profissional encontrei alguém que compartilha a minha prática de falar sem meias palavras e sem medo coisas que são consideradas “senso comum”.
Também poucas vezes encontrei alguém que escreve tão bem. Adorei o blog, adicionei ao meu leitor de feeds e te linkei no meu blog.
Assino em baixo de cada palavra tua nesse post, inclusive na resposta dos comentários e devaneios.
Um abraço,
Alex
Pingback:Débito Técnico » Blog Archive » O ciclo ágil de um dia… MundoJava no. 29
Olá Rodrigo,
a respeito do trecho:
“Se a funcionalidade é simples e a expectativa do usuário está clara, documentos de Casos de Uso e modelos UML podem ser descartados.”
como você define que a funcionalidade é simples e a expectativa está clara ?
Obrigado,
Walter
Fala Walter, bom, creio que qualquer sistema tem funcionalidades simples como relatórios básicos, cadastros básicos (os famosos CRUDS) e etc… Já parou para pensar que os casos de uso CRUD que escrevem por aí são muito semelhantes entre sí? Pra quê essa ambiquidade?
Geralmente algumas funcionalidades simples que não representam muita importância para os usuários são aqueles cuja expectativa está clara. Imagine um sistema de vendas. Existe “Emitir Pedido” que é um caso de uso que concentra 80% da complexidade do sistema onde a expectativa é alta. Ee existe o “Cadastro de Tipo de Cliente”, um CRUD idiota. É aquele tipo de caso de uso que os usuários não tem expectativa.
OK?
Entedi a visão e concordo. Coisas como CRUD, e outras na qual se possa criar um padrão bem definido para o sistema inteiro, não merecem mais do que uma modelagem e/ou descrição genérica.
Sds,
Pingback:Iterações pra que te quero! at Mergulhando no Caos
Ola rodrigo,
gostaria de saber se você usa UML, Caso de Uso ?
Você disse “Se a funcionalidade é simples e a expectativa do usuário está clara, documentos de Casos de Uso e modelos UML podem ser descartados.” e concordo com você. beleza, mas em casos complexos vc usa?
Obrigado!
Sim! A grande maioria dos projetos que desenvolvo uso a UML. Mesmo que seja o UMLasSketch do Fowler (rascunhando com UML).
Casos de Uso não aplico em todas as aplicações. Uso mais para algumas funcionalidades que muitas vezes não estão claras nem para o usuário.
Mas a grande verdade é que faz um bom tempo que não mantenho muitos artefatos UML em minha configuração.
Pow cara, perfeito essa formação ideológica no desenvolvimento do software, eu sei sobre UML mas simplesmente acho uma grande perda de tempo fazendo toda aquela modelagem. Pra mim existem duas grandes coisas que se deve fazer: estabelecer metas e requisitos dos sistema, e finalmente uma documentação.
Muito bom!
O uso indiscriminado é um anti-pattern, a quadra por si só não. Até porque a quadra, se não for aplicada constantemente não é nem mesmo um padrão..