[Resolvido] Dúvida no Diagrama SCRUM que fiz

HelloWorld Membro desde: 08/03/2009 17:05:03 Mensagens: 10 Offline

Olá pessoal! Em primeiro lugar, esse é meu primeiro tópico aqui, mas vocês estão de parabéns pela colaboração.
Fui estimulado por um membro do site: Fernando Boaglio.

O caso é o seguinte: Estou estudando SCRUM e resolvi montar um diagrama para o pessoal da minha empresa entender como funciona.
Porém, como comecei a estudar SCRUM a pouco tempo, não sei se está correto.

Nossa equipe é pequena (3 desenvolvedores) e quero deixar claro na cabeça de todos como funcionará o desenvolvimento a partir de agora.

Envio o arquivo JPG para darem a opinião de vocês.

ATENÇÃO: Essa não é a versão final (por isso estou postando aqui) e não envolve somente SCRUM; também inseri processos de desenvolvimento que não são tratados pelo Scrum.
Se quiserem opinar no desenvolvimento, ok, ficarei grato, mas o mais importante é o ciclo de vida Scrum estar correto. Ai quero ser fiel ao Scrum.

Segue o arquivo anexado.

GUJ Expert Membro desde: 22/03/2005 20:57:48 Mensagens: 3433 Offline

Primeiro vc tem que saber que existe uma diferença (algumas na realidade) entre Scrum e Gerenciamento Agil de Projeto (APM)
Scrum existe que exista um Product Owner e um Backlog (lista principal de requisitos/estorias)
Scrum não exige XP mas casa muito bem. Então é comum ver as pessoas confundirem os dois. mas Scrum não estabelece como o desenvolvimento é feito porque é uma metodologia de gerenciamento , não de desenvolvimento (XP é de desenvolvimento).

Além do Product Owner e do Backlog existe a "Definição de Pronto". Este definição muda de projeto para projeto e de equipe para equipe. Às vezes pronto significa "programado" outras significa "programado e testado" outras "programado, testado automaticamente, documentação atualizada".

O primeiro passo é a criação do backlog. Isto só acontece uma vez. Mas podemos pensar que criar o backlog nada mais é que atualizar um backlog vazio, logo, o primeiro é atualizar o backlog com as estorias que compoem o software.
O segundo passo é avaliar as estorias. O terceiro é priorizar as estorias.

O primeiro e o terceiro é feito pelo project owner. o segundo pela equipe de desenvolvimento. O scrum master não participa do processo ele apenas acessoria o processo (lembre-se que é um processo de gerencia). Mesmo que o scrum master seja tb um dos desenvolvedores ele não pode misturar as coisas.

O proximo passo é criar sprints. O sprint é um periodo de tempo em que ha desenvolvimento de uma sub-lista de estorias retiradas do backlog. A escolha de quais é feita pelo PO e a equipe juntos.

Durante o desenvolvimento ( o sprint) os desenvolvedores têm que acabar as estorias (conforme a especificação de "pronto"). Desenvolvedores inclui toda a equipe desde designers a testers. (em XP não existe o processo de passar as coisas aos testes pq todoas são testes, mas em geral isso é um subprocesso irrelevante para o scrum). O ponto é que no fim do sprint algumas estorias estão prontas e outras não. "pronto" aqui tem um significado tecnico e não é aceitável "meio-pronto' ( o famoso: "está pronto mas falta testar " não existe)

Outro ponto importante do scrum é a demostração. Cada sprint tem que acabar com uma demonstração publica das estorias implementadas. Sempre. Às vezes o sprint tem que ser maior para dar tempo de criar a infra necessária para a demo, mas não é possível abdicar da demo ( não em scrum).

A estoria não é mostrada quanto está pronta , ela é mostrada no fim do sprint em que ficou pronta.

APM é mais flexivel que scrum, porque não exige demo, nem product owner.

O seu diagrama falta o esquema de sprints que é o coração de todos os processo ageis.

