Empregos

[doom_master]

Verdade. Volta e meia há reuniões apenas porque é suposto haver.

[Visitante]

Aqui usa-se o OpenProject.

Como é uma agência volta e meia caga-se nisso até alguém se lembrar, como ninguém fecha tarefas ou dá feedback eu já desisti daquilo.

O OCD do chefe quer que toda a gente ponha as horas de (não do) trabalho lá, cago de alto nele, não tenho paciência para microgestão.

[HIM]

Citação de Solero, há 8 horas:

Claro que fazem, sem dúvida nenhuma. O meu comentário foi exagerado, como é óbvio, mas acho que se dá um peso excessivo a reuniões que param a equipa toda como sprint plannings e reviews e acaba-se por se perder aquilo que tanto se apregoa, que é agilizar. 

As míticas reuniões para saber se devem de contratar a empresa de Catering X porque tinham uns bolinhos miniatura muito bons na última vez que a contrataram.... fuck, been there, done that...

Planeamento e gestão de pessoas é complicado, principalmente quando se tenta agradar a gregos e a troianos. Mas existem mínimos que muitas vezes não são cumpridos.... já trabalhei em mais de 10 equipas diferentes, onde a grande maioria era associada à mesma empresa, e posso dizer que apanhei 1 máximo 2 gestores/coordenadores/managers efetivamente bons. E apanhei muita malta daquela que mencionei antes (“Martins e Marias” com “licenciaturas tiradas na Católica”).

Acho que das m*rda mais gratificantes que um colaborador pode sentir no sítio onde trabalha é que a sua voz é ouvida, e acho que nunca apanhei um Gestor onde efetivamente pedia a opinião dos seus colaboradores sobre o que podia ser feito para melhorar a gestão de trabalho/ambiente...

Editado 29 Março 2019 por HIM

[Ghelthon]

Citação de Solero, há 9 horas:

Claro que fazem, sem dúvida nenhuma. O meu comentário foi exagerado, como é óbvio, mas acho que se dá um peso excessivo a reuniões que param a equipa toda como sprint plannings e reviews e acaba-se por se perder aquilo que tanto se apregoa, que é agilizar. 

Eu até percebo o que queres dizer, mas sou absolutamente contra - um grande problema das empresas (não só em PT, como a seguir vou exemplificar) é achar que o SCRUM se pode fazer pela metade. Se queres seguir a framework, tens de fazer tudo como é descrito.

Por exemplo, é muito bonito dizer que tens SCRUM, mas depois tens o PM/BA a fazer estimativas. E depois acontecem coisas tipo estimarem uma estória em 20 horas, quando aquela m*rda se faz em 20 minutos (real, aconteceu-me esta semana). Sendo que também acontece o inverso. Isto é altamente contra o SCRUM, como saberás, porque quem faz as estimativas são os devs. Podem ter input de outras pessoas, mas a decisão é sempre dos devs. Só um exemplo de algo que acontece regularmente e que estraga logo o benefício do SCRUM.

Estamos a fazer um off-topic gigante, mas todas essas reuniões do SCRUM existem por uma razão e fazem todo o sentido. O problema é quando não se segue o SCRUM à risca, ou se usa as reuniões para outras coisas que não o que seria suposto.

Editado 29 Março 2019 por Ghelthon

[Solero]

Citação de Ghelthon, há 2 horas:

Eu até percebo o que queres dizer, mas sou absolutamente contra - um grande problema das empresas (não só em PT, como a seguir vou exemplificar) é achar que o SCRUM se pode fazer pela metade. Se queres seguir a framework, tens de fazer tudo como é descrito.

Por exemplo, é muito bonito dizer que tens SCRUM, mas depois tens o PM/BA a fazer estimativas. E depois acontecem coisas tipo estimarem uma estória em 20 horas, quando aquela m*rda se faz em 20 minutos (real, aconteceu-me esta semana). Sendo que também acontece o inverso. Isto é altamente contra o SCRUM, como saberás, porque quem faz as estimativas são os devs. Podem ter input de outras pessoas, mas a decisão é sempre dos devs. Só um exemplo de algo que acontece regularmente e que estraga logo o benefício do SCRUM.

Estamos a fazer um off-topic gigante, mas todas essas reuniões do SCRUM existem por uma razão e fazem todo o sentido. O problema é quando não se segue o SCRUM à risca, ou se usa as reuniões para outras coisas que não o que seria suposto.

Nisso concordo, se não forem os devs a fazer as estimativas, deixa de fazer sentido. Os PM devem definir as tarefas e assigná-las à equipa de desenvolvimento, mais que isso já será desvirtuar o SCRUM. 

