Processo Ágil de Requisitos de Software
Origem: Wikipédia, a enciclopédia livre.
Remova este aviso somente depois de todo o texto estar wikificado.
Processo Ágil de Requisitos de Software: Boas Práticas
No âmbito da subárea de Engenharia de Requisitos que por sua vez pertence a área de Engenharia de Software, surgiram novas medodologias de especificar requisitos. A metodologia convencional de especificação e desenvolvimento de software dá forte ênfase na documentação e planeamento antecipado de todo o Processo de Engenharia de Requisitos. No entanto novas métodos de desenvolver software surgiram, sendo que o Desenvolvimento ágil de software e as suas metodologias tais como XP, Scrum, Feature Driven Development ou Test-driven development permitiram que se desenvolvesse software mais rapidamente, com maior qualidade, simplicidade e robustez. A nível organizacional e social permitiu maior interacção, comunicação entre todos os stakeholders envolvidos maior incidência no trabalho de especificação de requisitos e Desenvolvimento de Software não dando tanto ênfase ao planeamento, contracto de negociação, documentação extensiva, processos e ferramentas. Tal mundança alterou a forma como o Processo de Engenharia de Requisitos é abordado, dado origem a um Processo Ágil de Requisito de Software.
Com este artigo pretende-se abordar boas práticas que um Processo Ágil de Especificação de Requisitos deve ter em consideração. Não se pretende afirmar que todas estas práticas devam ser incluídas, mas sim analisadas consoante o contexto do projecto e/ou do cliente. Geralmente são práticas de senso comum, muitas vezes esquecidas e/ou negligenciadas devido à absorção diária de trabalho, rotinas, falta de constante actualização de novas formas de liderar e/ou desenvolver projectos de software.
[editar] Participação activa dos stakeholders
Quando se está a modelar e a levantar requisitos a prática fundamental é a participação activa dos stakeholders(Robertson 2006). Aqui há duas questões a ter em conta de forma a permitir esta boa prática (Ambler 2002):
- disponibilidade dos stakeholders do projecto para fornecer requisitos
- vontade dos stakeholders para interagirem conjuntamente.
Quando uma equipa de projecto não consegue ter acesso adequado aos stakeholders, isto é culpa da própria equipa de projecto (Ambler 2002), portanto, pode ser complicado aceder aos stakeholders e mesmo colocá-los a participar.
É importante que os stakeholders do projecto e os colaboradores estejam envolvidos na identificação de ideias e sugestões, discutindo requisitos, modelando-os e possivelmente documentando-os. Os stakeholders do projecto são somente responsáveis por prioritizar os requisitos e por sua vez os colaboradores são responsáveis por estimar o esforço. No entanto o esforço estimado é passível de ser alterado sempre que existem alteração de requisitos ou quando há uma má estimativa.
[editar] Adopção de modelos inclusivos
Para facilitar o envolvimento dos stakeholders do projecto na modelação de requisitos e documentação devemos seguir a prática "Usar Ferramentas Simples". Notas de "Post It" e User Card Stories são dois exemplos de levantar/modelar requisitos (Ambler 2002). Sempre que se introduz tecnologia para modelar os requisitos levantados, de forma a desenhar um nova versão dos diagramas, estamos a tornar difícil a participação dos stakeholders, dado que agora não estão apenas a aprender técnicas de modelação de requisitos bem como a aprender ferramentas de modelação (Ambler 2002). Mantendo o processo simples estamos a encorajar a participação e a aumentar a a colaboração efectiva.
No entanto workshops, sessões de brainstorming são métodos de extracção e modelação de requisitos que são bastante úteis na maioria dos projectos (Robertson 2006). Ambos os métodos têm por base um grupo de pessoas interessadas em gerar novas ideias de forma a resolver o problema comum. São geralmente sessões onde os stakeholders sentem maior entusiasmo e onde se sentem como mais um elemento de uma equipa com o objectivo de resolver um problema.
[editar] Adoptar uma abordagem "Primeiro em Largura
É-se aconselhado a evitar a começar a descrever pormenorizadamente requisitos (Ambler 2002) (Robertson 2006). Deve-se adoptar inicialmente uma abordagem "Primeiro em Largura", ou seja, ter uma visão geral de todos os requisitos que dará por si só a visão do projecto. Sendo que depois sempre se pode detalhar requisito a requisito. No entanto muitas empresas ainda preferem a abordagem "Big Modeling Up Front (BMUF)", onde se investe tempo significatico a recolher, documentar, rever e a aceitar requisitos no período inicial do projecto e só depois é que avançam para a fase de implementação (Ambler 2002). Teoricamente parece ser uma ideia excelente, mas na realidade não é muito eficaz na maioria dos projectos. Num estudo efectuado em 2001 por M. Thomas no Reino Unido, de 1027 projectos analisados referiam que a gestão relacionada com as práticas do modelo "Waterfall" incluindo requisitos já detalhados antes da fase da implementação, foi citado em 82% dos casos como a causa número 1 pela falha do projecto. Este estudo é suportado pelo estudo de Jim Johnson do Standish Group que refere que sempre que os requisitos são especificados na fase inicial do ciclo de vida do produto cerca de 80% das funcionalidade não são relevantes para o cliente, referindo que 45% das características não são usadas, 19% são raramente usadas e apenas 16% são usadas algumas vezes (Ambler 2002). Sendo que as principais causas para tal acontecer são as seguintes:
- Quando os analistas ou engenheiros de requisitos são colocados perante um problema eles tentam imaginar todos os potencias requisitos que daí podem adver, sem sequer pensar se isso é realmente relevante para o cliente. Contribuindo assim para que o ciclo de desenvolvimento do produto seja bem maior.
- Os requisitos e as características pretendidas pelos clientes e/ou utilizadores mudam ao longo do ciclo de desenvolvimento do sistema/aplicação/produto/serviço.
[editar] Modelar detalhes em Just in Time (JIT)
Os requisitos são identificados ao longo do projecto, apesar de a maioria dos requisitos serem identificados e trabalhados no ínicio do processo de Requisitos, é provável que ainda estaremos a trabalhar neles mesmo antes da entrega de uma release. É aqui que devemos "abraçar" as alterações de requisitos e adoptar um levantamento de requisitos de uma forma evolucionário, iteratica e incremental.
[editar] O objectivo é implementar requisitos, não documentá-los
Demasiados projectos são confrontados com o excesso de trabalho para desenvolver e manter documentação compreensiva e manter pontos de ligação entre os diversos documentos. Devemos seguir uma abordagem ágil e manter a documentação "*lean*" e efectiva. A documentação eficiente e efectiva é geralmente suficiente boa o projecto em mão. Actuando assim podemos focar a nossa energia no desenvolvimento de software.
[editar] Criar requisitos independetes da plataforma
Deve-se sempre que possível evitar que um requisito dependa ou seja baseado em elementos tecnológicos. Aqui a focalização é levantamento de requisitos e não a associação com qualquer tipo de tecnologia. Da mesma forma não se pode modelar requisitos assumindo que determinada empresa irá adoptar determinadas tecnologias só por serem as mais aconselhadas para a elaboração do projecto. Mais uma vez determinadas empresas ainda não estão culturalmente, socialmente ou economicamente preparadas para dar esse salto. Nesse caso provavelmente terá de se tirar vantagem das infrastruturas tecnológicas da própria empresa ou organização, sendo que mesmo até nestes casos os requisitos deverão ser sempre que possíveis independentes da tecnologia.
[editar] Pequeno é o melhor
Pequenos requisitos, como características e "_user stories_" são mais fáceis de estimar e construir do que requisitos grandes complexos, tais como "_use-cases_" (Robertson 2006). Normalmente um use-case descreve maiores e mais complexas funcionalidades do que um "_user story_". Pequenos requisitos são igualmente bem mais fáceis de prioritizar e de gerir.
[editar] Questionar o rastreamento de requisitos
Pensar bem antes de investir numa matriz de rastreamento de requisitos. Rastreamento é a capacidade de relacionar vários aspectos de um artefacto de um projecto e uma matriz de rastreamento é o artefacto criado para guardar essas relações. Relaciona modelos de análise, arquitectura, desenho, código fonte e testes unitários. Por vezes será melhor efectuar uma correcta gestão de conhecimento na empresa, departamento ou equipa de modo a poder ser mais simples perceber qual a dimensão e a complexidade de uma alteração no sistema e/ou produto (Ambler 2002). Esta solução pode ser adoptada dado que a manutenção de uma matriz de relacionamento de Requisitos é muito custosa de manter. No entanto depende da cultura da própria empresa. (Ambler 2005)
[editar] Adoptar terminologias dos stakeholders
Não adoptar jargões técnicos ou artificiais quando se colabora com stakeholders no projecto. É para eles que o sistema está a ser construído, portanto é a terminologia deles que deve ser usado na modelação do sistema. Sendo que esse tipo de terminologia é de ser evitada! Um importante artefacto em todos os projectos é a criação de um glossário conciso de termos (Robertson 2006).
[editar] Tenta manter o processo divertido
Modelação e especificação de requisitos não tem de ser uma tarefa árdua, de facto, sempre que possível devemos tirar o máximo de prazer dessa mesma tarefa. Os colaboradores irão empenhar-se num ambiente agradável, sentir-se-ão mais confortáveis e tornar-se-ão mais produtivos! (Ambler 2002)
[editar] Obter suporte da gestão
Investindo esforço em modelação de requisitos com recurso a metodologias ágeis, é um conceito relativamente novo para muitas organizações. Um ponto importante é que os stakeholders do projecto têm de estar envolvidos na dinâmica do processo ágil, para se poder criar uma cultura fundamental para a adesão ao processo ágil. Sem o apoio dos gestores séniores dificilmente haverá sucesso na implanatação de metodologias, além de que todo o apoio dos gestores do departamento do sistema de informação é fundamental. (Ambler 2005)
[editar] Tornar os stakeholders em colaboradores
Uma implicação desta abordagem é que os stakeholders do projecto estão a aprender competências de desenvolvimento quando estão envolvidos no projecto de software. Tornar os stakeholders em colaboradores traz uma mais valia para uma análise e modelação de requisitos mais correcta e da forma mais desejada para o cliente e/ou utilizador final. (Robertson 2006)
[editar] Processar os requisitos com prioridade
Reflectindo o "Planning Game" do XP (Extreme Programming) e a metodologia Scrum, uma equipa de desenvolvimento terá uma lista de requisitos estimados e prioritizados que necessitam de ser implementados, sendo que por vezes os colaboradores poderão ter uma pilha de "user-stories cards" já prioritizadas (Ambler 2002). A equipa retira um requisito do topo da pilha que eles acreditam que poderão implementar nessa iteração, sendo que scrum aconselha que se congele a análise de requisitos durante a iteração, para dar estabilidade à equipa de desenvolvimento (Abrahamsson 2002). Se a alteração de um requisito acontecer então essa alteração será tratada como um novo requisito (Abrahamsson 2002) (Ambler 2002).
[editar] Referências
- Ambler, Scott, Ron Jeffries (2002). Agile Modeling: Effective Practices for Extreme Programming and the Unified Process. John Wiley & Sons, Inc. New York. ISBN 0-471-20282-7.
- Robertson, Suzanne, James Robertson (2006). Mastering the Requirements Process (2nd Edition). Addison Wesley. ISBN-10 0-321-41949-9.
- Ambler, Scott, John Nalbone, Michael J. Vizdos (2005). The Enterprise Unified Process: Extending the Rational Unified Process. Prentice Hall PTR (February 11, 2005). ISBN-10 0131914510.
- Abrahamsson, Pekka, Oti Salo, Jussi Ronkainen, Juhani Warsta (2002). Agile Software Development Methods: Review and Analysis. VTT Publications Finland. ISBN 951-38-6009-4.
- Ambler, Scott (2006 a). Scott Ambler’s Web Site. http://www.ambysoft.com/ Último acesso: 26/12/2006
- Ambler, Scott (2006 b). Agile Modeling (AM) Home Page: Effective Practices for Modeling and Documentation. http://www.agilemodeling.com/ Último acesso: 26/12/2006
