Gostaria de iniciar uma discussão sobre métodos ágeis e gerencia de demanda. Eu confesso não ter muito conhecimento sobre o assunto e nem sei se estou misturando assunto bem diferentes. Gostaria de começar com o tema: Como a metodologia ágil vê a gerencia de demanda? E partir para o ponto de como funciona esta área de gerência de demandas, como estrutura, perfil dos profissionais e etc.
Amigo,
Procure assuntos relacionados a governança e gerencia de projetos
PMI, CMMI, scrum, xp, etc.
abs
De onde surgiu a motivação para discutir o assunto, já que você mesmo diz não ter experiência? TCC?
O fato de não ter experiência não me coloca em possição de não buscar conhecimentos. A ideia chave do meu tópico e “ouvir” opiniões que possam direcionar a busca por este conhecimento. A motivação surgiu de necessidades que possuo em agregar em minhas exepriencias profissionais as mais diversas experiencias vivas por varias pessoas.
Tive contato com as varias métodologias existentes atualmente, quanto aos metodos ageis tenho participado de DOJO para pratica de TDD e em minha carreira profiisional ao longo de 14 anos de TI trabalhei com varias outras métodologias, contudo vejo um pouco de cada coisa acontecendo nos mais diversos ambientes e percebo algumas confusões se estabelecerem. Estou buscando ouvir as praticas individuais, para me ajudar a ter um possicionamento sobre o caminho mais abordado nos dias atuais.
[quote=jonestorres]Amigo,
Procure assuntos relacionados a governança e gerencia de projetos
PMI, CMMI, scrum, xp, etc.
abs[/quote]
Jones, sim andei lendo um pouco sobre cada ponto citado. Mas no seu ponto de vista quais os principais erros na implantação de uma área de demandas quando as equipes de desenvolvimento, produção e suporte estão mais propensas a métodos ágeis? Faz sentido uma área de demandas com o papel apenas de receber as demandas sem gerar 1º nível de suporte no recebimento das mesmas?
A meu ver não faz o menor sentido em metodologias ageis. Nessa o software é desenvolvido de forma incremental ou seja não a “demanda” pois tudo discutido com cliente. Como exemplo, na XP podemos dizer resumidamente que se faz o levantamento do que o cliente quer e são criados varias “estórias” e o cliente decide quais delas são mais importantes e quais das mais importante é a principal assim na primeira iteração os desenvolvedores criam um esqueleto do sistema e implementam somente essa estória, e mostram para o cliente o cliente vê o sistema e o ajusta caso necessário criando novas “estórias” e assim ele vai sendo implementado uma estória de cada vez conforme a importancia destas para o cliente.
Recomendo a leitura do livro do Kent Beck Programação Extrema Explicada
A meu ver não faz o menor sentido em metodologias ageis. Nessa o software é desenvolvido de forma incremental ou seja não a “demanda” pois tudo discutido com cliente. Como exemplo, na XP podemos dizer resumidamente que se faz o levantamento do que o cliente quer e são criados varias “estórias” e o cliente decide quais delas são mais importantes e quais das mais importante é a principal assim na primeira iteração os desenvolvedores criam um esqueleto do sistema e implementam somente essa estória, e mostram para o cliente o cliente vê o sistema e o ajusta caso necessário criando novas “estórias” e assim ele vai sendo implementado uma estória de cada vez conforme a importancia destas para o cliente.
Recomendo a leitura do livro do Kent Beck Programação Extrema Explicada[/quote]
Legal x@ndy seu ponto de vista. Este ponto é um dos que tenho visto, Monta-se uma area de gestão de demandas e no momento em que as demandas chegam já são repassadas a equipe de desenvolvedores - sendo que em enumeros casos não eram para ser resolvidas por desenvolvedores, e ao mesmo tempo querem implementar praticas ageis. Ao meu ver parece antagonico, como ter uma area de gestão de demandas, IMPORTANTE: que desce as demandas o tempo todo para o desenvolvedor, e ao mesmo tempo termos uma equipe de desenvolvimento com praticas ageis? Seria possivel o convivel harmonico dos dois? Imagino que com pequenas alterações do tipo a area de demandas deveria ter competencia para resolver algumas demandas e em casos de realmente necessario desce-las para a area de desenvolvimento, que esta respeite o processo de empacotamento e desenvolvimento das estorias que serão montadas pelo cliente. A demanda serviria para comunicar o que esta acontecedo ou que é para acontecer dai para o desenvolvimento trafegaria de acordo com o processo agil adotado pela equipe, voce acha que isto é possivel? ou não tem nada a ver?
Oi Haikal,
Se entendi sua explicação, acredito que seja possível; porem em processos àgeis podemos observar a indicação da participação do cliente no desenvolvimento.
Admitindo a idéia que vc discorreu teriamos uma espécie de fachada entre os desenvolvedores e o cliente quebrando um pouco a proposta dos processos àgeis, normalmente isto causa problemas.
flws
Realmente o oposto do que a equipe de desenvolvimento quer! Esse processo de demandas não é desenvolvimento ágil é waterfall classico. O problema pelo que eu vejo é que existe duas culturas nesse caso os desenvolvedores que querem ser agil e a empresa que adota o processo de waterfall. Isso é um problema.
Na verdade o convívio pode ser até harmonioso mais ai você não vai ter agilidade nenhuma.
Em metodologia ágeis nunca haveria um setor responsável por demandas, na verdade ele não é necessário, poderia até haver um suporte mas ai é diferente o suporte seria responsável por resolver problemas técnicos e só isso.
Por que não haveria departamento de demandas? Porque não existiria demandas!!!
Em um processo pseudointerativo teriâmos cliente solicita algo o setor de demandas avalia e diz ao desenvolvedor o que fazer ou seja
Cliente->Demandas->Desenvovimento.
Cascata pura.
No agil não. O Desenvolvedor Interage com o Cliente ou seja O Cliente diz o que quer e o Desenvolvedor modela em conjunto com o cliente em seguida implementa e apresenta ao cliente, este vê o que foi feito e corrige algo ou não e pede mais alguma coisa. Nesse caso o feedback do cliente, que seria uma “demanda” é rápido. Outro tipo de feedback ou “demanda” do cliente é o caso de um bug do no sistema. Nesse caso toda a equipe para e se dedica a correção do problema, só depois é que continua a interação normal.
Nesse tipo de desenvolvimento o Cliente “dirige o desenvolvimento” ele é o responsável “pelas tais demandas”!
OK, ficou claro. Um ponto importante que o x@ndy disse foi a distinção entre a parte de suporte e de gestão de demandas. Talvez esteja ai um fator importante da confusão gerada pela maioria que querem implantar uma area de suporte e acabam implantando uma de gestão de demandas. Talvez por uma falsa impressão de segurança.
fantomas, realmente temos uma fachada entre os interessados e além dos problemas que você citou teriamos a ausencia de prioridade de comunicação gerando aquele velho problema de entendimento entre solicitante e atendente efetivo da demanda, um horror.
A verdade é que tudo é relativamente tão novo e inevitavelmente se faz confusões nas implantações deste processos. Talvez seja a novidade*(metodos ageis) se misturando ao habito (waterfall);
*novidade para os tempos de hoje, pois nos bastidores se se discutia e utilizava metodos ageis há algum tempo.
Realmente, há muita gente que quer implantar Agile em cima de uma estrutura Waterfall.
Mas não acredito que esse problema seja por causa da “novidade” do assunto, que nem é mais novo assim, já que temos literatura publicada há mais de 10 anos.
O problema é que as pessoas querem mudar, sem ter que realmente mudar. É por isso que as pessoas vão para terapia e desistem depois de 2,3 meses. Elas não querem mudar nada! Só foram porque acharam que o terapeuta ia validar o comportamento delas.
Da mesma forma, eu vejo as empresas dizendo: “Vamos fazer Agile!! Uhuuu muthafucka!! Mas o cliente só participa na primeira semana. Mas a equipe está distribuída na China, India, Brasil e Chechênia. Mas antes de escrever código precisamos escrever requisitos e elaborar o design. Mas nossas iterações tem 6 meses. Mas nossos releases não precisam rodar. Mas nossas estórias são escritas sob a forma de caso de uso. Mas já demos o preço e a data de entrega em cima de uma lista de funcionalidades que nem sabemos como implementar ainda. Mas qualquer mudança de escopo implica em revisão do contrato.”
Concordo plenamente com vc, eu tambem estou a bastante tempo na àrea da computação e quando dá dou este toque de que o assunto não é de agora.
Muitos conceitos são dificeis de se estabelecer. Temos o despreparo dos individuos junto com a força dos paradigmas correntes, sem falar nos conflitos de interesses, que não deixam muitas coisas bacanas acontecerem de forma plena e abrangente.
É difícil encontrar um lugar que realmente tenha conseguido implantar processos àgeis totalmente. O pior dos casos que já presenciei foi um lugar onde diziam que haviam implantado um processo àgil mas na verdade haviam transformado a coisa toda em uma bagunça maior ainda.
flws
Não acretido nisso. As empresas tem que evoluir sempre, a concorrência nesse mercado é altissima, o problema é que elas não tem "cultura ágil"
Por que Scrum pegou no Brasil e XP não? Quando o gerente vê que XP utiliza a programação em pares, ai ele desite na hora! “Dois programadores para fazer o mesmo serviço! Não mesmo!” Diz ele. Vai tentar explicar que não é bem assim, que a produção vai ser mais rápida, etc.
Tem também o Analista Mac Donald’s que não entende nada de desenvolvimento de sistema e tem medo de perder seu emprego. Tem o programador nerd que acha que o cliente não sabe nada ele é que sabe e assim vai.
Adotar as práticas ágeis é um compromisso de todos em uma empressa. Mas tem gente que não muda sua cultural
Alexandre,
Disse Maquiavel: “Deve-se ter em conta que não há coisa mais difícil de realizar, nem de êxito mais duvidoso, nem de maior perigo para conduzir, do que o estabelecimento de grandes inovações. Porque o inovador tem por inimigos todos quantos viviam bem no regime anterior, e só encontra tímidos defensores entre os favorecidos com a nova ordem. Timidez produzida em parte por medo dos adversários e em parte pela natural incredulidade dos homens, que não se convencem de que uma coisa nova é boa, até que a experiência o comprove.”
[quote=esmiralha]Alexandre,
Disse Maquiavel: “Deve-se ter em conta que não há coisa mais difícil de realizar, nem de êxito mais duvidoso, nem de maior perigo para conduzir, do que o estabelecimento de grandes inovações. Porque o inovador tem por inimigos todos quantos viviam bem no regime anterior, e só encontra tímidos defensores entre os favorecidos com a nova ordem. Timidez produzida em parte por medo dos adversários e em parte pela natural incredulidade dos homens, que não se convencem de que uma coisa nova é boa, até que a experiência o comprove.”[/quote]
Nossa, perfeito. É um resumo bem sucinto da Fábula dos Porcos Assados
Na verdade essa confusão é bem antiga olha esse post no Blog do Shoes de 2007
[/quote]
Muito interessante o post. Obrigado por compartilhar o link.
[quote]Realmente, há muita gente que quer implantar Agile em cima de uma estrutura Waterfall.
Mas não acredito que esse problema seja por causa da “novidade” do assunto, que nem é mais novo assim, já que temos literatura publicada há mais de 10 anos.
O problema é que as pessoas querem mudar, sem ter que realmente mudar. É por isso que as pessoas vão para terapia e desistem depois de 2,3 meses. Elas não querem mudar nada! Só foram porque acharam que o terapeuta ia validar o comportamento delas.
Da mesma forma, eu vejo as empresas dizendo: “Vamos fazer Agile!! Uhuuu muthafucka!! Mas o cliente só participa na primeira semana. Mas a equipe está distribuída na China, India, Brasil e Chechênia. Mas antes de escrever código precisamos escrever requisitos e elaborar o design. Mas nossas iterações tem 6 meses. Mas nossos releases não precisam rodar. Mas nossas estórias são escritas sob a forma de caso de uso. Mas já demos o preço e a data de entrega em cima de uma lista de funcionalidades que nem sabemos como implementar ainda. Mas qualquer mudança de escopo implica em revisão do contrato.” [/quote]
esmiralha, também não acho que seja a novidade, até como eu destaquei no meu post, não é tão novo assim. Achei interessante sua colocação no ultimo paragrafo, é exatamente isto que se ve muito kkkk. Quando vc me perguntou da minha motivação, acho que atingi o objetivo, agora posso mandar o link do forum para meu gerente :lol: :lol: :lol:
fantomas, você lembrou bem de uma coisa conflito de interesse, parece repetitivo, mas como existe.
No mais, valeu galera pelo compartilhamento das experiencias e dos conhecimentos, para mim foi de grande valia.
Ola pessoal da discursão…
Acredito tambem que controle e gerência de demanada associada ao XP=waterfal, porém acredito que gerencia de demanda a cascata podem trabalhar juntos.
Na empresa onde trabalho esta tentando desenvolver isto,pois os desenvolvedores estão sendo requisitados por algo que o suporte mesmo poderia resolver.
Flw