XP - O que fazer quando não existe o apoio da equipe pra implantar a metodologia?

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!

Boa sorte!

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

http://sergiotaborda.javabuilding.com/2009/10/scrum-para-tradicionalistas/
http://sergiotaborda.javabuilding.com/2009/11/scrum-tarefas/
http://sergiotaborda.javabuilding.com/2009/11/scrum-para-tradicionalistas-previsoes/

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.

Oi carol_programadora,

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.

flws

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.

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.

Particularmente gosto desse artigo
http://blog.fragmental.com.br/2007/08/15/introduzindo-agilidade-num-ambiente/

rodrigoy:

sergiotaborda:

A sua equipa pode desenvolver em XP sem a necessidade dos gerentes saberem disso ou interferirem com isso.

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.

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

in http://www.ferolen.com/blog/xp-vs-scrum/

in http://weblogs.asp.net/rosherove/archive/2006/11/17/scrum-vs-xp-why-scrum-is-easier-to-sell.aspx

in http://www.objectmentor.com/omSolutions/agile_xp_differences.html

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.

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.

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.

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.

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.

Fico imaginando um waterfall evoluido. Nao entendi essa. :?

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

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.

Agora mudou. Aí sim.

projeto - analise - implementacao

Continua sendo waterfall. Com ou sem estigmas.

projeto - analise - implementacao

Continua sendo waterfall. Com ou sem estigmas.

E qual o seu ponto, provar o que é waterfall ou negar que ele tenha evoluido? Eu falei que o RUP é um waterfall evoluído porque ele faz essas mesmas coisas, só que em ciclos.

Paulo Silveira:

sergiotaborda:

XP são práticas de desenvolvimento de software. Scrum são práticas de gerenciamento de projeto.

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.

Agora mudou. Aí sim.

:lol: :lol:

User stories , small releases, iteration planning são estruturas de todas as metodologias ageis. dizer que XP é mais do práticas que engenharia
é redundante, até tautologico, porque se não for mais que isso, não é uma metodologia. É o arcabouço agil em si mesmo.
Então o que diferencia XP de Scrum, não são essas coisas que são comuns a todas as metodologias ageis. Isso é o que eles têm em comum e pelo qual são consideradas ageis.

Embora eu nunca tenha dito que XP são apenas práticas de engenharia, e sim que ele se diferencia de outras metodologias pelas práticas de engenharia, vale a consideração que as práticas de planejamento de XP não são realmente próprias ao XP e sim comuns a todos os mecanismos ageis.
(O livro Agile Software Estimation deixa isto mais obvio.) A pessoas planejam sprints em todos os mecanismos ageis. A diferença é o que se considera o " objetivo do sprint". Em scrum, por exemplo, e á diferença de XP, o sprint precisa levar a codigo apto para deploy. Em XP isso não é obrigatório.
São essas diferenças filosoficas que diferenciam se está usando XP ou outra coisa.

O meu ponto é apenas que, toda a parte de planejamento assocaida ao XP é feita melhor se usado Scrum. Por outro lado, o ponto é tambem que as práticas associadas ao XP como TDD e repositorios de codigo não são exclusivas do XP. São práticas do desenvolvimento de software que o XP amarra e estabelece critérios de uso para elas, mas as práticas não são do XP, são usadas pelo XP. Ha uma diferença.

Enfim, a ideia é apenas dizer que podem ser usadas as práticas de desenvolvimento sem que isso caracterize XP e também ser feliz e ter bons resultados. Não é preciso entrar na onda “extremista” do XP de tudo ou nada. Para a parte de planejamento Scrum tem mais ou melhores efeitos que a do XP porque os valores são mais rigidos nessa parte. E para a parte de engenharia as práticas per se são suficientes.

Nao quero provar nada. Soh achei esquisito o termo “waterfall evoluido”. Se o waterfall evoluiu pra alguma coisa nao eh mais waterfall, oras.