Por aqui também acontece algo semelhante, por vezes. Há um número de horas definido para assignar a tarefas em cada sprint a cada dev (80% das horas, penso), sendo que a sprint costuma ser de 15 dias. No entanto, na minha equipa estamos dependente de outra equipa e por vezes é difícil manter um sincronismo entre o que são os objetivos de uma e de outra. Isto acaba por fazer com que a equipa que esteja mais adiantada acabe por estimar mais horas do que as que precisava para terminar certas tarefas, tal como descreveste, de maneira a não comprometer os objetivos da sprint. Já cheguei a dar 8h para algo que fiz em 1h, por exemplo. 

Outra coisa que por vezes acontece é a falta de foco. Malta (BAs e PMs) que está em 2/3 projetos e acaba por não se conseguir focar em nenhum deles. Conclusão: vão passar metade da sprint em reuniões, vão aparecer novos requisitos que vão atrasar a entrega, o backlog vai crescer e termina-se a sprint e ficou tudo "quase" feito mas não se entregou nada. Como disse, acredito no SCRUM puro e duro em equipas focadas e competentes, mas o que vou vendo é que não é uma tarefa nada fácil. Bem aplicado, é ótimo para todos. 

[Bashir]

Aqui a estimativa é dev only, no dia que não for, vai continuar a ser feito no tempo que o dev achar 😂 Até para as dailies tenho pouca paciência. 

[Ghelthon]

Citação de Solero, há 2 horas:

Nisso concordo, se não forem os devs a fazer as estimativas, deixa de fazer sentido. Os PM devem definir as tarefas e assigná-las à equipa de desenvolvimento, mais que isso já será desvirtuar o SCRUM. 

Por aqui também acontece algo semelhante, por vezes. Há um número de horas definido para assignar a tarefas em cada sprint a cada dev (80% das horas, penso), sendo que a sprint costuma ser de 15 dias. No entanto, na minha equipa estamos dependente de outra equipa e por vezes é difícil manter um sincronismo entre o que são os objetivos de uma e de outra. Isto acaba por fazer com que a equipa que esteja mais adiantada acabe por estimar mais horas do que as que precisava para terminar certas tarefas, tal como descreveste, de maneira a não comprometer os objetivos da sprint. Já cheguei a dar 8h para algo que fiz em 1h, por exemplo. 

Outra coisa que por vezes acontece é a falta de foco. Malta (BAs e PMs) que está em 2/3 projetos e acaba por não se conseguir focar em nenhum deles. Conclusão: vão passar metade da sprint em reuniões, vão aparecer novos requisitos que vão atrasar a entrega, o backlog vai crescer e termina-se a sprint e ficou tudo "quase" feito mas não se entregou nada. Como disse, acredito no SCRUM puro e duro em equipas focadas e competentes, mas o que vou vendo é que não é uma tarefa nada fácil. Bem aplicado, é ótimo para todos. 

100% de acordo, então a cena da falta de foco no último parágrafo é quase diária.

Mas sim, lá está: o SCRUM funciona na teoria, porque na prática quase nenhum projecto aplica a framework como deve ser. Mesmo assim acho que prefiro assim vs alternativas.

Citação de Bashir, há 1 hora:

Aqui a estimativa é dev only, no dia que não for, vai continuar a ser feito no tempo que o dev achar 😂 Até para as dailies tenho pouca paciência. 

Na prática os devs são quem importa, porque podes ter outra pessoa qualquer a estimar por defeito que isso, só por si, não vai fazer com que o trabalho vá magicamente demorar menos tempo. Pode é criar quebras de confiança e expectativas mal geridas da parte do cliente, mas isso já não é responsabilidade dos devs.

[Ego Sum]

Citação de Thierry Henry, Em 26/03/2019 at 09:20:

Como expliquei, anda a vender-se trabalhos com o objetivo de dobrar as vendas enquanto se vai ficando sem staff.

Acho que ajudei a piorar essa situação esta semana :mrgreen:

[HappyKing]

https://dms.licdn.com/playback/C5605AQEP2jUji7OzRQ/891157de723e48aea993a64076871e70/feedshare-mp4_3300-captions-thumbnails/1507940147251-drlcss?e=1553983200&v=beta&t=BpAc8oiiymhpOPr0iLaeoS11aACcpWuTx6KdKNSL3yc

Em relação ao que falavam há uns posts atrás.

(Não dá para colocar embebido infelizmente).

Editado 29 Março 2019 por HappyKing

[UnReal]

mudámos de partners para devs, dailies, sprints e frameworks

so internationaleiro

[Bashir]

Vais ver quanto tempo fico no desemprego só por ter isso no cv.

 

(É assim que se faz?)

[lastdance]

Citação de Solero, Em 28/03/2019 at 23:03:

Claro que fazem, sem dúvida nenhuma. O meu comentário foi exagerado, como é óbvio, mas acho que se dá um peso excessivo a reuniões que param a equipa toda como sprint plannings e reviews e acaba-se por se perder aquilo que tanto se apregoa, que é agilizar. 

