Como devemos lidar com recursos cosméticos adicionais nos scrum sprints?

Eu estava lendo os documentos do Scrum e diz que as tarefas no Sprint devem ser "potencialmente entregáveis".

Estou confuso com o que isso significa. Suponha que no Sprint 1 o objetivo fosse "formulário de registro do usuário".

Quantos detalhes eu preciso adicionar para que algo esteja pronto para ser enviado? Por exemplo:

1. Posso mostrar o formulário simples com campos sem nenhum estilo sofisticado e marcá-los como concluídos
2. Eu posso apenas fazer a validação do lado do cliente como marcada como concluída, mas o lado do servidor também é a opção ou ambas
3. Também posso adicionar algumas dicas de ferramentas sofisticadas do jQuery, passar o mouse, captcha, cores, etiquetas para o formulário
4. Há muito estilo sobre como mostrar mensagens de erro na tela

Eu posso fazer infinitamente em um tópico. Então, como podemos dividir isso e quando posso pensar nisso como remessa pronta.

Ou eu preciso escrever cada coisa possível, como mostrar erros, pop-up ou texto de caixa de luz como subtarefas e colocá-las como sprint. Isso levaria a milhares de tarefas para todo o projeto.

Quero dizer, novamente, se alguns funcionam para o Internet Explorer e outros para o Firefox, novamente eu preciso dividi-los também como tarefas. O tempo deve ser gasto com eles e, quando o gerente me perguntar o que você fez naquele período, não terei nenhuma tarefa para contar, mas, na realidade, todos fazem parte do registro do usuário.

Concorde com o proprietário do produto e a equipe do Scrum, não com a Internet. Isso deve ser determinado em sua Definição de Concluído e dependerá em grande parte de como a equipe trabalha.

Embora o recurso deva ser 'entregável' (eu odeio esse termo no Scrum), pode-se argumentar que a funcionalidade é entregável sem a interface do usuário. Muitas pessoas sofrem desse equívoco no Scrum - o objetivo de um sprint é obter o máximo de histórias possível (idealmente todas) 'Concluído', mas definitivamente não precisa ser incorporado a algo que possa ser lançado.

É importante resolver essas coisas cedo, para que todos da equipe trabalhem com um objetivo comum. O espírito do Scrum é a comunicação, então pergunte à equipe do Scrum e tire uma conclusão lógica.

Você pode trabalhar em uma equipe em que a interface do usuário geralmente é tratada separadamente, por exemplo, por uma equipe diferente ou depois que os especialistas em interface do usuário decidirem como o formulário deve aparecer etc. Como alternativa, em um projeto / equipe pequeno, pode-se esperar que a interface do usuário seja criada como você ir.

Desde que a equipe saiba a resposta, é irrelevante qual é a resposta.

Se os recursos cosméticos fazem parte do recurso, provavelmente devem ser feitos como parte da história. O ponto é que, depois que você diz que uma história é concluída, não precisa mais codificar um recurso específico. No entanto, em última análise, isso é decidido pelo proprietário do produto - eles podem querer os recursos cosméticos ou não. Isso deve ser explicitado nos critérios de aceitação.

Isso não significa necessariamente que está pronto para o usuário final usar, apenas significa que está pronto para alguém . Que alguém possa ser um testador ou outra equipe, como a equipe de back-end.

Se você estiver perguntando isso como desenvolvedor, a resposta será "você sabe, porque o proprietário do produto dirá se eles querem os recursos cosméticos ou não".

Se você está perguntando isso como proprietário do produto, basta decidir se deseja dividir o recurso em mais de uma história. Não há nenhum requisito, além do que deve satisfazê- lo , como forma de satisfazer seu cliente .

Lembre-se: o objetivo não é aderir estritamente ao scrum. O objetivo é fornecer software de alta qualidade ao usuário final. Use isso como um guia ao enfrentar questões como essa. Adicionar os cosméticos na mesma história que as peças puramente funcionais ajudará você a fornecer um código de qualidade ao seu cliente? Ou, dividir isso em duas histórias ajuda? A resposta é clara ou não importa e você pode fazer o que funcionar para sua equipe.

"Potencialmente entregável" significa entregável, não necessariamente algo que você envia. Por exemplo:

Um formulário de registro na web que parece terrível e não tem validação em campo pode ser bom para algumas situações, como um projeto escolar, mas em um negócio multimilionário, danificaria a marca para mostrar aos usuários finais. O código pode ser entregável sem ser algo que você gostaria de enviar ou que o marketing ou o jurídico permitisse.