Eu tenho comigo que processos de desenvolvimento de software soh servem pra alguma coisa se as pessoas envolvidas servem pra alguma coisa. RUP, XP, Scrum, e mais meia duzia de nomes ai, soh servem pra algo se as pessoas envolvidas estao “envolvidas”, repetindo a repeticao. De resto nao entro em discussoes detalhistas, nem tenho know-how pra isso.

E outra, se faz em ciclos nao eh waterfall (a nao ser que vc esteja considerando que a agua evapora e cai na cachoeira novamente) :mrgreen:

Sergio, você escreve muito. Seja mais direto. Coloque seu ponto de vista sem fazer estripulias. Fica difícil discutir com você como sempre. Só um desabafo.

Se eu tirar o Scrum do XP ainda sobra:

Valores:

1. Simplicidade (é um conceito de gestão)
2. Coragem (é um conceito de gestão)

Princípios (que envolvem Gestão):

1. Falha
2. Humanismo
3. Passos de Bebê
   4,.Redundância

Práticas (mais uma vez, somente as que envolvem GESTÃO):

1. Ambiente Informativo (psc, esses quadrinhos da moda Scrum não é prática do Scrum)
2. Ciclo Trimestral (sim, se você leu o livro do Ken, note que ele não fala sobre planejamento de release, dá zero para ele)
3. Folga (equipes Scrum não precisam disso, são Chuck Norris por natureza)
4. Histórias (opa, mais uma prática de Gestão do XP, noooooosa, stories não é do Scrum?)
5. Sentar-se Junto (será que os POs ficam o tempo todo com a equipe?)
6. Trabalho Energizado (prática de Gestão).

É falácia. O Scrum define sim práticas de engenharia. Leia o livro do Ken. O papel do ScrumMaster é promover boas práticas de engenharia. O pedaço de funcionalidade potencialmente implantável é uma prática de engenharia, e uma das mais difíceis.

Estude melhor o XP. XP menos Scrum não fica só práticas de engenharia como provado acima. Isso é falácia de Scrummeiro. Os tópicos que coloquei acima não estão no Scrum e pode ter certeza que ritmo sustentável, sentar-se junto, coragem e humanismo mudam mais a gestão do que as coisas do Scrum. Sim, o Scrum tem o mérito de ser mais simples, mas o humanismo do XP é algo que muda a gestão completamente. XP não fere o humanismo em detrimento a performance.

sergiotaborda:

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.

Fontes por favor? Artigo, pesquisa? Quem disse que está em decaimento?

sergiotaborda:

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.

Mais uma vez, cases por favor? Quais empresas você tentou isso e não deu certo? Qual a sua experiência? Engraçado, meus melhores argumentos são contra o medo…

Sergio, Sergio. Isso aconteceu num cliente meu. A Synchro. Antes relutantes e depois confiantes, e isso com um treinamento de 8 horas. O mais engraçado de tudo isso é que este cliente que estou atuando agora é uma das maiores seguradoras do país com faturamento de 8 bilhões de reais, o Agile lá vai escalar para 300 devs e convencí eles em uma palestra de 2 horas. Na semana passada ministrei um treinamento de TDD e XP na Imagem (img.com.br). Esses caras se convenceram lendo o Débito Técnico. Não é lavagem cerebral, tenho bons argumentos e bons cases, principalmente em clientes ISV e empresas pequenas. Eu sei das dificuldades que esses gestores tem. É bem simples até, mas a decisão é do gestor. A palestra é simplesmente para tirar dúvidas. Concordo que empresas como a minha são involuntariamentes beneficiadas pelo efeito “santo de casa não faz milagre”, por isso recomendei essa estratégia para a Carol.

Pessoal, antes de mais nada, obrigada pela contribuição de todas, foram muito esclarecedores e me ajudaram muito, estou discutindo tudo que vocês passaram com a equipe aqui.

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.

Pois é ViniGodoy, exatamente esse o problema, talvez se simplesmente usarmos o RUP da maneira correta já seria um avanço, mas o que acontece é a cascata mesmo, e a burocracia não deixa, o que importa são documentos, documentos e documentos :argh

