GUJ Discussões   :   últimos tópicos   |   categorias   |   GUJ Respostas

Scrum/Agile em Empresa Tipo Fabrica de Software.. Help


#21

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.


#22

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.


#23

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]

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

Abraços.


#24

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


#25

Galera.

Eu fiz um blog para falar sobre as experiencias passei e vou passar.

http://nopainnoscrum.blogspot.com.br

Espero que curtam...


#26

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.


#27

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


#28