Não descarte os Requisitos
Diferente do que prega o XP, eu lhes digo o código é o que menos importa. Você até pode ter um código, lindo maravilhoso utilizando todos os patterns do nossa amigo Kent Back, tal qual ela fala no Implementation Patterns, mas de nada irá adiantar isso se a análise de requisitos já estiver comprometida.
Por outro lado com os Requisitos bem levantados e com um devido processo de priorização, através de um mecanismo de CCB ou algo mais simples, é melhor do que ter código perfeito. Se os requisitos estão OK, é simples de se arrumar o código.
A Lógica inversa
O problema é que muitas empresas querem melhorar ou alavancar sistemas legados através do código, lhes digo que é possível melhorar um pouco, mas não será possível deixar o sistema 100% nos trilhos a partir do código. As coisas devem partir da análise. Uma vez a análise comprometida todo o sistema está comprometido.
Por que gastar mais tempo com Requisitos?
Por que estatísticas mostram que projetos que gastam menos de 5% do tempo em requisitos, passam em mais de 120% alem do prazo e custo. De outro lado projetos que gastam mais de 10% do tempo em requisitos estão apenas 30% alem do prazo e custo.
Particularmente não acho que 30% acima do prazo e custo seja uma boa, mas para resolver isso você pode gastar mais tempo em requisitos em torno de 15% a 20% do tempo do projeto, que acredito ser uma taxa ainda razoável.
Como sei quanto tempo gastar?
Existem vários fatores que nos levam a gastar mais ou menos tempo com requisitos. Como por exemplo: Experiência da equipe de Requisitos ou experiência dos programadores no domínio da aplicação. Se você ainda acha que pode gastar pouco tempo com requisitos lembre-se:
"Cada um real gasto em requisitos pode virar até 120x mais caro em operações"
Para os agilistas
Provavelmente vocês irão discordar desta máxima da Engenharia de Software. OK. Eu entendo, até por que o Kent Back já diz em seu livro que não acredita nessa escala, ele particularmente acredita em uma escala mais freqüente de gastos. Mas não podemos esquecer que o XP prega o principio de "Viajar com pouco peso", logo então, eles não gastam muito tempo com requisitos. Essa abordagem até funciona, mas para alguns casos, não todos.
Requisitos não tem nada a ver com Gestão?
Totalmente errado. Na verdade todas as disciplinas tem tudo a ver com requisitos. Existe outra máxima da Engenharia de Software que diz "Antes de construir, é bom saber o que construir". E de fato essa frase se referencia aos requisitos. Muitos processos são baseados em requisitos.
Nota:O RUP por exemplo é baseado em casos de uso, que nada mais são do que requisitos do usuário. Claro que o processo permite tratar requisitos não funcionas através de especificações suplementares.
A Gestão do projeto bem como a Gerência de configurações deve ser baseada em Requisitos. As tarefas de baseline e release, roadmap e tudo mais devem ocorrem sobre um conjunto de requisitos.
É trabalho do Gerênte de projeto Adionar ou Remover requisitos através das iterações. Mas todo esse trabalho deve ser feito junto a um trabalho de priorização.
Preciso do Cliente full time?
O On-Site Constumer do XP é uma lenda. De fato não é necessário nem desejável ter um cliente 100% do dia junto ao desenvolvimento. E apenas uma pessoa do negocio não irá ajudar muito no projeto. Logo é muito melhor de Product Champions. Quem não precisam ficar 100% do dia junto a o desenvolvimento, de fato eles precisam estar acessíveis em momentos que a equipe de requisitos estará realizando a Elicitação e nos momentos de priorizações.
Sim é necessário Envolvimento, Mas...
É necessário que o Cliente se envolva no projeto. Mas esse envolvimento deve se dar através dos Product Champions, que devem ser os principais stakeholders do projeto. Cabe lembrar a importância de se mapear o publico alvo do projeto. Esse mapeamento ocorre através do documento de visão do projeto, o qual as metodologias ágeis não tem...
Artefato Documento de visão?
Esse é o artefato padrão de metodologias como o RUP e o OpenUP, porem o artefato não significa um documento MS Word. Pode ser um poster de papelão colado em uma parede na sala de desenvolvimento do projeto. Esse documento que traz a identificação dos principais stakeholders pro projeto.
É importante realizar essa identificação e coloca-la no documento de visão por que caso nos esqueçamos de algum stakeholder chave, podemos produzir um software que não atende 100% das necessidades da empresa.
Nota: Muitas vezes quem paga o projeto, o famoso Sponsor, Não é a pessoa quem usa o sistema, portanto não é aconselhável focar todas as fixas em cima do Sponsor ou apenas o stakeholder mais importante.
Casos de Uso são OK
Pessoal, não se enganem. Casos de uso textual não são Anti-Patterns. Infelizmente já ouvi muito essa besteira. Casos de uso são OK. Por que:
Casos de uso Visuais também são OK
De fato você não irá criar casos de uso visuais para tudo. Sim, estou falando do Use Case Diagram da UML. Em contextos mais complexos utilizar casos de uso visuais pode ser uma boa idéia para a facilitação da quebra e balanceamento de casos de uso.
Se de fato um requisito está muito complicado ou existem muitos requisitos em comuns. A utilização de casos de uso visuais pode ajudar a identificar e resolver essas situações mais facilmente.
Nota: Eu particularmente já utilize casos de uso visuais em alguns contextos e fui bem sucedido. Como por exemplo em um projeto de Engenharia Reversa.
Ferramentas de Requisitos
As ferramentas de requisitos baseadas em dados, podem ser uma boa pedida. Principalmente para questões como Rastrabilidade e Gerência de configuração, Geração de SRS e outras facilidades. Infelizmente as ferramentas de requisitos são muito caras e não muito populares qui no Brasil, além de que não são assim "Uma Brastemp" :)
Começando um projeto com um bom processo de desenvolvimento e gerência de requisitos nos dá uma boa base para poder criar uma arquitetura sólida e um design coeso e assim sim um código de qualidade.
Na seqüência eu vou escrever muito mais sobre requisitos, principalmente associados a questões como estimativas.
Abraços e até a próxima.
Por outro lado com os Requisitos bem levantados e com um devido processo de priorização, através de um mecanismo de CCB ou algo mais simples, é melhor do que ter código perfeito. Se os requisitos estão OK, é simples de se arrumar o código.
A Lógica inversa
O problema é que muitas empresas querem melhorar ou alavancar sistemas legados através do código, lhes digo que é possível melhorar um pouco, mas não será possível deixar o sistema 100% nos trilhos a partir do código. As coisas devem partir da análise. Uma vez a análise comprometida todo o sistema está comprometido.
Por que gastar mais tempo com Requisitos?
Por que estatísticas mostram que projetos que gastam menos de 5% do tempo em requisitos, passam em mais de 120% alem do prazo e custo. De outro lado projetos que gastam mais de 10% do tempo em requisitos estão apenas 30% alem do prazo e custo.
Particularmente não acho que 30% acima do prazo e custo seja uma boa, mas para resolver isso você pode gastar mais tempo em requisitos em torno de 15% a 20% do tempo do projeto, que acredito ser uma taxa ainda razoável.
Como sei quanto tempo gastar?
Existem vários fatores que nos levam a gastar mais ou menos tempo com requisitos. Como por exemplo: Experiência da equipe de Requisitos ou experiência dos programadores no domínio da aplicação. Se você ainda acha que pode gastar pouco tempo com requisitos lembre-se:
"Cada um real gasto em requisitos pode virar até 120x mais caro em operações"
Para os agilistas
Provavelmente vocês irão discordar desta máxima da Engenharia de Software. OK. Eu entendo, até por que o Kent Back já diz em seu livro que não acredita nessa escala, ele particularmente acredita em uma escala mais freqüente de gastos. Mas não podemos esquecer que o XP prega o principio de "Viajar com pouco peso", logo então, eles não gastam muito tempo com requisitos. Essa abordagem até funciona, mas para alguns casos, não todos.
Requisitos não tem nada a ver com Gestão?
Totalmente errado. Na verdade todas as disciplinas tem tudo a ver com requisitos. Existe outra máxima da Engenharia de Software que diz "Antes de construir, é bom saber o que construir". E de fato essa frase se referencia aos requisitos. Muitos processos são baseados em requisitos.
Nota:O RUP por exemplo é baseado em casos de uso, que nada mais são do que requisitos do usuário. Claro que o processo permite tratar requisitos não funcionas através de especificações suplementares.
A Gestão do projeto bem como a Gerência de configurações deve ser baseada em Requisitos. As tarefas de baseline e release, roadmap e tudo mais devem ocorrem sobre um conjunto de requisitos.
É trabalho do Gerênte de projeto Adionar ou Remover requisitos através das iterações. Mas todo esse trabalho deve ser feito junto a um trabalho de priorização.
Preciso do Cliente full time?
O On-Site Constumer do XP é uma lenda. De fato não é necessário nem desejável ter um cliente 100% do dia junto ao desenvolvimento. E apenas uma pessoa do negocio não irá ajudar muito no projeto. Logo é muito melhor de Product Champions. Quem não precisam ficar 100% do dia junto a o desenvolvimento, de fato eles precisam estar acessíveis em momentos que a equipe de requisitos estará realizando a Elicitação e nos momentos de priorizações.
Sim é necessário Envolvimento, Mas...
É necessário que o Cliente se envolva no projeto. Mas esse envolvimento deve se dar através dos Product Champions, que devem ser os principais stakeholders do projeto. Cabe lembrar a importância de se mapear o publico alvo do projeto. Esse mapeamento ocorre através do documento de visão do projeto, o qual as metodologias ágeis não tem...
Artefato Documento de visão?
Esse é o artefato padrão de metodologias como o RUP e o OpenUP, porem o artefato não significa um documento MS Word. Pode ser um poster de papelão colado em uma parede na sala de desenvolvimento do projeto. Esse documento que traz a identificação dos principais stakeholders pro projeto.
É importante realizar essa identificação e coloca-la no documento de visão por que caso nos esqueçamos de algum stakeholder chave, podemos produzir um software que não atende 100% das necessidades da empresa.
Nota: Muitas vezes quem paga o projeto, o famoso Sponsor, Não é a pessoa quem usa o sistema, portanto não é aconselhável focar todas as fixas em cima do Sponsor ou apenas o stakeholder mais importante.
Casos de Uso são OK
Pessoal, não se enganem. Casos de uso textual não são Anti-Patterns. Infelizmente já ouvi muito essa besteira. Casos de uso são OK. Por que:
- Mostram a perspectiva do usuário
- Mostram a iteração do usuário com o sistema
- Mostram o contexto de iteração do usuário e os sistemas se existirem
- Facilitam a interação do Analista com o usuário
Casos de uso Visuais também são OK
De fato você não irá criar casos de uso visuais para tudo. Sim, estou falando do Use Case Diagram da UML. Em contextos mais complexos utilizar casos de uso visuais pode ser uma boa idéia para a facilitação da quebra e balanceamento de casos de uso.
Se de fato um requisito está muito complicado ou existem muitos requisitos em comuns. A utilização de casos de uso visuais pode ajudar a identificar e resolver essas situações mais facilmente.
Nota: Eu particularmente já utilize casos de uso visuais em alguns contextos e fui bem sucedido. Como por exemplo em um projeto de Engenharia Reversa.
Ferramentas de Requisitos
As ferramentas de requisitos baseadas em dados, podem ser uma boa pedida. Principalmente para questões como Rastrabilidade e Gerência de configuração, Geração de SRS e outras facilidades. Infelizmente as ferramentas de requisitos são muito caras e não muito populares qui no Brasil, além de que não são assim "Uma Brastemp" :)
Começando um projeto com um bom processo de desenvolvimento e gerência de requisitos nos dá uma boa base para poder criar uma arquitetura sólida e um design coeso e assim sim um código de qualidade.
Na seqüência eu vou escrever muito mais sobre requisitos, principalmente associados a questões como estimativas.
Abraços e até a próxima.
