Comments on: Times Scrum trabalhando em vários projetos ao mesmo tempo?

By: Paulo Barros

Paulo Barros — Fri, 20 Aug 2010 19:52:04 +0000

Esse post funciona como o “Lampadinha” para o Prof. pardal !!! Esse é um grande dilema, principalmente pra quem vai começar a trabalhar com SCRUM. Existe uma variação desse cenário que quando o ROI não é tão bem definido. Trabalho em uma empresa em que a atividade fim não é TI, porém (por questões que não vem ao caso) ela possuí time de desenvolvimento próprio. Ou seja, existem projetos internos e “todos são urgentes”. Fica mais difícil negociar com o cliente (interno) e por sua vez eleger o projeto mais importante…..

By: Scrum (recomendações de leitura) « Desenvolvimento de Software

Scrum (recomendações de leitura) « Desenvolvimento de Software — Tue, 15 Sep 2009 10:40:11 +0000

[...] Times Scrum trabalhando em vários projetos ao mesmo tempo? http://gc.blog.br/2008/07/29/times-scrum-trabalhando-em-varios-projetos-ao-mesmo-tempo/ [...]

By: Dimas Kotvan

Dimas Kotvan — Sun, 03 Aug 2008 05:10:13 +0000

Cara, muito legal a forma como você mostrou o problema do ROI. Acho que ainda terei a oportunidade de usá-lo em uma apresentação para a alta gerência
O que minha experiência, ainda é pouca eu confesso, com Scrum me diz é que vai acontecer o seguinte:
1. Por terem de ser feitos ao mesmo tempo, normalmente os projetos tem a mesma prioridade, então as estórias de cada projeto vão ficar intercaladas.
2. Quase sempre o time que está nessa situação é grande, +/- 8 pessoas, então fica dificil todos atuarem ao mesmo tempo na mesma estória.
3. Isso encoraja a formação de grupos no time para atacar isoladamente cada projeto.
4. Como gasta-se tempo para conversar com os usuários sobre cada estória e passar as informações, membros de um “grupo” se sentem menos comprometidos com as sessões de design do outro “grupo”,
afinal não é do “projeto” deles. Mesmo o daily scrum é afetado pois o integrante que está falando está falando sobre “outro projeto”.
Sei que esse é um caso estremo, mas já tive um pouco dessa experiência, e achei bem desgastante e desanimador para o time.

Abraços

By: Guilherme Chapiewski

Guilherme Chapiewski — Fri, 01 Aug 2008 03:09:26 +0000

@Juan, excelente link!

By: Juan Carlos Castro

Juan Carlos Castro — Thu, 31 Jul 2008 23:41:35 +0000

Ahá! Outro fã do Joel: http://www.joelonsoftware.com/articles/fog0000000022.html

By: Guilherme Chapiewski

Guilherme Chapiewski — Thu, 31 Jul 2008 21:17:44 +0000

@Eduardo

A prova matemática funciona para projetos de qualquer duração e ROI. O que não tem é uma receita de bolo. Como vc mesmo falou, é preciso avaliar os ROIs e durações de cada projeto e escolher um para começar – e fazer a sua empresa e o seu cliente começarem a faturar antes

By: Felipe

Felipe — Thu, 31 Jul 2008 14:42:37 +0000

Concordo plenamente.
Aliás, essa é uma discussão interessante que aconteceu na lista da visão ágil. Vale a pena conferir. http://www.visaoagil.com

By: Eduardo

Eduardo — Wed, 30 Jul 2008 19:47:15 +0000

Guilherme, se os projetos tiverem durações diferentes quando feitos em série, tem-se que saber qual terá o menor prazo para começar por ele.
E estimar prazo não é algo trivial.

Essa sua “prova matemática” só é válida para projetos com a mesma duração e que dêem o mesmo ROI, o que é praticamente impossivel de se encontrar na vida real, ou seja, devemos sempre avaliar o Roi e o prazo de cada projeto (coisas dificeis de se fazer) para decidirmos qual fazer primeiro.

abraços,
–EC

By: Return Of Investment « Ricardo Almeida - Manifesto na Web!

Return Of Investment « Ricardo Almeida - Manifesto na Web! — Wed, 30 Jul 2008 19:24:56 +0000

[...] Times Scrum trabalhando em vários projetos ao mesmo tempo? (Scrum na Globo.com) [...]

By: Guilherme Chapiewski

Guilherme Chapiewski — Wed, 30 Jul 2008 18:51:24 +0000

@Rodrigo, pode dar um exemplo, por favor?

O meu post é justamente argumentando (com provas matemáticas) de que trabalhar de forma serial é bom para os negócios, ao contrário do que se imagina. Nem toquei na questão de se é bom ou não tecnicamente.

[ ]s, gc

By: Rodrigo Veiga

Rodrigo Veiga — Wed, 30 Jul 2008 15:46:54 +0000

Do ponto de vista técnico, sem dúvida é melhor trabalhar em um projeto só. Do ponto de vista de negócio, já nem sempre podemos dizer isso. Isso vai depender do contexto em que estamos considerando. Já participei de experiências em que foi super válido trabalharmos exclusivamente em um projeto, porém, também já participei de momentos em que mais de um projeto foi fundamental para garantir o sucesso um pouco mais na frente. Algumas vezes o retorno não vem diretamente e isso tem que ser ponderado. Esse tipo de problema existe não só na área de tecnologia, mas em qualquer outra, sendo empírica ou não.

By: Domingos Neto

Domingos Neto — Tue, 29 Jul 2008 19:31:51 +0000

Às vezes certas coisas que são óbvias demais passam despercebidas. Esse seu exemplo é uma delas. É tão óbvio que muitas vezes não nos damos conta disso e trabalhamos em vários projetos simultaneamente.

Vou repassar esse post!

By: Guilherme Chapiewski

Guilherme Chapiewski — Tue, 29 Jul 2008 18:28:21 +0000

@Vitor Isso aí

By: Vitor Pellegrino

Vitor Pellegrino — Tue, 29 Jul 2008 17:28:45 +0000

Gc,
Um raciocínio análogo poderia ser aplicado às histórias de um projeto, certo?

Um time trabalhando em 3 histórias ao mesmo tempo demoraria um tempo maior para ter algum feedback do cliente (ou do P.O) e ainda correria um risco de deixar de entregar valor (por falta de tempo em um sprint) do que aconteceria caso tivessem trabalhado em uma história de cada vez.

Grande abraço!

By: Guilherme Chapiewski

Guilherme Chapiewski — Tue, 29 Jul 2008 16:49:20 +0000

@Rafael

Dependendo do que fosse acho que não teria problema. Na maioria das vezes os bugs são coisas muito simples e que podem ser assumidas sem muitos problemas, porque nos times ágeis normalmente trabalha-se com várias camadas de teste, revisão antes do projeto ir para produção e etc.

Se forem bugs graves pode ser necessário fazer mais um Sprint, porém, neste caso isso seria o menor dos problemas. Se o projeto chegou nesse ponto significa que o time simplesmente não quer saber de qualidade, o que pra mim é inaceitável e muito mais difícil de resolver.

Enfim, acho difícil criar uma regra que atenda a todos os casos. O melhor mesmo é avaliar cada situação.

[ ]s, gc