Como convencer minha equipe de que uma especificação de requisitos é desnecessária se adotarmos histórias de usuários?

9

Planejamos adotar histórias de usuários para capturar a "intenção" das partes interessadas de maneira leve, em vez de uma SRS (especificação de requisitos de software) pesada. No entanto, parece que, embora eles entendam o valor das histórias, ainda há um desejo de 'converter' as histórias em uma linguagem semelhante ao SRS com todos os atributos, prioridades, entradas, saídas, origem, destino etc.

As histórias de usuários 'eliminam' a necessidade de um SRS formal como artefato, para que começar; então, qual é o sentido de ter um SRS? Como convencer minha equipe (que são pessoas de CS muito qualificadas, a propósito - tanto pela educação quanto pela prática) de que o SRS seria 'eliminado' se adotássemos histórias de usuários para capturar os requisitos funcionais do sistema? (NFRs etc também podem ser capturados, mas essa não é a intenção da pergunta).

Então, aqui está o meu argumento de 'fluxo de trabalho': capture os requisitos iniciais como histórias de usuários e depois os elabore para casos de uso (que precisam ser documentados em um nível baixo, isto é, descrevendo interações com os protótipos / modelos de interface do usuário e são uma publicação que pode ser entregue) desdobramento, desenvolvimento). Assim, passando de histórias de usuário para casos de uso, em vez de histórias de usuário, para SRS e casos de uso.

Como vocês estão atualmente capturando histórias de usuários no seu local de trabalho (se houver) e como sugerem que eu "defenda" a ausência de SRS na presença de histórias de usuários?

— Doutorado
fonte

isso não vai acontecer em um dia, ter abordagem fácil

— Yusubov

Se você trabalha para um provedor de serviços de software, o SRS pode não ser necessário para executar a implementação, mas para executar o "jogo de culpa" quando o cliente deseja reduzir os argumentos de custo ou fornecedor de serviços de que é necessário mais dinheiro ou que ambos estão indo a tribunal.

— K3b

14

Passos de bebê. Continue escrevendo o SRS por um tempo. Depois, convoque uma reunião e discuta se eles ainda servem a um propósito. Alguém ainda os lê? O tempo gasto com eles é justificado? Existe outro passo intermediário que seria mais leve?

Você nunca sabe, pode achar que está errado. Lembre-se do manifesto Agile, encontramos mais valor em "Trabalhando software em documentação abrangente", mas ainda há valor no último.

Meu palpite, porém, é que você descobrirá rapidamente que o desejo de continuar a escrever documentos pesados diminui quando eles vêem a proximidade entre os casos de uso e as histórias de usuários.

— pdr
fonte

2

@ Phd: Você está certo. É quase primordial. E é por isso que você não vencerá essa batalha com nenhum tipo de lógica, apenas com evidências. Passos de bebê.

— PDR

2

Eu trabalhei para gerentes que enfrentaram mudanças com pequenos passos . Era a palavra de código deles para "fazer apenas o suficiente para falhar, para que eu possa dizer que estava certa". Este não é um caminho para o sucesso, pois mostra uma falta fundamental de compreensão da nova metodologia. e falta de adesão completa da administração, que é crucial para uma mudança bem-sucedida. Isso parece bom em teoria, mas na prática é uma desculpa para não mudar e reivindicar a vitória que o novo caminho não funciona e o antigo. Assim, o SRS foi reforçado e as histórias serão rotuladas como trabalho extra e você voltará para onde estava.

2

Minha experiência não é singular, são mais de 22 anos no setor, a maioria dos quais foi consultoria. Por isso, trabalhei com muito mais gerentes e tomadores de decisão do que a maioria das pessoas no mesmo período de tempo. Meu argumento é que essa abordagem de etapas do bebê é uma abordagem de falha, apenas o comprometimento da alta gerência com a mudança e a filosofia por trás da mudança levará à implementação bem-sucedida. Se seus colegas não estiverem convencidos, deixá-los continuar fazendo o que querem não os convencerá, apenas alimenta o que ainda precisamos da maneira antiga e a nova maneira é uma discussão de perda de tempo.

11

@JarrodRoberson Eu só quero acrescentar que minhas experiências refletem mais de perto as suas. Existem dois tipos de pessoas e, portanto, dois tipos de gerentes, conservadores e tomadores de risco. Os conservadores são naturalmente avessos a mudanças e riscos. Quando eles encontram um modelo que funciona, mesmo mal, eles se apegam a ele. Quando a mudança é forçada ou pressionada, eles subconscientemente a sabotam, tentando dar passos de bebê . É por isso que a única vez em que vi o verdadeiro trabalho de adoção do Agile é quando é liderado por pessoas que assumem riscos.