Outro erro é tomar o gerente como scrum master. O gerente é o Product Owner.
O Cliente não tem papel em scrum. Em tese ele pode ser o product owner, mas isso é uma má ideia.
O cliente pode participar das reuniões e o PO pode procurá-lo para pegar info.
Outra opção é deixar o analista como PO. Neste caso o Gerente está à margem do processo.

O scrum master é melhor alguem independente que tem nada a perder/ganhar com o projeto. Ele é como um juiz no futebol ele está ali para que as regras sejam seguidas e principalmente não seja dobradas ou quebradas. Ele não está ali para jogar o jogo.

É claro que nem sempre é possivel ter uma pessoa diferente para todos os papeis, mas esse é o plano ideal.

HelloWorld Membro desde: 08/03/2009 17:05:03 Mensagens: 10 Offline

sergiotaborda wrote:
O seu diagrama falta o esquema de sprints que é o coração de todos os processo ageis.

Outro erro é tomar o gerente como scrum master. O gerente é o Product Owner.

O scrum master é melhor alguem independente que tem nada a perder/ganhar com o projeto. Ele é como um juiz no futebol ele está ali para que as regras sejam seguidas e principalmente não seja dobradas ou quebradas. Ele não está ali para jogar o jogo.

Sergio, agradeço por suas colocações.
A principal que vai fazer diferença é a questão da diferenciação do papel de gerente e SCRUM master. Showww de bola! Você tem toda razão.

Sobre os Sprints, coloquei isso no diagrama.
No meu entendimento, no SCRUM a gente faz várias reuniões com o PO (nesse caso o PO é o cliente ao meu ver).
Nessas reuniões são apresentados os resultados do Sprint anterior e levantadas novas histórias para a próxima etapa. (Nada de uma única reunião para determinar todo o escopo do projeto)
As iterações se repetem sempre a cada sprint... levantam-se os backlogs, as prioridades, desenvolve-se, testa-se, demonstra-se, etc, etc, etc.
Neste caso, não sei se entendi o que quis dizer com "O gerente é o PO". Se eu entendi, não concordei, já que cada sprint tem que ser discutido com o cliente.

Sobre o SCRUM não tratar questões referentes ao desenvolvimento, isso eu já sabia. No tópico citei isso, dizendo que não me importava com as etapas de desenvolvimento contanto que a parte de SCRUM estivesse fiel.
Pelo visto não fui claro na colocação., então está citado: Eu sei que detalhei o processo de desenvolvimento e que isso não faz parte do SCRUM, mas como esse diagrama será usado para minha equipe entender todo o processo de desenvolvimento, resolvi unicar as coisas para ficar mais claro.

Outra coisa que faltou que um amigo me alertou foi deixar claro a questão dos registros após cada Sprint para tirar conclusões e tomar decisões.

Resumindo:
1) Separar Scrum master de gerente de projeto
2) Citar os registros após cada Sprint
3) Unificar tester e desenvolvedores (sugerido por um amigo, alegando que a equipe deve ser multidisciplinar)
4) Colocar os desenvolvedores na mesa para discutir o Sprint com o cliente (também sugerido por um amigo)

Concordam?

HelloWorld Membro desde: 08/03/2009 17:05:03 Mensagens: 10 Offline

Segue Diagrama corrigido:

HelloWorld Membro desde: 08/03/2009 17:05:03 Mensagens: 10 Offline

Me surgiram mais algumas dúvidas:

Como fica essa questão no caso de trabalhar com designers para a parte visual junto com os programadores? Não há como ter multidisciplinaridade neste caso.
Por experiência própria, o processo mais fácil é os designers prepararem as telas e os programadores virem em seguida codificando.
Como no Scrum todos estão envolvidos com o processo como um todo, acho difícil integrar o designer nesse contexto de "fazer tudo".

Outra questão é sobre o desenvolvimento em sí.
Imaginem: O designer está preparando a tela enquanto os programadores modelam o BD e fazem as regras de negócio.
Se for isso, imagino que o designer vá terminar as telas bem antes que os programadores.

Assim que o designer terminar de codificar as telas, o que ele faz? fica parado esperando o próximo Sprint (desperdício de recurso)? Ou mando o designer para outro projeto por exemplo?

