Vou tentar expor meu dilema e pedir ajuda para os GURUs…
Trabalho em uma empresa que tem um produto que pode ser customizado. PONTO.
Temos N cliente e N projetos simultâneos. Ou seja, por exemplo, hoje, o Bradesco pede uma customização, amanhã a Coca-Cola fecha um projeto novo, etc.
Detalhe, em customizações os clientes não compram horas abertas… Falam por exemplo, preciso de uma tela assim, quanto é pra fazer… PONTO…
Precisamos nos munir com o mínimo de documentação para fechar o escopo para o cliente, para que caso ele altere o escopo, pague a diferença do retrabalho ou do que ele quer a mais…
Tenho 1 unica equipe de 12+ desenvolvedores, na qual eu gerencio, meio que usando o meu método… Não é scrum, mas gostaria de usar… Tenho uma forte queda por usá-lo…
Na minha estrutura temos os Gerentes de Projeto, que atuam com o cliente final (Bradesco por exemplo), fazendo o levantamento, prazos, cronogramas, etc…
Ao meu ver esse meu GP seria meu PO… OK?..
Mas tenho 7 GPs… e cada um toca N projetos , de clientes diferentes, ou seja tenho 7 POs.
Eu como “Scrum Master” organizo tudo que precisa ser desenvolvido desses X projetos para a Equipe de 12+ desenvolvedores.
O PO (GP) priorizou as coisas deles no prazo que foi acordado com o cliente, eu junto todas as priorizações dos POs(GPs) e coloco na lista de tarefas a fazer, meio que KANBAN…
Vai liberando vou passando a próxima, logico que eu vou ponderando uma atividade que é mais simples para 1 junior, por complexidade, para um Pleno/Senior que termina antes e gasta menos tempo fazendo, etc…
Meu Planejamento (Sprint) não é imutável como deveria ser no Scrum, pois em alguns momentos o cliente pega a funcionalidade para homologar 2 semanas depois que liberamos para ele e ele descobre que esqueceu de um requisito e pede uma melhoria, a empresa abre as pernas(nao cobra, ou até cobra, mas prioriza) e o cliente precisa para daqui a 4 dias a alteração para poder subir em produção na segunda… Então, entra coisa nova no meio do caminho, que tenho que priorizar… (Detalhe, isso eu não vou conseguir mudar… É um valor da empresa… Agilidade no atendimento ao cliente)…
Eu conseguiria usar SCRUM para esse meu caso?
Alguém com alguma experiência que possa compartilhar…?
A questão é, porque você quer usar Scrum ? Qual é exatamente o problema que você espera resolver com Scrum ? Por que Scrum ? Por que todo mundo tá falando que é legal ?
Cara, o que eu estou buscando é mudar a forma com que minha equipe trabalha hoje… Cada um trabalha sem se comprometer com o time, com a empresa, com as tarefas como um todo…
Eu tenho um grupo, não tenho um time.
A Metodologia agil ajuda na questão da equipe estimar e ajudar e se comprometer com o que foi definido e planejado para o Sprint…
Alguns estão em uma zona de conforto e isso está gerando um problema para o gerenciamento.
Muitos tem preguiça de ajudar os mais novos, pois cada 1 precisa entregar suas coisas sem se preocupar com as coisas do outro…
Cara, o que eu estou buscando é mudar a forma com que minha equipe trabalha hoje… Cada um trabalha sem se comprometer com o time, com a empresa, com as tarefas como um todo…
Eu tenho um grupo, não tenho um time.
A Metodologia agil ajuda na questão da equipe estimar e ajudar e se comprometer com o que foi definido e planejado para o Sprint…
Alguns estão em uma zona de conforto e isso está gerando um problema para o gerenciamento.
Muitos tem preguiça de ajudar os mais novos, pois cada 1 precisa entregar suas coisas sem se preocupar com as coisas do outro…
[/quote]
O problema talvez seja mais da empresa estar sobrecarregando as pessoas, não tendo tempo para enxergar os outros em volta, deixar conversar com liberdade, etc, tempo para isso é importante. Sobre as 12 pessoas, a primeira coisa seria dividir a equipe em times pequenos de 4 pessoas por exemplo, para atuarem em um mesmo módulo ou cliente, assim aumenta a intimidade, transparência e comprometimento, pois todos estão bem juntos pegando tarefas de um mesmo objetivo, não tem “o cara” que é responsável por tal coisa e não depende de ninguém. Depois disso avalie também se é necessário mais pessoal para formar mais times afim atender de forma confortável as demandas. Então a primeira coisa é adequar a cultura da empresa ou setor.
Vamos lá… Respondendo sua pergunta, sim, você pode introduzir o scrum. Desculpe perguntar mas vocês trabalham com quais linguagens e quais tecnologias?
É o seguinte, isso que você busca de comprometimento e dedicação ao time é uma via de mão dupla.
Vou tentar explicar, as pessoas só se comprometem com as empresas que se comprometem com elas… Hoje em dia o salário não é suficiente, muitas pessoas deixam de ganhar mais para trabalhar melhor (eu mesmo conheço um monte)…
Então, pra falar a verdade, a primeira coisa que precisa mudar seria a mentalidade dos funcionários e, principalmente, do dono da empresa (acredito que seja você, então fica mais fácil).
Veja bem o que quero dizer, porque eu ficaria querendo entregar uma tarefa no prazo ou antes dele se assim que eu acabar minha tarefa eu terei outra, ou melhor, faço hora extra 3 dias da semana para conseguir entregar uma tarefa na quinta, e folgar a sexta, mas aí meu gerente não aceita… Quer dizer, as horas extras podem ser feitas, minha folga não??? To dando exemplos trivias, ok???
trabalhei numa empresa que tentamos implementar o scrum, a primeira pergunta do dono foi: -Se a sprint acabar antes do tempo as pessoas vão ficar a toa?
Olha a preocupação dele. Não foi que vai entregar um projeto antes, ou que o cliente ficaria satisfeito e recompensaria a equipe, foi que os funcionários ficariam parados, ou seja, ninguém se comprometia…
Olha só, trabalho a 2 anos com Scrum, se quiser manda mensagem privada que conversamos.
Todo o desenvolvimento aqui é java, com ajax, struts1, maven(nexus), svn e tenho as ferramentas da atlassian (JIRA, BAMBOO, FISHEYE) + Sonar.
Bem que gostaria de ser o dono… mas não é o caso infelizmente. Sou Gerente de Desenvolvimento atualmente. Fui Desenvolvedor (ainda sou um pouco). Trabalho aqui a 8 anos.
Vou mandar sim, preciso de ajuda para acertar os ponteiros aqui…
Valeu.
Concordo gomesrod…
Isso com certeza vai ser util para alguém…
Diogo…
No meu caso… Meu gp seria o Product Owner. Certo?
Outra…
Geralmente eu preciso estimar as horas das funcionalidades para que o GP (PO) possa montar o cronograma para meu cliente. Eu geralmente hoje dou um chute… Levando em consideração a situação da minha equipe hoje, onde varios deles não se empenham totalmente para fazer no menor prazo possível… Ou seja trabalham com o pé no freio.
Acredito que com as atividades inerentes ao scrum, ou seja, planejamento do sprint. Reunioes, etc. Vou acabar aproximando a equipe e fazendo com que eles se comprometam entre si…
Obs. A empresa que trabalho é muito familiar apesar de relativamente grande… 150 funcionários…
Meu turnover na equipe é bem baixo…
A ultima pessoa que saiu da equipe por vontade propria foi a 3 anos…
Somos velhor de casa… E sabemos bem o negocio…
Qual seu ponto de vista a respeito dessa minha ideia…?
Estou no caminho certo?
Posso pedir o investimento da empresa para um treinamento de scrum para pegar uma bagagem externa…
Pensei na adaptworks…
[quote=hwneto]Concordo gomesrod…
Isso com certeza vai ser util para alguém…
Diogo…
No meu caso… Meu gp seria o Product Owner. Certo?[/quote]
Depende. Você disse que possui clientes e que eles são terceiros, então provavelmente eles serão o Product Owner, os seus gerentes seriam os Scrum Masters, visto que eles que intermediariam as negociações da equipe de desenvolvimento e os clientes.
Por exemplo, quais e quantas tarefas serão desenvolvidas naquela sprint? Isso é definida com a equipe e passada para aceitação ou não do cliente pelo scrum master.
[quote=hwneto]
Outra…
Geralmente eu preciso estimar as horas das funcionalidades para que o GP (PO) possa montar o cronograma para meu cliente. Eu geralmente hoje dou um chute… Levando em consideração a situação da minha equipe hoje, onde varios deles não se empenham totalmente para fazer no menor prazo possível… Ou seja trabalham com o pé no freio.
Acredito que com as atividades inerentes ao scrum, ou seja, planejamento do sprint. Reunioes, etc. Vou acabar aproximando a equipe e fazendo com que eles se comprometam entre si…
Qual seu ponto de vista a respeito dessa minha ideia…?
Estou no caminho certo?
Posso pedir o investimento da empresa para um treinamento de scrum para pegar uma bagagem externa…
Pensei na adaptworks…
Valeu…[/quote]
Você poderá estimar seu preço por sprints como fazíamos, porque será negociado as tarefas, por exemplo o cliente pede uma funcionalidade nova e você e sua equipe dizem que faz tais tarefas numa primeira sprint, tais em uma segunda e aí por diante… só você estimar o custo de cada sprint sua.
Quanto ao curso acho que sempre vale a pena, porém, como disse anteriormente, o que precisa mudar é a mentalidade de todos antes de qualquer coisa… Todos precisam sair ganhando para que valha a pena…
O que eu gostaria de fazer é eu ser o scrum master…
Caso contrario eu teria no minimo 7 SMs.
A ideia era nao mudar o processo que temos hoje entre o GP e o nosso cliente final…
Pois se for fazer isso ai sim seria quase impossivel mudar essa galera toda… Todos PMOs…
A ideia era tratá-los como POs pois hoje na verdade nem eu nem o time falamos com o cliente… Os GPs representam o Cliente dentro da empresa hoje…
Eles fazem um cronograma para passar uma data para o cliente final, mas na pratica eu posso mudar as ordens do desenv. Contanto que o prazo final nao seja ultrapassado…
O meu GP ja priorizou o desenvolvimento no cronograma…
Eu e o time precisaríamos organizar isso nos sprints e reportar aos POs (GPs).
O que acha… Existe uma chamce de sucesso dessa forma?
Eu acho que você não tá entendendo o papel de um e de outro…
O Scrum Master tem como um dos papeis facilitar o trabalho dos desenvolvedores, remover impedimentos e está em contato com o cliente.
O Product Owner é o dono do produto, quem vai ficar ou não satisfeito com as entregas.
Você pode fazer do jeito que quer, porém o seu product owner tem que ser o dono do produto, por exemplo, seus gerentes poderão resolver sobre o produto??? se houver algum impedimento eles poderão resolver abortar ou excluir tarefas da sprint? eles podem resolver se o produto está ok ou não?
Se eles tiverem esta autonomia então podem ser os products owners…
[quote=diogogama]Eu acho que você não tá entendendo o papel de um e de outro…
O Scrum Master tem como um dos papeis facilitar o trabalho dos desenvolvedores, remover impedimentos e está em contato com o cliente.
O Product Owner é o dono do produto, quem vai ficar ou não satisfeito com as entregas.
Você pode fazer do jeito que quer, porém o seu product owner tem que ser o dono do produto, por exemplo, seus gerentes poderão resolver sobre o produto??? se houver algum impedimento eles poderão resolver abortar ou excluir tarefas da sprint? eles podem resolver se o produto está ok ou não?
Se eles tiverem esta autonomia então podem ser os products owners…[/quote]
Exatamente… Eles tem essa autonomia…
Dificilmente tem impedimentos pois como tinha dito no inicio nossos requisitos nao sao storys apenas… Sao documentação com detalhamento que foi colhida pelo GP e pela equipe de Analise de Requisitos…
E assinadas pelo Cliente…
Se tivermos alguma duvida o GP sabe tudo que foi levantado e caso ele precisa ele consulta o cliente de forma bem rapida…
Por isso tenho eles hoje com representante do produto que o cliente espera… Ele sabe tudo que o cliente realmente precisa…
Sim nosso GP não é um simples GP…
A proposito…
Essa metolologia de trabalho com os clientes é nossa… Os GPs certificados PMI que chegam relutam bastante, mas se adaptam…
oi, hwneto, interessante o seu “problema”, vou dar meus palpites aqui tambem.
Antes de mais nada, voce deve ter atenção no seguinte fato (provavelmente você tem, mas não custa registrar):
Se voce tem N clientes, 12 desenvolvedores e trabalha numa empresa com 150 funcionários podemos assumir que as coisas, de um modo ou de outro estão funcionando. Exceto se estiver tudo indo pro buraco, o que não parece ser o caso, avaliando pela tranquilidade dos seus posts. Certo, seus processos podem ser melhorados, os resultados da sua equipe podem melhorar, mas a primeira coisa a que você deve se atentar é de que as coisas estão funcionando. E aqui é que se deve tomar cuidado. Sabemos que temos coisas erradas, sabemos que temos muito a melhorar e também sabemos que temos coisas certas e que funcionam.
Por mais que possa parecer simples, distingui-las umas das outras pode ser bem complicado e você pode acabar estragando o que está funcionando ao tentar consertar o que você julga não estar.
Então a primeira dica é, vai com calma, não faça alterações revolucionárias. Se você gostou do Scrum e acha que ele pode te ajudar, va em frente, mas teste uma prática aqui e outra li e veja se funciona. Meça, tente entender porque funcionou e porque não. E antes de mais nada certifique-se de que você entendeu a metodologia que está querendo aplicar e os porquês das suas práticas.
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.
Ok, não conheço sua realidade e nem a fome voraz de seus clientes em querer arrancar mais dois dedinhos de funcionalidade sempre que podem. Mas já vivi situações parecidas, onde qualquer alteração tinha que ser assinada por meio mundo e qualquer A que saísse do que estava no papel tinha que ser cobrado a parte. E sem querer te desanimar, essa realidade de pedir alterações, de requisitos mal levantados, coisas mal entendidas pelos desenvolvedores não vai mudar. Ainda não inventaram um processo que solucione isso e provavelmente ainda estão longe de inventar.
O que fazer então? Sentar e chorar abraçado ao prejuízo? Tem muita gente que faz isso, tem gente que divide o prejuízo com o cliente, mas nenhuma dessas soluções é a ideal.
Talvez a pergunta que você queira fazer não seja: como eu faço pra diminuir as alterações que os clientes pedem quando o desenvolvimento já foi iniciado. Nem seja, o que eu devo fazer para cobrar do cliente o prejuízo que ele me causa pedindo pra alterar funcionalidades depois do desenvolvimento iniciado?
Talvez a pergunta certa seja, como eu posso reduzir o custo das mudanças que os clientes fazem nos requisitos depois do desenvolvimento iniciado?
A partir daqui e só a partir daqui o Scrum começa a fazer sentido para o seu cenário.
Embora o Scrum não tenha um número fixo de membros no time, 12 com certeza é muito. Provavelmente você deveria dividir. Só lembre de ao dividir procurar deixar os times menores “crossfuncionais”, não divida por exemplo em time de arquitetos, time de juniores, testers e dbas. As equipes devem conter por elas mesmas todas as habilidades pra fazer o projeto andar.
No Scrum quem organiza é o Product Owner, no caso prioriza.
Mais um sinal de que você deveria dividir, idealmente em uma equipe para cada GP. Se for demais, você pode fazer com que alguns GPs dividam a mesma equipe e deixe que eles se organizem, você só interviria quando houvesse conflito de interesse entre eles.
Se a demanda de um cliente não é tão grande para valer uma equipe toda dedicada a ele, talvez também não seja para um GP exclusivo para ele. Mas aí vai da sua realidade e de como são feitos os contratos e contatos com seus clientes.
Isso aqui tambem vai contra o Scrum, quem decide quem faz o que e porque é o próprio time. Com equipes menores isso é bem mais fácil de dar certo.
Nem deve mudar, o que você tem que fazer é diminuir o tempo de feedback. Quanto antes ele perceber que tem que mudar melhor, menos tempo foi gasto indo pro caminho errado. Outra coisa que deu pra perceber nesse parágrafo é um indicativo de falha na priorização das demandas. Repare que se o cliente leva duas semanas pra homologar algo e só depois perceber que está errado, essa provavelmente não era a maior prioridade dele. Se não era prioridade talvez não devesse ser feita agora.
Eventualmente acontece de surgir uma demanda urgente no lugar de outra, mas se isso acontece sempre, tem algo errado na priorização. Repare, que mudança no requisito é normal e bem vindo porque as coisas não ficam claras no começo do desenvolvimento. Agora mudança de prioridade de requisito é bem menos frequente. Se essa frequência é grande tente achar o motivo.
Parece que sim, pelo menos ser mais ágil você pode com certeza. Mas só você pode avaliar sua realidade, não se prenda às práticas, procure entender o princípio por trás dela. Se uma sprint de duas semanas é muito pra você, tente algo menor. Não é porque se diz que duas semanas é o ideal na maioria dos casos que tem que ser pra você.
Primeiramente muito positivo seu post…
Me fez pensar bastante…
Com certeza funcionam… As vezes fico maluco, mas funcionam sim…
Acontece casos de o cliente mudar o escopo, pedir para alterar alguma coisa antes ou até durante o desenv, e desde que elas não sejam tão grandes permitimos alterar sim… Temos que permitir…
Existe o caso do GP ruim… que não analisa e levanta direito os requisitos, daí falta coisa, e temos que nos adaptar… (O erro foi da empresa e temos que resolver)
Exatamente isso… Pra mim pouco importa se ele vai pagar ou não… Eu aponto o quanto isso aumenta no escopo inicial e o comercial se vira com os pagamentos…
Preciso diminuir os impactos que isso gera e fazer essas alterações rapidamente para encerrar o assunto o mais rápido possível e liberar o projeto para que eu possa iniciar o outro que já está na Fila…
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…
Isso ta embassado pra mim…
Os GPs da empresa não se conversam, eu que faço o controle de tudo que tem que ser desenvolvido.
Nesse caso, se eu sou o PO os meus GPs seriam meus clientes?
Mas um PO não deveria ser o cliente? Ele pode representar um cliente?
Melhor, ele pode ter vários clientes…?
No meu caso como você sugeriria a separação dos papeis…
Hoje eu coordeno todo o desenvolvimento e sou Lider Técnico…
É complexo, mas qualquer proposta precisa ter um GP envolvido, independente se for levar 40 horas para desenvolver…
Mas quanto a separação posso pensar em algo…
Caso o trabalho do time A acabar ele pode assumir coisas e ajudar o time B ou isso não é aconselhável…?
É exatamente isso que eu quero… O time tem que decidir isso… Isso tenho que mudar de qualquer jeito…
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.
2 - [quote=YvGa]Ok, não conheço sua realidade e nem a fome voraz de seus clientes em querer arrancar mais dois dedinhos de funcionalidade sempre que podem. Mas já vivi situações parecidas, onde qualquer alteração tinha que ser assinada por meio mundo e qualquer A que saísse do que estava no papel tinha que ser cobrado a parte. E sem querer te desanimar, essa realidade de pedir alterações, de requisitos mal levantados, coisas mal entendidas pelos desenvolvedores não vai mudar. Ainda não inventaram um processo que solucione isso e provavelmente ainda estão longe de inventar. [/quote]
Concordo plenamente, mas vejo que o scrum é justamente, não para resolver isso, e sim para acender um farol no burndown, tipo, “olha estamos com um impedimento que o cliente pediu uma nova tarefa e temos que realizar, então se a sprint furar existe um motivo”, além de você começar a poder mensurar o quanto de custo isso gera para sua empresa.
Acho que a idéia é exatamente essa. Você começa a mensurar quanto e quem está gerando o prejuízo (seja o cliente, seja o gp) e falar com o cliente, “suas alterações me geram x de prejuízo, portanto, esse preço eu te faço se você não alterar as coisas, casso contrário preciso subir pra tanto.”
3 - [quote=YvGa]Embora o Scrum não tenha um número fixo de membros no time, 12 com certeza é muito. Provavelmente você deveria dividir. Só lembre de ao dividir procurar deixar os times menores “crossfuncionais”, não divida por exemplo em time de arquitetos, time de juniores, testers e dbas. As equipes devem conter por elas mesmas todas as habilidades pra fazer o projeto andar. [/quote]
Na verdade você tem que ver o que se adequa melhor, acho que 12, 20, 80 dev’s não importa, o que importa é o tempo que será gasto para isso… Por exemplo, você tem condições de fazer as daly’s de 5 minutinhos pra cada um com 80 dev’s? fica inviável e sem necessidade, pois a daly serva para integrar todos do time ao que aquele dev está fazendo, para, caso ele falte algum dia, outras pessoas possam saber em que pé estão as coisas.
Então concordo com o YvGa, equipes muito grandes atrapalham.
4 - [quote=YvGa]No Scrum quem organiza é o Product Owner, no caso prioriza.[/quote]
Isso eu discordo, PO prioriza sim, mas o SM serve para dar aquela consultoria, tipo, isso seria bom vir antes disso, fazer aquilo agora era melhor.
Além de que o SM é quem negocia com o PO quais tarefas irão entrar na sprint.
5 - [quote]Vai liberando vou passando a próxima, logico que eu vou ponderando uma atividade que é mais simples para 1 junior, por complexidade, para um Pleno/Senior que termina antes e gasta menos tempo fazendo, etc…
Foi exatamente isso que disse, a primeira coisa a se mudar é a mentalidade. O SM ou o PO não escolhe o que o desenvolvedor irá fazer, toda sprint é disponibilizada todas as tarefas que tem que ser feitas, e os dev’s escolhem qual será feita hoje, amanhã, etc… Lembrando que todos tem a responsabilidade de entregar a sprint no prazo, pois eles deram o prazo do que “daria tempo” para fazer.
4 - [quote=YvGa][quote]Meu Planejamento (Sprint) não é imutável como deveria ser no Scrum, pois em alguns momentos o cliente pega a funcionalidade para homologar 2 semanas depois que liberamos para ele e ele descobre que esqueceu de um requisito e pede uma melhoria, a empresa abre as pernas(nao cobra, ou até cobra, mas prioriza) e o cliente precisa para daqui a 4 dias a alteração para poder subir em produção na segunda… Então, entra coisa nova no meio do caminho, que tenho que priorizar… (Detalhe, isso eu não vou conseguir mudar… É um valor da empresa… Agilidade no atendimento ao cliente)… [/quote]Nem deve mudar, o que você tem que fazer é diminuir o tempo de feedback. Quanto antes ele perceber que tem que mudar melhor, menos tempo foi gasto indo pro caminho errado. Outra coisa que deu pra perceber nesse parágrafo é um indicativo de falha na priorização das demandas. Repare que se o cliente leva duas semanas pra homologar algo e só depois perceber que está errado, essa provavelmente não era a maior prioridade dele. Se não era prioridade talvez não devesse ser feita agora.
Eventualmente acontece de surgir uma demanda urgente no lugar de outra, mas se isso acontece sempre, tem algo errado na priorização. Repare, que mudança no requisito é normal e bem vindo porque as coisas não ficam claras no começo do desenvolvimento. Agora mudança de prioridade de requisito é bem menos frequente. Se essa frequência é grande tente achar o motivo. [/quote]
Então, o scrum não é imutável, apenas temos o tempo de feedback menor, aí você consegue tirar isso de uma sprint e passar para a outra, veja, você fez um projeto tudo certo e em 7 dias (1/2 sprint no caso) o cliente decide mudar ou acrescentar algo, você vai mensurar pra ele o impacto disso e dizer, isso ficaria um custo de x se você quiser agora, ou posso colocar pra ser feito em 1 semana e ficaria em um custo de x - valor de quebra de sprint. Fica mais fácil você trabalhar. (não sei se consegui ser claro neste ponto)
5 - [quote=YvGa]Parece que sim, pelo menos ser mais ágil você pode com certeza. Mas só você pode avaliar sua realidade, não se prenda às práticas, procure entender o princípio por trás dela. Se uma sprint de duas semanas é muito pra você, tente algo menor. Não é porque se diz que duas semanas é o ideal na maioria dos casos que tem que ser pra você. [/quote]
Isso eu concordo, nenhuma atividade é tão grande que não possa ser dividida em partes menores e possa ser resolvida em 15 dias. Se você tem uma atividade maior, divida em sub-atividades. 15 dias ficam mais fácil de planejar e evita erros maiores.
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…
PO é quem é o dono do produto final, ou seja, quem vai dar o aceite ou não, ou melhor, quem diz o que precisa e suas necessidades.
SM é quem representa o time, ele serve para tirar qualquer impedimento que exista, serve para representar o time diante do PO.
Imagine que o PO quer que desenvolva 3 crud’s nessa sprint e o SM sabe que sua equipe vai ser capaz de desenvolver apenas 2, então é ele que vai “defender” a equipe, dizendo que não será capaz pois é muita tarefa, ou falando que precisaria alocar mais gente e com isso o custo da sprint aumentaria.
Estou agora na fase de reflexão…
Aprendendo com cada comentário…
Mas de antemão ja adianto que consegui o apoio do meu diretor para seguir em frente…
Discutimos alguns pontos e decidimos em conjunto que independente de como e quando mas posso seguir com a reestruturação pois vai ser construtiva.
Chegamos ao mesmo veredito com relação a dividir a equipe e formar times menores…
Chegamos num ponto de discorde…
Eu entendi o ponto de vista dele… E quero falar aqui… Para opinarem…
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?
Outro ponto a favor dessa separacao seria a possibilidade de cada equipe poder começar os sprints em datas diferentes, ja que geralmente sao projetos diferentes…
Isso nos daria um poder de maior flexibilidade para incluir coisas nos sprints, coisas que caem do ceu…, afinal isso acontece muito aqui…, e em 1 semana ou menos teremos sprints iniciando em cada time…
O que acham disso?
Reúna os interessados a fazer um treinamento prático de Scrum e Kanban, nem que seja básico. Depois analisem o que for mais compatível, não precisa seguir a risca. A partir daí façam um piloto, com um time durante um bom tempo.
[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.
Discordo de novo, só o PO prioriza, o Scrum Master não se envolve em priorização, em tese ele desconhece completamente o negócio, cabendo somente ao cliente (PO) dizer o que é prioritário e o que não é, em que ordem as coisas são feitas e quando. Quando muito o time de desenvolvimento pode orientar ele nessas decisões com informações técnicas que ajudem na priorização. Por exemplo, quando há uma tarefa que envolve um alto risco técnico, algo novo, algo que não é de domínio completo do time, ele pode propor ao PO que essa funcionalidade seja feita antes, para que se diminua a incerteza em cima disso.
O Scrum Master priorizando nunca vi.
[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.
mas não é o caso infelizmente. Sou Gerente de Desenvolvimento atualmente. Fui Desenvolvedor (ainda sou um pouco). Trabalho aqui a 8 anos.