O que é um (mas rápido) beta cronograma de versões realista? [fechadas]

Question

A minha equipa está perto de implantar nossa aplicação, e estamos prestes a entrar em beta fechado com alguns clientes selecionados. Eu estou querendo saber o que é um prazo realista seria para produzir novas versões beta, e quantos desses ciclos poderíamos esperar realisticamente a necessidade antes de podermos chamar a primeira versão estável o suficiente para a liberação.

O aplicativo em si é um aplicativo de imagens médicas, por isso absolutamente não pode falhar ou corromper dados. Muitos usuários também estará usando o software por pelo menos quatro a oito horas por dia de forma contínua, por isso espero que os erros de usuário normal será encontrado rapidamente. A aplicação está ligada a uma parte específica de hardware, e se eles têm o hardware, eles terão esta aplicação ou a versão anterior do aplicativo para executar o seu hardware.

É claro, há também pressão de cima para liberá-lo agora, agora, agora! e uma vez que pagam meu salário, eu sou obrigado a seguir as suas instruções, apesar de tudo o receio eu possa ter sobre lançamentos rápidos.

Eu estou pensando que os seguintes cenários poderia jogar fora:

tempo de ciclo semana
1. Two. Temos um grupo selecionado de usuários, dizem três a cinco locais, e quando encontram erros, nós corrigi-los. Eu acho que este tempo de ciclo é absurdamente rápido, mas eu já posso sentir que ele vai ser como os poderes que vai querer implantar. Para esta abordagem, nós bloquear o produto para uma compilação particular, e quaisquer erros que se acumulam vamos corrigir no próximo lançamento (que poderia ser cinqüenta constrói mais tarde).
2. tempo Seis ciclo de semana. Temos o mesmo grupo seleto de usuários, mas esse grupo pode crescer, e à medida que cresce, agimos como na etapa 1. Não tão rápido como 1, mas certamente mais cauteloso. O problema é que os usuários podem ter a impressão de que o produto é excessivamente de buggy (se encontrar bugs), e não terá essa impressão combatida até que solte uma outra versão, em que ponto eles podem deixar de cuidado. Desde há que lockin ao hardware mencionei anteriormente, essa impressão de bugginess pode apenas traduzir em resmungo suave ao invés de vendas perdidas. No entanto, cada nova versão beta será apenas isso muito mais controlados do que o último.
3. O mais rápido que os bugs são corrigidos, se as versões nas mãos de usuários fixos. Temos um servidor de compilação, temos vários testadores, e estamos muito rápido para responder (você pode até dizer, 'ágil'). Há desvantagens para apenas dando correções de bugs o mais rápido que corrigir um bug, desde que a correção não quebrar algum outro comportamento que as necessidades de software? Se tomamos esta abordagem, estaríamos fazendo ciclos, ou apenas um 'período' beta?

Eu percebo que essas questões variam muito de usuário para usuário, e que algo como um período beta da Blizzard ou Gmail é um pouco sobre o lado mais longo. Eu ainda gostaria de ter uma idéia geral de como eu deveria responder a perguntas constantes da administração sobre quanto tempo ele deve estar em beta.

Answer 1

No nosso caso, deixamos o feedback do cliente ditar o nosso ciclo. Depois de lançar a versão beta inicial, ouvimos o feedback. Às vezes há um erro catastrófico e nós deter lançamento do beta, corrigi-lo e, em seguida, retomar. Outras vezes, nós coletamos erros com base na importância do cliente e, em seguida, rollout uma atualização uma vez que a queixa morre para baixo. Em última análise, a percepção do cliente é o que mais importa aqui (em referência a velocidade) e assim equilibrar as suas queixas contra o que a gestão quer é o aspecto complicado. No nosso caso, nós geralmente ir com algum lugar na faixa de 2-4 semanas com base em quantos e quão urgente os erros são.

Answer 2

Isso parece ser uma pergunta melhor respondida logo após a sua primeira onda de retorno de chegar da versão inicial beta. Se os clientes são geralmente feliz, e as questões são mais estética do que estrutural, o plano para uma sessão de beta mais curto. Se você achar que o oposto é verdadeiro, gestão de preparação para se preparar para um longo mais em profundidade período beta.

Eu não sei os detalhes exatos de sua aplicação, mas eu acho que um calendário de lançamento conjunto será mais fácil para os seus clientes para acompanhar. Quando um cliente não encontrar uma questão de alta prioridade, é bom ouvir que a resolução é e será no próximo lançamento em 2 semanas, ou até 6 semanas, desde que não seja meses de distância. 'Patch' a não ser extremamente diciplined pode causar mais problemas do que resolve, com os clientes tendo bases de código estranho e muito diferentes, o que criará difícil de reproduzir questões.

Answer 3

Go com o número 1. Sem dúvida, é provavelmente o melhor caminho a percorrer. # 2 não é, obviamente, ideal, por causa do tempo de ciclo longo. # 3 é tentador, e fará com que você praticamente uma quantidade enorme de problemas. Aqui está a razão:. Se você implantar correções para quem precisa deles como eles precisam, você perde completamente qualquer esquema de versionamento racional, e manter o controle de qual cliente tem que corrige e quais versões é complicado na melhor das hipóteses

Answer 4

Eu vi um-e-um calendários de lançamento. O primeiro lançamento está previsto, maior, inclui características, aybe 6-8 semanas ou às vezes mais. A segunda é uma correção planejada, duas semanas de intervalo. Assim, a cada 10-12 semanas você tem 2 lançamentos.