rodrigoy:

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.

Obrigada pela dica, sem dúvida ajudou muito, infelizmente, infelizmente mesmo, estamos no planalto central bem longe de sampa. Mas leio bastante seu blog e tento assimilar para trazer uma solução aqui.

Vou planejar aqui com a equipe uma estratégia para seguirmos em frente, seja de um jeito ou de outro, traçar alguns planos A, B… O que não dá é continuar fazendo software da maneira como é feita :roll:

Obrigada a todos pela atenção e colaboração, foram de grande valia suas experiências.

rodrigoy:

Sergio, você escreve muito. Seja mais direto. Coloque seu ponto de vista sem fazer estripulias. Fica difícil discutir com você como sempre. Só um desabafo.

:lol: não obrigo ninguém a ler.

Não resta não. Os valores de Scrum implicam coragem e simplicidade (Foco).

Esses principios e prática não são do scrum nem do XP. São principios gerais.
Como tal não têm nenhum peso argumentativo para mostrar que XP é mais que scrum + práticas de engenharia.

“promover” e “definir” são coisas diferentes. A posição do scrum e especialmente do ken é “a arte do possivel”. Neste sentido se é possivel trabalhar com boas práticas de engenharia, faça-o. Aliás, sempre que perguntado sobre como/quais são essas práticas ele relega dizendo que deveriamos olhas as práticas do XP (The Enterprise And Scrum).
Promover significa que deve uma boa prática deve ser defendida face a uma má prática ou nenhuma prática. Mas o scrum não define o que é uma “boa prática” da mesma forma que não define o que significa “pronto”. Ele apenas afirma que a equipa deve estabelecer esses conceitos e defendenlos/promovê-los. É bem diferente do XP que explica o que é pair programming e fala que vc deve usá-lo.

Não não é uma prática de engenharia. É uma prática de gestão de projeto. O poder é do product owner não dos desenvolvedores. Em scrum - a apenas em scrum - é uma obrigação dos desenvolvedores ter o produto em modo de deploy no final de cada sprint. Nos outros modelos ageis isso não é obrigatório. É um nice to have e não um must have como no scrum.

Eventualmente a equipa pode deixar o projeto nesse estado a cada final de sprint em xp, mas isso não é uma obrigatoriedade. E não o é ex

Não foi provado nada. Vc nem sequer deu argumentos.

Fontes por favor? Artigo, pesquisa? Quem disse que está em decaimento?

http://www.se-radio.net/podcast/2009-11/episode-150-software-craftsmanship-bob-martin

Ninguem afirmou que está em decaimento, mas se infere isso pelos comentários que as pessoas fazem.
Quando alguem defende que pair programing não deve ser feito todo o tempo e que é muito melhor parear apenas quando necessário
está-se dizendo nas entrelinhas que XP na sua forma “pura” e “absoluta” não é mais necessário. Da minha experiencia e de equipes que vi usar XP na forma pura, não ha realmente ganho em parear toda a hora. Mais pessoas estão vendo isso…

Mais uma vez, cases por favor? Quais empresas você tentou isso e não deu certo?

Não estou em liberdade para dizer os nomes. (procure o meu curriculo e tire sua conclusões dai)

O ponto não é esse. O ponto é: essas pessoas eram gerentes de visão-curta que acham que seu processo waterfall é RUP ?
Essas pessoas já tinha lido algum material sobre agil ao ponto de estarem curiosas em como isso poderia os ajudar ?

Se a sua resposta é sim às duas perguntas então não conta. Estamos falando de pessoas que estão no primeiro grupo e não no segundo.

My point exactly. Se as pessoas já estão convencidas à priori sua palestra não as está convencendo de nada. No máximo está detalhando passos e tirando duvidas. Estamos falando de gerentes que não sabem ler, que não querem ler ou que têm raiva de quem leu. Tlv não seja o universo de gerentes que vc conhece nas sua andanças pelas empresas de 8 bilhões de faturamento, mas são os que eu conheço nas empresas de milhares em faturamento: gerentes que usam a palavra “agil” como chamariz ou para embelezar o seu processo warterfall e não têm sequer noção do que é um valor moral, muito menos um valor agil.

