Isso só acontece se o Product Owner entender que deve ser feito assim.
Como se alguem fosse dar o aceite de um produto que não responde com a rapidez que lhe é cabida. Basta ver como a Lockheed Martin usou o Scrum.
[quote]Isso só acontece se o Product Owner entender que deve ser feito assim.
Como se alguem fosse dar o aceite de um produto que não responde com a rapidez que lhe é cabida. Basta ver como a Lockheed Martin usou o Scrum. [/quote]
Ok, legal. Vou dar uma olhada.
Se alguém mais do fórum quiser opinar sobre o assunto…
[quote=fernando.palma]Aqui em Salador conheci uma empresa que trabalhou em um projeto para software de controle de calderões em usinas. Se o sftware falhar, explode o calderão.
O software quando é entregue é uma vez só e tem que estar 100%. O que eu fico em dúvida (não tenho certeza) é de como realizar iteratividade neste caso?
Em ambos os exemplos, os produtores do software deverão planejar e garantir que o software funcione. A iteratividade pode não ser justificada, porque o “cliente” desse projeto não vai saber avaliar o artefato, você tem que ser o especialista em produzir o sistema confiável e entregá-lo. Entede?
No caso desta empresa que eu descrevi, se ela fizesse uma pequena entrega e pedisse uma avaliação, o cliente - a usina - provavelmente iria dizer: quem vai me dizer se está avaliado é você.
Nestes casos também a agilidade não e fator crítico e não existem funcionalidades, requisitos de usabilidade, etc, para serem avaliados. O software tem apenas uma fncionalidade: manter a temperatura.
[/quote]
Independente da complexidade do sistema, este possui módulos que podem ser entregues iterativamente.
Gosto de ressaltar que ser ágil não é utilizar xp ou scrum e sim a forma de pensar da equipe, sempre primando pela qualidade e possuindo acima de tudo o comprometimento e sinergia com o cliente, que em muitos casos não é possível, pois o cliente não está aberto a tal colaboração necessária.
Basicamente é seguir o manifesto ágil, independente da metodologia escolhida.
[quote]Gosto de ressaltar que ser ágil não é utilizar xp ou scrum e sim a forma de pensar da equipe, sempre primando pela qualidade e possuindo acima de tudo o comprometimento e sinergia com o cliente, que em muitos casos não é possível, pois o cliente não está aberto a tal colaboração necessária.
Realmente essas colaborações para o tema estão mais coerentes para mim, fazem mais sentido. Começo a entender melhro o ponto de vista.
Eu acho que é simplificar um problema. A partir do momento que o custo da release torna-se extremamente caro, o ágil começa a perder o sentido.
Já vou deixando claro que sou completamente à favor do desenvolvimento ágil. Mas já trabalhei na indústria de hardware, e sei que alguns sistemas tem custos de manutenção astronômica. Mesmo sendo software só usado por pessoal de campo. E, nesses casos, justificava sim um ciclo mais pesado, com mais documentações e fases mais longas e burocráticas.
Só para complementar. Não significa que o desenvolvimento “não ágil” seja totalmente em cascata. Waterfall completo é algo que não existe há muitos anos, embora a literatura ágil dê a entender o contrário (vide o livro de UML e padrões do Craig Larmann).
Muitas técnicas que surgiram no ágil também são aplicadas à outros ciclos de desenvolvimento. Não creio que hoje exista uma empresa séria em desenvolvimento não-ágil que abra mão de testes unitários, por exemplo. Ou faça ciclos de desenvolvimento maiores que do dois meses (sendo que dois meses é um ciclo já considerado longo, mesmo por elas mesmas).
As scrums, que surgiram no processo de fabricação automobilistica (e que está bem longe de ser ágil como o software) foram primeiro aplicadas no RUP, por exemplo.
Só não concordo quando começam a defender qualquer tipo de desenvolvimento como a única alternativa. Como ressaltei num post em que defendi o singleton, construir software é, como todo projeto de qualquer coisa, escolher entre diversos trade-offs. Para tudo, ganha-se de um lado, perde-se de outro.
O importante para o desenvolvedor é saber reconhecer em cada processo ou técnica de programação utilizado seus pontos fortes e fracos. A partir do momento que você torna evangelista “demais” de uma técnica, corre-se o risco de estar também se tornando míope, um cuidado que todos nós devemos evitar.
è, é isso ai. Eu gostei do tópico para conhecer mais discursos de quem trabalhou na pratica mais vezes com desenvolvimento ágil. Achei ótimo.
Eu tenho minha área de especilização também, mas sei que o tema qual sou especializado também não é perfeito e não se adpata em qualquer caso (não é desenvolvimento), quem quiser conhecer: http://gsti.blogspot.com
Como Marcos disse, para tudo que fazemos, devemos mensurar quais são os objetivos e sermos sensatos.
Obrigado pela colaboração de todos!
Mas seria posível? Este projeto exige um planejamento macho. O projeto dura muito mais do que o ciclo de desenvolvimento.
Outrs pontos:
-
Este é um tipo de software que não evului muito, quando for entregue é aquilo mesmo.
-
O fator agilidade aqui não conta muito, a variável de sucesso aqui é 99% eficácia (cumprir o objetivo, senão a nave explode)
-
Não da pra fazer pequenas entregas pro cliente testar, da?
-
A especificação será revisada mil vezes. Não é só desenvolvimento de código. O TDD não resolve tudo.
-
[/quote]
[quote=fernando.palma]Aqui em Salador conheci uma empresa que trabalhou em um projeto para software de controle de calderões em usinas. Se o sftware falhar, explode o calderão.
O software quando é entregue é uma vez só e tem que estar 100%. O que eu fico em dúvida (não tenho certeza) é de como realizar iteratividade neste caso?
[/quote]
Acho que vcs não entenderam. Agil se aplica ao desenvolvimento. Ou seja, enquanto o software está sendo feito.
O software está sendo feito até à entrega do ultimo release! O numero de releases é planejado com antecedência.
O projeto pode ter apenas um release como nesse seu exemplo, nos da NASA, de hardware,firmware , etc…
Nada disto impossibilita o processo agil porque ele não se preocupa com a forma /uso do software e sim com o processo de como chegar na entrega final.
O processo agil sugere (o scrum exige) que no meio tempo demos sejam apresentadas. Isso é independente do meio final onde o software irá rodar.
Em um release podem haver quantos sprints vc quiser (ou forem matemáticamente possiveis). Por exemplo,um software de controle de caldeirão deve ter alguma parte que é o controlador (critico) e uma parte de apoio (telas, cadastros etc) VC pode serparar os dois e ter dois releases facilmente.
Quando vc pensa agil sempre existe uma forma e não depende do tipo de projeto. Lembre-se que agil foi introduzido no mundo dos fabricantes de automoveis.
Isso é simplesmente errado. A iteratividade é ainda mais importante quanto mais o projeto tem riscos. O risco do caldeirão explodir é muito grande para ser deixado num processo não iterativo (aka waterfall).
Isto é inaceitável. O Cliente sempre tem que se responsabilizar pela qualidade do que recebe. quando vc compra um carro um uma casa vc não faz vistoria ? confia no vendedor ? Não. software não é diferente.
Se o cliente não sabe, não pode ou não quer ter essa responsabilidade contrate uma terceira empresa. É mais caro ? É. Problema dele por não querer trabalhar.
Lol, isso o termostato tb faz. Concerteza tem mais coisa nessa salada.
Vc está dando uma versão minimalista dos requisitos. Mas mesmo que o sistema tenha apenas 1 requisito ele rápidamente se desdobra em um monte de coisas que os desenvolvedores têm que fazer e é ai que entra a agilidade. Não no levantamento de requisitos
Aquele ciclo que vemos por ai de Levante Requisitos -> produz -> entrega -> Levanta Requisitos - produz -> entrega não é correto. Isso não é agil. Isso é amador. E dá a falsa ideia que ser agil é levantar requisitos aos soluços. Nada disso.
O levantamento de requisitos sempre é levantado no inicio antes do desenvolvimento começar. É dai que são gerados back ogs, estimativas, prazos, custos, etc… é dai que o projeto é planejado. Depois começa o desenvolvimento. A diferença é que em agil é sabido, entendido e está previsto que esses requisitos mudem. O fato deles mudarem não altera o projeto! É esta a grande diferença , o pulo do gato, que permite tem um projeto fixo em um mundo de requisitos voláteis.
[quote]Acho que vcs não entenderam. Agil se aplica ao desenvolvimento. Ou seja, enquanto o software está sendo feito.
O software está sendo feito até à entrega do ultimo release! O numero de releases é planejado com antecedência.
O projeto pode ter apenas um release como nesse seu exemplo, nos da NASA, de hardware,firmware , etc…
Nada disto impossibilita o processo agil porque ele não se preocupa com a forma /uso do software e sim com o processo de como chegar na entrega final.
O processo agil sugere (o scrum exige) que no meio tempo demos sejam apresentadas. Isso é independente do meio final onde o software irá rodar.
Em um release podem haver quantos sprints vc quiser (ou forem matemáticamente possiveis). Por exemplo,um software de controle de caldeirão deve ter alguma parte que é o controlador (critico) e uma parte de apoio (telas, cadastros etc) VC pode serparar os dois e ter dois releases facilmente.
Quando vc pensa agil sempre existe uma forma e não depende do tipo de projeto. Lembre-se que agil foi introduzido no mundo dos fabricantes de automoveis. [/quote]
Ok! Valeu.
[quote]Lol, isso o termostato tb faz. Concerteza tem mais coisa nessa salada.
Vc está dando uma versão minimalista dos requisitos. Mas mesmo que o sistema tenha apenas 1 requisito ele rápidamente se desdobra em um monte de coisas que os desenvolvedores têm que fazer e é ai que entra a agilidade. Não no levantamento de requisitos [/quote]
É, ode ser, eunão participei só conheci os cara. Mas o sistema por mais que tenha alguns requisitos se desdobrando, será de funcionalidade minimista, usabilidade que tente a zero. Os requesitos não funcionais são: é segugarnça, confiabilidade, sustentabilidade e resiliência. A evolução pode existir mais será bem menor que os software que nós costumamos produzir (evolução quase exponencial).
Concordo com tudo. Muita coisa pregada no Manifesto Ágil não é novidade, mas uma boa prática conhecida. E tem muita gente que fica babando ovo pro Agil como e defendendo Scrum como a bala de prata pra todos os problemas.
Como você disse, até parece que quem não usa agil é 100% waterfall e quem usa é 100% eficiência.
Como todo processo empírico, o melhor é conhecer várias práticas e saber quando aplicá-las. Senão a discussão nunca vai terminar e pra cada exemplo de sucesso/fracasso alguém vai achar um contra-exemplo de fracasso/sucesso.[/quote]
A discussão não vai acabar enquanto as pessoas não entenderem o que significa Agilidade. E isso implica em desmistificar várias miss-conceptions comuns e populares que levam as pessoas a não consideram agil nos seus projetos.
Quem não usa agil pode até não ser waterfall ( não acredito nisso , mas ok…) mas concerteza não é tão eficiente como com agil.
Coloque uma equipa RUP tradicional e uma agil fazendo o mesmo software. Enquanto a primeira está fazendo um monte de boneco a segunda já tem algo que corre e pode ser demonstrado, avaliado pelo cliente : aka feedback. Com o feedback começando mais cedo, ha menos “erros de especificação” e com isso mais eficiente porque o desenvolvedor não fica enchendo linguiça enquanto outros fazem bonecos. Meça o fator de foco dos membros das equipas nos dois modelos. Asseguro-lhe que o de agil será maior. Isto significa que o software são logo e sem enrolação. Sem aquele papo de estimar 60 hora um trabalho de 10 para ficar 50 na boa vida. Se colocar pair-programing a diferença é maior ainda.
Agil de adqua a todos os projetos de software independente de localização, tamanho ou objetivos do projeto. a razão é simples :
Agil não é uma metodologia, é uma forma de pensar. Uma melhor forma de pensar que respeita os intervenientes é sim uma bala de prata para matar os mercenários parasitas que existem por ai construindo software ruim e cobrando caro: verdadeiros charalães vendedores da banha-da-cobra. Pode haver uma melhor no futuro, mas agora, esta é a que temos para nos defender.
Se é uma forma de pensar eu acredito, aliás acho que é sim uma forma de compartilhar o conhecimento sem a governança de uma gerencia de Marketing aliada à PMI, CMMI 1, 2, 3, 4, 5, 6 etc… PMBOK´s e vendor lo lo lo, "é sim todos na responsabilidade do sucesso "
Eu costumo ter o mesmo ponto de vista de Marcos. Falei sobre entusiasmo algumas vezes aqui. Estou achando ótimo conhecer pessoas que trabalham na prática com SRCUm e XP. Mas nada é maravilhoso e vai mudar o mundo.
Trabalho com implantação de processos baseado em práticas da ITIL. Me especializei, fui para mais alta das certificações, ensino e faço consultoria no assunto. Muitas pessoas me procuram por conta desta especialização. Mesmo assim, não sou radical ou entusiasta, si bem ponderar, saber quando usar ou não as práticas e quais das práticas no momento certo.
[quote=fernando.palma]
Trabalho com implantação de processos baseado em práticas da ITIL. Me especializei, fui para mais alta das certificações, ensino e faço consultoria no assunto. Muitas pessoas me procuram por conta desta especialização. Mesmo assim, não sou radical ou entusiasta, si bem ponderar, saber quando usar ou não as práticas e quais das práticas no momento certo. [/quote]
Existe uma ciência que entende-se hoje como produção de software, algo que está ao domínio de linguagens de programação e dela e você faz o deployment soluções de frameWorks e extrair documentação.Os requisitos de sistemas são interações por uma colaboração de equipe gerenciadas por pequenas historias junto ao cliente que assina os contratos e aprovações, trabalhar com Ágil é uma cultura orientada a mudanças e inovações.
[quote=marcosalex][quote=sergiotaborda]
Coloque uma equipa RUP tradicional e uma agil fazendo o mesmo software. Enquanto a primeira está fazendo um monte de boneco a segunda já tem algo que corre e pode ser demonstrado, avaliado pelo cliente : aka feedback. Com o feedback começando mais cedo, ha menos “erros de especificação” e com isso mais eficiente porque o desenvolvedor não fica enchendo linguiça enquanto outros fazem bonecos. …
[/quote]
Não foi o Manifesto ágil que inventou entregas parcias e planejamento em ondas sucessivas, nem a coleta de feedback.
[/quote]
Ninguem está dizendo que foi. Isso é totalmente irrelevante. Processos iterativos até o RUP tem. A questão é que ninguém segue! Na maioria dos casos RUP é usado como desculpa para um processo waterfall.
Como disse, agilidade é uma forma de pensar. Se vc pensa agil vc pode ser agil até com RUP.
Fala sério - quem acha que os métodos tradicionais - que comprovadamente são uma merda - têm alguma change contra os ágeis ?
Veja o exemplo da microsoft e do google : qual vc vê conduzir agil ? e qual vale mais no mercado ?
É uma questão de tempo (pouco) que os empresário se atenham ao fato que emrpesas ageis rendem mais. Simple economics. É o dinheiro que move o mundo e não a filosofia. Ágil tem simplesmente melhor custo/beneficio sem truques.
Além disso , programadores profissionais que estão cansados de ser tratados como peões num sistema feudal de gerencia estão procurando ambientes melhores e esses ambientes na grande maioria daz vezes seguem agil.
Agíl não é moda. É o padrão de fato. Já que em 50 anos de dev de software nada conseguiu ser tão consistente.
Pois é, eu tenho o mesmo ponto de vista, aparentemente radical, que o Sergio.
Nao sei quanto aos casos que postou o Vinigodoy sobre softwares embarcados e tal, porque nunca trabalhei com esse tipo de desenvolvimento. Mas, exceto pelo release incremental, nao vejo porque nao se pode usar ageis. Mas enfim, como nunca vivenciei…
Quanto ao entusiasmo, digo que nao é entusiasmo, é a diferenca entre funcionar e nao funcionar. Quantas vezes voces usaram as metodologias tradicionais e entregaram o projeto com atraso? Se todo mundo responder sinceramente, é mais facil contar as vezes em que entregaram dentro do prazo, se é que alguma vez entregaram no prazo.
Falar em pros e contras dos metodos tradicionais? Eu nao consigo ver pros, nao os encontro. Existem sim, ponto que ainda estao fracos nas ageis, pelo menos pontos em que tivemos dificuldade (como integracao dos trabalhos de mais de uma equipe, determinar as fronteiras). Com certeza existem outros pontos fracos, mas os pontos fortes sao muitos.
Em pouco tempo as empresas irao perceber o quanto de dinheiro estao perdendo com esse blablabla, e terao que se tornar ageis.
[quote=sergiotaborda]
Agíl não é moda. É o padrão de fato. Já que em 50 anos de dev de software nada conseguiu ser tão consistente.[/quote]
O Problema é que hoje Ágil é visto sim como as tecnologias que já são tendências algo como Rails que já é alvo do desenvolvimento orientado ao domínio, com técnicas avançadas de TDD, BDD , FDD e assim por diante, todavia não estão localizando o que é a essência ao Manifesto Ágil não estão se colocando de forma mais exata como você se colocou, uma nova forma de pensar,e ai fica essa desvirtualização entre a tecnologia e as boas pratica ao desenvolvimento.
[quote=YvGa]Pois é, eu tenho o mesmo ponto de vista, aparentemente radical, que o Sergio.
Nao sei quanto aos casos que postou o Vinigodoy sobre softwares embarcados e tal, porque nunca trabalhei com esse tipo de desenvolvimento. Mas, exceto pelo release incremental, nao vejo porque nao se pode usar ageis. Mas enfim, como nunca vivenciei…
Quanto ao entusiasmo, digo que nao é entusiasmo, é a diferenca entre funcionar e nao funcionar. Quantas vezes voces usaram as metodologias tradicionais e entregaram o projeto com atraso? Se todo mundo responder sinceramente, é mais facil contar as vezes em que entregaram dentro do prazo, se é que alguma vez entregaram no prazo.
Falar em pros e contras dos metodos tradicionais? Eu nao consigo ver pros, nao os encontro. Existem sim, ponto que ainda estao fracos nas ageis, pelo menos pontos em que tivemos dificuldade (como integracao dos trabalhos de mais de uma equipe, determinar as fronteiras). Com certeza existem outros pontos fracos, mas os pontos fortes sao muitos.
Em pouco tempo as empresas irao perceber o quanto de dinheiro estao perdendo com esse blablabla, e terao que se tornar ageis.[/quote]
se as empresas perdem dinheiro e continuam fazendo isso a muito tempo então tem duas alternativas, ou não aprenderam até hoje ou então alguém está ganhando dinheiro - consultorias, novos projetos, manutenções, etc, etc
[quote=JavaLivros][quote=sergiotaborda]
Agíl não é moda. É o padrão de fato. Já que em 50 anos de dev de software nada conseguiu ser tão consistente.[/quote]
O Problema é que hoje Ágil é visto sim como as tecnologias que já são tendências algo como Rails que já é alvo do desenvolvimento orientado ao domínio, com técnicas avançadas de TDD, BDD , FDD e assim por diante, todavia não estão localizando o que é a essência ao Manifesto Ágil não estão se colocando de forma mais exata como você se colocou, uma nova forma de pensar,e ai fica essa desvirtualização entre a tecnologia e as boas pratica ao desenvolvimento.
[/quote]
Quando eu comecei a ouvir falar de agil os autores passavam muito a ideia de que o processo agil é feito aos pedaços em que vc pega requisitos somente depois de ter implementados os anteriores e vai refatorando milhares de vezes entre iterações. Hoje, depois de ter lido livro e acompanhado o pensamento sobre agil por ai isso é claramente longe da verdade. O que quero dizer com isto é que tem muito “pregador” que não tem noção que as sua palavras , mal empregadas, podem detonar todo o futuro de um novo paradigma.
Evangelistas de verdade têm mais cuidado, mas tb são mais bitolados. Não enxergam as coisas além daquilo que leram na “biblia”.
É preciso na realidade se informar bem. Como em tudo na vida, antes de dizer que X é ruim.
E é preciso ter muito cuidado com pregadores de primeira maré que ficam bradando a 7 ventos coisas que não são totalmente reais.
[quote=André Fonseca]
se as empresas perdem dinheiro e continuam fazendo isso a muito tempo então tem duas alternativas, ou não aprenderam até hoje ou então alguém está ganhando dinheiro - consultorias, novos projetos, manutenções, etc, etc[/quote]
Repare, temos as empresas produtoras. Estas não estão perdendo dinheiro já que estão chupando ele das empresas “clientes”.
São as empresas clientes que têm que acordar e ver que estão levando um boa noite cinderela desde do principio do anos 90.