Eu vejo os diagramas como um aliado seu, vc monta o diagrama descrevendo aquela funcionalidade cabulosa do projeto e apresenta ao cliente, depois de ele ter concordado e vc implementado ele não tem como reclamar dizendo que não era isso que ele queria… Mas uma coisa que eu acho prática é ter uma pessoa só pra fazer os diagramas, o que soh acontece em grandes empresas, geralmente quem desenvolve, faz a analize de requisitos, diagramas, cronogramas etc etc etc…
A premissa do Agile não é o usuário saber o que quer mas permitir que as decisoes sejam tomadas no “last-responsible-moment”.
Ao invés disso o que se vê é projetos onde analistas de sistemas são alocados pra fazer BDUF achando que isso vai suprir a necessidade do cliente como parte do desenvolvimento. Quando comeca a implementação os analistas de sistemas são descartados e o que resta são diagramas e schemas com o deadline pra ontem.
Com o papel inutil do analista de sistemas sendo substituído por uma interação diretamente com o cliente (sob a figura do product owner) as reuniões são mais frequentes e ao invés de contemplar figurinhas desenhadas o foco passa a ser o entendimento do que deve ser implementado naquela iteração, nem que pra isso seja necessário desenhar alguns digramas UML num quadro branco ou num papel de pao.
Não existem projetos gigantescos e sim mal gerenciados, como é o caso quando existem 30 programadores trabalhando juntos!
Mas aí é que está. Existe um product owner, que é o sujeito que tem autonomia sobre o sistema e pode tomar decisões sozinho.
Na implantação de sistemas coorporativos, sobretudo quando existe modificações de processos e mudanças estruturais não só no sistema, mas na forma com que a empresa espera realizar o seu negócio, essa figura nem sempre existe da forma que a metodologia ágil prega.
Implantar sistemas assim tem várias complicações, que não estão presentes na maior parte dos sistemas. Entre elas, gerenciar conflitos, usuários que te boicotam com medo de uma demissão, boicote de gerentes, etc. Por isso também, cobra-se milhões em projetos assim.
Não? O que dizer de centrais telefônicas, jogos, sistemas operacionais grandes (como o Windows), ou sistemas como SAPs?
Tudo mal gerenciado? Talvez você ainda não tenha participado de um projeto de grande magnitude. Mas existem projetos sérios com dezenas de programadores.
Que forma você se refere especificamente que a metodologia prega?
É isso que você faz no seu dia-a-dia?
[quote=ViniGodoy]
Talvez você ainda não tenha participado de um projeto de grande magnitude.[/quote]
Pode ser. Ou talvez sua idéia de projeto esteja limitada à uma visão monolitica.
Nesse caso se faz valer uma boa gerência seja para a dificil tarefa de conciliar tantos interesses diversos seja para ajudar a ampliar o horizonte!
Não. Mas, como eu falei, nós aqui no meu setor usamos o Extreme Programming, que é um processo ágil. Aliás, eu sou 100% a favor de processos ágeis.
Mas setor aqui do lado tem mais de 30 pessoas que fazem software de centrais telefônicas, aqui na Siemens. Além deles tem o pessoal do firmware, mas como estamos falando de processos de software, não entremos nesse quesito.
Acho muito difícil imaginar um processo menos burocrático, já que a equipe é grande, os requisitos vem da Alemanha e muitas vezes a visão do cliente se baseia em pesquisas estatísticas sobre o mercado consumidor. Além disso, há custos envolvendo também hardware e um erro de dimensionamento do software da central pode se tornar muito caro.
A correção do software no cliente, uma vez que é produzido e distribuída em escala, num equipamento que muitas vezes não aceita updates automáticos, também não é simples como no caso de software de prateleira. Só para se ter uma idéia, existe um outro departamento inteiro só focado em testes e rigorosas especificações de qualidade.
No caso dos processos ágeis usamos um pressuposto, que é válido para a absurda maioria dos sofwares, que é o de que modificar programas é relativamente fácil e barato. O que não é válido para o pessoal aqui do lado, mas é bastante válido em meu setor.
Veja bem. Estou mesmo falando apenas situações bem específicas, onde acho que o processo mais burocrático em regime de mini-waterfall se encaixa melhor do que o processo ágil. Para as demais situações, e creio que sejam a absurda maioria, também sou partidário do desenvolvimento ágil.
Não me anima nem um pouco sair do processo ágil para voltar a enfrentar longas etapas de diagramação, descrições de casos de uso, diagramas de sequência, páginas e páginas de textos…
[quote=ViniGodoy]
Mas existem projetos sérios com dezenas de programadores.[/quote]
Projetos sérios também falham, não é brincadeira!
A discussão parece bem interessante e gostaria de comentar.
Em projetos grandes utilizar automatização para geração de código através de MDA, traz muita agilidade ao processo.
Como fazer isso sem utilizar diagramas UML??
Sem dúvida, e o Longhorn que o diga.
Mas o que eu quis dizer é que existem situações em que justifica ter uma equipe tão grande. Diferentemente do que faz muita softwarehouse por aí, que quer impressionar o cliente, e contrata vários programadores de baixo conhecimento técnico só para cobrar caríssimo, sem que isso seja sequer justificável.
Ah sim, e elas ainda usam a documentação como uma forma de dizer que tem “padrões de qualidade”. Como se papel garantisse algum tipo de qualidade.
(Aliás, o oposto também vale. Tem muita gente usando a desculpa de que é ágil para fazer bagunça e justificar a ausência de processo, o que também não é correto).
Independente do cliente na alemenha alguem será eleito pra fazer a parte cliente on-site, e nao vale dizer que ta faltando pessoal!
Desculpe mas não vejo isso como falha da metodologia ja que ela esta preocupada em entregar software funcional. Isso nao exclui a necessidade de competencia para gerir sua cadeia de processos. Por exemplo, não acho que o tamanho do projeto deva se dar em funcao do numero de pessoas disponiveis e sim em funcao do que é possível ser gerenciado levando em conta as possibilidades. Grandes projetos precisam ser divididos para serem conquistados. Não com o objetivo primario de eliminar burocracia mas de permitir algo passível de ser gerenciado.
Se é uma caracteristica do seu negócio nao vejo porque nao pode ser suportado pelo processo ágil mas se também vocês adotam outra metodologia que lhe servem e permite desenvolver o software de qualidade que precisam ótimo, seria um bom estudo de caso!
O fato de haverem X mil programadores num projeto não traz necessidade de diagramas de classe, interação e etc como especificação formal ou mesmo documentação (apesar de haverem -poucos- casos onde isso seria útil). Como o Moscoso falou um projeto desse tem que ser dividido em projetos menores ara se tornar gerenciável.
Assim como ninuém nunca precisa nsultar um diagrama de classes do Hibernate para ver como ele funciona (para coisas simples uma página de wiki te basta, para coisas complexas a documentação é textual e baseada em exemplos) não é preciso mantêr diagramas em UML.
[quote=alexsander.santana]Em projetos grandes utilizar automatização para geração de código através de MDA, traz muita agilidade ao processo.
[/quote]
Isso foi o que lhe contaram ou você já teve essa experiência?
Seria realmente ótimo se existisse essa figura. Teriam que distribuir uma pessoa para cada um dos 7 sites de desenvolvimento no mundo, que deveriam estar totalmente integradas com o projeto centralizado. Mas com um pouco de esforço acho que poderia ser feito.
Não entendi no contexto, isso o que?
Bom, acho que isso é meio óbvio, não? Dividir para conquistar é um lema de todos os processos sérios, desde os mais burocráticos até os mais simples. O número de pessoas pode não ser o único fator para definir se um projeto é grande ou complexo, mas certamente é um dos fatores.
Ainda não vejo como aplicar métodos ágeis quando o custo de modificar fica exponencialmente mais alto a medida que o produto final aproxima-se do cliente. Embora essa já tenha deixado de ser a realidade da maior parte dos softwares, esse certamente não é o nosso caso, por todos os motivos já citados. Já citando o próprio Kent Beck, no seu livro Extreme Programming Explained:
“It is the technical premise of XP. If the cost of change rose slowly over time, you would act completely differently from how you do under the assumption that costs rise exponentially.”
O mesmo foi repetido pelo Craig Larmann numa palestra que ele deu na Nokia Siemens, falando de Agile no geral.
Torno a repetir: Eu não sou contra processos ágeis. E aliás, não só sou completamente a favor como também me empenhei para que ele fosse implantado onde trabalho. Também creio que haja muito mais potencial para ele dentro das empresas, especialmente as grandes. Reconheço que ele é adequado para a absurda maioria dos softwares atuais, especialmente aqueles desenvolvidos no comércio (grandes ou não). No nosso caso, acho que muitos setores ainda poderiam se beneficiar de um método ágil. Mas não creio que ele seja a solução para todos os problemas de TI.
Vini, eu entedi seu arument e concordo, só que para mim a quantidade de softwares que cai nessa exceção é bem menor e não inclui seus exemplos. Sobre Sisemas Operacionais, a Microsoft é um dos grandes nomes por trá de agile nos últimos anos e apesar de eu não conhecer a fundo o processo de desenvolvimento do kernel do Linux eu nunca coheci um projto livre de sucesso que fosse waterfall ou mesmo BDUF. Já trabalhei com telefonia o suficiente para saber que o problema é cultural, não tecnológico (convencer engenheiros a não fazer um mega-projeto numa ferramenta CAD, ops, CASE é algo complicado) e sobre jogos , apesar de não ter experiência,eu tenho um exemplo bem interessante:
http://www.se-radio.net/podcast/2008-04/episode-92-introduction-game-development
É engraçado como o processo de desenvolvimento é descrito, extremamente iterativo e incremental, e como o entrevistado fala que processos burocráticos servem apenas para sotware comercial em grandes empresas.
[quote=alexsander.santana]A discussão parece bem interessante e gostaria de comentar.
Em projetos grandes utilizar automatização para geração de código através de MDA, traz muita agilidade ao processo.
Como fazer isso sem utilizar diagramas UML??
[/quote]
Acho que o ponto aqui é ailidade como o que foi definido pleo manifesto ágil, não sobre velocidade. Ainda assim, alternativas de Model Driven Design não dependem de uma linguagem especifica, Microsoft DSL Tools, Metacase, Jetbrains MPS e outros métodos são alternativas. Segundo alguns defensores de MDA nem mesmo este padrão depende de UML -o que eu não concordo.
O processo de desenvolvimento do kernel do Linux não é nada muito complexo.
Existe um grupo de responsáveis por cada parte (os maintainers) e os desenvolvedores mandam patches, normalmente para uma lista de discussão. As pessoas comentam, mandam sugestões/correções e quem dá a palavra final é o responsável, que no final do processo adiciona o patch ao kernel.
dividir o projto em menores para não precisar utilizar tais documentações e uma boa…
mas e em casos onde o projeto e muito integrado como fica?
O maior problema é o custo do software que vai embarcado para o cliente, ou que acompanha o hardware (e não necessariamente é embarcado, mas gravado em memória flash ou outro dispositivo que ficará isolado de uma rede e, portanto, não sujeito a updates automáticos).
Esse software sim, é caríssimo de se modificar. Mas também concordo (e por isso venho tentando convencer o pessoal de adotar mais técnicas ágeis por aqui), que boa parte do processo poderia ser, no mínimo, mais ágil. E que nem todas as etapas do processo precisam necessariamente ser burocráticas.
Os processos ágeis, na minha opinião, foram os primeiros a encarar software realmente como ele é: software. E não a utilizar uma abordagem inspirada na engenharia civil.
Quanto aos exemplos, eu só estava citando casos de software de grande porte, em que se justificava ter vários programadores. Não falava exatamente do fato disso ser aplicável a processos ágeis ou não.
Quanto aos jogos: Eu acho o desenvolvimento de jogos ainda é burocrático demais hoje. Tenho defendido um processo mais interativo e práticas ágeis no desenvolvimento há muito tempo. Mas por lá, também existe uma séria dificuldade cultural. Me deixou feliz saber que a Hoplon, desenvolvedora do Taikodom inspirou-se muito em processos ágeis para melhorar o seu ciclo produtivo. Ainda no GamaSutra surgem artigos de grandes figuras no mundo dos games defendendo um processo muito próximo do RUP. Claro, já existem movimentos no sentido contrário, o que creio que será realmente a tendência futura.