guvilla wrote:Me surgiram mais algumas dúvidas:

Como fica essa questão no caso de trabalhar com designers para a parte visual junto com os programadores? Não há como ter multidisciplinaridade neste caso.
Por experiência própria, o processo mais fácil é os designers prepararem as telas e os programadores virem em seguida codificando.
Como no Scrum todos estão envolvidos com o processo como um todo, acho difícil integrar o designer nesse contexto de "fazer tudo".

Alguns links sobre o assunto:
http://www.acarlos.com.br/blog/2008/12/agile-ux-como-integrar-ux-e-desenvolvimento/
http://www.acarlos.com.br/blog/2009/01/mais-pensamentos-sobre-agile-ux/
http://gc.blog.br/2008/12/19/como-trabalhar-com-os-designers/

Boa leitura!

HelloWorld Membro desde: 08/03/2009 17:05:03 Mensagens: 10 Offline

Muito bom, mas ainda assim o conteúdo do link não foi objetivo dizendo algo como: "Pode fazer como achar melhor, mas aqui fazemos assim assim assado"

Vejamos:

Discutir: O Scrum Master discutindo com o PO -- isoladamente -- é fonte de RUIDO. O ideal é que o time TODO converse com o PO, entenda o que ele quer e escreva as user stories, epicos, etc. Cada user story deve ter um criterio de aceitação bem definido, assim como a tripla { PARA QUEM | O QUE | DE QUE FORMA }. O Scrum Master esta ali para zelar pelo time, não para gerenciar o projeto. Nessa etapa de discussão o time estima o tamanho das tarefas de acordo com a sua complexidade através de planning poker.

Decidir: O time, sabendo da sua velocidade media anterior, se compromete com uma quantidade X de pontos, então são escolhidas as user stories que o PO priorizou. Se o time não sabe a sua velocidade, deve ser feito um piloto, um primeiro sprint para experimentar as novas tecnologias e desafios. O time não pode se comprometer com mais do que ja fez no passado! O PO não pode forçar a barra, muito menos o Scrum Master - esse é o compromisso do time e, naturalmente, a velocidade vai subindo até atingir o seu patamar de "cruzeiro". Lembrando que estas estimativas são apenas... estimativas!

Desenvolver: o time desenvolve. Encontrado um obstaculo/ impedimento o Scrum Master deve agir. Scrum Master não é time então não pode se comprometer com taregas ou com a entrega - senão ele não fará o seu papel direito. Se vc quer desenvolver e passar para o testador depois, isso é uma decisão sua, não vejo pq o tester não ser parte do time, comprometido com a entrega e testando sob demanda: inclusive o time poderia inovar em testes unitarios e funcionais/automatizados usando o expertise do tester para encontrar os cenarios de teste mais adequados. Integração continua, por exemplo, é uma realidade em muitas empresas como HP, globo.com, etc. Ao meu ver o COMO vc desenvolve é responsabilidade do time: se vc vai ter teste automatizado, se vai documentar, etc.

Demonstrar: o time mostra ao PO que o produzido passa nos criterios de aceitação especificados antes do inicio do sprint (o PO dá o aceite) E o time reflete como foi o ultimo sprint, os pontos bons e os pontos a melhorar.

Perceba como eu reforcei a palavra "time" -- da forma como vc descreveu é um RUP com PO e Scrum Master + post-its.

HelloWorld Membro desde: 08/03/2009 17:05:03 Mensagens: 10 Offline

Vamos lá:

peczenyj wrote:
Discutir: O Scrum Master discutindo com o PO -- isoladamente -- é fonte de RUIDO. O ideal é que o time TODO converse com o PO, entenda o que ele quer e escreva as user stories, epicos, etc. Cada user story deve ter um criterio de aceitação bem definido, assim como a tripla { PARA QUEM | O QUE | DE QUE FORMA }. O Scrum Master esta ali para zelar pelo time, não para gerenciar o projeto. Nessa etapa de discussão o time estima o tamanho das tarefas de acordo com a sua complexidade através de planning poker.

