• Nenhum resultado encontrado

Story Points e priorização de requisitos

4. DEFINIÇÃO DE UM AMBIENTE VISUAL PARA APOIAR O SPRINT E PRODUCT BACKLOG

4.4 Estudo de Caso para validação da proposta

4.4.3 Story Points e priorização de requisitos

Story points é uma unidade de medida para expressar uma estimativa do esforço geral

que será necessário para implementar totalmente um item (uma user story) do Product Backlog [103].

Quando realizamos uma estimativa com story points, atribui-se um valor em pontos a cada

user story. Os valores brutos que atribuímos não são importantes. O que importa são os valores

relativos [103]. Projetos de software possuem um alto grau de incerteza. Mesmo que os desenvolvedores ou um consultor forneçam uma estimativa do projeto, até o desenvolvimento começar, é difícil saber exatamente o que é necessário para implementar as user stories planeadas para as versões. No entanto é certo que para garantir que o projeto será um sucesso, deve-se usar métodos de priorização, que ajudem a perceber quais user stories devem ser abordadas primeiro. As metodologias ágeis de desenvolvimento de software tornam-se cada vez mais populares à medida que a palavra se espalha sobre os benefícios oferecidos em certas condições do projeto. Uma característica chave de qualquer abordagem ágil é o seu foco explícito na criação de valor de negócio para os clientes [103]. Essencialmente, em projetos ágeis de software, o

91

processo de desenvolvimento é um processo de criação de valor de negócio que depende da participação ativa do cliente. A criação de valor de negócios é assegurada tanto pelo produto final quanto pelo próprio processo. A priorização de user stories é uma tarefa difícil num ambiente ágil por causa da sua natureza volátil. A ignorância da criticidade das user stories resultará em vários problemas, como cliente insatisfeito e má qualidade do produto.

Os requisitos para este caso de estudo foram fornecidos na forma de user stories. No sentido de elicitação e priorização de requisitos, essas user stories foram priorizados como se verá ainda nesta secção. Na priorização foi considerada a importância e o esforço das user stories, mas também foi tido em conta a importância que algumas user stories têm, conforme o desejo do cliente.

Considerando a proporção de Importância atribuída pelo cliente e Esforço estimado pela equipa do projeto (I / E) (a equipa neste projeto em concreto é a autora destes valores).

Priorização de user stories = 𝐼𝑚𝑝𝑜𝑟𝑡â𝑛𝑐𝑖𝑎 𝑑𝑎𝑠 𝑢𝑠𝑒𝑟 𝑠𝑡𝑜𝑟𝑖𝑒𝑠𝐸𝑠𝑓𝑜𝑟ç𝑜 𝑝𝑜𝑟 𝑢𝑠𝑒𝑟 𝑠𝑡𝑜𝑟𝑖𝑒𝑠 [1]

A restrição de tempo é um grande problema para o cliente, bem como para o ambiente ágil. A libertação do produto é dada ao cliente de acordo com a user story, ou seja, o cliente informará qual user story deve ser feita antes, para iniciar o seu trabalho o mais rápido possível. O produto que é lançado cedo ou periodicamente é a melhor maneira de satisfazer as necessidades do cliente.

Dependências de user stories no Product Backlog têm um papel vital no ambiente ágil e foram tidos em conta neste caso de estudo (agrupar as user stories que apresentam a mesma dependência). As dependências entre user stories afetam a priorização no ambiente ágil. Combinar vários itens dependentes num grande Epic e dividir os itens de maneira diferente são duas técnicas comuns para lidar com user stories dependentes.

A segurança pode ser considerada como segurança de rede, segurança funcional, segurança de código, segurança de documentação e outros tipos, com base na lista dos requisitos do cliente. No momento de desenvolvimento do projeto, a segurança do ciclo de vida deve ser considerada um fator de grande prioridade.

92

Os pré-requisitos / disponibilidade de recursos são orçamento, pessoas, material, tecnologia, espaço e outros ativos que são necessários para uma operação eficaz. A disponibilidade de pré-requisitos tem um papel vital no ambiente ágil porque a tarefa poderá ficar atrasada se o recurso não estiver disponível naquele momento.

Nesta fase, a importância e o esforço da user story foram calculados e, em seguida, a proporção da importância e do esforço (I/E) para cada user story foi usada para a priorização. Como exemplo foi considerado o sprint 1 (primeiros 10 user stories), enquanto a tabela para as restantes user stories pode ser consultada no Anexo I.

Tabela 8 - User Stories

User Stories, Importance and Effort Factor

ID User Story I E I/E

7 As a System Administrator, I want to CRUD an industrial

group in order to manage business groups. 90 68 1,32 8 As a System Administrator or a corporate manager, I want

to CRUD a group company in order to manage group companies. 100 70 1,43 12

As a System administrator, Corporate manager, Company manager or Factory manager, I want to CRUD factories in order to

manage factories 95 70 1,36

13 As a Forwarder admin or systems admin, I want to CRUD

trucks in order to manage trucks. 80 67 1,19 24 As a user I want to perform login, in order to access

collaborative web app. 85 78 1,09

25 As a user I want to recover login credentials, in order to

access collaborative web app. 83 79 1,05 29 As a user I want to perform login, in order to access

collaborative web app. 81 79 1,03

30 As a user I want to recover login credentials, in order to

access collaborative web app. 78 78 1,00 32 As a System Administrator I want to CRUD work tokens in

order to manage work tokens. 96 70 1,37 37

As an Entity (forwarder, client or supplier) manager I want to request, read, update and disable work tokens in order to manage

work tokens to my entity. 98 70 1,40

Considerando o Product Backlog do projeto UH4SP, o gráfico Importância / Esforço (Figura 32) apresenta a ordem de priorização das user stories mostrando o resultado dos cálculos realizados para cada user story.

93

Figura 32 - Priorização por cálculo de Importância / Esforço (sprint 1)

Depois de priorizadas as user stories, foi desenhado o gráfico entre a importância para a relação esforço (E/I) para cada user story. Inicialmente procurou-se encontrar a menor user story na ótica do autor que representa toda equipa do projeto. A menor user story (user story número “5”) encontrada foi-lhe atribuído o valor de “I” igual a 1 e depois seguiu-se encontrar a user story de maior prioridade segundo o autor, que neste caso é a user story número “8” e recebeu o valor máximo de “100”. Os resultados dos demais podem ser visualizados na Figura 32. Depois da priorização das user stories, a fase seguinte foi a criação de sprints.

Documentos relacionados