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! 