No SEGUNDO DIAGRAMA (corrigido) fiz essa mudança e integrei o time ao PO.

peczenyj wrote:
Decidir: O time, sabendo da sua velocidade media anterior, se compromete com uma quantidade X de pontos, então são escolhidas as user stories que o PO priorizou. Se o time não sabe a sua velocidade, deve ser feito um piloto, um primeiro sprint para experimentar as novas tecnologias e desafios. O time não pode se comprometer com mais do que ja fez no passado! O PO não pode forçar a barra, muito menos o Scrum Master - esse é o compromisso do time e, naturalmente, a velocidade vai subindo até atingir o seu patamar de "cruzeiro". Lembrando que estas estimativas são apenas... estimativas!

No SEGUNDO DIAGRAMA (corrigido) fiz essa mudança e citei a questão de apurar o Sprint anterior.

peczenyj wrote:
Desenvolver: o time desenvolve. Encontrado um obstaculo/ impedimento o Scrum Master deve agir. Scrum Master não é time então não pode se comprometer com taregas ou com a entrega - senão ele não fará o seu papel direito. Se vc quer desenvolver e passar para o testador depois, isso é uma decisão sua, não vejo pq o tester não ser parte do time, comprometido com a entrega e testando sob demanda: inclusive o time poderia inovar em testes unitarios e funcionais/automatizados usando o expertise do tester para encontrar os cenarios de teste mais adequados. Integração continua, por exemplo, é uma realidade em muitas empresas como HP, globo.com, etc. Ao meu ver o COMO vc desenvolve é responsabilidade do time: se vc vai ter teste automatizado, se vai documentar, etc.

Não mudei, afinal o Scrum master sempre teve papel separado no meu diagrama. Desde o primeiro.

peczenyj wrote:
Demonstrar: o time mostra ao PO que o produzido passa nos criterios de aceitação especificados antes do inicio do sprint (o PO dá o aceite) E o time reflete como foi o ultimo sprint, os pontos bons e os pontos a melhorar.

Como disse, no SEGUNDO DIAGRAMA (corrigido) fiz essa mudança e citei a questão de apurar o Sprint anterior.

peczenyj wrote:
Perceba como eu reforcei a palavra "time" -- da forma como vc descreveu é um RUP com PO e Scrum Master + post-its.

E por último, não entendi onde deixei de considerar a equipe um time.

Será que entendi tudo errado ou você não me entendeu?

guvilla wrote:Me surgiram mais algumas dúvidas:

Como fica essa questão no caso de trabalhar com designers para a parte visual junto com os programadores? Não há como ter multidisciplinaridade neste caso.
Por experiência própria, o processo mais fácil é os designers prepararem as telas e os programadores virem em seguida codificando.
Como no Scrum todos estão envolvidos com o processo como um todo, acho difícil integrar o designer nesse contexto de "fazer tudo".

Outra questão é sobre o desenvolvimento em sí.
Imaginem: O designer está preparando a tela enquanto os programadores modelam o BD e fazem as regras de negócio.
Se for isso, imagino que o designer vá terminar as telas bem antes que os programadores.

Assim que o designer terminar de codificar as telas, o que ele faz? fica parado esperando o próximo Sprint (desperdício de recurso)? Ou mando o designer para outro projeto por exemplo?

Eu acho que entendi, o duro é lhe propor uma solução pra isso rsrsrs.

Estas coisas que vc quer aplicar não pressupõe elementos com atividade extremamente específica; como a de um designer. Porque a parte visual acaba saindo de qualquer maneira no final devido as criticas / sugestões expostas pelo time e principalmente pelo cliente (melhoria continua) durante o desenvolvimento. Porem concordo com vc, ter designers na equipe realmente facilita muito em vários momentos.

Na minha opinião, se vc não tiver demanda para estes designers e eles não estiverem dispostos a executar outras atividades acredito que será dificil mante-los no contexto.
Sendo assim vejo 2 saidas sem causar traumas:

