Ola pessoal, não tenho experiencia em metodologias Ageis, na verdade estou lendo um pouco mais sobre elas agora, li esse artigo na InfoQ:
http://www.infoq.com/br/news/2010/03/serious-flaws-agile-scrum
Gostaria de saber a opnião de vocês sobre o ponto de vista demonstrado.
Obrigado
Não vejo as metodologias como Scrum como se bloquea-se a criatividade como foi citado, eu acho que um metodo de organizar e analisar como as demandas dos clientes vem sendo atendida,
mas até onde sei ninguem olha o que o cliente quer e sai fazendo, muitas vezes algumas funcinalidades são simplesmentes ideias dos desenvolvedores para aprimorar o software.
Em um ponto concordei com a visão do Kai, que é a falta de visão para o cliente, porém se as demandas forem bem estruturadas vc tem a relação de funcionalidades de uma maneira bem simples. O quanto de informação é agregada a um software e o quando isso é valido, não é o desenvolvedor que tem que informar, e o proprio cliente. Ele é o especialista na área, e deve saber o que o sistema faz.
Acho que a grande pergunta é: “Os desenvolvedores são capazes de dizer o que é melhor para o cliente?”
O duro dessas discussões é que sempre esbarram em dois tipos de projeto, que ao meu ver são completamente distintos: softwares de prateleira e softwares feitos sob encomenda.
No software feito sob encomenda, acho que não devemos tentar ser criativos mesmo. Ou melhor, restringir a criatividade ao que o cliente pede. Afinal, geralmente estaremos modelando o negócio do próprio cliente, e quem melhor conhece o negócio do que ele mesmo? O que podemos fazer é orientações criativas sobre o uso da tecnologia, dentro do que ele precisa fazer. Ou seja, podemos mostrar a ele formas melhores de como fazer usando tecnologia, e não sobre o que fazer. Assumir que o cliente não sabe o que faz é um pressuposto no minimo perigoso. O cliente teve capacidade de fazer o negócio crescer ao ponto de contrata-lo, então, não seja arrogante só porque você entendeu alguns processos dele.
O segundo ponto são softwares de prateleira. Não temos um cliente, mas sim centenas. Alguns desses softwares precisam até mesmo surpreender os clientes. Ou dar a eles soluções de problemas que eles não necessariamente pensaram à respeito. Precisam atender a públicos distintos, alguns deles inexperientes e outros especialistas. Nesse caso, a equipe de desenvolvimento precisa ser atuante também sobre o que fazer, além do como. Afinal, não estamos aqui modelando o negócio de ninguém, mas sim, tentando chegar numa ferramenta ou mesmo, criando uma aplicação totalmente inovadora, sobre algo que os clientes sequer ouviram falar (e que com sorte, vai virar a nova megatendência).
Acho interessante a opnião dos dois e concordo e fico pensando que realmente e necessario tomar cuidado em ser criativo, pois acredito que o primeiro objetivo é atender o que o cliente pede com qualidade. Penso tambem que com a ideia de Agilidade e entrega de springs rapidos e feedback constante esse objetivo se torna mais palpavel, mas tambem acho que essa mesma agilidade não abre espaço para tentar ser inovador o foco é o cliente, ele domina o negocio, mas como o Viny disse isso é valido para softwares feitos sobre encomenda, e isso me fez pensar e quando não temos um cliente mas sim muitos como é o caso de um software de prateleira, como vocês enxergam o uso de metodologias ageis nesse contexto ?
Questiono isso pois fico pensando em coisas como :
-Quem sera o nosso product owner?
[quote=ViniGodoy]Acho que a grande pergunta é: “Os desenvolvedores são capazes de dizer o que é melhor para o cliente?”
O duro dessas discussões é que sempre esbarram em dois tipos de projeto, que ao meu ver são completamente distintos: softwares de prateleira e softwares feitos sob encomenda.
No software feito sob encomenda, acho que não devemos tentar ser criativos mesmo. Ou melhor, restringir a criatividade ao que o cliente pede. Afinal, geralmente estaremos modelando o negócio do próprio cliente, e quem melhor conhece o negócio do que ele mesmo? O que podemos fazer é orientações criativas sobre o uso da tecnologia, dentro do que ele precisa fazer. Ou seja, podemos mostrar a ele formas melhores de como fazer usando tecnologia, e não sobre o que fazer. Assumir que o cliente não sabe o que faz é um pressuposto no minimo perigoso. O cliente teve capacidade de fazer o negócio crescer ao ponto de contrata-lo, então, não seja arrogante só porque você entendeu alguns processos dele.
[/quote]
Não é uma questão de arrogância, é uma questão de conhecimento de causa. Existem dois tipos de regras que são incluidas no software: regras de dominio e regras de negocio. As regras de dominio são aquelas que são iguais para aplicações do mesmo dominio ( por exemplo, todos os e-comerce tem regras em comum). Regras de negocio são particularidades daquele cliente especifico. Neste caso, quando o cliente desafia uma regra de dominio é muito provável que ele esteja errado. Quando ele força uma regras de negocio é muito provável que ele não conheça a regra de dominio equivalnete.
No livro Software Requirements do Karl Wiegers ele fala “Do not assume the client is always right. The client allways a point, through” (“Não assuma que o cliente tem sempre razão. contudo,o cliente sempre tem algo a dizer que merece ser ouvido”. (tradução livre))
Vc não deve ignorar o que o cliente diz, mas não deve acatar cegamente o que ele diz.
Sistema de prateleira implementarm principalmente regras de dominio. Regras de negocio são normalmente adicionadas via patchs, script, ou algum tipo de plugin.
Sistema on demand implementam principalmente regras de negocio. Regras de dominio são confundidas com regras de negocio porque não ha conhecimento em amplitude para destingir.
Ou seja, se você repetir a implementação de vários sistemas do mesmo dominio, vc acaba vendo como criar uma aplicação de parteleira para aquele dominio.
[quote=abaldove]Ola pessoal, não tenho experiencia em metodologias Ageis, na verdade estou lendo um pouco mais sobre elas agora, li esse artigo na InfoQ:
http://www.infoq.com/br/news/2010/03/serious-flaws-agile-scrum
Gostaria de saber a opnião de vocês sobre o ponto de vista demonstrado.
[/quote]
Esse artigo e o artigo que ele analisa é completa insanidade. Agile sempre defendeu os stakeholders e o valor nunca os desenvolvedores e as suas preocupações. no extremo existe uma força que suga valor à custa de software porco. É por isso que nasceu o manisfesto para o Software Craftsmanship.
Estes artigos são total non-sense anacrónico
Exatamente. O que eu chamei de arrogante a postura que muitos programadores tem de achar que o cliente é burro e incapaz, o que também está longe de ser verdade.