É algo que os programadores (e outras pessoas que estão em processo neste momento, por exemplo, designers) ficariam felizes em lançar como está agora, mesmo que, por algum motivo, nunca fosse realmente lançado assim (por exemplo, precisa ser traduzido para outros idiomas antes de poder ser enviado a qualquer pessoa - o Canadá tem regras estritas sobre o governo que compra um software que considera igualmente o francês e o inglês).

Este é um ponto de verificação da qualidade, você olha todos nos olhos e pergunta se eles ficariam felizes em enviá-lo como está agora, sem trabalho extra, sem verificação para ver se eles fizeram a última coisa. Eu ouvi isso chamado de ponto de verificação de engenheiro de avião. Você olha nos olhos de um engenheiro e pergunta se eles estão dispostos a acompanhá-lo no voo de teste.

A idéia é ser o mais ágil possível. Quanto mais rápido você conseguir algo para usuários reais; seja cópias beta do código para selecionar indivíduos ou testes A / B no seu site, melhor. Se você mostrar aos usuários um código muito grosseiro, conforme definido pelas expectativas do produto, eles fornecerão um feedback inútil. Eles falarão sobre coisas sobre as quais você não está procurando informações: elas não gostam que o botão seja amarelo ou que a caixa de texto não esteja alinhada com os rótulos. Se for bom o suficiente, você poderá obter um feedback útil. Quanto mais rápido você receber esse feedback, melhor! Você pode validar o ajuste do produto / mercado e as suposições feitas sobre o recurso que você tentou criar.

Enviar o recurso é a parte menos importante disso. Mover a equipe de desenvolvimento e terminar as Histórias de Usuário é o importante. Chegar ao ponto em que você pode afirmar que algo foi feito é um grande motivador.

No meu entender, cada história deve ser "executável" e "entregável" na medida em que esteja pronta para o consumo por alguém , não necessariamente pelo usuário final . Portanto, sua história pode oferecer algumas funcionalidades que podem ser entregues ao proprietário do produto, que pode optar por liberá-la para os usuários finais ou repetir a funcionalidade novamente.

Dito isto, você não está impedido de incluir denominando a "Como um usuário final, vou ser capaz de registrar" história. Em nossa equipe, tentamos tornar cada história tão pequena quanto possível para manter uma maior previsibilidade e garantir melhor que possamos cumprir o que prometemos. Se tivermos um design pronto antecipadamente e acharmos que é trivial aplicar, ele será incluído na história. Se achamos que pode haver alguma iteração no design, essa é uma história separada - possivelmente múltipla.

Além das outras ótimas respostas para essa pergunta, você também pode pensar nos recursos cosméticos como a parte variável do escopo do triângulo escopo-recursos-tempo. Certifique-se de cumprir os requisitos básicos dessa história e adicione as coisas bonitas, se tiver tempo.

O Scrum não deve garantir a entrega de certos recursos em um determinado momento. Ele deveria fornecer o trabalho útil máximo possível em um determinado momento. Se os recursos cosméticos "opcionais" não forem concluídos durante o sprint, deve ser porque eles não eram possíveis.

Depende da pessoa que define os requisitos, o "proprietário do produto". Como programador, posso estar contente com uma página "formulário de registro" não estilizada, que simplesmente prova que a lógica de negócios em meus serviços da Web funciona corretamente e que esse registro permite que você seja autenticado com outros recursos do sistema. De fato, "potencialmente entregável", uma vez que isso não implica necessariamente que vamos literalmente enviá-lo a um cliente, poderia permitir que esse fosse o resultado da primeira história do usuário sobre o tópico, principalmente se a equipe técnica e a equipe de design é recursos separados com backlogs separados.

Em um projeto mais maduro, você pode enviar uma versão "desenvolvida pelo desenvolvedor" do recurso, com estilo mínimo, para um cliente piloto ou beta, mas revisitar o mesmo recurso para modificações de funcionalidade (com base no feedback) e conclusão do design.

O objetivo da metodologia Agile é permitir que seus requisitos conduzam o processo de desenvolvimento de software, e não o contrário. Não caia na armadilha de supor que uma descrição da metodologia seja o Verdadeiro e Único Requisito Ortodoxo. É mais fácil falar do que fazer, é claro, principalmente se você estiver em uma organização grande onde o Scrum se tornou uma desculpa para impor o caos à equipe de desenvolvimento.