O Papel dos Requisitos
No cenário atual do desenvolvimento Java existe uma visão errada da Engenharia de Requisitos, eu particularmente também possui essa visão. Na verdade isso se constituiu pelo fato de muitos analistas não terem a menor idéia de conceitos OO e bem como técnicas de análise orientada a objetos. Isso ocorre pelo cenário em que o Java se encontra no Brasil, quem nunca trabalhou com uma analista de mais idéia que trabalhava com alguma tecnologia legada e mal sabe o que significa polimorfismo?
O problema é ainda maior. Se fosse apenas o caso de não conhecerem OO Analisys seria uma coisa, a questão é que normalmente esse tipo de profissional mal sabe Análise estruturada Moderna e quando me refiro a isso não falo apenas de conhecer as ferramentas como DHF, DFD , ER , etc. Estou falando de método e de técnicas. Hoje em dia isso ocorre com o suposto analista OO também que por que sabe UML acredita que isso é o bastante, mas vale a pena lembrar que UML é só a linguagem e não tem método.
Estudando cada vez mais sobre o assunto percebo que é uma assunto de extrema importância e cada vez mais chego a conclusão de que existem pouquíssimos profissionais qualificados para o papel. Tudo começa com a questão dos requisitos.
O que é um requisito?
É uma característica desejada para o sistema que é observada externamente. Pode ser algo do tipo o sistema deve fornecer suporte a multi-idiomas ou algo do tipo o sistema deve permitir diferentes níveis de acesso customizaveis. Para identificar se um possível requisito podemos aplicar as seguintes perguntas:
1) É uma característica observável extremamente do sistema?
2) Satisfaz alguma necessidade do cliente?
Caso a resposta seja sim para as duas perguntas, estamos falando de um requisito.
Por que requisitos são importantes?
Primeiro que, pelo principio básico de que é bom saber o que construir antes de começar a construir, esse principio é valido por que para se atingir qualidade é necessário atingir um grau de precisão desejável.
O grande vilão são os Assumptions que fazemos. Por não investirmos tempo suficiente em requisitos acabamos fazendo softwares que não atendem as necessidades dos clientes e muitas vezes tem funcionalidades que nem são utilizadas. Por isso é importante documentar um requisito e ter claro em mente o que o sistema deve fazer.
Falando de XP
Como conselhos nunca são de mais, o problema é que as pessoas não escutam os conselhos. O grande problema do XP é tratar os requisitos de forma muito simplista e inúmeros projetos que utilizaram XP falharam. Quero deixar claro novamente que isso não é uma posição religiosa minha contra o XP e a favor do RUP como muitos já devem estar pensando nesse momento. Mas meramente fazer um User Stories não é o suficiente.
Todo o tempo gastado em cima de requisitos é bom! Quando mais cedo você detectar uma mudança ou engano mais barato será sua implementação. Essa questão dos requisitos está diretamente ligado ao problema da priorização.
A prática de priorizar é de suma importância. Meramente entregar software iterativamente e colher feedback com o usuário não é o bastante. É necessário entregar valor ao cliente.
Falando de Scrum
Esse é o ponto que o SCRUM erra! No Scrum o Product Owner é quem prioriza e dá uma importância aos itens do backlog. Tanto é que a equipe até pode discutir mas no final das contas é o P.O quem decide. Pedir para o P.O priorizar os itens do backlog é perda de tempo, muitas vezes ele ira dar a mesma importância a vários itens. Outras vezes ele irá dar prioridades muito diferentes para itens que devem entrar na mesma Sprint. Essa constatação não é somente minha mas vem também do Alan M. Davis em seu livro JERM.
Outros aspectos importantes
Aspectos importantes quando tratamos de requisitos são: identificação, clareza, rastriabilidade, gerencia e aceite. Identificar requisitos por um ID unico é uma boa idéia. A clareza deve se estabelecida atreves de sucessíveis perguntas por que? Através desse recurso que estaremos descobrindo requisitos de verdade e não a solução propriamente dita.
A rastreabilidade é muito importante. Precisamos saber quanto uma mudança em um requisito irá afetar outros requisitos, essa rastreabilidade de começar a nível de requisitos e através dos requisitos refletir casos de uso e por fim código. Esse é um ponto que as pessoas erram muito também. Muitas vezes elas não dão bola a essa questão. Já trabalhei em empresas em projetos que não queriam de jeito nenhum ter um CCB. O ideal é ter o comite de mudanças, e as mudanças partirem dos requisitos. Já participei de projetos que a análise de impacto era feito a partir do código, bom ai vocês já podem até imaginar o CAOS.
O aceite é um contrato, pode ser incorporado como parte do processo de revisão de requisitos. Em cenários corporativos onde existem múltiplos sistemas é muito importante analisar o impacto em termos de custo e tempo. Possuir esses recursos sobre requisitos irão prover uma base para aplicatibilidade dessa necessidade.
Abraços.
O problema é ainda maior. Se fosse apenas o caso de não conhecerem OO Analisys seria uma coisa, a questão é que normalmente esse tipo de profissional mal sabe Análise estruturada Moderna e quando me refiro a isso não falo apenas de conhecer as ferramentas como DHF, DFD , ER , etc. Estou falando de método e de técnicas. Hoje em dia isso ocorre com o suposto analista OO também que por que sabe UML acredita que isso é o bastante, mas vale a pena lembrar que UML é só a linguagem e não tem método.
Estudando cada vez mais sobre o assunto percebo que é uma assunto de extrema importância e cada vez mais chego a conclusão de que existem pouquíssimos profissionais qualificados para o papel. Tudo começa com a questão dos requisitos.
O que é um requisito?
É uma característica desejada para o sistema que é observada externamente. Pode ser algo do tipo o sistema deve fornecer suporte a multi-idiomas ou algo do tipo o sistema deve permitir diferentes níveis de acesso customizaveis. Para identificar se um possível requisito podemos aplicar as seguintes perguntas:
1) É uma característica observável extremamente do sistema?
2) Satisfaz alguma necessidade do cliente?
Caso a resposta seja sim para as duas perguntas, estamos falando de um requisito.
Por que requisitos são importantes?
Primeiro que, pelo principio básico de que é bom saber o que construir antes de começar a construir, esse principio é valido por que para se atingir qualidade é necessário atingir um grau de precisão desejável.
O grande vilão são os Assumptions que fazemos. Por não investirmos tempo suficiente em requisitos acabamos fazendo softwares que não atendem as necessidades dos clientes e muitas vezes tem funcionalidades que nem são utilizadas. Por isso é importante documentar um requisito e ter claro em mente o que o sistema deve fazer.
Falando de XP
Como conselhos nunca são de mais, o problema é que as pessoas não escutam os conselhos. O grande problema do XP é tratar os requisitos de forma muito simplista e inúmeros projetos que utilizaram XP falharam. Quero deixar claro novamente que isso não é uma posição religiosa minha contra o XP e a favor do RUP como muitos já devem estar pensando nesse momento. Mas meramente fazer um User Stories não é o suficiente.
Todo o tempo gastado em cima de requisitos é bom! Quando mais cedo você detectar uma mudança ou engano mais barato será sua implementação. Essa questão dos requisitos está diretamente ligado ao problema da priorização.
A prática de priorizar é de suma importância. Meramente entregar software iterativamente e colher feedback com o usuário não é o bastante. É necessário entregar valor ao cliente.
Falando de Scrum
Esse é o ponto que o SCRUM erra! No Scrum o Product Owner é quem prioriza e dá uma importância aos itens do backlog. Tanto é que a equipe até pode discutir mas no final das contas é o P.O quem decide. Pedir para o P.O priorizar os itens do backlog é perda de tempo, muitas vezes ele ira dar a mesma importância a vários itens. Outras vezes ele irá dar prioridades muito diferentes para itens que devem entrar na mesma Sprint. Essa constatação não é somente minha mas vem também do Alan M. Davis em seu livro JERM.
Outros aspectos importantes
Aspectos importantes quando tratamos de requisitos são: identificação, clareza, rastriabilidade, gerencia e aceite. Identificar requisitos por um ID unico é uma boa idéia. A clareza deve se estabelecida atreves de sucessíveis perguntas por que? Através desse recurso que estaremos descobrindo requisitos de verdade e não a solução propriamente dita.
A rastreabilidade é muito importante. Precisamos saber quanto uma mudança em um requisito irá afetar outros requisitos, essa rastreabilidade de começar a nível de requisitos e através dos requisitos refletir casos de uso e por fim código. Esse é um ponto que as pessoas erram muito também. Muitas vezes elas não dão bola a essa questão. Já trabalhei em empresas em projetos que não queriam de jeito nenhum ter um CCB. O ideal é ter o comite de mudanças, e as mudanças partirem dos requisitos. Já participei de projetos que a análise de impacto era feito a partir do código, bom ai vocês já podem até imaginar o CAOS.
O aceite é um contrato, pode ser incorporado como parte do processo de revisão de requisitos. Em cenários corporativos onde existem múltiplos sistemas é muito importante analisar o impacto em termos de custo e tempo. Possuir esses recursos sobre requisitos irão prover uma base para aplicatibilidade dessa necessidade.
Abraços.
