Todo analista de sistemas sabe da importância da correta identificação e gerenciamento dos requisitos de uma aplicação, e o papel fundamental que os mesmos representam durante todo ciclo de vida de um projeto.
Com o crescimento na utilização de metodologias ágeis, muitos dos problemas em relação aos mesmos foram minimizados, porém o problema está longe de ser considerado resolvido. Muito pelo contrário, não é preciso ter muita experiência em projetos de TI para perceber que diversas vezes os problemas encontrados no software têm origem nos requisitos(ou estórias) ou na falta deles e diversas são as causas para tais problemas. Onde, a principal causa talvez seja o fato do gerenciamento dos mesmos, durante um projeto, continuar sendo frequentemente menosprezado.
Apesar de impactar o trabalho de todos envolvidos em projetos de software (desenvolvedores, testadores, designers e até mesmo dos gerentes) os requisitos ainda são comumente relegados a segundo plano. Até o próprio assunto não é debatido com muita freqüência nas empresas e na internet, e com esse post tentaremos trazer um pouco mais o referido tema para o BDB.
Abaixo tentamos listar alguns dos problemas comumente encontrados por nós, focando, nesse primeiro momento, nos projetos que utilizam metodologias ágeis e versões adaptadas das mesmas:
Isso não funciona:
– Analista de requisitos inexistente:
É comum e até indicado pelas metodologias ágeis que os profissionais tenham perfis multidisciplinares e possam atuar em diferentes papéis durante o projeto, porém isso muitas vezes é confundido e acaba gerando a eliminação de alguns especialistas, onde o caso dos requisitos é um bom exemplo de atividade, que cada vez mais é realizada por pessoas não dedicadas inteiramente a função e que não possuem os atributos requeridos para a mesma, assim temos engenheiros sobrecarregados e muitas vezes executando tarefas que não os agrada.
– Product Owner distante:
No scrum o product owner é muitas vezes o responsável pela definição das estórias e por apoiar a equipe no esclarecimento de eventuais dúvidas a respeito do comportamento esperado das estórias escolhidas para a sprint. Porém, essa comunicação nem sempre funciona de maneira eficiente, fatores como a distância física, dificuldade em entender as responsabilidades do papel ou até mesmo os conflitos naturais que podem surgir da relação cliente X equipe podem criar barreiras que dificultam o trabalho da equipe.
– Entendimento das estórias:
Mesmo quando temos uma comunicação eficiente com o product owner, ainda precisamos nos preocupar com a garantia de uma boa comunicação entre os membros da equipe, evitar ao máximo que as pessoas tenham entendimento diferente das estórias selecionadas, garantir que os mesmos compreendam a extensão e os detalhes que envolvem cada estória.
– Projetos longos:
A medida que o tempo de vida de um projeto aumenta, diversos outros pontos começam a surgir e que podem dificultar o desenrolar das atividades, por exemplo, a necessidade por algum tipo de rastreabilidade entre os requisitos, atividade que dificilmente pode ser executada de maneira eficiente sem dedicação plena.
– Turnover:
A chave do sucesso dos projetos ágeis está na comunicação entre os membros da equipe, o conhecimento a respeito das funcionalidades do projeto passa diretamente pelos integrantes, onde alguns por possuírem determinadas habilidades, acabam se tornando referenciais técnicos, quando tratamos do comportamento correto da aplicação. Porém, frequentemente enfrentamos a rotatividade de pessoal, o que consequentemente leva a perda desse conhecimento, aumentando o grau de dificuldade para novas tarefas e realização de correções e melhorias.
– Cliente imediato não é o cliente final, logo como não documentar tudo?
Muitas vezes confundimos também a idéia de evitar o excesso de documentação encorajada pelas metodologias ágeis com documentação zero, o que para alguns projetos específicos pode fazer sentido e não gerar nenhum tipo de problema, porém de maneira geral dificulta a entrada de novos integrantes ou a correção de defeitos relacionados a estórias implementadas a algum tempo. Esse problema pode ainda se tornar maior quando nosso cliente imediato não é o cliente final, quase que eliminando a possibilidade de trabalhar focado nas necessidades imediatas e feedbacks do usuário final.
– Todo mundo quer ser ágil:
A adaptação da metodologia ágil selecionada para as características da equipe de trabalho é essencial, porém ocorre também o erro comum de tentar aplicar métodos ágeis em todos os projetos, no entanto nem sempre eles são os mais indicados. Com isso surgem situações como projetos ágeis sendo guiados por um imenso documento de requisitos tradicional, repleto de casos de uso e quase nenhuma flexibilidade.
P.S. A partir dos 2 minutos o vídeo exibe apenas propaganda dos produtos da IBM.
Por enquanto, é melhor nem falarmos dos requisitos não funcionais, onde os problemas e dificuldades são ainda maiores.
No próximo post descreveremos algumas soluções que tem ajudado em nossos projetos. Participe comentando sobre problemas relacionados a requisitos enfrentados por você e sua empresa.
Links relacionados:
– Vídeo descrevendo o problema com a definição do software através do documento de requisitos
– Post Scrum master não pode ser o product owner
Para relaxar:
Bytes don't Bite! 
Onde eu trabalho temos muitos problemas relacionados ao PO. Não é uma empresa tradicional. É um laboratório de desenvolvimento dentro da Universidade. Porém ocorrem algumas “confusões” por parte do professor que é o responsável pelo Laboratório.
Além da distância – muitas vezes ele não está na universidade nem em contato com a equipe – existe o pensamento de que metodologia ágil é um monte de processo que basta seguir. Isso não funciona. Tem que pensar de maneira ágil, não apenas aplicar metodologia ágil.
Então o principal problema nosso aqui no lab. acaba sendo isso. O nosso PO, que está em contato com o resto da universidade, para quem desenvolvemos os sistemas, não segue as ideias. Ele faz as reuniões com os outros departamentos, promete uma pilha de coisas, e depois vem pra gente com um tanto de requisito novo, de última hora. E ele não entende o jeito de trabalhar.
Resumindo, o principal problema que temos é que tentamos seguir uma tendência nos sprints, definindo pequenos escopos, mas a todo momento chegam novos requisitos, de outros componentes e até de futuras versões, mas com a exigência de serem feitos agora, porque ‘simplesmente’ foi prometido ao cliente, sem abertura de discussão nenhuma. O processo se perde todo e a lista de bugs e erros cresce.
Apesar de ser um laboratório dentro de uma universidade, acredito que esse problema não é devido a isso, e ocorre em mais lugares. E ocorre por que? Porque as pessoas não PENSAM de maneira ágil, tendo abertura com o cliente, qualidade de trabalho, sprints bem definidos. As pessoas pensam QUE ÁGIL é um processo e que basta segui-lo. Acho que um dos problemas é esse.
até mais.
Muito bom post.
Oi Ramon, o que você falou é uma verdade sim, as pessoas cada vez mais dizem que utilizam metodologias ágeis, quando na verdade o que fazem é colar post-it na parede. Essas pessoas desconhecem o que é de fato uma metodologia ágil, para que servem, quais são os fundamentos, quais os príncipios por trás das práticas e etc (recomendo uma apresentação que fiz http://bit.ly/jpN4ny).
Quanto aos problemas que você citou, esse é somente um deles não é? Acho que Carréra foi muito feliz ao listar outros tipos de problemas que temos, e alguns desses nós podemos vivenciar na prática. A medida que o projeto vai crescendo e fazendo aniversários (projetos de 2 ou 3 anos) e, obviamente, pessoas entram e saem da equipe, o conhecimento (que no movivmento ágil está mais nas pessoas e na comunicação entre elas) também vai se perdendo. Mas talvez se esse conhecimento estivesse em documentos também seria seria perdido ( por questões de dificuldade de encontrar o documento com a informação que é preciso, por falta de manutenção, etc).
É uma questão complexa mas é preciso estar de olhos abertos pra não deixar a coisa desandar.
Muito bom o post Burgos! Depois queria ler sua opinião a respeito de “Cliente imediato x Cliente final x Product Owner”.
Grande Leo! tem muito a se falar, mas uma coisa é certa de cara:
Para que um projeto consiga rodar uma metodologia ágil com sucesso é preciso que TODOS os stakeholders topem e entendam os princípios e fundamentos por trás disso tudo ou NÃO VAI DAR CERTO (ou não tão certo quanto poderia)!
Excelente post Carréra!
Acho que você conseguiu cobrir bem todos os aspectos de risco envolvidos na análise e definição de requisitos. Acho também importante mencionar que, por mais que trabalhemos em todos esses pontos, os requisitos SEMPRE vão mudar. Por mais que tentemos tapar todos os buracos levantados por você no post se não houver uma boa reação a mudança, uma boa gestão desses requisitos, a tendência é ir para o caos. O diferencial em projetos ágeis ou não, está na forma de controlar esses deslizes que fatalmente irão ocorrer. Bom, essa pelo menos é a minha humilde opinião. =)
Me pediram para deixar uma opinião aqui 🙂 coincidentemente vou dar aulas numa pós-graduação na disciplina de Engenharia de Requisitos a partor do próximo Sábado, então comecei a me lembrar em todos os projetos que já participei como funcionou o levantamento e gerenciamento dos requisitos. Sou da opinião que não existe uma receita única para todo tipo de projeto e que metodologia ágil não é solução para todos os problemas. Eu, particularmente, não sou muito a favor de uma equipe multidisciplinar em muitos contextos, simplesmente porque ninguém sabe fazer tudo bem (por tudo, entenda-se, especificar requisitos, elaborar uma arquitetura robusta, codificar, especificar casos de teste e testar; o mínimo que deveria ser feito em qualquer projeto de desenvolvimento de software em graus diferentes dependendo da complexidade, tamanho, tecnologia, …).
Já participei de projetos de sucesso onde documentávamos requisitos de forma textual no Word com um processo de revisão formal. Já especifiquei muito usando casos de uso. Já vi projetos onde um protótipo navegacional com algumas observações era suficiente. Outros com estórias. No último projeto que liderei para desenvolvimento de jogos para celular tínhamos apenas o modelo navegacional no início e depois utilizamos estórias para complementar e tivemos um excelente resultado, mas nãoo é por isso que agora vou usar estórias em todos os projetos que participar.
Requisitos devem ser levantados, especificados e priorizados de alguma maneira; não faltam estudos que comprovam que falhas de entendimento nessa fase (independente do ciclo de vida do projeto) causam prejuízos bem maiores; a melhor maneira para se fazer isso? Bem, avalie seu projeto, a equipe disponível, o conhecimento da equipe, experiência, duração do projeto, complexidade, necessidade de documentação, requisitos não funcionais, o ponto principal é, mantenha, sempre que possível, o usuário FINAL por perto e receba feedbacks o mais rápido possível, usando, inclusive, protótipos em papel. Fácil? Não, mas quem disse que seria fácil quando escolhemos essa área para estudar e trabalhar 🙂
Excelente os feedbacks de vocês. Realmente, o ponto central que queria trazer era esse, a imensa complexidade que é tratarmos dos requisitos de maneira eficiente, como diversas variáveis influenciam a forma como devemos abordá-los, desde tempo do projeto, tecnologia, características da equipe, etc…
E fundamentalmente, um ponto que acho que precisamos voltar a levar em consideração é a inclusão de alguém inteiramente dedicado em manter os requisitos gerenciáveis em um projeto, avaliando a cada momento, a cada renovação que mudanças precisam ser feitas para que essa manutenção continue eficiente.
Pensando na divisão de papéis do SCRUM, por exemplo, não há esse profissional preocupado com a manutenção das estórias e seu entendimento por todos, essa tarefa fica dividida entre scrum master (gerenciando o backlog), product owner e a própria equipe, e desse modo, sinto falta de alguém, talvez um “stories master” =) cuidando para que os mesmos sejam gerenciados corretamente.
Carréra concordo com você em gênero, número e grau. Uma ou mais pessoas na equipe precisam ser responsáveis pelos requisitos, não dá para deixar na mão de todos, acaba que não é de ninguém. Agora o formato no qual os requisitos serão documentados e por quem, vai variar muito. No meu último projeto o responsável pela elaboração do protótipo navegacional e pela escrita das estórias foi o UX e funcionou muito bem já que o desenvolvimento para celular envolve uma grande preocupação com a usabilidade da aplicação.
Pegando um gancho no que Déa falou, realmente precisa-se avaliar dentre tantas coisas, o prazo do projeto e o que fazer para gerar num prazo curto, insumos de qualidade que gerem produtos com qualidade. Não necessariamente precisa-se ter uma documentação robusta com muitos passos e linguagem rebuscada. A simplicidade pode ajudar e fazer toda a diferença. Num projeto que trabalhei o documento de requisitos do produto e cliente foi substituído pelo documento de design (Wireframe). Este foi construído pelo designer – UX e todos os fluxos contidos no wireframe foram discutidos com eng de testes, eng de qualidade e eng de sistemas. Uma tabela de comportamento foi criada para responder aos principais questionamentos da equipe de testes. Todas as dúvidas eram respondidas e o artefato era mantido sempre atualizado. Resultado, tivemos os requisitos compostos por esses dois artefatos, com altíssima qualidade e entendimento de todos. Foi mais um case de sucesso!
Uma experiência que achei muito interessante foi usar modelos mais visuais (apresentação de slides, diagramas de fluxo, etc) para representar os requisitos.
Nas conferências de elicitação via Skype compartilhamos a tela do nosso computador com o cliente em alguns momentos para mostrar os desenhos que estávamos fazendo (no MS Paint mesmo :-P).
Foi muito legal ouvir dele que estávamos acertando em alguns pontos “mas…” ele nos corrigiu na hora e o resultado dos desenhos foi muito mais fiel ao que ele queria nos explicar.
Enviamos a imagem por email após a call e guardamos no repositório como evidência de elicitação.
A partir daí movemos as informações para uma apresentação de slides que foi sendo evoluída. Nada de .doc enorme.
Perfeito, Telmo! Justamente o que estavamos falando sobre cada projeto ter suas características. Também tivemos um exemplo de muito sucesso documentando as estórias do projeto utilizando protótipos comentados em PPT. O fundamental é termos alguém que possa apoiar essas decisões e ajudar no refinamento desses processos formais ou informais…
José, eu adorei esse post, e não foi por concordar com cada ponto nele, mas por conseguir ter uma ideia de como a percepção de quem está no projeto pode ser prejudicada, como coisas boas, boas intenções podem acabar gerando sofrimento.
Eu sou analista de negócios / PO / whatever e ficaria muito feliz se você desse uma olhada nesse artigo que escrevi. Sinto que existe uma evolução em um produto/projeto/processo e que afirmativas que são verdadeiras em um momento deixam de ser válidas em outro.
blog.kerber.com.br/o-dia-em-que-me-tornei-desnecessario
um grande abraço!
Claudio Br
Excelente seu post Cláudio, essa percepção por parte do cliente e PO de como a equipe se organiza, e a forma com que ela trabalha também pode se tornar um elemento fundamental para o sucesso de um projeto.
Obrigado pela visita
[…] havia prometido no post – Apertem os Cintos, o Analista de Requisitos Sumiu!, descrevo hoje como abordávamos o gerenciamento dos requisitos (estorias) num dos projetos […]
[…] Deficiente Estórias ou requisitos mal descritos, ausência de Product Owner ou Engenheiro de Requisitos, proporcionam dificuldades para desenvolvedores e testadores, o que acaba significando um maior […]
[…] Apertem os cintos, o analista de requisitos sumiu! […]