quando nem todos estão presentes para o DailyScrum

GUJ Master Membro desde: 29/05/2008 14:09:28 Mensagens: 1618 Offline

Tenho pesquisado sobre processos ágeis, e tenho especial interesse pelo Scrum. Pelo que li até agora, uma das práticas mais importantes do Scrum é o DailyScrum, uma reunião diária, de até 15 minutos onde todos os membros da equipe apresentam e discutem o que foi feito no dia anterior e o que se espera no dia que começa, como forma de todos estarem cientes sonre o andamento do projeto.
A minha dúvida é a seguinte, se é possível aplicar o DailyScrum quando nem todos os membros da equipe estão presentes no mesmo local físico. Esta situação é comum quando o cliente está situado em uma cidade e a equipe de desenvolvimento em outra. Nesse caso é necessário que um mebro da equipe esteja na cidade do cliente para o levantamento de requisitos.

O daily scrum pode ser feito remotamente, se for necessário, tu podes fazer usando vido-conferência tranquilamente, a idéia é de que todos os membros participem, como dura no máximo uns 15 minutos, não tem dificuldade em fazer uma cofnerência com os membros remotos.

Estou com o Luiz Aguiar. Ouvi dizer que tem gente que faz até Pair-Programming remoto.

GUJ Master Membro desde: 29/05/2008 14:09:28 Mensagens: 1618 Offline

Sim! Eu já havia lido sobre isso:

http://en.wikipedia.org/wiki/Pair_programming#Remote_pair_programming

O maior problema que tenho na verdade é com o horário dessa reunião....

Rafael Nunes wrote:O maior problema que tenho na verdade é com o horário dessa reunião....

Isso é pior ainda quando os membros da equipes estão em países diferentes, o ideal é encontrar 15 minutos comuns no dia de todos rs

O que é importante frisar é que o DailyScrum é um report para a equipe e não para o PO(cliente) ou SM, então as atividades desenvolvidas por cada um do time são informada para o TIME por isso as 3perguntas basicas.
O PO pode ser um convidado permanente nas reuniões se o time discutir/aceitar, mas o foco das reuniões do DailyScrum são para que o time tenha uma visão geral do sprint e duvidas e opiniões que o PO/SM/TIME queira discutir devem ser feitas em outro momento ou não...

Java Ninja Membro desde: 03/03/2005 09:53:07 Mensagens: 275 Offline

Pelo que li até agora, uma das práticas mais importantes do Scrum é o DailyScrum, uma reunião diária, de até 15 minutos onde todos os membros da equipe apresentam e discutem o que foi feito no dia anterior e o que se espera no dia que começa, como forma de todos estarem cientes sonre o andamento do projeto.

No projeto atual temos feito a reunião mesmo quando um ou dois não estão presentes. Deixamos de fazer algumas vezes quando isso aconteceu e o resultado não foi legal, acabavamos fazendo em outros horários e bagunçando as coisas.

Diferente da reunião de fechamento da iteração, essa sim obrigatóriamente temos feito com todos.

Aproveitando, como vocês tem feito quando, ao fim da iteração, muitas atividas estão concluídas porém não testadas/aprovadas ?

andersonlfl wrote:
Aproveitando, como vocês tem feito quando, ao fim da iteração, muitas atividas estão concluídas porém não testadas/aprovadas ?

Cheguem a um acordo no que é algo "concluído". Testar tem que ser obrigatório antes de dizer que algo está pronto. E se o seu conceito também incluir que algo tem que ser aprovado pelo cliente, então também terá que esperar ele dar o OK.

Se ao final da iteração houverem funcionalidades que ainda não estão concluídas, elas precisarão ser replanejadas. Não tem outro jeito...

Tente uma solução por uma semana, peça feedback. Métodos ágeis funcionam out-of-the-box com certos parâmetros (equipe no mesmo ambiente, cliente presente, projeto relevante, etc) mas funcionam bem em ambientes aversos também.

