[Resolvido] Dúvida no Diagrama SCRUM que fiz

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.

[color=red]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.[/color]

Segue o arquivo anexado.


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.

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?

Segue Diagrama corrigido:


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?

[quote=guvilla]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”.
[/quote]
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!

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.

Vamos lá:

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

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

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

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

[quote=peczenyj]
Perceba como eu reforcei a palavra “time” – da forma como vc descreveu é um RUP com PO e Scrum Master + post-its.[/quote]
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?

[quote=guvilla]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? [/quote]

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

É 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.

[quote=guvilla]
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?[/quote]

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. :slight_smile:

[quote=cmoscoso]
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.[/quote]

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 :wink:

meus dois 2 cents se tratando das estimativas:

[]s

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.

Sou especializado em testes de software, atuei 6 anos com desenvolvimentos de software em cascatas e nos últimos 3 anos estou atuando com a minha equipe em métodos ágeis onde muitas vezes utilizamos o SCRUM para gerenciamento das nossas atividades.

Muito boa a sua abordagem, num modo geral, mas lhe antecipo algumas dificuldades que já passei utilizando profissionais de testes dentro dos times scrum:

  • falta de confiança dos desenvolvedores nos profissionais de testes;
  • impossibilidade dos especialistas em testes em codificar;
  • grande quantidade de defeitos encontrado dentro dos sprints;
  • grandes dificuldades em colocar desenvolvedor para realizar testes, devido a falta de conhecimento em técnicas de testes;
  • visão muito equivocada dos Scrum Master’s que automaticamente quando se concluía a as atividades de codificação deveria ser concluído o Sprint, não dando a importância as atividades de testes (funcional, performance, integração, regressão);
  • como os testes de aceite ficavam fora do sprint (acredito que seja correto isso) e com o cliente, dificuldade em realizar bons aceites;
  • devido a grande quantidade de defeitos encontrado pelos especialistas em testes, os prazos dos sprints ficavam comprometidos;
  • falta de visão do scrum master, pois o mesmo sempre induzia a equipe em tirar atividades de testes e não escopo;

Essas foram algumas dificuldades que tivemos no início, mas com o passar do tempo, com a qualificação de nossos scrum master, encontramos solução par todas elas.

olá guvilla, parabéns pela abordagem, ficou bastante agradável e objetivo.

acho que seria interessante inserir o final do sprint, tendo consequente reunião no final da iteração com equipe sobre os 5 aspectos abaixo:

[quote]1. o que deu certo. quem vai ganhar chocolate ?
2. o que deu errado. quem cagou ? quem vai levar dedada ? e quem vai passar pelo corredor ?
3. o que deveria ter sido feito
4. o que será e o que não será feito no próximo sprint ou projeto como num todo
5. o que foi feito e poderá ser melhorado(será melhor avaliado, tendo consequente pesquisa)
6. onde vai ser a rodada de cerveja ? :lol: [/quote]
após reunião, colocar na wiki.

onde estão os testers no seu diagrama ou stakeholders? testes funcionais são interessantes por não desenvolvedores ou não participantes do desenvolvimento do sprint ou que não tenha desenvolvido a funcionalidade em questão!

uma dica também é você não ter um diagrama seco do scrum, você pode acrescentar algumas práticas que você achar conveniente, como pair programming, incentivo ao uso da wiki em alguns casos para colher informações importantes no início, durante e fim do sprint, como mencionei acima.

quanto aos passos que você passou para os desenvolvedores, a sequência sempre tem sido desta forma, o que tem dado certo e errado ? a intenção é você adicionar uma opção alternativa ou condicional, caso alguma coisa não tenha saído na sequência certa.

outra dúvida é como você consegue separar status para cada um destes passos no seu scrum-ban para cada cartão ou ferramenta de issue tracker, pergunto pois você especificou teste de performance, regressão e aceitação ?

Veja que na primeira versão do diagrama eu coloquei os testers, mas por conselho de algumas pessoas, tornei a equipe multi-disciplinar, ou seja, quem desenvolve também testa. Pelo que me foi passado, no Scrum não há papéis isolados e bem definidos. Todos são responsáveis pelas entregas. Achei meio caótico, mas como nem se quer implantei ainda, não tem como eu contra-argumentar.

Me explica melhor como usar Wiki no desenvolvimento, pois tenho ouvido em alguns lugares esse tipo de sugestão, mas não sei como integrar isso ao dia-a-dia. Estou super interessado nesse tema.

[quote=faelcavalcanti]
outra dúvida é como você consegue separar status para cada um destes passos no seu scrum-ban para cada cartão ou ferramenta de issue tracker, pergunto pois você especificou teste de performance, regressão e aceitação ?[/quote]

Imagino fazer isso com os post-its, já que as tarefas estarão no quadro. Estou errado?

concordo, equipe multi-disciplinar fica mais evidente o objetivo da equipe.

a intenção é disponibilizar informações para equipe quanto à decisões, guias, lições, auto-ajuda, entre outros fatos durante a execução do backlog. dependendo do tamanho do projeto, isto pode-se tornar fundamental, principalmente quando existe rotatividade de profissionais na empresa.

com uma wiki você terá a possibilidade também de manter informações acessíveis sobre seu projeto, sobre o que está acontecendo de fato, por exemplo o seu burndown chart do dia.

dentre estas razões eu resumiria também:

[quote]1.tornar certos treinamentos mais baratos, rápido aprendizado e mais acessível
2. estimula auto-organização, quebra de rotina e mais participação com o projeto
3. aumento de imagem externa da equipe, dando mais visibilidade[/quote]

existe uma apresentação sobre a wiki bem legal da atlassian com o confluence, mas você pode usar em junção com seu issue tracker como no caso do redmine, entre outros open sources por conta do custo, mas a longo prazo acho que vale a pena

não. fiquei imaginando, uma situação caótica em que uma atividade é concluída, porém ela possui inúmeros testes que não passaram, entre outras coisas novas que apareceram e não foram previstas, bem como mudança de arquitetura e banco, então como você manteria a rastreabilidade ou hierarquia para identificar que esta funcionalidade está fechada até passar no teste de aceite conforme seu fluxo em diagrama ou abordagem que você pretender tratar ainda ?