1) Supondo que tenha demanda de vários projetos para designers na empresa, eles poderiam ser uma equipe "separada" desempenhando um papel de fornecedor de serviços para sua equipe (Eles podem até aplicar scrum também etc...).

2) Se vc tiver mais sorte eles podem estar dispostos a executar outras atividades dentro da equipe quando a parte de designer "terminar".

Desculpem se enrolei muito, mas achei que tinha que falar alguma coisa nesse momento rsrsrs.

flws

HelloWorld Membro desde: 08/03/2009 17:05:03 Mensagens: 10 Offline

É Fantomas, mas tenho lido por ai e me recordo do vídeo do Daniel Bardusco onde ele diz que separar a equipe de designers é tira-los do esquema Scrum e o jeito é integra-los.

Estou pensando em integrar o designer part-time caso fique ocioso. E o tempo que estiver livre partir para outro projeto ou atividade por exemplo. As interações dos designers seriam em momentos em que eles são importantes.

Se durante o processo ficar claro que precisa-se dele full-time, ótimo, é questão de realocar. Não sei se isso irá ferir o esquema do Scrum, mas não estou vendo outra saída.

This message was edited 1 time. Last update was at 11/03/2009 19:05:53

guvilla wrote:
Outra questão é sobre o desenvolvimento em sí.
Imaginem: O designer está preparando a tela enquanto os programadores modelam o BD e fazem as regras de negócio.
Se for isso, imagino que o designer vá terminar as telas bem antes que os programadores.

Assim que o designer terminar de codificar as telas, o que ele faz? fica parado esperando o próximo Sprint (desperdício de recurso)? Ou mando o designer para outro projeto por exemplo?

Acho que isso se aplica a todos, nao apenas ao designer, considerando que cada um é responsavel por reportar o termino da sua tarefa me parece o mais saudavel para o processo cada um decidir o que fazer nas horas vagas, baseado num leque de opcoes de atividades pendentes para o projeto, ou nao. Se tiver um video game disponivel pode ser uma forma de passar o tempo tb. Ou ainda, se nao houver mais atividades pendentes poderia mandar ir ao bar buscar algumas cervejas.

HelloWorld Membro desde: 08/03/2009 17:05:03 Mensagens: 10 Offline

cmoscoso wrote:
Acho que isso se aplica a todos, nao apenas ao designer, considerando que cada um é responsavel por reportar o termino da sua tarefa me parece o mais saudavel para o processo cada um decidir o que fazer nas horas vagas, baseado num leque de opcoes de atividades pendentes para o projeto, ou nao.

Interessante a sugestão. Posso inclusive estimular os designers (ou mesmo os programadores) a estudarem no tempo livre após o fim das tarefas no Sprint...
Vou pensar direitinho, mas creio que funcionará bem assim

meus dois 2 cents se tratando das estimativas:

http://robsonvf.wordpress.com/2009/03/08/estimando-imprevistos-em-ciclos-ageis/

[]s

GUJ Expert Membro desde: 22/03/2005 20:57:48 Mensagens: 3433 Offline

guvilla wrote:
Nessas reuniões são apresentados os resultados do Sprint anterior e levantadas novas histórias para a próxima etapa. (Nada de uma única reunião para determinar todo o escopo do projeto)

Isso não é bem assim.
Existe sim um conjunto de reuniões antes de começar nas quais se forma o backlog.
O backlog tem que ter estorias do principio ao fim do sistema. Podemos dizer que o "backlog é o sistema" no sentido que apenas o que está nele será implementado.

É necessário ter um backlog macro para pode estimar a duração do projeto. Sim é necessário determinar o escopo do projeto!
A cada sprint são escolhidas estorias desse backlog (por ordem de prioridade, principalmente) e forma-se um sprint log. Esse é o que deve ser feito até o final do sprint.

A única coisa é que o backlog é dinamico e é suposto serem adicionadas e removidas estorias. Estorias grandes separas em menores, e pequenas agrupadas em maiores.
Tudo isto acontece à margem do sprint, sem interferir com o sprint log.

Este metadologia não é esclusiva de scrum, é compatilhada por todas as metodologias ageis.

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