Todos juntos seria péssimo. Como seria todos os projetos, o número de demandas para a reunião seria alto, você provavelmente passaria o dia inteiro estimando e priorizando, com tres ou quatro participando e o resto só bocejando e esperando terminar. E depois na hora de fazer, como ninguém prestou atenção, tudo teria que ser explicado de novo desde o início.
Dividir acho o seu primeiro passo mesmo. Só o que eu digo é cuidado, vá devagar, faça uma alteração e avalie, faça outra e avalie. Se ver que não deu certo, volte atrás e tente de outra forma.
[quote]Ele me disse que nao sabe o quanto seria produtivo toda a equipe… 12 pessoas participar o planning e organizar as atividades por sprint para todas elas ao mesmo tempo…
Eu tinha uma visão de fazer tudo junto, mas com as indagações dele dei um step back e decidi pedir sua opiniao…
O que vc acha? [/quote]
Como já mencionei em outro post, divida essa equipe em times menores. E veja sobre o treinamento, coloque o experimento em prática num piloto e adapte a sua realidade.
[quote=YvGa][quote=diogogama]Seu post contribuiu bastante, porém discordo de alguns pontos:
1 - [quote=YvGa]Por exemplo, a sprint do Scrum serve para que você encontre o seu cliente, mostre a ele o que você fez e possibilite a ele fazer as alterações antes que seja tarde demais. Você tem esse cenário? Essas alterações que o cliente deseja são bem vindas ao processo? Não parecem ser no seu cenário, visto que você tem os “analistas de requisito”, as demandas bem definidas de antemão e assinadas pelo cliente. Inclusive penalizando ele caso ele tenha esquecido de alguma coisa. [/quote]
Não concordo que a sprint sirva para isso somente, na verdade isso é o menos importante numa sprint, eu por exemplo já trabalhei em um projeto que o cliente só via o resultado a cada 5 ou 6 sprints.
Acho que o mais importante na sprint é a medição e acompanhamento, é você ter prazo e valores bem definidos.
Tipo, tal funcionalidade será desenvolvida em 2 sprints, tenho uma equipe de 5 desenvolvedores voltadas pra isso, então tenho 5 devs, por 2 semanas (supondo que a sprint será de 2 semanas) alocados naquele desenvolvimento, fácil mensurar o preço, certo?
Além de poder acompanhar o desempenho, visto que em 1 semana você consegue ver se a sprint está ok ou deve ser abortada.
[/quote]
Definitivamente discordamos nesse ponto. Ok, o acompanhamento é legal, o burndown é util, mas nenhum nem outro exige a existencia da sprint, voce pode fazer, por exemplo, um planejamento de 6 meses, ou um de vez em quando e acompanhar do mesmo jeito o andamento das coisas. Sem precisar um replanejamento a cada semana ou duas.
Contato com o cliente a cada 5 ou 6 sprints aumenta muito o tempo de feedback e acaba caindo nos mesmos riscos de um projeto em cascata.
Outra coisa que discordo é uma funcionalidade atravessar varias sprints. É uma das regras mais claras do Scrum que uma story deve caber dentro de uma sprint, se não cabe deve ser quebrada para que caiba. Ao final de uma sprint você tem que ter uma versão executável do produto e essa versão não pode conter tarefas inacabadas.
Agora, se quando você diz que uma funcionalidade atravessa várias sprints você quer dizer que ela é quebrada e uma parte é feita na sprint 1 e outra na sprint 2, sem problemas. Desde que essas partes sejam independentes entre si e estejam completas por si mesmas. Por exemplo a funcionalidade “criar login” pode ser grande demais para um sprint e pode ser dividida" o usuario podera criar seu login e senha" e outra “o usuario deve confirmar a senha ao cadastrar seu login”. São duas estorias independentes, que podem ser criadas em momentos completamente distintos, como na sprint 1 e sprint 10, mesmo assim sendo vistas como uma funcionalidade.
O que é certo é que ao fim de uma sprint, para o Scrum, uma versão executável deve ser entregue.[/quote]
Realmente discordamos, não disse que suas estórias tem que ser quebvradas, disse que “se houver necessidade de dividir uma funcionalidade”, yes, you can. Me diga, o cliente quer fazer uma funcionalidade de mudar o banco dele de banco relacional para georeferenciado (supondo que não caiba em uma sprint de 15 dias) o que fazer?
Entende que isso não é um grande problema, desde que haja uma necessidade real?
Novamente acho que meu post não ficou claro. Não disse que o SM deve priorizar, disse que ele (para empresas que prezam excelência) “poderia” prestar um serviço do tipo consultor, visto que o PO pode entender da regra de negócio, mas normalmente não entende de desenvolvimento.
Um exemplo bem extremista e irreal, mas só pra exemplificar o que estou querendo explicar. Imagina um cliente que quer depois desta sprint colocar o sitema no ar, e o sistema dele é um sistema bancário, ele pede para que todas as transações de transferência estejam prontas, mas não existe login ainda. Acho que cabe sim ao SM avisar e prestar esse suporte de consultor dizendo que seria melhor para o sistema colocar o login para subir a aplicação para produção, afinal isso é vital.
Claro, esse exemplo não foi o melhor, rs…, mas é pq não consegui pensar em nada as 8 da manhã… Mas o que quero dizer, é que o PO entende de regra de negócios, mas o SM entende de analise e desenvolvimento (ou deveria) então, acho que ele pode, e deveria, sim opinar o que seria melhor para que o sistema cresça de forma agradável, mas concordo plenamente que a palavra final é do PO.
[quote=YvGa]
[quote]
6 - [quote=hwneto]Ja pensei em quebrar em 3 equipes (Em termos de desenvolvedores seria 1 Senior, 1 ou 2 Plenos e 1/2 Junior ) Pensei em trazer 2 testers da equipe de QA para o Time… E eles testam tudo das 3 equipes.
Algo assim… Mas preciso fazer essa separação com a própria equipe… Vou pensar nisso com carinho, já que não foi a primeira pessoa que falou isso… [/quote]
O scrum defende que todos são dev’s e todos são tester’s (não vejo problema de colocar pessoas especificamente pra isso, mas acho que os testes ficam viciados e prefiro que todos façam tudo), pois uma pessoa tem uma metodologia de testes e uma outra tem uma diferente, por aí vai…
Espero ter ajudado.[/quote]
As vezes há uma pequena confusão de termos nesse ponto. O Scrum defende uma equipe multidiscilplinar, não exatamente que todos fazem tudo. Pode haver especialistas dentro da equipe, a soma das habilidades do time é que deve alcançar todos os requisitos técnicos para o projeto. Não é porque um tester está numa equipe ele tem que aprender a programar.
De resto concordo com você.[/quote][/quote]
Então, concordo que as vezes acontece essa confusão, mas ela acontece porque é realmente como as coisas deveriam ser… A dificuldade de se encontrar bons profissionais multidisciplinar que mudou a posição do mercado.
Acho que seria altamente interessante para o projeto você ter um tester que saiba programar sim, e vice-versa.
Basta ver o exemplo acima que dei, imagine uma pessoa testando 50 crud’s, se um erro tiver contido no primeiro crud que passou sem ela notar, provavelmente vai passar pelos outros 49, visto que as pessoas são condicionadas a repetir sempre as mesmas coisas. Pense o seguinte, se você sai do serviço e vai para sua casa direto (desconsidere fatores externos como trânsito, tempo, etc…) durante 200 anos você iria pelas mesmas ruas, agora imagine você dando seu endereço pra alguém, essa pessoa, muito provavelmente irá por um caminho diferente (pode acontecer de ir pelo mesmo, mas é muito mais fácil ela ir por um diferente do que você)
e isso serve para tudo, além de que um dev sendo tester, ele consegue se envolver melhor no projeto, visto que o mesmo conhece bem os erros, além de poder aprender, pois um erro que ele achar, numa proxima sprint que ele for programar aquele erro será difícil de ele cometer pois estará melhor condicionado…
[quote=YvGa][quote=hwneto]
Ele me disse que nao sabe o quanto seria produtivo toda a equipe… 12 pessoas participar o planning e organizar as atividades por sprint para todas elas ao mesmo tempo…
Eu tinha uma visão de fazer tudo junto, mas com as indagações dele dei um step back e decidi pedir sua opiniao…
O que vc acha?
[/quote]
Todos juntos seria péssimo. Como seria todos os projetos, o número de demandas para a reunião seria alto, você provavelmente passaria o dia inteiro estimando e priorizando, com tres ou quatro participando e o resto só bocejando e esperando terminar. E depois na hora de fazer, como ninguém prestou atenção, tudo teria que ser explicado de novo desde o início.
Dividir acho o seu primeiro passo mesmo. Só o que eu digo é cuidado, vá devagar, faça uma alteração e avalie, faça outra e avalie. Se ver que não deu certo, volte atrás e tente de outra forma.
[/quote]
Também concordo que seria horrível. O que você pode fazer é ao final um review para que todos saibam como está o projeto como todo, etc… Ou a cada 3 sprints, mas acho que o principal estamos todos de acordo… Seria desastroso… rs…
Eu fiz um blog para falar sobre as experiencias passei e vou passar.
Espero que curtam…[/quote]
Parabéns pela participação bastante ativa. Sobre o time do CAOS, não sei se entendi bem, mas acho que cada time deve saber lidar com sua parte do caos. Fora isso, seria desmotivante trabalhar num time que só cuida do caos, eu meteria o pé da empresa.
Eu fiz um blog para falar sobre as experiencias passei e vou passar.
Espero que curtam…[/quote]
Parabéns pela participação bastante ativa. Sobre o time do CAOS, não sei se entendi bem, mas acho que cada time deve saber lidar com sua parte do caos. Fora isso, seria desmotivante trabalhar num time que só cuida do caos, eu meteria o pé da empresa.[/quote]
Esqueci de dizer que esse time é provisório.
Vai existir somente até colocarmos as coisas em dia…
Eu também com certeza nao gostaria de ser desse time para sempre…