— Maple_shaft

2

@ maple_shaft: O truque é seguir em frente. Se uma mudança incremental não funcionar, não dê o mesmo passo para trás novamente, considere por que não funcionou ... como se você estivesse gastando muito tempo ainda, escrevendo um documento agora sem sentido. Agora vou admitir que é preciso um bom gerente para pensar dessa maneira, e que a maioria voltará à sua zona de conforto. Mas, exatamente pela mesma lógica, isso não significa que a única outra opção seja uma mudança drástica. Um gerente ruim estragará tudo.

— Pd

6

Épicos são espaços reservados

Em praticamente qualquer metodologia Agile, o conceito de Epics seria o necessário para uma Especificação de Requisitos; os marcadores de posição são o que você precisa nesse nível. Essas entradas serão priorizadas constantemente, mais detalhes serão desperdiçados se o requisito obtiver baixa prioridade por um longo tempo ou nunca for implementado. Documentá-lo e gerenciar a documentação ao seu redor seria uma completa perda de tempo. O YAGNI se estende às atividades de requisitos e às atividades de codificação.

As ferramentas são suas amigas!

Se você usar uma ferramenta adequada para coletar e gerenciar as histórias de usuário, poderá gerar a Especificação de Requisitos a partir delas. De qualquer forma, uma especificação de requisitos é um documento de artefato temporal , não é um documento vivo, é uma captura instantânea de requisitos no tempo. E nunca está em sincronia com a realidade.

Gerar artefatos automaticamente

Histórias de usuários que podem ser exportadas de uma ferramenta adequada são muito mais valiosas do que qualquer documento de artefato estático a qualquer momento. Pessoalmente, prefiro o Pivotal Tracker para rastrear as User Stories, até escrevi um conjunto de plugins MoinMoin no Python para publicar todas as várias Stories e seus estados no Wiki (que continham notas detalhadas do desenvolvedor e coisas do gênero), os dados ao vivo são sempre melhor que dados estáticos.

O Wiki tornou-se um documento ativo de todas as lojas / requisitos e seu estado de conclusão e prioridade com detalhes e comentários e outros metadados.

Muito melhor do que um enorme documento do Word no Sharepoint, que é enviado por e-mail constantemente e nunca é atualizado, garantindo que todos tenham uma versão diferente e estejam fora de sincronia com todos os outros!

Histórias de usuários são mais ricas que casos de uso

A História de Uso é muito mais valiosa que um Caso de Uso, porque eles dizem POR QUE .

O formato da história do usuário: As a [ROLE] I [ACTIVITY] so that [WHY]é muito mais expressivo do que os casos de uso que são The System [shall/shall not/may/must] perform [action](onde ação é um fluxograma).

Com um usuário Story, você tem OMS quer fazer alguma coisa, você tem QUE eles querem fazer (o que pode apontar para um diagrama / documento mais detalhado para tarefas complexas) e você tem a parte mais importante PORQUE eles querem fazer esta atividade.

Se você tiver o primeiro, o segundo será completamente redundante e, na melhor das hipóteses, apenas ruído. Uma especificação formal tradicional de requisitos de uma metodologia Waterfall não tem lugar em um ambiente Agile.

No final

Se sua gerência não estiver comprometida com a mudança, você não terá sucesso com uma nova metodologia. Eu trabalhei para uma empresa de mais de 100 bilhões de dólares por ano, eles não deram pequenos passos ao mudar para o Agile / SCRUM, eles apenas disseram: toda a empresa está mudando para isso, aqui está a nova maneira de fazer as coisas, aqui está quando seu treinamento no novo caminho começar, aqui estão as novas ferramentas que vamos usar, aqui é a data em que começaremos a fazer as coisas dessa maneira. Funcionou para eles em menos de um ano. Eu trabalhei na implementação disso em empresas menores com o mesmo sucesso.

Comprometimento

implementações de etapas de bebê , independentemente da mudança, é uma receita para o fracasso. É uma palavra de código para a gerência que eles não concordam silenciosamente e estão passivamente agressivamente configurando você para a falha. Eles estão dizendo que eu não acredito nisso o suficiente para se comprometer com isso, então eu deixarei você fazer o suficiente para falhar / não ter sucesso , para que eles possam dizer que tentaram e que não funcionou e como estavam gerenciando o trabalho muito bem o tempo todo. O compromisso parcial acaba levando ao fracasso.

