Solucionado (ver solução)
Solucionado
(ver solução)
2
respostas

Dúvidas gerais / Situação real

Prezados, algumas dúvidas. Vou por um exemplo prático apenas para ver se as idéias se enquadram. Vamos supor por exemplo, que eu tenha um cliente.

1) Reunião "comercial": Na maioria das vezes é um responsável comercial que faz as negociações com o cliente e já fecha um "pacote de horas" ou um valor pelo projeto. Considerando metodologia ágil, essa abordagem mudaria? Seria um membro da equipe ágil que participaria dessa reunião com o comercial para ver as necessidades iniciais? Seria então o caso de se definir um valor/hora e então conforme as entregas forem sendo feitas seria cobrado?

2) Na reunião inicial, o cliente apresenta a sua necessidade, exemplo: "Tenho em minha empresa 4 sistemas, um de emissão de nota/boleto, sistema de pedido por mobile, sistema de venda interna e sistema de envio de email em massa. Quero unificar todos os cadastros em um único sistema, para não ter que ficar atualizando todos os cadastros sempre que mudar ou aparecer um novo cliente". Aqui já haveria participação de outros membros da equipe? O cliente já falaria de todas as "histórias" ?

3) Reunião Inception: Definição dos membros da equipe, análise da solicitação do cliente. Com a "história" inicial, seria feita uma nova reunião para detalhamento da solicitação inicial do cliente? E se houver necessidade de ir até a empresa do cliente para entender melhor como é sua estrutura e seus programas para montar/entender as reais necessidades do cliente? Vamos supor que cada sistema do cliente, é uma forma diferente de acessar os dados (direto via Banco de Dados, via WebService, via leitura de arquivo texto). Cada forma seria um "recurso", com suas respectivas histórias?

4) Uma história seria algo como: a) Preciso de uma interface única, acessível via internet. Nessa interface eu veria todos os meus clientes cadastrados; b) Preciso que ao atualizar um cliente nessa interface, automaticamente atualiza nos demais sistemas que eu uso;

5) Processo de Desenvolvimento: Realização do Backlog, Sprints, Reuniões Diária, revisões, roadmap, release, demonstração, e entrega. A instalação na estrutura do cliente seria uma história, responsabilidade da equipe?

6) Eu li em uma outra questão do fórum, que as história são temporárias, são descartadas. Mas como proceder caso no futuro o cliente solicitar novas alterações, e os membros que participaram desse projeto estiverem em outro projeto (ou não estiverem mais na empresa) e a equipe disponível é nova... Como proceder? Faz algum tipo de documentação do projeto?

Por enquanto é só. Obrigado!

2 respostas
solução!

1) Eu pratico o seguinte: Levanto o máximo de detalhes durante a pré-venda e levo para um dos meus times e fazemos o planning poker com o nível de detalhes que possuímos. A partir desta métrica inicial, passo para o cliente as horas e tento deixar mais claro o possível que a fase de pré-venda é uma estimativa, podendo estar sofrer alterações tanto para cima quanto para baixo no valor do projeto, e que sempre estas alterações serão passadas claramente para o cliente e de comum acordo.

2) Você poderia apresentar as histórias de acordo com as informações que ele passou e o nível de detalhes dela. Neste caso mais uma vez eu deixaria claro que haveria um refinamento de detalhamento destes.

3) Provavelmente quando esta história sair do backlog do produto para ir para o backlog do sprint atual você terá que levantar mais detalhes sim deste requisito. Na minha opinião o time deve prever a necessidade de uma eventual visita ao cliente e marcar este ponto como um impedimento para iniciar esta história. Em relação ao cenário de acesso aos dados, se você entender que são diversas interfaces, eu quebraria em diversas histórias, caso contrário, eu montaria uma história contendo os requisitos e os critérios de aceite bem detalhados.

4) Esta lista são mais necessidades do que histórias você pode usar o modelo apresentado no curso: "Como eu quero " vale a pena você detalhar a prioridade deste item de acordo com a necessidade do cliente

5) Isso varia de caso a caso. Se no seu projeto está imprevisto a implantação, você deve criar sim uma história para tal. Caso contrário, não vejo necessidade.

6) Você pode incluir no projeto qualquer tipo de documentação que você julgar necessário. É uma prática muito comum ao término do projeto gerar uma especificação final do projeto ou implementar ela durante o andamento como uma história independente das demais (Ex: Criação de um detalhamento de caso de uso) ou até mesmo inserir a necessidade da criação de uma documentação como definição de pronto de uma história, mesmo que esta seja feita após o desenvolvimento.

Obrigado Hellen. Suas colocações me auxiliaram muito.

Quer mergulhar em tecnologia e aprendizagem?

Receba a newsletter que o nosso CEO escreve pessoalmente, com insights do mercado de trabalho, ciência e desenvolvimento de software