andersonlfl wrote:
Aproveitando, como vocês tem feito quando, ao fim da iteração, muitas atividas estão concluídas porém não testadas/aprovadas ?

Como disse o Sanchez, pelo que você disse elas não estão concluídas, apenas o códio foi escrito para elas. Desenvolver software Não é um trabalho apenas de programadores, sem passar pelo ciclo voc6e não conclui nada.

This message was edited 1 time. Last update was at 24/06/2008 08:24:09

andersonlfl wrote:
Aproveitando, como vocês tem feito quando, ao fim da iteração, muitas atividas estão concluídas porém não testadas/aprovadas ?

o conseito de done é uma metrica que o time estipula. Se no conseito de done um dos item é a revisão de codigo alguem do time tem que fazer essa tarefa se não essa tarefa não esta culprinda ou se um dos criterios é fazer o depoy da aplicação e não foi feita tambem não está culmprida a tarefa, mas esse criterio qm tem que fechar é sua equipe.

andersonlfl wrote:
Aproveitando, como vocês tem feito quando, ao fim da iteração, muitas atividas estão concluídas porém não testadas/aprovadas ?

Carinha, confesso que não entendi bem o que vc perguntou. Pelo que vc disse eu entendi que vcs estão utilizando métodos àgeis, logo os testes TERIAM que ter sido feitos já que as atividades estão concluidas, correto?. Como não há aprovação se a idéia é ter o cliente presente?

Abraços

Java Ninja Membro desde: 03/03/2005 09:53:07 Mensagens: 275 Offline

s4nchez wrote:

andersonlfl wrote:
Aproveitando, como vocês tem feito quando, ao fim da iteração, muitas atividas estão concluídas porém não testadas/aprovadas ?

Cheguem a um acordo no que é algo "concluído". Testar tem que ser obrigatório antes de dizer que algo está pronto. E se o seu conceito também incluir que algo tem que ser aprovado pelo cliente, então também terá que esperar ele dar o OK.

Se ao final da iteração houverem funcionalidades que ainda não estão concluídas, elas precisarão ser replanejadas. Não tem outro jeito...

pcalcado wrote:
Como disse o Sanchez, pelo que você disse elas não estão concluídas, apenas o códio foi escrito para elas. Desenvolver software Não é um trabalho apenas de programadores, sem passar pelo ciclo voc6e não conclui nada.

Ok, eu falhei na palavra concluída. Na verdade quero saber como vocês tem feito nessa situação onde o "programador terminou sua parte" e o prazo da iteração acabou sem o aval dos testers/cliente ou seja lá quem é o responsável por esse aval no seu projeto.

O que temos feito é manter o cartão repontuando a atividade novamente considerando testes e possibilidade de volta para os programadores corrigirem os bug que podem aparecer.

O que vocês acham dessa abordagem e como tem feito quando isso ocorre?

Acho que você está fugindo do real sentido de iterações. Numa iteração ágil não existe 'meio' concluído, se não foi concluído então não pode ser adicionado à velocidade.

Exemplo:
DONE conta com 4 cartões concluídos somando 8 pontos
em TODO existe apenas um cartão: Acertar a Rebimboca - 3 pontos

Par Shoes & Lampião vão trabalhar na história (como se fala 'play the story' em português?), eles terminam seus testes unitários e estão satisfeitos com seu trabalho. O testador, MarceloD, não veio trabalhar hoje porque ficou trabalhando em seu livro de filosofia sub-quântica. A iteração acaba hoje.

Qual a velocidade aferida nesta iteração?

8. O último cartão não foi concluído, estar meio concluído não é estar concluído. O cartão passa a ser o primeiro da listo pra próxima iteração. Na retrospectiva o par levanta o ponto de que a velocidade oi reduzida porque o testador não estava presente, grupo decide que quando o testador não está presente um outro par pode exercer o papel de QA. Pronto.

Notícias, artigos e o maior fórum brasileiro sobre Java