Desenvolvimento nativo de aplicativos para dispositivos móveis - como estruturo minhas histórias de usuários?


9

Estou prestes a iniciar um projeto que envolverá o desenvolvimento de protótipos de aplicativos móveis nativos (iOS e Android inicialmente), além de uma interface administrativa baseada na Web e uma API para a comunicação desses aplicativos. Já temos uma lista de histórias elaboradas, mas muitas delas estão no formato:

As a mobile user I want to be able to view a login screen so that I can sign into the app

Se isso fosse direcionado para uma única plataforma, eu não veria um problema. No entanto, como estamos segmentando várias plataformas, não tenho certeza se agora elas devem ser duplicadas, por exemplo, "como usuário do Android" ou similar. Parece duplicação, mas é um trabalho que precisará ser concluído separadamente para cada plataforma.

Este é o primeiro projeto móvel em que nos tornamos nativos - anteriormente era o Phonegap e reunimos todas as histórias em "Como usuário móvel". Como essencialmente esse era um aplicativo baseado na Web envolto em código nativo, isso não apresentava muitos problemas, mas estou consciente de que aplicativos totalmente nativos são um jogo diferente!


Isso não é realmente específico para dispositivos móveis - aplica-se a um projeto que deve ser entregue em várias plataformas, como um PC e Linux ou vários consoles de jogos. O título deve ser alterado?
precisa

Respostas:


3

Não vejo por que você não deseja criar histórias de usuário separadas para cada aplicativo móvel. Embora as histórias pareçam semelhantes, elas têm enormes diferenças do ponto de vista dos desenvolvedores e dos usuários.

Se você estiver usando um sistema como o Jira, poderá criar um projeto separado para cada aplicativo. Essa abordagem é melhor, especialmente se todos os aplicativos forem completamente independentes em termos de recursos _ diferentes desenvolvedores, diferentes recursos de computador etc. Seria mais fácil fazer estimativas para cada uma das tarefas.

Se você ainda não deseja criar histórias de usuário separadas, pode criar tarefas para cada aplicativo na mesma história. Mas isso seria conveniente se você desenvolvesse todos os aplicativos simultaneamente, para que cada história fosse concluída quase ao mesmo tempo.


2

(Eu suponho que você use scrum). Se o proprietário do produto souber de antemão que sempre priorizará as diferentes plataformas móveis igualmente. (Por exemplo, porque é uma política da empresa)

E se suas histórias de usuário forem pequenas o suficiente, para que sua equipe possa fazer pelo menos quatro ou cinco delas em uma corrida.

Só então você não deve dividir suas histórias para celular em uma história por plataforma. Use a definição de done para indicar todas as plataformas esperadas.

Em todos os outros casos: divida as histórias para celular por plataforma. Não há absolutamente nada de errado com isso.


Graças Kris - Eu levo o seu ponto sobre eles ser pequeno o suficiente, isso é definitivamente algo a ter em mente quando dividindo-los (ou não, conforme o caso pode ser!) :-)
richsage

1

Para qualquer pessoa que tenha acessado esta página, talvez essa resposta possa ajudar a fornecer uma opção para o desenvolvimento bem-sucedido de um aplicativo para as plataformas iOS / Android.

Como gerente de projeto que gerencia projetos do Agile / Scrum, a explicação acima sobre o desenvolvimento do mesmo aplicativo para dois sistemas operacionais diferentes indicaria dois fluxos de trabalho separados.

Para fazer isso com sucesso, seria necessário dois projetos separados. Cada sistema operacional terá seus próprios requisitos. Ao misturar os dois sistemas operacionais em um único projeto, você pode criar confusão sobre o que deve ser desenvolvido em qualquer sistema operacional. Assim, sua equipe pode perder um tempo valioso decifrando a qual SO o requisito pertencia. Em suma.

Eu recomendaria a criação de dois projetos com seu próprio conjunto de histórias de usuário específicas para o sistema operacional.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.