Sim, sim Sérgio… Scrummeiros geralmente dizem que Scrum envolve tudo. Projetos de software e etc… É bastante engraçado pois a literatura base do Scrum que é o livro do Ken SÓ DÁ EXEMPLOS DE PROJETOS DE SOFTWARE. Scrummeiros também seguem o seguinte lema: Se o Scrum diz que serve para voar, então, passáros, moscas, aviões e asteroides estão incluídos no Core do Scrum.

Me dê mais detalhes. Aonde Coragem e Simplicidade estão no Scrum? No Foco? Que relação há entre Foco e Coragem? O que você entende por Coragem no XP?
(eu sei que vc vai colocar no Google “courage +xp” e me mandar o primeiro link)

Ter o sistema “deploy ready” é uma prática de gestão? Oras, então Pair Programming é para Foco e assim, seria mais uma prática de gestão do XP para complementar meu argumento. Taí!!! Pair Programming é uma prática de gestão do XP que não tem no Scrum… Se vale dizer que qualquer prática é de gestão fica ainda mais fácil ainda defender meu argumento. Ou será que é o Sérgio Taborda que decide quais práticas são de gestão e quais são de engenharia.

Engraçado, a maioria das pessoas que falam que fazem agile, que implantam agile, que fazem isso e aquilo no mercado nunca estão em liberdade para dizer nomes. Eu acho isso muito estranho. Muito mesmo. Sem fundamentar seu argumento em fatos não dá para continuar a discussão.

Só para reafirmar, SIM, todo o meu trabalho que faço atualmente nesta seguradora partiu de uma palestra que ministrei no ano passado a pedido e um aluno que NÃO ERA GERENTE. Se você não consegue fazer isso eu te recomendo um curso de vendas.

rodrigoy:

Sim, sim Sérgio… Scrummeiros geralmente dizem que Scrum envolve tudo. Projetos de software e etc… É bastante engraçado pois a literatura base do Scrum que é o livro do Ken SÓ DÁ EXEMPLOS DE PROJETOS DE SOFTWARE. Scrummeiros também seguem o seguinte lema: Se o Scrum diz que serve para voar, então, passáros, moscas, aviões e asteroides estão incluídos no Core do Scrum.

Me dê mais detalhes. Aonde Coragem e Simplicidade estão no Scrum? No Foco? Que relação há entre Foco e Coragem? O que você entende por Coragem no XP?
(eu sei que vc vai colocar no Google “courage +xp” e me mandar o primeiro link)

Vc não leu o link que mandei ? então leia este http://sergiotaborda.wordpress.com/scrum/valores/

Valores do scrum :
Comprometimento , Foco , Abertura , Respeito, Coragem

