Curioso como ninguem mais usa cascata hoje em dia. Alias, nao sei porque se fala tanto de processo em cascata se ninguem usa.
Diga pra nos entao, Fernando, qual processo voce usa.
E Marcos é possivel sim um software 100% livre de bugs, ou voce acha que software para a industria medica tem bugs pra todo lado? Software militares? entre muitos exemplos.
Ora, imaginem se esses pensamentos dos gerentes fosse tambem usado na engenharia.
O bug esta no pensamento arcaico da maioria dos gerentes, esta nesse processo pesado que nao funciona, nem nunca funcionou.
Talvez ainda nao seja, mas é um grande passo nesse caminho. Quem nao conseguiu diminuir sensivelmente o numero de bugs com agile, é porque esta usando de forma errada, ou seja embora pense que é, nao é agile.
[quote]E Marcos é possivel sim um software 100% livre de bugs, ou voce acha que software para a industria medica tem bugs pra todo lado? Software militares? entre muitos exemplos.
Modelo Iterativo e Incremental[/quote]
Estes softwares têm poucos bugs, mas nenhum é 100% confiável. Eles falham e vidas se perdem por conta disso. 100% não é tecnicamente possível, independente da metodologia ou competência profissional.
Veja alguns exemplos de sistemas que falham (sistemas deste nível):
Já respondi também a você que utilizo testes em todo o ciclo de vida de desenvolvimento: desde as verificações de especificação a testes de sistema em homologação interna e externa. Uso iteração e incremento sim. Entrego pequenas partes, buscando algumas vantagens que o modelo cascata não traz. No contrato que estou hoje, nçao vejo vantagem em aplicar gestão ágil e abidicar de documentações tradicionais. Mas isso é ponto de vista meu específico para este contrato, tenho minhas razões.
O que eu conheço de gestões ágeis é interessante, pretendo aprender mais e voltar a usar quando considerar que será viável. Não sou leigo como você classificou, muito menos especialista. Mas a metodologia não tem relação com sistema 100% livres de bugs. Acho que você está usando uma justificativa incoerente, por estar muito satisfeito com ela atualmente e resistente a outros pontos de vista.
[quote=fernando.palma][quote]E Marcos é possivel sim um software 100% livre de bugs, ou voce acha que software para a industria medica tem bugs pra todo lado? Software militares? entre muitos exemplos.
Modelo Iterativo e Incremental[/quote]
Estes softwares têm poucos bugs, mas nenhum é 100% confiável. Eles falham e vidas se perdem por conta disso. 100% não é tecnicamente possível, independente da metodologia ou competência profissional.
Veja alguns exemplos de sistemas que falham (sistemas deste nível):
[/quote]
Exemplos de falhas nesse tipo de sistema nao diz que eles nao sao a prova de bugs, eles tem que ser a prova de bugs.
Isso voce ja disse, nao disse qual, nem como.
Voce consegue enumarar as razoes pra nao utilizar metodologias ageis no seu atual projeto?
É evidente que tem, por favor, essa uma afirmacao sem cabimento. A metodologia que voce usa influencia muito no resultado.
[quote]
Já respondi também a você que utilizo testes em todo o ciclo de vida de desenvolvimento: desde as verificações de especificação a testes de sistema em homologação interna e externa. Uso iteração e incremento sim.
Isso voce ja disse, nao disse qual, nem como. [/quote]
Iterativo.
[quote]Entrego pequenas partes, buscando algumas vantagens que o modelo cascata não traz. No contrato que estou hoje, nçao vejo vantagem em aplicar gestão ágil e abidicar de documentações tradicionais. Mas isso é ponto de vista meu específico para este contrato, tenho minhas razões.
Voce consegue enumarar as razoes pra nao utilizar metodologias ageis no seu atual projeto? [/quote]
Quando você toma decisões em certos contratos muitas coisas são levadas em consideração. Não da para sair mudando tudo s´´o porque eu tenho idéias que considero boas. Não estou falando de gestão ágil, estou generalizando.
[quote]
Mas a metodologia não tem relação com sistema 100% livres de bugs. Acho que você está usando uma justificativa incoerente, por estar muito satisfeito com ela atualmente e resistente a outros pontos de vista.
A diferença do cascata para um iterativo é que em cascata você corrige no final, levando a um custo maior de correção. Mas, em ambas betodologias, a mesma quantidade de erros é corrigida.
O que garante corrigir mais bugs é a automação, competência, expertise no assunto. Não a metodologia: agil ou cascata. Gestão ágil não corrige mais, simplesmente corrige de uma maneira mais eficiente e menos custosa.
quer ver como isso é mentira ?
Como sua equipa automatiza testes ? Vc tem testes unitários ? Vc usa um servidor de integração ? Qual é a politica de prioridade de correção de testes vs implementações de outra especie ? Quanto demora um ciclo de testes feito na estação do desenvolvedor ? e no servidor de continuidade ? vc usa o maven ou ant para explicitar o empacotamento ? Vc tem servidor de desenvolviemento ? e de homologação ? e de ensaio ? Quantos bugs a sua equipa corrigiu entre o primeiro e vigésimo dia do projeto ?
Humm… isso quer dizer que o seu processo é baseado nele.
:lol: :lol: :lol: só para vc entender o que passa pela nossa cabeça quando um gerente diz isso:
“Eu sei nada de desenvolvimento, então tenho que mostrar trabalho entegando um monte de documentos word que ninguem lê e só enchem linguiça, mas eu sou pago para isso mesmo” - não necessáriamente nestas palavras.
Sinceramente, o que vc conhece é zero, nada.
Não ha o que discutir. É sempre viável. Basta que vc saiba como e tenha vontade de usar!
quantas vezes vc já usou um processo ágil no seus projetos ? nunca ? então como sabe que não funciona melhor ?
10 vezes ? 2 vezes ? então porque vc demonstra não saber nada sobre processos ageis ? Das duas uma. ou vc nunca usou, ou vc não quer nunca usar.
Se é a segunda opção, boa sorte arranjando emprego daqui a 5 anos. Se é a primeira, tente usar nos seus proximos projetos (todos eles). A gente ajuda nas duvidas.
É obvio que tem. Mas exatamente porque não é óbvio para si é que vc é gerente.
Quando o seu superior descobrir o rio de dinheiro que está perdendo , ai vc mudará de opinião…
[quote]A diferença do cascata para um iterativo é que em cascata você corrige no final, levando a um custo maior de correção. Mas, em ambas betodologias, a mesma quantidade de erros é corrigida.
O que garante corrigir mais bugs é a automação, competência, expertise no assunto. Não a metodologia: agil ou cascata. Gestão ágil não corrige mais, simplesmente corrige de uma maneira mais eficiente e menos custosa. [/quote]
Nao, com TDD, por exemplo, muitos dos erros que fazem todo mundo ficar estressado, cliente ligando, gerente reclamando, programador pedindo a conta, NAO SAO introduzidos, por que existem testes para eles antes mesmo das funcionalidades deles serem escritas.
E outra, gestao agil é car…, nao existe gestao agil, existe desenvolvimento agil, ou voce participa dele ou nao. O Sergio esta coberto de razao quando diz que os gerentes de hoje estao com os dias contados. Ou se atualizam e acompanham os desenvolvedores ou tao fora.
Infelizmente agile é um processo que só acontece de baixo pra cima, só os desenvolvedores conseguem introduzir agilidade numa empresa. Ela nao vem de cima pra baixo.
Por isso discutir com um gerente sobre isso é pura perda de tempo, a nao ser que seja o seu gerente obviamente (e mesmo nesses casos é muito dificil).
[quote]
Nao, com TDD, por exemplo, muitos dos erros que fazem todo mundo ficar estressado, cliente ligando, gerente reclamando, programador pedindo a conta, NAO SAO introduzidos, por que existem testes para eles antes mesmo das funcionalidades deles serem escritas. [/quote]
Eu sei que a técnica evita erros, por implementar funções de testes antes do código. No meu tempo de analista de testes eu ja lia sobre Programação orientada a Testes, isso foi em 2006. Mas caso você não aplique TDD, irá ter mais custo para corrigir depois.
Portanto, você ganha na eficiência e não eficácia. Você corta o mal pela raiz, o que o waterfull não faz. Mas o waterfull também chega com um sistema bonitinho, redondinho com poucos erros no final, só que em mais tempo e maior custo.
Gestão Ágil é uma expressão utilizada. Não precisa de tanta resistência ao ler a palavra Gestão. Calma.
Cara, acho que este tipo de afirmação pode soar meio “prepotente” entene?. Parece um desafio entre profissionais: um querendo engolir o outro. Em uma equipe, precisamos com skills diferenciados sim.
Existem pessoas que dizem que os programadores estão com dias contados, porque código cada vez mais é gerado automaticamente. Eu acho bobagem também e tenho contra-argumentos pra este tipo de afirmação. Eu acredito que dificilmente um profissional qualificado está com dia contato, independente de sua área de atuação. Não é impossível, mas é dificil que ele seja eliminado, caso tenha competência e conhecimento constantemente atualizado.
Concordo com você com o fato que devemos estar atualiazados. Eu não estou aqui para perder tempo, estou acompanhando, conversando com profissionais que - talvez - tenham pensamentos parecidos com os das equipes em que trabalho(lharei). Li o material que você me passou, foi legal.
E já que tocou no assunto: acredito também que os profissionais pagos cada vez mais para pensar em vez de operacionalizar.Independente de ser programador ou diretor.
E não, administração não será facilmente anulada, porque é mais complexo de automatizar. Toda atividade precisa ser organizada, medida, para obter informações que comprovem se o processo está sendo eficaz, eficiente, lucrativo.
Toda equipe precisa de um facilitador, que interaja com outras equipes. Até em um prédio existe um síndico. Em uma manifestação, um líder.
Precisamos de um responsável por uma equipe, um setor, etc. Alguém que reprte e responda.
Nas atividades que envolvem processos de construção (TI ou não TI), tais como engenharia, é preciso de um profissional com expertise em medir, controlar, reportar resultados, tomar decisões rapidas e eficazes e chegar à conclusão de se e o quanto a equipe está encontrando resultados. Sim, os indicadores, números e gráficos não vão acabar facilmente. Acredite, por mais absurdo que te pareça, eles têm utilidade! .
sem querer ofender, você deveria ler algum livro sobre Scrum e Lean, lhe ajudariam muito como gerente.
Concordo também com o que foi dito sobre agile vir de baixo para cima, porém já vi gerentes darem o pontapé inicial. Quem sabe você se torna um deles e começa a escrever artigos sobre o assunto voltado para empresários?
Ser ágil é mais do que utilizar uma metodologia ou técnica, é uma mudança de comportamento dos profissionais.
[quote]Concordo também com o que foi dito sobre agile vir de baixo para cima, porém já vi gerentes darem o pontapé inicial. Quem sabe você se torna um deles e começa a escrever artigos sobre o assunto voltado para empresários?
Ser ágil é mais do que utilizar uma metodologia ou técnica, é uma mudança de comportamento dos profissionais. [/quote]
Ok, sugestão aceita. Estava apenas abordando alguns pontos, mas me interesso sim.
A certificação SCRUM está no meu calendário entre as que almejo. O papo com vocês é ótimo.
Gestão Ágil é uma expressão utilizada. Não precisa de tanta resistência ao ler a palavra Gestão. Calma.
[/quote]
Nao tenho nada contra gestao, tenho e muito contra a forma burocratica utilizada por muitos que se dizem gestores e nao tem a menor ideia do que estao fazendo.
Nao, nao eh um desafio entre profissionais. Nao é uma questao de “eu sou importante, voce nao é”. Um bom gerente é importante, mas o que é um bom gerente é muito diferente do que se tem hoje por ai. A principal funcao de um gerente é administrar a equipe, nao o produto. Tem que saber cortar as asas de alguns desnvolvedores quando algo comeca a fazer mal a equipe, tem que incentivar o desenvolvedor quando ele precisa. Tem que administrar a briga de ego dentro da equipe. Tem que saber identificar a hora certa de fazer tudo isso.
Tem que saber se impor e dar a palavra final ao cliente quanto aos prazos estipulados pelos desenvolvedores, tem que saber como e o que cobrar da equipe, mas sem forçar demais e fazer a equipe trabalhar sob estress, porque programador sob pressao é bug na certa. É funcao do gerente saber se um desenvolvedor esta sobrecarregado e porque, identificar os que rendem menos, descobrir porque e fazê-lo render mais (sem chicotada, nem ameaca de demissao obviamente).
O que não é função do gerente: Fazer planilhas e graficos pra mostrar a diretoria o andamento do projeto. Se o andamento do projeto nao pode ser visto em funcionamento tem algo errado. Ficar trancado numa sala mandando conversando com a equipe por email ou skipes da vida, o gerente tem que estar proximo a equipe, do contrario nao vai saber se eles precisam de algo, nao vai saber se tem dificuldades, nao vai saber se estao insatisfeitos.
Não é funcao do gerente de modo algum tomar decisoes tecnica, essa é funcao da equipe e somente dela. A nao ser evidentemente que o gerente tenha conhecimento tecnico. Mas conhecimento tecnico profundo, que tenha vivencia na parte tecnica, nao experiencia de artigos aqui e ali. Alias desenvolvimento de software, se nao a unica, é uma das poucas areas em que é frequente pessoas sem o menor conhecimento tecnico tomarem decisoes tecnicas. E isso é invariavelmente desastroso.
Bom isso é uma utopia dos empresarios, mas nao vai acontecer nunca. Nao existe criar software sem conhecer logica e conhecendo logica profundamente voce se torna programador. Entao antes de poder usar as ferramentas dos sonhos, em que pensa software de um lado e sai software do outro, vao precisar aprender a pensar com logica, logo serao programadores. Bom, eu pelo menos sonho com uma ferramenta dessas, mas duvido que va ser tao util a quem a tanto deseja hoje.
Pensar, eu penso até no boteco e nem por isso ninguem me paga por esses pensamentos. Os profissionais sao pagos para fazerem as coisas funcionarem, nao pra pensar. Se voce é criativo e acha boas maneiras de fazer as coisas funcionarem, ótimo. Se nao seus pensamentos nao servem pra nada.
[quote] E não, administração não será facilmente anulada, porque é mais complexo de automatizar. Toda atividade precisa ser organizada, medida, para obter informações que comprovem se o processo está sendo eficaz, eficiente, lucrativo.
Toda equipe precisa de um facilitador, que interaja com outras equipes. Até em um prédio existe um síndico. Em uma manifestação, um líder.
Precisamos de um responsável por uma equipe, um setor, etc. Alguém que reprte e responda.
Nas atividades que envolvem processos de construção (TI ou não TI), tais como engenharia, é preciso de um profissional com expertise em medir, controlar, reportar resultados, tomar decisões rapidas e eficazes e chegar à conclusão de se e o quanto a equipe está encontrando resultados. Sim, os indicadores, números e gráficos não vão acabar facilmente. Acredite, por mais absurdo que te pareça, eles têm utilidade! .
Tenho que admitir, este fórum é divertido :)[/quote]
Pois é, eu concordo que é preciso lideranca, expus acima como acho que deve ser um gerente.
No mais, seu discurso é de muita retorica, clichês, frases feitas e nada de profundidade, nada consistente. Voce nao traz exemplos, nao mostra suas “estatisticas”, nao cita onde baseia suas fontes, em quais experiencias, quais metodologias utiliza. Nao nos da detalhes que tragam clareza a suas ideias.
Tudo retorica, aquele monte de frases que a gente ouve todo dia em propagandas de consultorias administrativas. De pratico, de conclusivo? Nada.
Gestão Ágil é uma expressão utilizada. Não precisa de tanta resistência ao ler a palavra Gestão. Calma.[/quote]
Nao tenho nada contra gestao, tenho e muito contra a forma burocratica utilizada por muitos que se dizem gestores e nao tem a menor ideia do que estao fazendo. [/quote]
Blz…
ok, massa. O lider é um facilitador.
[quote]
Tem que saber se impor e dar a palavra final ao cliente quanto aos prazos estipulados pelos desenvolvedores, tem que saber como e o que cobrar da equipe, mas sem forçar demais e fazer a equipe trabalhar sob estress, porque programador sob pressao é bug na certa. É funcao do gerente saber se um desenvolvedor esta sobrecarregado e porque, identificar os que rendem menos, descobrir porque e fazê-lo render mais (sem chicotada, nem ameaca de demissao obviamente). [/quote]
Ou seja: solucionador de probelmas. facilitar a vida da equipe e do cliente.
Não concordo com a primeira parte, concordo com a segunda. indicadores são importantes. Se você não mede, você não pode controlar (já sei, vc vai responder que é frase feita, mas é isso)
To contigo também nesse parágrafo. Eu não corrijo nem tomo decisão em cima de uma atividade que eu nunca fiz. Acho incoerente. Eu delego.
Bom isso é uma utopia dos empresarios, mas nao vai acontecer nunca. Nao existe criar software sem conhecer logica e conhecendo logica profundamente voce se torna programador. Entao antes de poder usar as ferramentas dos sonhos, em que pensa software de um lado e sai software do outro, vao precisar aprender a pensar com logica, logo serao programadores. Bom, eu pelo menos sonho com uma ferramenta dessas, mas duvido que va ser tao util a quem a tanto deseja hoje.
Eu digo mais que isso: sempre existirá um gap onde os desenvolvedores deverão interpretar o código. além do facto de que as ferramentas produzidas hoje ainda durarão anos para entrar em extinção. Como eu te disse lá em cima, eu tenho argumentso para discordar também. O qu eeu acho que está mudando é o perfil do desenvolvedor.
Um amigo meu até me disse outro dia: criatividade é coisa de pobre. Você tem que pensar e saber aplicar. Mais que isso: aplicar rápido, antes que seja tarde. Mas nós somos exigidos cada vez mais a pensar em vez de trabalhos mecênicos (já se foi a era industrial)
[quote]
No mais, seu discurso é de muita retorica, clichês, frases feitas e nada de profundidade, nada consistente. Voce nao traz exemplos, nao mostra suas “estatisticas”, nao cita onde baseia suas fontes, em quais experiencias, quais metodologias utiliza. Nao nos da detalhes que tragam clareza a suas ideias. [/quote]
cara, fraes feitas tb vejo quando vc defende desenvolvimento ágil (ta vendo, não usei a palavra gestão).
Eu venho aqui no fórum responder rapidamente e olhe que eu não costmo escrever pouco. Se eu não utilizar frases resumidas que já tenho de cabeça, vou ter que parar pra escrever um artigo.
Isso não ficou claro para mim… Há anos atrás quando trabalhei em fabrica usei CMMI. Hoje gerencio projetos com base no PBMBOK, uso praticas de gestão do governo (meu projeto é estadual) e modelo de desenvolvimento bem iterativo. Uso alguns conceitos de A ISO/IEC 12207 no processo que desenvolvemos recentemente de desenvolvimento. Entretanto, no modelo que trabalho hoje, não tenho uma estrutura de desenvolvimento estritamente CMMI ou SCRUM. Não uso um padrão de mercado, uso o meu padrão. Você já trabalhou alcado em cliente do estado? Não se se foi bem essa sua pergunta…
[quote]As diferenças entre metodologia moderna e tradicional são :
Respeite valores acima de tudo.
A unica coisa que temos a certeza (absoluta) em relação ao software é que ele evoluirá. [/quote]
Eu gostaria de uma opinião dos membros da comunidade. Vocês acham que outros métodos e padrões vão contra a essas filosofias. Ou seja: não respeitam valores e não reconhecem que o softwrae evoluirá.
Não pergunto para causar polêmica. Apenas quero uma opinião sincera para ter noção do que todos pensam.
Já conhecia estas frases sobre metodologia ágil, sei que existem fundamentos como base para estas afirmações. Mesmo assim, gostaria de que participassem. Considero interessante o tema.
O problema é que a grande maioria das pessoas que ocupam o cargo de “gerente” não têm nenhum skill na área de desenvolvimento. Têm muitos na área de manter a sua posição e repassar culpa para a equipe de desenvolvedores e acatar os desejos do cliente mesmo contra os interesses do projeto, da companhia ou da equipe. Esse tipo de gerente está em via de extinção.
Ai é que você se engana. Pode ser complexo de automatizar mas é muito simples de eliminar.
Administração de projeto tradicional gera custos e delays (que geram custos) que as empresas espertas estão aprendendo a eliminar. A gordura de um projeto é causada pela existência da figura do gerente. E isto as empresas espertas estão aprendendo a enxugar.
Sim, mas não precisa ser pelo gerente. Equipas auto-gerenciadas é a forma mais barata de alcançar os mesmos resultados e até melhores.
É verdade que a equipa precisa de um facilitador. Mas repare : não precisa que o facilitador seja hierarquicamente superior à equipe. É aqui que a porca torce o rabo. O Gerente pode assumir o papel de facilitator (Scrum Master) ou de Product Owner fácilmente , mas não os dois (como é comum hoje em dia). O problema é que os gerentes não suportam a ideia de serem rebaixados para o mesmo nivel dos desenvolvedores sem terem sobre eles poderes de comando.
Nas metodologias modernas existe cooperação - como numa colmeia - e não comando - como no exercito.
Esta é outra coisa que os gerentes tradicionais não entendem. A equipe é responsável por si mesma. Ela responde em unissono.
Não existe porta-voz. Existe respeito. coisas como codigo partilhado, e pair programing não entram na cabeça dos gerentes tradicionais, mas são a forma de responsabilizar todos os membros da equipe pelo que é produzido. Cada papel da equipe é responsável pela parte que lhe cabe. sem desculpas. Se a pessoa tem algum problema é discutido com o Facilitador e a partir dai a responsabilidade é dele.
Só que produzir software não é um processo de construção. Portanto nada disso se aplica.
Enquanto vc não entender isto, vc não conseguirá entender as metodologias modernas.
é preciso que algum membro deste forum tenha vivido isolado do planeta nos ultimos 10 anos ou não tenha experiencia com desenvolvimento, para acreditar que alguma coisa do que vc está dizendo faze sequer sentido, quanto mais usá-lo para algum fim util. As metodologias tradicionais estão mortas. Quem não enxergar isso morrerá com elas.
Implatar Metologias modernas requer uma mudança de cultura, de paradigma, a aceitação de valores e axiomas diferentes daqueles da metodologia tradicional. Mudar de paradigma é extremanente dificil, portanto utilizar metodologias ageis não é possivel do dia para a noite e não é facíl.
Essa desculpa de seguir o CMMI não cola. CMMI não diz como vc deve chegar nos niveis,Ele apenas diz quais são os niveis.
por exemplo: se o processo é gerenciado, temos um certo nivel. Mas não difinitivo o que significa "gerenciado’.
Gerenciado não significa ter um Gerente. Isto é um erro grave. Com Scrum vc tb tem um processo gerenciado e com mais e melhores indicativos que qualquer outra estrutura de gerenciameno.
O problema de trabalhar para o governo é outras historia. As pessoas no governo que pedem esses trabalhos têm a mesma visão obtusa que os gerentes tradicionais e por isso eles pedem garantias tradicionais.
quando o mundo do sfotware for agil os governos tb serão (é uma questão de tempo até que esses cargos seja ocupados por pessoas que pensam agil)
“Passar a culpa para desenvolvedores” é algo que deve ser banido. 90% dos casos a culpa é da gestão.
Eu entendo seu ponto, mas não é bem assim. Difícil sobreviver sem este papel. Só esperando para ver.
[quote]Sim, mas não precisa ser pelo gerente. Equipas auto-gerenciadas é a forma mais barata de alcançar os mesmos resultados e até melhores.
[/quote]
Ok, temos opiniões diferentes. Eu não sobrevivo sem um superior a quem passar certas decisões. Há não ser que eu seja sócio único da empresa. Eu posso até mudar de opinião um dia, não descarto a possibilidade.
Sim, até ai tudo bem. É como os modelos de gestão japonesas de cooperação, já abordavam menos hierarquia, com esta metáfora da colmeia . Isso já tem anos.
[quote]Esta é outra coisa que os gerentes tradicionais não entendem. A equipe é responsável por si mesma. Ela responde em unissono.
Não existe porta-voz. Existe respeito. coisas como codigo partilhado, e pair programing não entram na cabeça dos gerentes tradicionais, mas são a forma de responsabilizar todos os membros da equipe pelo que é produzido. Cada papel da equipe é responsável pela parte que lhe cabe. sem desculpas. Se a pessoa tem algum problema é discutido com o Facilitador e a partir dai a responsabilidade é dele. [/quote]
Bom, eu tenho que viver mas na prática para entender como funciona. Leio a respeito e vejo estes ponto, mas entendo que certas atividades exigem um repsosável para que funcione.
Única vez que usei métodos ágeis não apliquei com a experiência que você e outros demonstraram ter aqui. tenho que ver de perto para entender melhor como iso dá certo.
Eu acredito que você está com um pouco de entusiasmo com o tema. Práticas novas surgem todos os dias, quando estudamos e praticamos tendemos a não enxergar outros pontos de vista. O entusiasmo.
Me responda uma pergunta: quais são as desvantagens das metodologias ágeis? Em que casos elas terão dificuldades de ser utilizadas?
[quote]Essa desculpa de seguir o CMMI não cola. CMMI não diz como vc deve chegar nos niveis,Ele apenas diz quais são os niveis.
por exemplo: se o processo é gerenciado, temos um certo nivel. Mas não difinitivo o que significa "gerenciado’.
Gerenciado não significa ter um Gerente. Isto é um erro grave. Com Scrum vc tb tem um processo gerenciado e com mais e melhores indicativos que qualquer outra estrutura de gerenciameno.
O problema de trabalhar para o governo é outras historia. As pessoas no governo que pedem esses trabalhos têm a mesma visão obtusa que os gerentes tradicionais e por isso eles pedem garantias tradicionais.
quando o mundo do sfotware for agil os governos tb serão (é uma questão de tempo até que esses cargos seja ocupados por pessoas que pensam agil)[/quote]
A Fábrica era nível 3. Era um pré-requisito dos softwares. Se o mundo se tornar software ágil, ótimo, trabalharemos assim em projetos de todos os tipos (se eu ainda estiver trabalhando com desenvolvimento de software. Mas como eu disse; cuidado com o entusiasmo (é meu ponto de vista)
As desvantagem são politicas. Agil não funciona dentro de uma cultura militar. Não funciona quando as pessoas não sabem se responsabilizar perante as outras. Quanto todo o mundo é mestre em “tirar o seu da reta” não funciona. quando a equipe não é realmente uma equipe mas um conjunto de pessoas, não funciona. quando não existe um responsável pelo produto, não funciona.
Quando não existe um facilitador - que seja uma pessoa diferente do responsavel pelo produto - não funciona. Quando os valores não são aceites no coração dos membros não funciona. Quando as pessoas envolvidas não entendem o que estão fazendo nem o pq, não funciona. Quando o cliente tem sempre razão, não funciona. Quando a documentação de ha 6 meses vale mais que a palavra do desenvolvedor, não funciona. Quando a equipa de desenvolvedor não se pode auto-gerenciar, não funciona.
quando alguém teima em cotar as coisas em horas-homem não funciona. Quando não se deixa os desenvolvedores desenvolverem, não funciona. Quando não se entende o que é um Story Point, Velocidade,Fator de Foco e a diferença entre Estoria e Tarefa não funciona.
A desvantagem principal é que existe uma mudança de paradigma que é complexa e difícil se as pessoas não estão preparadas, e o processo de implantação deixa bem claro quem está preparado e quem não está. Isso pode levar a diversos problemas politico-hierarquicos.
“Preparadas” significa podem acatar valores como respeito, abertura, comunicação, etc… Por exemplo, às vezes o cara quer usar Scrum, mas não quer publicar um burndown chart. Ou seja, ele não está sendo aberto, logo está fazendo reserva mental ao não acatar esse valor. Esta pessoa não está preparada para usar Scrum.
Então, quando as pessoas não estão preparadas a implantação de agil não cola e fica a impressão que a culpa é do agil, mas a culpa é na realidade das pessoas que não conseguem seguir valores simples como respeito e abertura, entre outros…
[quote=sergiotaborda][quote=fernando.palma]
Me responda uma pergunta: quais são as desvantagens das metodologias ágeis? Em que casos elas terão dificuldades de ser utilizadas?
[/quote]
As desvantagem são politicas. Agil não funciona dentro de uma cultura militar. Não funciona quando as pessoas não sabem se responsabilizar perante as outras. Quanto todo o mundo é mestre em “tirar o seu da reta” não funciona. quando a equipe não é realmente uma equipe mas um conjunto de pessoas, não funciona. quando não existe um responsável pelo produto, não funciona.
Quando não existe um facilitador - que seja uma pessoa diferente do responsavel pelo produto - não funciona. Quando os valores não são aceites no coração dos membros não funciona. Quando as pessoas envolvidas não entendem o que estão fazendo nem o pq, não funciona. Quando o cliente tem sempre razão, não funciona. Quando a documentação de ha 6 meses vale mais que a palavra do desenvolvedor, não funciona. Quando a equipa de desenvolvedor não se pode auto-gerenciar, não funciona.
quando alguém teima em cotar as coisas em horas-homem não funciona. Quando não se deixa os desenvolvedores desenvolverem, não funciona. Quando não se entende o que é um Story Point, Velocidade,Fator de Foco e a diferença entre Estoria e Tarefa não funciona.
a
A desvantagem principal é que existe uma mudança de paradigma que é complexa e difícil se as pessoas não estão preparadas, e o processo de implantação deixa bem claro quem está preparado e quem não está. Isso pode levar a diversos problemas politico-hierarquicos.
“Preparadas” significa podem acatar valores como respeito, abertura, comunicação, etc… Por exemplo, às vezes o cara quer usar Scrum, mas não quer publicar um burndown chart. Ou seja, ele não está sendo aberto, logo está fazendo reserva mental ao não acatar esse valor. Esta pessoa não está preparada para usar Scrum.
Então, quando as pessoas não estão preparadas a implantação de agil não cola e fica a impressão que a culpa é do agil, mas a culpa é na realidade das pessoas que não conseguem seguir valores simples como respeito e abertura, entre outros…[/quote]
Tem mais um ponto ai. Por que motivos vc quer ser agil?
Isso é uma boa pergunta: existem empresas que não querem. Existem empresas que dão MUITO certo sem ser agil e, quando tentam usar algo como Scrum, falha.
Eu vejo o seguinte: vc precisa responder rapido ao cliente? Se sim, agile é uma boa opção.
Imagine que vc esta desenvolvendo um sistema complexo e vc vai lançando releases de tempos em tempos com alguma funcionalidade suficiente e tem tempo de receber feedback do que o cliente usou e achou: é um bom passo para vc evitar de fazer aquela tela pq o cara de terno azul pediu mas que todo mundo sabe que é inutil, pois vc pode jogar com coisas realmente uteis e, quando chegar a hora de fazer o relatorio detalhado do nada ao lugar nenhum simplesmente não vale a pena investir mais no projeto.
Agora imagine um portal que oferece serviços específicos e, um dia, a concorrência lança um produto ANIMAL e INOVADOR: vc acha que vai fazer frente a isso tendo uma fase de levantamento de requisitos, uma fase de … , uma fase de desenvolvimento, uma fase de teste (e uma fase de demissões pq demorou mais do que o previsto)? Nesse caso a empresa tem que reagir rapido.
Mas como ela reage? Tem muitas formas, uma delas é lançar algo O MAIS RAPIDO POSSIVEL. Ah mas ai alguem diz ‘puxa, mas o css ta feio, tem um dropbox no lugar de um [buzzword da web 2.0], ta incompleto, não tem toda a experiência imersiva, etc’. Ok, nesse meio tempo alguem mais vai lançar alguma coisa e, quando vc perceber, só vc não seguiu o bonde e vc perdeu audiência. Numa situação dessas Agile é interessante, mas Agile intrincado na estratégia empresarial. Se eu preciso responder e trabalhar sem ficar preenchendo planilha que não serve pra nada ou juntar buzzwords para manter o meu trabalho, então eu preciso do anti-agile.
Agora se eu só quero trabalhar e, de repente, melhorar o meu processo, eu posso ver que caracteristicas do Agile me servem. De repente um Kamban para certas atividades pode ajudar, ou simplesmente trabalhar com iterações curtas e retrospectivas.
Em mais de um ano trabalhando com Scrumm eu aprendi muita coisa, principalmente comportamental: eu questiono e sou questionado pelas minhas decisões. Geralmente isso é benefico para o time e todos colaboram no trabalho de uma forma mais ativa. No fim do dia vc sente orgulho do que fez, até. E olha q antes eu trabalhava numa coisa q tentava aplicar esses conceitos bonitinhos de teste de software que, no fim das contas, só me deixava ocioso em varios momentos - não que isso seja ruim.