No seu caso, eles provavelmente não acreditam nas Histórias de Usuário e, depois de um tempo fazendo as duas coisas, começarão a afirmar que são as Histórias de Usuário que são inúteis e não a SRS, e se esforçarão para parar de escrever as Histórias de Usuário. , o que apenas o levará para trás e não para frente.

— kmote
fonte

você ficará surpreso, as histórias de usuários SÃO gerenciadas por uma ferramenta que pode (e faz) exportar como requisitos. No entanto, a preocupação parece ser 'traduzir' as histórias de usuários para o idioma SRS de "o sistema deve ..." etc., e NÃO deixá-las como histórias de usuários.

— PhD

11

Bem, se o desligamento for a termanologia "deve / deve / pode", você provavelmente está cuspindo no vento com essas pessoas. As histórias de usuário informam a OMS / O QUE e, o mais importante, POR QUE algo precisa ser feito, muito mais útil do que os casos de uso estático, que são mais errados que corrigem na maioria dos casos.

2

-1: Não discordo da maioria das respostas, no entanto, afirmando que e o SRS é "Uma especificação de requisitos é um documento de artefato temporal de qualquer maneira, não é um documento vivo", é tão errado que mostra uma perturbadora falta de compreensão do que serve para um SRS, ou como é usado quando feito corretamente - geralmente apenas nas casas de software de modelo em cascata herdadas atualmente.

— mattnz

5

Um SRS é um documento morto assim que é publicado. Eu os escrevo desde 1990. Eles são como um plano de guerra, nunca sobrevivem ao primeiro contato. E eles nunca acompanham a implementação real, a menos que você tenha uma equipe dedicada de escritores constantemente editando a coisa e mesmo assim esteja errado por causa da desconexão da constante mudança e dos desenvolvedores que estão sempre à frente do documento e nem sempre diga ao proprietário do documento o que está acontecendo. As empresas gastam milhares de horas escrevendo coisas assim, e os documentos são colocados em uma prateleira e apodrecem enquanto o desenvolvimento começa.

3

@JarrodRoberson +1 para você. Na verdade, o mattnz também tem razão em que o SRS seja um documento ativo, mas você toma alguns problemas críticos de produção que o cliente exige que sejam alterados, enquanto trabalha em uma ou mais versões ramificadas da base de código, interpretando mal os requisitos por analistas de negócios, desenvolvedores e controle de qualidade ... o que resta é um documento que não é um reflexo verdadeiro do sistema no momento, mas também não é um reflexo verdadeiro das necessidades do usuário. Histórias de usuários são realmente adotadas por empresas mais preocupadas com o cliente do que com o sistema.

— Maple_shaft

0

Eu tentaria usar o humor.

Comece com o http://www.halfarsedagilemanifesto.org/

Fale sobre isso por um tempo ( desvio )
e fale sobre o que realmente significam os conflitos ( discussão aberta );
depois de um tempo, vá para a sua organização ( pivô )
e examine o SRS e se faz sentido com a nova configuração do projeto. .

Em seguida, concluo (ou talvez em outra reunião) uma discussão sobre a mudança na abordagem re: SRS e ver se você tem mais consenso.

No final do dia, você também é limitado pelo orçamento e atende às pessoas de negócios; portanto, pode haver um momento em que você é um pouco mais firme no que é usado, mas isso realmente depende do setor, tamanho da empresa, fatores organizacionais e muitos outros fatores. outros fatores.

— Michael Durrant
fonte

5

Tenha muito cuidado. Só funcionará se seus colegas de trabalho estiverem muito seguros e você tiver um bom relacionamento com eles. Muitas pessoas ficam chateadas se você usa o humor para dizer que elas estão erradas e escondidas.

— 21468 MarkJ em

-1

Convencer o mgmt a se afastar do SRS e começar a usar as histórias do usuário é essencialmente o mesmo que convencer o mgmt a adotar o Agile. Existem estatísticas convincentes sobre os benefícios de produtividade do Agile. Um exemplo é a apresentação que VersionOne fez em uma conferência de 2013. Mostre a esses dados do setor e se eles são do tipo de escuta, você tem uma chance.

— Joe
fonte

11

Desculpe, isso não é muita resposta. Você diz 'mostrar estatísticas' e nem fornece links.

— Jan Doggen

e fazer palavras completas gravação e frases ...

— jwenting