Pular para o conteúdo principal

Engenharia de software | User Stories (Conceitos básicos)

As metodologias ágeis dominaram o mercado de desenvolvimento de software, isso porque trouxe facilidades e velocidade nos momentos de levantamento de requisitos e estruturação do projeto.

Essas formas de metodologias utilizam diversos outros métodos para atingir as características descritas acima. Uma delas são as User Stories ou histórias de usuário, vejamos agora um pouco sobre o que são elas e como funcionam.

Vale aqui lembra que, as User Stories, assim como qualquer outro método talvez não se adapte a todos os casos de desenvolvimento e levantamento de requisitos. 

Objetivo

As Users Stories, tem como objetivo facilitar o processo de levantamento de requisitos. Ela busca fazer isso de forma rápida e com muita interação dos usuários que irão utilizar o sistema.

Características 

O fato das Users Stories não encaixar em qualquer projeto se da por algumas características que ela apresenta, e além disso o seu objetivo.

Este método trabalha na captura de informações diretamente com o usuário, e não foca muito em documentar todos os detalhes.  Aqui são gravados o que o usuário deseja fazer, e nada mais, como por exemplo detalhes de implementação, ou como o sistema deve se comportar.
Outro fato interessante sobre esta forma de levantamento de requisitos é o quão fácil é seu aprendizado e aplicação, isso permite que todos os envolvidos possam criar as User Stories, sem a necessidade de um especialista fazendo a interface com o cliente e a equipe que desenvolve.

Sua aplicação é feita principalmente quando as equipes são pequenas, e a comunicação com o usuário pode ser feita frequentemente.

Aplicação

Sua forma de aplicação, como já citado, é bastante simples. Veja que as histórias devem ser curtas e diretas ao ponto. 
Para a criação de uma história um paragrafo deve resolver o problema, caso não seja o suficiente, ela deve ser revista e caso necessário removida ou segmentada em outras pequenas histórias.

Ela deve conter os tópicos listados abaixo:
  • Ator - Representa quem escreveu aquela história, ou, a quem ela atende;
  • Ação - Mostra a ação que o ator quer efetuar;
  • Funcionalidade - Mostra o resultado que o ator espera após a execução a execução da ação.
Um exemplo simples de descrição pode ser visto abaixo:

Como cliente quero verificar quais livros estão disponíveis para compra, para que possa seleciona-los e efetuar a compra.

Conclusão 

Por fim foi possível notar que este método é bastante simples e de rápida aplicação. Pode ser utilizado em projetos em que a interação com o usuário é frequente.
Além desses permite a equipe uma visualização segmentada da estrutura do projeto, o que facilita o desenvolvimento.

Comentários

Postagens mais visitadas deste blog

Sistemas operacionais | O problema da sincronização e a exclusão mutua

Olá, hoje vou tratar sobre a sincronização dos processos e como esta forma de trabalho trouxe alguns problemas na implementação dos sistemas operacionais. Como de costume, aviso que, as informações aqui são frutos das anotações das aulas de sistemas operacionais. Com a chegada dos sistemas multiprogramados outro problema também surgiu, o compartilhamento de recursos entre os processos. Processos concorrentes Para que exista concorrência entre os processos é sabido que é necessário que haja a comunicação entre os processos, para que os mesmos saibam os passos do outro processo e assim consigam gerar  a concorrência. Essa comunicação é feita através de várias formas, seja esses utilizando buffer de memória, uma variável global ou  trocas de mensagens.  Esses mecanismos de comunicação entre os processos são chamados de mecanismos de sincronização, esses são fundamentais para garantir a confiabilidade dos processos que estão sendo executados em um sistema operaciona...

Engenharia de software | Eriksson-Penker Bussiness Extensions (Conceitos)

Eriksson-Penker Bussiness Extensions (EPBE), é uma forma de modelagem de negócios que foi criada a partir da UML (Notação utilizada em projetos de aplicações orientada a objetos).  Essa criação foi feita por conta de a UML ser um modelo bastante extensível. A criação A criação desta forma de modelagem veio em 2000, quando seus criadores perceberam que no mercado de modelagem de negócios existiam muitos padrões diferentes, o que gera um problema, não há padrão, isso porque cada empresa e área de negócio utilizava um padrão diferente. Então eles geraram um modelo padrão para a modelagem de processos e negócios, este nomeado  Eriksson-Penker Bussiness Extensions Modelagem Quando foi criado, o EPBE foi descrito para uso de qualquer empresa, isso porque seus criadores identificaram que as empresas podem ser representadas através de Processos, Recursos, Regras e Objetivos . Veja as características de cada um desses pontos: Recurso: Representam todos os recursos...