Completamente de acordo. Demasiadas cerimónias.

DSM, ainda papo, agora ter dsm, review, retrospectiva, planeamento e refinement, todas a ocupar o tempo dos devs, as coisas vão levar o dobro do tempo a fazer.

Editado 30 Março 2019 por lastdance

[doom_master]

Ainda ontem estive com um amigo que disse que já estava há 2 dias inteiros num sprint planning. E, segundo ele, nem estavam a ir muito ao detalhe nas tarefas a realizar, apenas eram muitas. Fiquei parvo.

Editado 31 Março 2019 por doom_master

[Erwin]

Citação de doom_master, há 12 horas:

Ainda ontem estive com um amigo que disse que já estava há 2 dias inteiros num sprint planning. E, segundo ele, nem estavam a ir muito ao detalhe nas tarefas a realizar, apenas eram muitas. Fiquei parvo.

Isto é completamente parvo. Perde-se, no máximo, 1h. E já estou a exagerar.

[Ghelthon]

Citação de doom_master, há 14 horas:

Ainda ontem estive com um amigo que disse que já estava há 2 dias inteiros num sprint planning. E, segundo ele, nem estavam a ir muito ao detalhe nas tarefas a realizar, apenas eram muitas. Fiquei parvo.

Lol wtf. A não ser que o sprint seja gigante, isso é só parvo - claramente têm demasiadas estórias para o sprint.

Além disso, o que o SCRUM diz é que o sprint planning dura no máximo 8 horas para um sprint de um mês. Ou seja, para o mais comum, que são sprints de 2 horas, só deve durar 4.

[doom_master]

Citação de Ghelthon, há 1 hora:

Lol wtf. A não ser que o sprint seja gigante, isso é só parvo - claramente têm demasiadas estórias para o sprint.

Além disso, o que o SCRUM diz é que o sprint planning dura no máximo 8 horas para um sprint de um mês. Ou seja, para o mais comum, que são sprints de 2 horas, só deve durar 4.

Exacto. Pelo que entendi, tinham muita coisa mesmo para planear, porque o projecto é muito grande. Não faz sentido.

[Solero]

Sprints de 1 mês não fazem qualquer sentido, imo.

[Ghelthon]

Tudo depende, mas sim, 2 semanas é o clássico, e faz sentido.

[Kratosthegod]

Aqui sprints de 4 semanas é o standard.

[Erwin]

Citação de Ghelthon, há 6 horas:

Lol wtf. A não ser que o sprint seja gigante, isso é só parvo - claramente têm demasiadas estórias para o sprint.

Além disso, o que o SCRUM diz é que o sprint planning dura no máximo 8 horas para um sprint de um mês. Ou seja, para o mais comum, que são sprints de 2 horas, só deve durar 4.

4 horas de planning? Convém que saias de lá com um guião de tudo o que tens para fazer, outra pessoa com os testes já criados e etc.
Isso é meio-dia, é imenso.

Citação de doom_master, há 5 horas:

Exacto. Pelo que entendi, tinham muita coisa mesmo para planear, porque o projecto é muito grande. Não faz sentido.

Isso não é sprint planning, é project planning.

[Ghelthon]

Citação de Erwin, há 5 minutos:

4 horas de planning? Convém que saias de lá com um guião de tudo o que tens para fazer, outra pessoa com os testes já criados e etc.
Isso é meio-dia, é imenso.

O SCRUM diz que são 8 horas para um sprint de um mês, portanto 4 para um de 2 semanas. Isto são os timings máximos, não é preciso durar isso tudo. Mas durar 2 dias, como o doom falou, nossa senhora...

[Bashir]

Dificilmente gasto 1 hora para o sprint (semanas). E quando estica é pq se fala de outras coisas

[Solero]

O mais comum é as sprint plannings/retrospectives/reviews demorarem porque o pessoal começa a discutir soluções e detalhes funcionais ou técnicos que fogem por completo ao âmbito. Se não se começar a divagar, as coisas fazem-se rápido.

[doom_master]

Citação de Erwin, há 9 horas:

4 horas de planning? Convém que saias de lá com um guião de tudo o que tens para fazer, outra pessoa com os testes já criados e etc.
Isso é meio-dia, é imenso.

Isso não é sprint planning, é project planning.

Ele é que disse que era sprint.

[Ghelthon]

Citação de Solero, há 9 horas:

O mais comum é as sprint plannings/retrospectives/reviews demorarem porque o pessoal começa a discutir soluções e detalhes funcionais ou técnicos que fogem por completo ao âmbito. Se não se começar a divagar, as coisas fazem-se rápido.

Lá está, aí o problema é das pessoas, não da framework. 😁