Valores do XP (http://en.wikipedia.org/wiki/Extreme_Programming#Values)

Comunicação , Simplicidade, Feedback , Respeito, Coragem

O termo “Abertura” é tradução livre de Openness que é o valor se estar aberto a conversar e a entender o ponto de vista do outro e mostrar o seu. É isso que leva a pendurar burndown charts por ai… vc está aberto a que qualquer pessoa a qualquer momento o interpele sobre aquele gráfico.
Isso é mais que comunicação e mais feedback, é os dois juntos com mais a capacidade de se expor ao escrutinio de pessoas fora do projeto ( outras equipas, outros departamentos, auditorias, etc…)

Se simplicidade não resultado de manter o foco, não sei o que é simplicidade. Tlv vc entenda simplicidade como DRY ou KISS ou faça agora e refatore depois. Eu não entendo assim. XP não invoca o valor de comprometimento e é por isso que não é uma metodologia de gestão.

Acho que vc acabou de mostrar que não conhece Scrum. Coragem é um dos valores básicos. Não teria como vc me perguntar onde coragem está no scrum se vc conhecesse scrum.

Se vc não conhece scrum é inutil vc querer nos convencer do que quer que seja.

Por outro lado a sua limitação a achar que scrum é o que o Ken fala e diz mostra ainda mais a sua limitação no conhecimento de scrum. Aliás, o Ken acabou saindo da Scrum Alliance que ele mesmo fundou. Isso mostra várias coisas, mas mostra principalmente que não ha uma relação de identidade entre o ken e o scrum.

“Se o Scrum diz que serve para voar, então, passáros, moscas, aviões e asteroides estão incluídos no Core do Scrum.”

Esta sua frase não diz nada e mostra uma vez mais que vc desconhece o assunto, ou no minimo está apelando para um argumento de ridicularização que tb não abona em nada a sua argumentação.

Não é o Sergio Taborda que decide, mas é o Sergio Taborda que vai lhe explicar a diferença, pois parece que vc não sabe.
Práticas de engenharia têm que ver com o software em si e as técnicas que são usadas para o criar. Elas são válidas e usadas em qualquer mecanismo de gestão de projeto pois elas são independentes de haver um orçamento, um prazo, etc… Elas são comuns a todos aqueles que fazem software seja em que tipo de projeto for e sob qualquer tipo de gestão.
Práticas de gestão são relacionadas a projetos. Elas são independentes do tipo de projeto e do produto que estão sendo feito. Elas se preocupam em manter orçamentos e prazos e expectativas do cliente seja ele quem for.

Um esquema de projeto que apenas tem um release para o cliente não ha demanda para que seja possivel fazer o deploy antes do prazo do release.
Em scrum, embora haja um plano de release, o Product Owner pode decidir , no fim de qualquer sprint, adiantar esse release. Esta prática costa custos e aumenta o prazo util, melhorando as expectativas do cliente. Isto é uma prática de gestão sim. Ela é aplicada em qualquer tipo de produto cujos requisitos possam ser entregues em vários releases, que básicamente são todos os que não seguem um modelo waterfall.

Se vc pagar os custos legais do processo com que irei levar se revelar eu digo. Além do que ninguém o está impedindo de saber. Procure.

Além do mais qual é a diferença se eu lhe disser os nomes ? vc vai lá verificar ? Vc quer forçar um argumento de autoridade do tipo “eu sei porque aconteceu comigo na X e Y”. Qual é a diferença disso para “Eu sei porque aconteceu comigo” ? ou vc confia na minha palavra ou vc não confia. Leh dizer os nomes não muda a sua confiança , e portanto não muda o seu argumento.

O ponto é muito simples: Nem todos os projetos de implantação de agil são sucessos. Alguns falham. Vai-me dizer que é mentira isso ? Convença-nos então que isto não é real. Os mais comums são :

Teams Lacking Authority and Decision-Making Ability - todo o gerente tacanho vai impedir isto por entender que isto é uma forma minar a autoridade dele.

A Culture that Does Not Support Learning - A cultura do gerente e da empresa ( sim porque alguem poderia sobrepor-se ao gerente, mas isso tb não acontee) não aprende. muitos entram no agil porque é buzzword. Porque vende mais dizer que a empresa é Agil. É o mesmo conceito de marketing que dizer que a empresa tem idade média de 30 anos. Agil não é isso. Mas para eles não importa. Marketing não se importa com o que é, apenas com o que vende.

Denial is Embraced Instead of the Brutal Truth- o gerente se nega a tentar entender agil. Se nega a tentar entender porque os desenvolvedores querem mudar para agil. A unica palavra que se houve é “não”.

Este tipo de entraves não dependem da vontade ou skill do envangelista agil e sim do seu poder politico dentro da empresa. Se a ordem vier de cima, para adotar agil, tem que adotar e acabou. Mas isso, é raro.

Tlv vc não tenha conhecido nenhum destes gerentes - provavelmente porque nunca trabalhou numa equipa de desenvolvimento comandada por um - mas eu e muita gente aqui conhece. Vc pode achar que a sua palestra é infalível e espero bem que seja, o problema é que essas pessoas de que falo nunca estariam em uma a menos que a vida delas dependesse disso.

Você vir aqui dizer que basta que a carol mande os gerentes na sua palestra para que tudo vire XP do dia para a noite é no mínimo ingénuo e demonstrativo da sua falta de conhecimento do mercado real visto pelos olhos de quem trabalha todos os dias com desenvolvimento em projetos comandados por gerentes agile-haters.

O Scrum não é o que o Ken Schwaber fala (aka o cara que criou o método)? Que relação há entre a saída do Ken da SA e a sua autoridade no assunto Scrum? Não há uma relação de identidade entre Ken e Scrum? Conceitualmente incorreta sua colocação e me lembra os aloprados da OMG quando falaram para o Ivar Jacobson que ele não tinha entendido nada de casos de uso.

Se você toma a liberdade de dizer que o XP como ele é caiu em desuso, tomo a liberdade de dizer que coragem, algo citado no black book do Ken caiu em desuso. Isso nem consta no livro novo (que está mais direcionado para transparência, inspeção e adaptação) e sequer consta no Scrum Guide. Concorda comigo ou não?

Sua colocação define o que é gestão e o que é engenharia. Me explica: User Stories é engenharia ou gestão? O que ocorre num planning é só gestão?

Sergio, não preciso me justificar sobre meu conhecimento e principalmente minha atuação no mercado. Aliás, não achei seu curriculum em lugar nenhum. Outra sugestão: vamos acalmar os ânimos… desculpe se coloquei algo que te ofendeu. Não vamos partir para ofensas pessoais. Abraços!

rodrigoy:

sergiotaborda:

Por outro lado a sua limitação a achar que scrum é o que o Ken fala e diz mostra ainda mais a sua limitação no conhecimento de scrum. Aliás, o Ken acabou saindo da Scrum Alliance que ele mesmo fundou. Isso mostra várias coisas, mas mostra principalmente que não ha uma relação de identidade entre o ken e o scrum.

O Scrum não é o que o Ken Schwaber fala (aka o cara que criou o método)?

Scrum não é apenas o que o Ken fala. Ele fala muita coisa, mas ele tende a apresentar o Scrum como uma coisa etérea que cada um pode moldar a seu gosto. Eu perfiro a abordagem mais principio-efeito. São colocados principios, são derivadas regras, são encontradas práticas que seguem as regras. Neste sentido é que o scrum é aberto porque ele não define as práticas, apenas as regras. É como no próprio jogo de rugby, cada jogador tem um objetivo , o jogo tem regras, portanto cada jogador sabe o que é “falta” e o que não é. Durante o scrum (a reunião dos jogadores) a estratégia é definida, mas quando o cara tem a bola cabe a ele, e apenas a ele alcançar o objetivo. Para isso ele tem que ter um conjunto de práticas que , dentro das regras, o levam ao objetivo. Cada jogador tem as suas, e é isso que o torna valioso à equipa. Alguns jogadores têm as mesmas práticas ou algumas práticas são comuns a todos os jogadores. Isso são as práticas da equipa.

Em software, as regras são definidas pelos mecanismos de priorização-planejamento-sprint-dayly-meeting. Cada um tem um papel a cumprir e sabe o que lhe cabe no jogo (PO, SM, testers, designer, arquiteto, etc…) A alguns caberão mais papeis que a outros… os jogadores escolhem as praticas: pair programing, teste unitário, a regra do escuteiro, uso de checkstyle, svn, IC ,etc… algumas todos os jogadores - membros da equipa- adotam, algumas apenas alguns adotam. E assim vai.

O ponto é que as práticas de engenharia não são ditadas pelo scrum. Isso é ponto assente entre a comunidade scrum. Seria como no rubgy as regras do jogo dizerem exatamente como o jogador terá que fazer a jogada. Isso mata a criatividade e mata o jogo.

Vc nunca ouvira o Ken falar em coisas como estimativas e hiperprodutividade. Para ele isso simplesmente não existe - tlv porque ele trabalha principalmente como consultor de envangelhização e não na mesma empresa 5/7 em todos os projetos - contudo são conceitos extremamente importantes em scrum. Para quem não sabe o estado de hiperprodutividade é quando a equipa faz mais pontos do que seria matemáticamente possível ( ou seja o seu fator de foco é maior que 100%).

Enfim, o Ken não sabe tudo sobre Scrum. Ele não é o Papa. muitas outras pessoas trabalham e desenvolvem o scrum e temos que ouvi-las tb.
Se vc só leu os livros do Ken, vc só tem um lado da historia. Vc precisa ouvir os outros lados.
é neste sentido que não ha uma identidade Ken == Scrum.

Acho que ficou claro que não.

Esse é exatamente o problema. Vc está se baseando em argumento de autoridade. “Se o Ken falou, e ele é a autoridade , então é verdade”.
Isso é o conceito usado para o Papa. Não funciona assim.

O Ken não concorda que é possivel ter um “manual do scrum” no sentido de ter regras que dizem o que é scrum e o que não é. Isto junto ao fato dele ter fundado a SA levou a que durante anos a ceritifcação scrum não tivesse exames e fosse basicamente uma piada. Isto mudou recentemente. Ou seja, as pessoas do scrum não mais se revêem no Ken e querem levar o Scrum a um patamar mais… digamos… concreto. De forma que o mau scrum possa ser provado mau scrum e o bom scrum provado bom.
Ao sair da posição de presidente da SA, ele deixa o cargo de “Papa” e exatamente por isso cai esse conceito que vc está usando de que “o Ken é que sabe do Scrum e o resto é um bando de seguidores”.

Este argumento que vc está usando é um problema muito grande na adoção de Scrum e a nova SA visa eliminar este entrave “politico” e se concentrar mais no que realmente interessa : o Scrum. Mais sobre isso aqui.

Se é conceituamente incorreta é discutivel. Depende dos seus conceitos.

Primeiro eu não disse que XP caiu em desuso. eu disse o XP “puro” , “abolutista” , “linha dura”, caiu em desuso.
Segundo, quanto á coragem, ele nunca este na moda. Logo não pode estar em desuso. Se vc ler Agile Project Management withScrum vc tem muitos exemplos de como o scrum entra nas empresas , mas nenhum de falha.
Sendo que existem tantos projetos agil falhando é facil ver onde ha coragem e onde não ha. Ha onde dá certo, e é ausente onde não dá certo.

As historias em si são requisitos e requisitos são problemas a serem resolvidos. eles tanto são um problema para a eng como para a gestão. Requisito não é um prática ou uma regra é uma necessidade de limitar o problema. Podemos então dizer que não são nem um nem outro, ou ambos. Tanto faz.

Panning feito do jeito tradicional não ágil é puramente gerencial. É controle de custo e prazo (apenas). Panning feito do geito agil leva em consideração a realidades das coisas e da equipa e tem um braço estendiddo para o que a equipa pode e não pode fazer. Neste sentido , este planning tb é uma atividade mista. Contudo, o conceito de planejamento em si mesmo (temos que reunir e definir um caminho) tb é apenas gerencial. Tanto é que ele é aplicado em várioas tipos de projetos independentemente do tipo de trabalho (plenaejamento de vendas, de markaeting, etc…)

Esta entrevista da se-radio aborda exatamente das diferença entre Scrum, XP e Kanban e fala também sobre a ameaça que os gerentes sentem quando houvem falar em agil.

http://www.se-radio.net/podcast/2010-02/episode-156-kanban-david-anderson ( em inglês)

Por que o RUP não é mais waterfall. Ele não usa o waterfall da década de 80.
Se você ainda usa waterfall, você não usa RUP.

Waterfall não está relacionado as fases. E sim a duração das fases. Ter uma única (ou pouquíssimas) repetições dessas fases é o que define um projeto como waterfall.
Se as fases forem curtas, e houver realimentação, você está num projeto interativo. Pode não estar num projeto ágil, mas não está mais num projeto waterfall.