/br/br/comentarios Comentários do site Improve It. pt-BR 40 Improve It <p>Pessoal, sou novato no manifesto ágil, acho muito legal todos estes valores pregados, mas tenho algumas preocupações, por exemplo, imagine um grande projeto, realizado de forma incremental e iterativa usando por exemplo XP. Vamos supor que no 8º mês você perde um dos desenvolvedores e vai ter que repor a equipe. O cara que entrar para dar continuidade vai se basear em que ?? Ele vai ler os 200 User Stories gerados pra compreender o sistema ?? E a manutenção ?? como fica por exemplo se o projeto for finalizado e 1 ano depois por qualquer que seja o motivo a equipe que desenvolveu foi realocada em outros projetos ou saiu da empresa ??? Como treinar o pessoal que fará a manutenção ?? eles terão que ler o código pra entender os requisitos ??? Vocês não acham muito arriscado deixar todo o conhecimento do projeto na cabeça dos programadores ???</p> <p>Ricardo Coelho.</p> http://www.improveit.com.br/br/xp/manifesto_agil <p>muito legal eu achei tudo o que eu queria aqui o saiti e melhor que tem nunca deixe de fazer pesquisa aqui.</p> http://www.improveit.com.br/br/xp/manifesto_agil <p>Opa, o Vinicius também comentou bem.</p> http://www.improveit.com.br/br/xp/manifesto_agil <p>Que isso rapazeada, 6 tão viajando muito, tirando o que o Marcio Fabiano falou que a abstração é a grande causa de perda de qualidade, falhas e insucessos.</p> <p>A qualidade final é justamente o procurado quando se prega a colaboração do cliente. Se o cliente só valida um bando de documento, fica isolado durante um tempo e só então depois vai ver o sistema, a chance de ter muita coisa errada é muito grande.</p> <p>No processo ágil, entrega-se sempre partes do sistema que o usuário consegue usar. Você tanto elimina a pressão já dando algo usável por ele quanto diminui bastante o risco do projeto ao continuar o desenvolvimento sobre algo que já está aprovado e está do jeito que o cliente quer (e não imaginou lendo um bando de documentos).</p> http://www.improveit.com.br/br/xp/manifesto_agil <p>(parte 1 de 4) Realmente, concordo que os indivíduos e iterações entre eles devem ser a base que sustenta os processos e as ferramentas, isto é inegável, pois são os indivíduos que fazem as ferramentas funcionar, e os processos existem para dar apoio aos indivíduos e faze-los render mais e da melhor forma. Só não entendi uma coisa, como quem sustenta e melhora uma outra coisa, pode ser menos importante? Além disso, é preciso entender que a importância dos indivíduos para o sucesso de uma determinada atividade é diretamente proporcional a importância dos conhecimentos e das habilidades destes indivíduos dentro da atividade. No caso de software, o foco do blog e do manifesto ágil, os conhecimentos e habilidades dos trabalhadores são fundamentais. Isto não significa que processos e ferramentas não sejam importantes, eles são sim, e muito, mas são secundários, pois no fundo são meros instrumentos de apoio a materialização de um trabalho que ocorre quase que exclusivamente na cabeça das pessoas. Você poderia perguntar algo como: “Mas e daí? Porque que i$$o é importante para as empre$as?” Porque toda empresa quer produzir mais e melhor, para vender mais e melhor. Neste caso, o produto é software, que depende fundamentalmente de coisas como conhecimentos e habilidades, e estas características são drasticamente influenciadas por coisas como: Carga horária excessiva, ambiente de trabalho desconfortável, falta de reconhecimento, “faça o que mando e não interessa porque”, insegurança com o futuro, desconfiança, remuneração ruim, etc, etc, etc, etc... Ou seja, sem valorizar as pessoas, a produtividade cai, e sem produtividade os lucros caem, e sem lucros, bye bye.</p> http://www.improveit.com.br/br/xp/manifesto_agil <p>(parte 0 de 4) (vou responder aos pedaços, acho que num precisa explicar porque :) E aí Nay! Entendi bem boa parte do seu comentário, concordo com algumas coisas, discordo de muitas outras. Dentre as poucas coisas que não entendi, vale ressaltar algo que achei, digamos, curioso. Boa parte do que não compreendi, são críticas feitas ao mundo ágil e os respectivos argumentos para justificar estas críticas, sendo que estes argumentos estão em conformidade com as propostas defendidas nas metodologias ágeis. Não entendi. Dizer que “todo desenvolvimento ágil gera perda em qualidade da necessidade real do cliente final” é quase como dizer que um dieta balanceada e exercícios físicos necessariamente causam mal a saúde. A XP, por exemplo, a mais conhecida das metodologias ágeis, prega de forma quase espartana, em termos de disciplina, a defesa da qualidade e a geração de valor(necessidade real) para o cliente final(o penúltimo post do meu blog é sobre o princípio qualidade, dentro da XP(devagil.wordpress.com)). Uma pesquisa de março de 2007 com 781 pessoas da área de TI, sendo 52% desenvolvedores e 22% gerentes, organizada por Scott Ambler e publicada na Dr. Dobbs, entre outras coisas, mostrou que para mais 77% dos pesquisados o índice de sucesso(valor gerado) nos seus projetos foi maior que 75%. Nada mal, se considerarmos que historicamente(Chaos Research) os melhores resultados deste tipo de pesquisa(guardadas as devidas proporções de tamanho da amostra) rondam os trinta e poucos porcento. Realmente não existe fórmula mágica, mas o texto acima não tem nada a ver com “produtos com alta escala de demanda”, me desculpe, mas realmente não imagino porque você concluiu isso. Depois você me explica, novos pontos de vista quase sempre acrescentam valor.</p> http://www.improveit.com.br/br/xp/manifesto_agil <p>Cara, pra mim, todo desenvolvimento ágil gera perda em qualidade da necessidade real do cliente final. Não existe fórmula mágina, exceto dedicação. Porém, creio que o textículo acima relata sobre desenvolvimento de produtos com alta escala de demanda. Senão vejamos:</p> <p>1) Indivíduos e interação entre eles devem conviver junto aos processos e ferramentas. Se o primeiro for mais importante, pra que processo? Os primeiros devem sustentar os processos, e até melhorá-los, como também as ferramentas, mas não são mais importantes.</p> <p>2) Software em funcionamento mais que documentação abrangente. Este aí eu concordo em parte. É importante colocar o avião no ar, mas também a manutenção é essencial. Quanto mais demorada a manutenção (por falta de documentação) pior a qualidade. 1 minuto a menos para documentar pode gerar horas a fio de trabalho extra.</p> <p>3) Colaboração com o cliente mais que negociação de contratos. Sem os contratos, nenhuma empresa sobrevive. É lindo falar só em qualidade, mas é a quantidade que gera lucro, objetivo maior de qualquer empreendimento. Mas dar a devida atenção e principalmente RESPEITO aos clintes é essencial.</p> <p>4) Responder a mudanças mais que seguir um plano. As mudanças devem ser priorizadas em: - Necessárias - Podem ser feitas durante o desenvolvimento sem prejuízo do projeto, mas devem ser feitas logo pra não afetar os prazos. - Urgentes - É necessário parar o projeto e estabelecer novos prazos. É importante levantar de quem foi a culpa, pois o cliente quer saber que assinou um contrato e tem um prazo pra receber. Caso o erro seja na especificação, problema seu, vire noites, finais de semana, corra atrás, e deixe o imbecil que cagou tudo acompanhar a merda até a solução. - Importantes - Podem ser resolvidos após a entrega, como um PLUS, como o Service Pack... mas não poderão deixar de ser feitas pra manter a qualidade.</p> <p>Ou seja, os valores devem ser somados, e não subtraídos ou divididos, ou fracionados, quem diz que um é mais importante que outro, é leviano e irresponsável ou só está vendo seu lado. Havendo valor deve-se somar. A Prioridade quem dá é o momento, ok?</p> http://www.improveit.com.br/br/xp/manifesto_agil <p>Caramba, ou ele(Marciofi@hotmail.com) viajou muito ou eu não entendi nada do que ele escreveu. :) Por respeito, abraço a segunda suposição, então vou tentar argumentar em cima disto. Bom... o início, ou seja, a parte que vai até antes de BPM, eu realmente não entendi muito, seguindo a segunda suposição citada acima, creio que é complexo demais pra meu nível de conhecimento atual. Bom... BPM realmente promete muito, não sou nem especialista, nem leviano, então não posso afirmar conclusivamente se ela é tão boa quanto diz, ou não. Posso dizer apenas que se as BPM’s cumprirem o que prometem, terei prazer em estudá-las a fundo. Posso dizer também que pra isso acontecer, elas terão que cumprir o prometido em uma quantidade grande e heterogênea de projetos em diversos locais do mundo, “só isso”. Talvez falte um bocadinho pra chegar lá ainda. Boa sorte pra elas! “Desespero dos programadores, observando a quarta gerão de software, perdendo ser status mágico do desenvolvimento e manutenção dos softwares?”. Pelo pouco que conheço de sistemas, no desenvolvimento tradicional os desenvolvedores/programadores, faz um bom tempo são o último degrau da hierarquia do setor de TI, ou seja, desenvolver software não tem status mágico nenhum. Felizmente as metodologias ágeis praticamente exigem uma inversão deste tipo de desenho hierárquico. E o que mais me intriga é que estas metodologias tornaram-se a opção comum da maioria das empresas modernas, mesmo cometendo este pecado (valorizar muito o desenvolvedor). Será que foi porque os donos das empresas são bonzinhos ou porque as metodologias ágeis revelaram-se valorosas($$) para empresas? Duvida? Veja aqui: devagil.wordpress.com (no post existem as devidas referências). E ainda perguntam, “e o negócio, cadê o negócio?”, bom... respondo com outra pergunta. Porque será que “verdades” quase cinqüentenárias estão sendo abandonadas e os princípios ágeis (princípios do manifesto ágil, além de muitos outros, todos harmoniosos) vêm sendo largamente adotados? Porque uma mudança dessa magnitude está ocorrendo dentro das empresas(negócios)? Será que é porque são teoricamente bonitas, socialmente agradáveis, mais humanas, etc? Ou será que é porque os empresários estão percebendo que está é a melhor forma que existente atualmente de gerar valor($$$) para seus negócios? Sou todo dúvidas. Espero que o amigo Marciofi@hotmail.com possa me ajudar, não gosto de incerteza. Coincidências a parte, empresários também odeiam incerteza, mesmo assim estão permitindo a adoção de metodologias ágeis em suas empresas. Meu Deus!!! Que loucura!! Me ajude Márcio, por favor. Bom... agora vou falar de abstração. A semente da XP foi um projeto(algo concreto) muito bem sucedido implantado na Chrysler. A semente do SCRUM foi o excelente processo de desenvolvimento usado pela empresa PatientKeeper no sistema PatientKeeper(produto concreto). A semente do FDD foi um projeto praticamente falido em Singapura com 3500 casos de uso escritos e nenhuma linha de código implementada. O projeto foi declarado inviável pela empresa(grande e famosa) inicialmente contratada. Como última esperança, alguns grandes desenvolvedores foram chamados. Depois de pouco mais de um ano, o projeto estava com mais de 2.000 funcionalidades implementadas. Aconteceu basicamente a mesma coisa com todas as outras metodologias ágeis. Resumi bastante e não citei todas, porque o google pode fazer isto melhor que eu, e não posso escrever um livro aqui :). O mais interessante é que todas as metodologias ágeis são muito parecidas em seus princípios fundamentais, mas nasceram de projetos concretos, desafiadores, revolucionários e sem nenhum relação direta. Ou é mágica, ou é uma coincidência absurda, ou estes princípios comuns são muito importantes para o sucesso de um projeto de software. Escolham suas opções. Só concluindo a pequena contra-argumentação em cima do comentário “metodologia criada tendo como base a abstracção”, reforço que escrevi SEMENTE para reforçar a idéia de que as metodologias ágeis são como árvores que já cresceram bastante, mas que tendem a nunca parar de evoluir. Isto é verdade justamente porque elas estão muito próximas do concreto, ou seja, próximas dos resultados, do valor gerado para o cliente. Elas surgiram de projetos concretos, são muito flexíveis e evoluem ano após ano pragmaticamente sempre com base nos resultados(feedback) concretos de sua própria aplicação(evolução contínua). Poderia escrever muito mais sobre o lado concreto das metodologias ágeis, isto não seria muito difícil, afinal elas são muito influenciadas por conceitos que surgiram de experiências práticas(concretas). Poderia escrever argumentos diferentes para cada um dos 4 princípios do manifesto ágil, só para reforçar, mas acho que já é o bastante. Se o amigo quiser, eu posso, dentro de minhas limitações, tentar informá-lo um pouco melhor sobre o assunto. Abraços, Vinicius AC.</p> http://www.improveit.com.br/br/xp/manifesto_agil <p>Realmente, só posso crer que este tipo de metodologia é a tentativa da sustentabilidade da UML ou ainda da OO, sendo, que OO, criada pela metade, apressada pelas necessidades do mercado ou da possivel falta de mercado, se atrasasse mais um pouco para ser lançada, como comparar diante da metodologia de processos? E diante da atual busca, realmente tecnologica, das BPM's? Segundo paradigma do software quebrando-se? Desespero dos programadores, observando a quarta gerão de software, perdendo ser status mágico do desenvolvimento e manutenção dos softwares? Isso é o que vocês apresentam como agilidade em projetos? E o negócio? Cade o negócio? Caros senhores, a abstracção é o maior problema na desde a análise de requisitos até a homologação de qualquer software ou mais, de qualquer produto e uma metodologia criada tendo como base a abstracção já é o inicio de um processo fadado ao mau êxito. Bom, está é a minha opinião. Obrigado Marcio Fabiano marciofi@hotmail.com <br/> </p> http://www.improveit.com.br/br/xp/manifesto_agil