Olá gente, estamos tentando implantar a metodologia XP aqui no ambiente, local totalmente necessário e propício, apenas 2 desenvolvedores conhecem a metodologia e outros 3 não conhecem mas estão estudando e gostando, o problema é os 2 gerentes da equipe, não querem se aventurar em mudar nada.
Aqui é o típico local que “utiliza” RUP e no fundo é puramente “waterfall”, projeto sempre fora do prazo, tudo completamente em cascata, já mostramos a vantagem da metodologia, os benefícios para o cliente (o cliente às vezes está presente, mas sempre disponível).
O que vocês sugerem para seguirmos uma linha para que os gerentes tradicionais aqui (eles aqui querem seguir “engrenagem” de fábrica, tudo eles falam em engrenagem, PQP(desculpe gente), quando vão perceber que software não é carro??? não existe ***** de fábrica em software!!!)
Estamos aos poucos adotando práticas aqui entre nós desenvolvedores(as), mas algumas coisas não tem como sem o apoio gerencial.
Qual linha vocês recomendam seguir para tentar implantar o XP, mas os gerentes não apoiam de jeito nenhum??? Como convencer, ou o que fazer?
Olá
Proponha uma reunião, faça uma apresentação apontando as vantagens da metodologia, abra um espaço para perguntas e seja convincente.
Sem o apoio da gerência com certeza não vai rolar.
Eu, pessoalmente, prefiro a metodologia RUP, que é adotada aqui na empresa que eu trabalho. Na verdade temos um processo de desenvolvimento criado a partir do RUP mas devido a exigências de mercado (rapidez, agilidade, custo) alguns projetos estão sendo executados com metodologia ágil.
Não há conflito aqui e as coisas caminham relativamente bem.
Boa sorte. :!:
A primeira coisa a fazer é nao enfrentar os gerentes, a nao ser, obviamente, que voce tenha poder pra vencê-los.
A equipe pode por conta propria utilizar algumas partes da metodologia sem a interferencia dos gerentes, como testes unitarios, iteracoes (mesmo que nao haja ninguem pra mostrar ao final dela), controle de tarefas a parte do que ja existe, simulando o quadro, mesmo que faca em excel, para que ninguem venha perturbar.
A medida que voces forem implementando a metodologia, podem mostrar para os gerentes quais sao os ganhos, na pratica e nao na teoria.
Podem tambem expor as praticas do XP, sem mencionar o nome da metodologia, nem que estao usando outra metodologia, vao alterando o processo de forma gradual, colocando as praticas como se fossem ideias suas mesmo, evitando o choque da mudanca da pratica.
Ao final, se for bem aplicado, o processo vai mostrar seus ganhos e o gerente deixara de ser contrario.
Ha muitos gerentes que nao gostam de mudancas porque sao preguicosos e nao querem mexer em nada com medo de perder o controle, nesses casos sera complicado, e uma hora ou outra tera que passar por cima deles. Mas isso eh bem facil quando voce tem um historico documentado que prova que o que voce esta fazendo esta funcionando.
Ha outros gerentes que nao gostam de mudancas porque ja ouviram muitas promessas de metodologias e ferramentas milagrosas, mas na hora do vamos ver, nada funciona. Com esses sera mais facil porque ao verem que funciona, eles vao apoiar.
Faca as coisas com calma, primeiro vendo voce mesma se esta no caminho certo.
Nem de longe mencione o pair programming por enquanto, é uma tecnica que nao faz o menor sentido se for utilizada fora das metodologias ageis, e os gerentes nem aceitam argumentar com ela.
Geralmente o que convence esses gerentes retrógrados são exemplos de grandes empresas que usam metodologias ágeis.
Saiu uma reportagem interessante sobre Scrum na JavaMagazine 73. Nessa reportagem são mostrados alguns exemplos de gigantes que utilizam Scrum e outras metodologias ágeis. Recomendo a leitura, até mesmo pra ajudar na sua persuasão!
proponha um projeto piloto, algo pequeno com parte da equipe onde vc pode demonstrar que a coisa funciona na prática. depois vcs podem ir aumentando o tamnho e a importancia desses projetos, até conseguir implantar tudo. é uma mudança meio dura, mas se for de forma gradual, geralmetne os impactos são menores
Gostei dessa idéia de ir “comendo pelas beiradas”, aplicando as práticas aos poucos.
Dá até para ir além, e criar uma “fachada waterfall” para sua equipe. Ao se relacionar com a gerência fale como se estivessem seguindo à risca a metodologia do vovô, façam umas caras de quem está desanimado por causa de tanta burocracia e tal… eles vão ficar satisfeitos com isso! :lol:
Mas internamente vão botando ordem na casa e implantando as práticas tão desejadas por todos. Até para fazer as iterações tem jeito: não chame por esse nome, apenas diga que gostaria de pedir para o cliente “dar uma testadinha nessa tela”, para “não ter tanto trabalho depois, se tiver alguma coisa errada”. O cliente como maior interessado também não vai achar ruim.
Primeiro é preciso destinguir muito bem XP de Scrum.
XP são práticas de desenvolvimento de software. Scrum são práticas de gerenciamento de projeto.
A sua equipa pode desenvolver em XP sem a necessidade dos gerentes saberem disso ou interferirem com isso.
Coisas como um servidor de codigo (SVN , Mercurial,etc…) são práticas básicas de desenvolvimento modernas seja com xp ou sem.
A única prática que vc terá mais problemas é com pair programming. É aqui que vc precisa abandonar o XP “purista” ( que aliás hoje em dia não é mais defendido) e entender que “pair programing” é coisa de ocasião. Quando o colega fala “chega aqui e me ajuda” isso é pair programming.
O que a equipa tem que saber é que pode pedir esta ajuda. Quando a gerencia perguntar a equipa (não as pessoas, mas a equipa toda) deve responder que estão resolvendo uma questão tecnica X ou Y. ou seja, não chegue para o gerente dizendo que precisa juntar as mesas e trabalhar a dois porque eles são burros para entender que isso é mais eficiente que trablhar a 1. Mas isso não significa que vc não pode chegar junto do colegua e acompanhar com ele. Ou seja, pratique pair programing, mas não lhe chame pair programing na frente da gerencia.
Onde ha um maior conflito é com o modelo de estorias/backlog e a presença do cliente.
Primeiro que tudo ignore o cliente e concentre-se no dono do produto. O que é chamado “cliente” em XP, é na realidade o “Product Owner” do scrum. Ou seja, não é o cliente em si mesmo e sim a pessoa que responde por ele. Normalmente esta pessoa é o analista de requisitos ou o proprio gerente.
Faça o gerente entender que o mecanismos de estorias é para organizar o trabalho do dia a dia como se fosse uma lista de tarefas, so que melhor.
Nunca espere que o cliente real esteja presente , mas se tiver, aproveite para tirar duvidas.
Faça o gerente atuar como Product Owner.
Básicamente a estratégia é fazer os desenvolvedores se comprometerem com xp. Isso aumentará a eficiencia e diminuirá custos e horas extra. Isso é bom finaceriamente e uma forma do gerente aparecer bem na empresa. Quando ele entender as vantagens (meno bugs, menos sabados, menos horas extra, mais satisfação do cliente, mais entregas) ele começará a ter curiosidade…
Dê uma olhada em scrum tb, para a parte gerencial. XP provê essa parte porque ela é necessária a todas as metodologias ageis, mas não é o seu foco principal.
O movimento agil chega no rup tb. Dê uma olhada no OpenUP. Tente mostrar que RUP e agil não são incompatíveis.
Alguns textos que podem ajudar vc a entender as semelhança com o processo tradicional e como mudá-lo para o processo agil
Faça a gerencia compreender que não estão perdendo nada. Especialmente não estão perdendo poder de decisão(politico) e sim ganhando maior visibilidade. Avise que provavelmente problemas no processo atual serão descobertos e isso não oportunidades para melhorar a performance da equipa e colocá-la como referencia face às outras equipas.
Não é fácil. Dependendo do estilo de gerencia é mais facil ou mais dificil vc tocar XP /srum dentro da equipa de desenvolvimento sem a interferência do gerente. Mas tente fazer isso. A unica coisa que realmente é necessária é o compromisso dos membros da equipa. se eles estão dispostos a seguir a metodologia porque acreditam que lhes dá vantagem (e depois de 3 ou 4 sprints eles terão a certeza disso; por falar nisso mantenha-os curtos, 2 a 3 semanas no máximo. assim terá mais chance de mostrar a evolução e picar a curiosidade da gerencia ) será mais fácil porque eles mesmos irão resistir às investidas do gerente. Ou seja, vc precisa de unidade da equipa acima de tudo.
Gente muito obrigada pela ajuda, foi muito útil e estou lendo e relendo todas as dicas.
sergiotaborda os links que você passou estão sendo perfeitos para o nosso caso aqui, vai ajudar muito.
Obrigada a todos.
Se você está falando em gerentes tradicionais, você terá que falar a lingua deles. Para ele, pouco importa se a metodologia chama-se Scrum, XP, RUP ou abacaxi. Importa é como você irá comprir metas, reduzir custos, estimar prazos e definir contratos.
Por isso, fuja de muitas tecnicalidades, e foque-se em mostrar como a metodologia atenderá melhor os objetivos do negócio, e porque utiliza-la sairá mais barato e mais eficiente que manter o atual RUP.
Uma boa política é fazer um levantamento dos problemas notórios do processo waterfall na sua empresa:
Percentual de erros de prazo, número de insatisfações do cliente, custo de retrabalho, etc…
Só lembrando que se usam um processo essencialmente waterfall, não estão usando o RUP. Podem estar se inspirando nele, mas mesmo o RUP atualmente trabalha com releases curtas. Muitas vezes um caminho seria convence-los a melhorar as práticas do RUP, que eles já confiam, o que acabará fatidicamente por eliminar os ciclos waterfall ainda existentes.
Estou de acordo com as dicas dos amigos, na minha opinião são muito boas.
Uma coisa me chamou a atenção no seu caso: O fato de você dizer que a gerencia não “se aventurar em mudanças”.
Pediria que você(s) fizessem uma reflexão para verificar se isto não é um indicador de insegurança; quero dizer que, talvez vocês estejam querendo que alguem na hierarquia “assine” em baixo a “mudança” para reduzir a responsabilidade. Não há nada de errado nisto, mas insegurança é uma coisa que tem que ser tratada com atenção pois demonstra dominio supercial do assunto e incertezas em alguns pontos. Nestes casos significa que a equipe tem que estudar mais e principalmente conversar mais a respeito da tecnologia almejada atacando os pontos fracos (baixo conhecimento / dominio).
Talvez a galera não concorde comigo, mas penso que metodologias, estratégias e etc… tem que ser adaptadas ao ambiente onde são aplicadas sem sair da linha mestre do conceito; no seu caso tambem acho que este aspecto requer bastante atenção e criatividade.
P.S Causar mudanças sem poder é muito difícil e pode levar a correr riscos; ainda assim acho que vale a pena. Caso contrario a humanidade ainda estaria na idade da pedra.
[quote=ViniGodoy]
Só lembrando que se usam um processo essencialmente waterfall, não estão usando o RUP. Podem estar se inspirando nele, mas mesmo o RUP atualmente trabalha com releases curtas. Muitas vezes um caminho seria convence-los a melhorar as práticas do RUP, que eles já confiam, o que acabará fatidicamente por eliminar os ciclos waterfall ainda existentes.[/quote]
ciclos waterfall?
Seja la qual for a diferença entre ser “inspirado” ou usar RUP, é importante que eles mesmo se vêem fazendo RUP, apesar de ser waterfall como disse a carolprogramadora, e isso é o que mais tem por ai, apesar de muitos agora estarem usando o termo Scrum para parecerem mais cool.
Eu estava me referindo a diferentes projetos. Eles chamam isso de ciclo (development cicle), embora em cada ciclo do processo haja um projeto diferente. Novamente, estou falando do RUP como era usado a sei lá quantos anos atrás. Ainda assim, mesmo um projeto 100% waterfall tem ciclos. O primeiro é o desenvolvimento (de todo o projeto), seguidos de ciclos de manutenção, mais curtos, mas também longos.
Não confundir com o ciclo de desenvolvimento iterativo (development iteration).
A diferença entre ser “inspirado” pelo RUP e usar o RUP é a que a carol está sentindo. O RUP não é um processo waterfall, há muitos anos. Muitas empresas confundem adotar UML com implementar o RUP, assim como muitas empresas que fazem stand-up meeting se dizem fazendo Scrum ou XP.
Desculpa Sérgio… isso é impossível. XP não é só sobre técnicas de engenharia. O que dizer de ritmo sustentável, cliente presente, humanismo, responsabilidade aceita, benefício mutuo? Isso envolve mais a gestão e o cliente do que qualquer outra coisa do Scrum.
XP muda muito mais os gerentes do que Scrum.
Carol, não recomendo começar este trabalho sem ter apoio da gerência. Agile não são práticas para simples otimização local. É algo bem mais amplo e envolve a empresa toda. Para se ter uma idéia, o mindset do processo de contratação do cliente que estou atuando agora é o impedimento que estou combatendo para defender a implantação Agile. Logicamente que você tem beneficios em melhorar a comunicacão da equipe e etc… Mas os benefícios serão maiores se todos participarem. Feudos são o pior inimigo para implantações Agile.o
Se você estiver em São Paulo nós da Aspercom podemos fazer uma palestra gratuita. Mas seus caciques tem que participar.
Toda a adoção de novas metodologias envolve mais discussões politicas do que tecnicas. Vc pode produzir um projeto piloto foda que algum gerente pode transformar em um mega-lixo se ele se sentir acoado pela novidade. Existem muitos posts e livros sobre adoções de metodologias ágeis que auxiliam porem, IMHO, uma boa abordagem é vc ir em baby-steps. De repente é melhor vc introduzir uma ou mais boas praticas da XP, por exemplo, ao longo do tempo do que fazer um “piloto de XP”, pois boas praticas se disseminam rapido e não são totalmente eliminadas por processos burocraticos. TDD é um bom exemplo.
[quote=rodrigoy][quote=sergiotaborda]
A sua equipa pode desenvolver em XP sem a necessidade dos gerentes saberem disso ou interferirem com isso.
[/quote]
Desculpa Sérgio… isso é impossível. XP não é só sobre técnicas de engenharia. O que dizer de ritmo sustentável, cliente presente, humanismo, responsabilidade aceita, benefício mutuo? Isso envolve mais a gestão e o cliente do que qualquer outra coisa do Scrum.
[/quote]
Se vc pegar o XP e retirar dele as praticas comuns ao Scrum, sobra apenas tecnicas de engenharia.
Infelizmente não dá para fazer um diagrama de Venn. Se Scrum é um conjunto de práticas e valores S, e XP é um conjunto de práticas e valores P
e E é o conjunto de práticas de engenharia então P = S U E
Scrum não define práticas de engenharia porque em tese não serve apenas para projetos de TI. XP serve apenas para projetos de TI (“programming”), e por isso tem que ter essas caracteristicas de engenharia. XP precisa de valores, etc etc,… porque é uma disicplina agil, mas essa parte existe da mesma forma em Scrum.
Alguns links sobre como XP é mais orientado a fazer e Scrum a gerenciar
Discordo absolutamente. XP não pode mudar mais porque é menos focado em gerencia. Ele consegue equipas mais coesas e isso pode levar o gerente a aceitar a mudança,mas não muda o gerente. Tudo o que XP faz na parte de orgnaização , planejamento e retrospectiva é o mesmo que scrum faz.
A diferença é XP é extremo , num esquema de tudo ou nada. ou faz pair programing toda a hora ou não é XP. Este tipo de pensamento está em decaimento e XP , hoje em dia, resume-se a um conjunto de práticas de engenharia que junto com scrum.
Em uma empresa real, ou se faz isso, ou nunca se mudará nada.
Você não conseguirá convencer os gerentes de forma racional. Eles têm que sentir que XP/Scrum é melhor que o método atual.
Eles têm que sentir que não vão perder o emprego , que não vão perder o salário de “gerente” (eles pensam que num ambiente assim o gerente é dispensável e por isso eles têm medo de mudar). Vc não pode argumentar contra o medo. Não funciona.
Vc não pode fazer as pessoas adotarem os valores ageis do dia para a noite. Não é um mecanismo racional que se segue como um algoritmo. É processo de alteração de atitude e isso não acontece sem evidencias reais. Ou seja, sem que vejam funcionando. E não tem como verem se esperamos pela sua aceitação.
Na prática este tipo de gerente é ausente. Ele não está nem ai para como a equipa faz o software. Portanto, desde que a equipa o faça, está tudo bem.
A equipa não pode trabalhar como equipa num sistema não agil e o gerente não torna a equipa agil apenas dizendo “vamos usar xp”. É um processo.
O tendão de aquiles é a equipa e não o gerente. Se a equipa não é ágil não tem como a tornar agil (aka aceitar e praticar valores ageis). Por isso a equipa tem que mudar primeiro. Depois o gerente. O ideal é mudarem juntos, mas na prática isso nao é comum em empresas como a da Carol com gerentes ausentes e que têm medo de mudança.
[quote]
Agile não são práticas para simples otimização local. É algo bem mais amplo e envolve a empresa toda. Para se ter uma idéia, o mindset do processo de contratação do cliente que estou atuando agora é o impedimento que estou combatendo para defender a implantação Agile. Logicamente que você tem beneficios em melhorar a comunicacão da equipe e etc… Mas os benefícios serão maiores se todos participarem. Feudos são o pior inimigo para implantações Agile.o
Se você estiver em São Paulo nós da Aspercom podemos fazer uma palestra gratuita. Mas seus caciques tem que participar.[/quote]
Certo. Supondo que alguem os convence a participar e vc conseguir fazer essa lavagem cerebral a estes gerentes em uma palestra gratuita por favor nos avise dos resultados.
Seria interessante algum tipo de estatistica tipo quantos gerentes antes relutantes saem da sua, quer dizer da vossa, palestra convencidos.
Eu duvido que uma unica palestra consiga convencer alguem. Para isso funcionar a pessoa já tem que estar pré-disposta a aceitar Agil. E esse é que é realmente o problema aqui.
[quote=ViniGodoy]
A diferença entre ser “inspirado” pelo RUP e usar o RUP é a que a carol está sentindo. O RUP não é um processo waterfall, há muitos anos. Muitas empresas confundem adotar UML com implementar o RUP, assim como muitas empresas que fazem stand-up meeting se dizem fazendo Scrum ou XP.[/quote]
Quanta besteira… Porque quando falamos em RUP vc faz questão de dizer que evoluiu mas com Waterfall se baseia num conceito da decada de 80? Tudo evolui, até mesmo waterfall, e toda empresa que diz usar RUP esta na verdade fazendo uma versão mais moderna de waterfall.
Processos são algo muito atrelado a filosofia de uma empresa, não se muda contratando “consultores Agile para gerentes”. Desenvolver software já possui suas próprias dificuldades e tudo que essa gente consegue é queimar o filme na medida que fica o mercado todo falando que faz RUP e Scrum, quando na verdade voltam para o conforto e previsibilidade do waterfall.
A unica forma que vejo essa transição para agile numa empresa com cultura RUP/Waterfall é abrindo uma celula independente.
Fico imaginando um waterfall evoluido. Nao entendi essa. :?
[/quote]
Pra mim nada mais é do que o processo ter um contrato de interface entre os projetos bem definido para que existam fases maiores de analise e implementação, sem problemas. Voce deve ter uma visão estigmatizada de waterfall.
O Yoshima tem razão, XP não são apenas praticas de desenvolvimento de software. User stories, small releases, iteration planning são práticas que quem praticava Xp antes de Scrum já conhecia.
