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.
Sim! Eu já havia lido sobre isso:
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…
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 ?
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.
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.
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.
[quote]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 ? [/quote]
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
[quote=s4nchez][quote=andersonlfl]
Aproveitando, como vocês tem feito quando, ao fim da iteração, muitas atividas estão concluídas porém não testadas/aprovadas ?
[/quote]
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…[/quote]
[quote=pcalcado]
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.[/quote]
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?
- 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.
e esse cartão volta repontuado ou com a mesma pontuação da iteração anterior ?
Quando nem todos estão presentes, a gente costuma mandar antecipadamente as respostas das 3 perguntas para o ScrumMaster. É certo que a pessoa ausente perde a reunião, mas os outros não perdem o update da pessoa ausente. Acho que não é o ideal, mas é melhor que nada.
e esse cartão volta repontuado ou com a mesma pontuação da iteração anterior ?
[/quote]
No planejamento do Sprint/Iteração, todas os cartões podem ser reavaliados (IMO devem). Acho que a pontuação anterior pode até mudar, dependendo das pedras que o time já tenham quebrado durante a última iteração/sprint.
Com a mesma pontuação. Como falei você não conta pontos por meia história. Pode parecer que a iteração N+1 ganhou uma ajuda na velocidade mas o fato de que a iteração N perdeu pontos balanceia. Para todos os efeitos é como se vocês adiantassem o desenvolvimento de uma história que não era daquela ieração.
Se você repontuar vai voltar para o problema dos Gantt Charts com tarefas. Quantos % concluído? Quantos % equivale o código pronto em uma tarefa? Quantos % equivalem os testes? E no final o projeto chega ao fim com todas as tarefas em 70% concluídas 
Humm …
Mas se a percepção do problema mudar? Nem assim você acha que deve-se repensar? Talvez algum detalhe da estória que o PO não havia passado ou o time não havia percebido.