agilidadeQualidade
jan 20 2012

Agilidade X Qualidade de Software

 Olá pessoal, um dia desses, a Sara Barbosa colocou a seguinte questão no twitter: “Agilidade não é o mesmo que qualidade, Qualidade não é o mesmo que agilidade ?!” Preferi não responder na hora pois essa é uma questão que envolve muitos pontos de vista, e são inúmero os fatores que podem influenciar um projeto. A interpretação que dei a essa questão é se um produto desenvolvido de forma ágil sempre terá qualidade e se um produto de qualidade significa que foi desenvolvido de forma ágil.

Bom, primeiro precisamos ter uma definição sobre o que é qualidade de software. O primeiro ponto, sobre esse assunto é, qualidade para quem? Cliente ou desenvolvedor ou ambos? Claro que o ideal é que o produto tenha qualidade para o cliente e para o desenvolvedor, pois isso resultará em bons resultados na entrega, manutenção e evolução do software.

Os processos ágeis têm como principal objetivo a adaptação as mudanças, pois sabemos que elas são inevitáveis. A partir do momento em que começamos a parar de lutar contra as mudanças e passamos a utilizá-las para atingir o nosso objetivo, teremos como resultado um produto com maior qualidade para o nosso cliente e também para os desenvolvedores. Existem práticas ágeis de desenvolvimento que contribuem muito para obter um código mais limpo, mais legível e consequentemente mais fácil de manter e evoluir. Práticas da XP (Extreme Programming) como programação em par e TDD são bons exemplos que podemos utilizar. Portanto, quando trabalhamos com processos ágeis, estamos mais próximos dos objetivos e consequentemente da qualidade do produto.

Quando temos um produto de software de boa qualidade nas mãos, não necessariamente isso significa que ele foi desenvolvido por um processo ágil. Em primeiro lugar, vamos analisar a seguinte questão: Qual é a metodologia (ou processo) de desenvolvimento mais ágil que existe? Talvez muitas coisas venham em sua mente agora, mas a resposta a essa pergunta, é o famoso DEPENDE. Por que? Porque a agilidade empregada em uma organização pode variar, ela depende do tamanho do time de desenvolvimento, depende dos recursos disponíveis, do tamanho do projeto, da presença de alguém fornecendo feedback e acompanhando o desenvolvimento do produto, etc. Para uma organização envolvida em um projeto de grande porte, geograficamente distribuído e envolvendo dezenas de desenvolvedores, talvez um RUP seja o processo mais ágil que eles consigam trabalhar, ou até mesmo um Waterfall. Nesse cenário, o caminho até o objetivo final pode ser mais oneroso, mas isso não significa que o resultado não seja um produto de boa qualidade.

Portanto, adotando processos ágeis estamos caminhando para um resultado de qualidade, tanto para o cliente quanto para o desenvolvedor, porém a agilidade não é o único caminho para se atingir a qualidade esperada num produto de software, sendo assim, qualidade não necessariamente significa agilidade.

Recomendo fortemente dar uma lida no texto produzido por Klaus Wuestefeld entitulado:  O Círculo Vicioso do Software Retranqueiro, retrata bem o cenário que vivemos no desenvolvimento de softwares.

nov 12 2011

Visão Ágil – dica de leitura!

Olá pessoal, hoje vou mostrar uma ótima opção de leitura para quem está ou pretende seguir o caminho dos princípios ágeis de desenvolvimento de software, é uma revista chamada Visão Ágil, escrita por pessoas envolvidas com os processos ágeis e uma ótima referência para ficar por dentro desse novo mundo, além de links para vídeos, eventos etc…
Segue o link:

http://www.visaoagil.com

Boa leitura!

out 29 2011

Palestra sobre Scrum e TFS

Olá pessoal, nessa última semana de outubro aconteceu na Univille a Semana da Informática onde eu dei uma palestra sobre Scrum e Plataforma Microsoft. A ideia era dar um overview do Scrum visto que havia pessoas que sabem o que é Scrum, pessoas que nunca ouviram falar e pessoas que já trabalham com Scrum.

Em seguida fiz uma rápida demostração utilizando o Team Foundation Server e o Visual Studio 2010. Espero que os alunos tenham saído com algum conhecimento a mais, ou da ferramenta ou do framework Scrum.

Scrum e Plataforma Microsoft
Veja mais slides de Fernando Ferreira

enjoy!

Abraços!

out 21 2011

Uma linguagem necessária

Esse texto é na verdade um resumo de uma conversa que tive com um professor um dia desses pelo corredor da universidade onde estudo aqui em Joinville (Udesc).

Como profissional de tecnologia tenho visto que muitos dos colegas de profissão não dão a devida importância para uma linguagem extremamente necessária, a língua portuguesa.  Há certo preconceito por parte dos profissionais de tecnologia, principalmente desenvolvedores em relação a língua portuguesa. Certa vez ouvi que quem trabalha com desenvolvimento não precisa dominar o básico da língua portuguesa. Lembrando que não saber é uma coisa e não precisar é outra.

                Em primeiro lugar, devemos saber nos comunicar de forma clara e objetiva, seja na escrita ou na fala, em segundo lugar quem não tem o hábito da leitura e não tem algum domínio da língua portuguesa, terá sérias dificuldades de interpretação, e como fará ao receber um documento de requisitos em suas mãos? Ficará perguntando o tempo todo para o colega ao lado? Em terceiro lugar, o mercado está cada vez mais competitivo, é necessário que saibamos vender o nosso “peixe”, ou seja, precisamos ter um domínio ao apresentar  um projeto, uma ideia, um produto, seja para um cliente, seja na própria empresa, e se você não o fizer de forma clara, pode perder uma oportunidade.

                Sabemos que a língua inglesa é indispensável para quem é da área de T.I., porém vejo pessoas que gostam de exibir seu domínio nesse idioma e sequer sabem escrever um texto coerente, com ideias bem encadeadas, bem elaboradas e objetivas,  escrevem textos que só eles entendem. Não estou dizendo que todos os profissionais de T.I. devem dominar profundamente a língua portuguesa, o que quero dizer é que devem dominar o suficiente ao ponto que essa falta de domínio não seja um empecilho na sua vida. Se uma pessoa busca uma ascensão profissional, com certeza essa é uma das competências que ela deve dominar.

Para finalizar aí vai uma dica, a leitura é uma excelente forma de melhorar nosso vocabulário, nossa forma de se expressar, e hoje em dia onde a criatividade é indispensável, a leitura se torna ainda mais importante. Porém devemos ler qualquer coisa, seja uma ficção, um romance, um poema, qualquer coisa, sabe por quê? Porque a criatividade vem desse tipo de conteúdo, não vem de livros técnicos, lendo livros técnicos, ficaremos melhor na área que atuamos, mas isso não estimula a criatividade. Outra vez, não estou dizendo para substituir a leitura técnica por outra de um tipo diferente, estou dizendo para agregar outros tipos de leitura na sua vida!

 

Abraços!

Fernando.

ago 23 2011

TDC 2011 Floripa 1º dia

 

Olá pessoal, hoje foi comentar aqui como foi o TDC Floripa 2011. A ideia é fazer um panorama geral do evento, e comentar com mais detalhes as trilha que participei. O que falarei aqui são os pontos principais de alguma anotações minhas. Algumas palestras eu consegui colocar os slides para vocês, outras eu não encontrei. As trilhas que vou falar aqui, serão testes e arquitetura, pois foram as que participei, mas também farei uma visão geral do evento!

Minha primeira vez no TDC foi em 2010 na edição de São Paulo. Eu e um amigo (Marcos Dallanelo) saímos daqui de Joinville-SC e passamos a noite na estrada para no dia seguinte estarmos no evento, em resumo, valeu cada centavo e segundo que dedicamos. Posso dizer que muita coisa mudou depois daquele evento, conheci uma perspectiva que não imaginava. No ano de 2011 não pude ir para SP, então esperei o de Floripa e parti. De início ia sozinho, mas na última hora, duas amigas (Milena e Chirle) também resolveram ir, e uma delas tem casa próximo do evento, logo cancelei o hotel..:)

Agenda e recomendações do dia.

O primeiro dia do evento, sábado 20/08/2011 ao chegarmos no local (Universidades Estácio de Sá), passamos pelos guichês de identificação para pegarmos nossos crachás, um cafezinho pra começar o dia bem “antenado” e fomos direto para o auditório principal da universidade,  pois lá aconteceria a abertura do evento.  Chegamos por volta de 08:30 e pouco antes das 09:00 o auditório já estava lotado, e algumas pessoas tiveram que permanecer de pé.

A abertura do evento é um momento muito interessante, pois são apresentados os patrocinadores os apoiadores, as trilhas que acontecerão durante todo o dia do evento, enfim, todos conhecem o que realmente é o TDC e o porquê ele vem crescendo a cada edição. Um ponto forte também desse evento é o networking, isso os organizadores reforçam constantemente, na abertura, nas palestras e em todo o evento. Trocar contatos, ideias, ou uma simples conversa, isso sempre agrega alguma coisa. No último dia do evento, conversando com algumas pessoas acabei por conseguir uma carona até a rodoviária de Florianópolis, onde depois iria voltar para Joinville. Não foi minha intenção, mas me ofereceram. ;)

Para cada dia do evento, existe uma abertura  conforme citada acima. Cada um desses dias tinha algo novo pra galera brincar ou conhecer. No sábado essa surpresa foi um robô, isso mesmo um robô construído com Arduíno. Mas o que tinha demais nesse robô? Esse robô podia ser comandado por qualquer participante via twitter!  Foi muito legal isso! Através de uma hashtag seguida do comando que poderia ser frente, trás ou girar (se não me falha a memória) qualquer pessoa podia comandá-lo.  Foi divertido! Nos corredores da universidade, tinham estandes de algumas empresas, com brindes, novidades e havia também disponível para o pessoal brincar o kinect, era cena comum passar pelos corredores e ver pessoas pulando, fazendo movimentos de comandos, se abaixando, girando enfim, descontração também não faltou.

Bom, a hora do almoço ia chegar, só que ninguém precisaria sair das dependências da universidade para almoçar ou ir até a cantina da mesma. No momento da identificação, todos os participantes ganharam um ticket que dava direito a um Subway, isso mesmo tinha Subway para todo mundo e refrigerante a vontade, sem falar os intervalos para o coffee break, com biscoitos, barras de cereais, docinhos e café (é claro).

Começando as palestras, a primeira delas teve como título Automação Rápida de Testes para Web com José Correia (Iterasys)  -nessa palestra ele fez um panorama sobre como funcionam os processos de testes na empresa (que nesse caso é especializada em testes) e citou alguns casos. Alguns pontos chaves sobre a dificuldade de testar as aplicações de um modo profissional:

  • Faltam objetivos claros;
  • Faltam casos de testes ou nem existem;
  • Equipes em constantes mudanças;
  • Descobrir o que é mais importante;
  • Testar os principais requisitos;

Outro ponto chave, é como obter as informações para o teste:

  • Arquivos mais alterados;
  • Páginas mais acessadas;
  • Defeitos mais comuns;
  • Reclamações;

Fatores que possam influenciar os testes, é por exemplo quando o ambiente do desenvolvedor, possui bons recursos e o do tester, apenas micros já ultrapassados, que vieram de outros setores. Isso faz com que não se possa obter muitas vezes o resultado esperado.

Algumas ferramentas free: BadBoy e Jmeter, que até 5 usuários são gratuitas.

Alguns passos para automatizar:

  1. Transformar valores fixos em variáveis;
  2. Fazer com que o teste entre em loop para que a massa dedos possa ser testada até o fim;
  3. Gerar os scripts de automação;

Slides da apresentação

A segunda palestra, tratou de um servidor de integração contínua chamado Jenkis. Eu não conhecia essa ferramenta até então, durante a apresentação, o Bruno fez um exemplo prático de como ela funciona, criando os casos de testes, os cenários de testes, e automatizando isso tudo ao final. Além de elaborar os testes, o Jenkis também exibre estatísticas, gráficos e pode ser integrado com outras ferramenta do mercado.

A terceira palestra foi com o Cristiano Caetano, onde ele apresentou de forma simples e objetiva a importância de uma linguagem comum chamada DSTL (Domain Specification Test Language). Mostrou como é feito os testes com TDD e ATDD. O fator importante aí é o comportamento descrito com BDD e através dessa DSTL gerar os testes de aceitação ou ATDD.  Mostrou também algumas ferramentas disponíveis que podem ser utilizadas para tal. Foi apresentado também um case real desse cenário.

Slides da apresentação.

A quarta palestra tinha com título:  O que CrowdTesting de jogos tem a ver com software corporativo? E foi apresentada por Guilherme Motta (ThoughtWorks) . Essa palestra mostrou de uma ótica diferente esse tipo de teste. O palestrante comentou sobre o porquê de  muitas pessoas realizarem esse tipo de teste e quais são os seus perfis. Para quem não sabe esse tipo de teste é aquele que muitas empresas realizam quando lançam versões ainda beta, por exemplo o google+ foi lançado para ser testado por todos, com isso ele receberá feedbacks que serão incorporados na versão final do sistema. A Microsoft utiliza isso nas versões chamadas CTP (Community Tecnology Preview) ou seja, ela lança as versões beta para a comunidade testar. Talvez nos games isso seja mais evidente, sei lá por qual motivo, mas há uma tendência que se torne cada vez mais presente nos demais softwares.

Vamos agora para a próxima palestra, essa foi com Luana Lobão, do Instituto Nokia.  Essa apresentação nos deu uma ideia de como são feitos os testes para dispositivos móveis. Muitas vezes temos um interesse num determinado assunto, mas não sabemos por onde começar. Ela fez  uma abordagem bem legal em relação aos equipamentos, os simuladores de aparelhos, as técnicas empregadas como testes de sinal do aparelho, testes de bateria, testes dos níveis de memória. Existem testes que podem ser feitos com simuladores, mas outros como o da TV digital, não é possível que se faça assim. O que acontece quando algumas atividades ocorrem em paralelo? Como podemos testar isso? Através das interrupções, as mesmas usadas pelos sistemas operacionais para a troca de processos e que vimos na faculdade. No final foi feito uma demonstração usando testes automatizados no equipamento.

Slides da apresentação

O final desse dia foi muito legal! Voltamos para o auditório principal onde rolou uma mesa redonda com todas os palestrantes do dia (trilha testes) e o público pode fazer perguntas e discutir as questões levantadas. Tivemos perguntas das mais variadas. O encerramento se deu com sorteio de brindes para os participantes.

Abaixo uma relação de links das ferramentas apreentadas no dia. Fonte: http://sembugs.blogspot.com.

Abraço e até o segundo dia! ;)

mai 26 2011

Uma nova visão e além….

A ideia desse texto é passar para vocês um ponto de vista sobre a análise de sistemas que estudei  esses dias em sala de aula, a ideia que segue abaixo nos foi apresentada pelo professor Claudiomir Selner e que de antemão já adianto que compartilho desse ponto de vista.

Vamos começar fazendo uma viagem, isso mesmo pode ser de formatura, final de ano, férias qualquer coisa….

Vamos todos para New York, afinal de contas, dinheiro não falta mesmo não é?

Todos com suas bagagens preparadas…indo pro aeroporto….hora de partir….lá fomos…

Enquanto as asas do avião quase congelam, a ansiedade toma conta dos que não adormeceram.

Algumas horas depois lá estamos, todos felizes, curiosos, alguns cansados…bom, numa viagem assim qual é o item que não pode faltar??

Câmeras fotográficas e filmadoras é claro, afinal queremos guardar esse momento, registrar tudo.

Primeiro local a ser visitado, estátua da liberdade, chegamos lá, obtemos algumas informações com o guia turístico, e em seguida queremos fotografá-la….são cliques para todo lado, são diversas poses com a estátua ao fundo, umas fotos ficam boas, outras nem tanto, mas afinal a câmera é digital, basta apagar e bater de novo.

Vamos a um outro detalhe, logo ali perto existe uma banca de jornais que vende cartões postais da estátua da liberdade e é claro outros pontos turísticos de new York.

Bom, não seria uma atitude muito mais inteligente se comprássemos um desses cartões postais? Vamos aos motivos: primeiro, a pessoa que bateu a foto é um profissional, ela conhece as melhores posições de acordo com o horário, sabe como obter a melhor iluminação, a qualidade da sua câmera é muito superior, conhece os ajustes finos que otimizam a qualidade, enquanto que as nossa câmeras  possuem apenas algumas opções pré-configuradas, com certeza o dia em que a foto foi batida, estava melhor do que o dia que visitamos….etc.

Com todos esses motivos, porque não compramos um cartão postal em vez levarmos as câmeras? Você deve estar pensando “mas no cartão postal eu não apareço”, legal, é um dos motivos.

Mas o principal motivo pelo qual não queremos nem saber dos cartões postais é que na verdade nós queremos registrar o EVENTO, esse é o nosso ponto principal, não estamos interessados em atributos estáticos da estátua, altura, largura, para onde está direcionada, quantas toneladas pesa, esse atributos estão for a da nossa visão, pois não nos interessa.

Quando realizamos uma análise de sistemas devemos nos deter nos eventos, nas interações entre objetos, não em atributos estáticos, sabe porque?

Porque os atributos são estáticos. Os problemas só ocorrem quando há interações entre as partes, é aí que devemos nos deter.

Atributos estáticos assim continuarão até que um evento os altere, e se um evento não alterar, não teremos problema ali.

Você já viu algum notebook dar problema? Nenhum notebook dá problema só!

Acontece que um notebook em uma prateleira de loja não apresenta nenhum problema, os problemas aparecem quando começam surgir interações, interações entre o note e o usuário, entre o note e a corrente elétrica, entre o note e certa condição climática, é aí que os problemas aparecem, do contrário, tudo certo.

Você agora deve estar pensando…”é realmente ele tá viajando…” então vamos continuar….

Bom vamos a outro exemplo. Uma nota fiscal. Uma nota fiscal nunca teve nem terá problema algum até que alguém comece a interagir com ela, enquanto isso ela é perfeita e não lhe causará problemas.

Mas quando alguém lançar informações nessa nota, aí sim devemos ficar atento, pode haver um lançamento incorreto, um percentual tributário diferente do que deveria ser, e isso pode gerar enormes problemas com o fisco, mas enquanto isso não ocorre, seus atributos estáticos estão lá! ESTÁTICOS!

Por que devemos nos atentar a eles se eles não causam problemas? NÃO devemos nos atentar a eles!

Lembre-se devemos nos deter nos eventos que ocorrem em um sistema, e aqui o sentido da palavra sistema, não é referente a Sistemas de Informação mas a análise de sistemas sociais direcionados para softwares, é aí que começa a análise!

O analista de sistemas tem que esta no meio dos problemas, dando identidade a eles caracterizando-os e não na frente de uma IDE escrevendo códigos.

As ferramentas de um analista de sistemas deveriam ser o Word, o Outlook e o seu navegador preferido!

Se atentem  para o foco da análise de sistemas, e experimentem dar outra perspectiva a essa prática!

Pensem!

Abraço!

abr 15 2011

Não testar x TDD

Olá pessoal, esse post foi sugerido por um amigo meu, Leonardo Cidral, ele indicou esse assunto, e é um tema bem interessante e que está cada vez mais em evidência no desenvolvimentos de softwares, então vamos lá.

Testar aplicações deve ser um item primordial do desenvolvimento de sistemas, faz parte do seu profissionalismo. Você não terá um sistema estável, fácil de modificar, com baixo custo de manutenção se você não realiza testes. Isso mais cedo ou mais tarde, acarretará grandes problemas.

Existem 2 tipos de desenvolvedores  que não realizam testes:

  •  Chuck Norris
  •  Desenvolvedor amador

Você é Chuck Norris? Provavelmente não, então já sabe qual sua classificação.

“Desenvolvedor que não testa, é como um cirurgião que não lava as mãos!” (Robert C. Martin “Uncle Bob”). 

Mas o que é TDD?

A sigla significa Test Driven Development – Desenvolvimento Dirigido por Testes. È uma técnica que visa escrever os testes antes mesmo de escrever o código fonte! Estranho? No começo pode parecer que sim, mas com o tempo você verá os benefícios que ele trará no seu dia a dia.

Essa prática foi popularizada por Kent Beck na eXtreme Programming (XP), ela parte da ideia que será escrito um código apenas para o teste falho passar. Não haverá linhas de códigos desnecessárias no seu sistema, cada parte do seu código será testada antes de entrar em produção.  

Como funciona?

TDD = Test First Desing (TFD) + Refactoring

A primeira coisa a se fazer é escrever um pequeno teste antes mesmo de o código existir.  O primeiro teste escrito irá falhar, claro, ainda não há código para testar, em seguida você escreve o código e testa novamente, se passar, o próximo passo é a refatoração. A partir daí esse é o ciclo que será seguido. É importante que você avance os testes seguindo os baby steps, ou seja, avance em passos bem curtos, para ter um bom controle do seu código, com o passar do tempo, você começa a adquirir segurança nessa técnica, pode ir um pouco além, mas é sempre prudente e recomendado que não avancemos muito na hora de escrever um teste.

Fluxo TDD

Um desing limpo e agradável.

Imagine a seguinte situação, você vai até a cozinha prepara o alimento, se alimenta e sai, você não lavou a louça. No dia seguinte repete a situação, e no outro também e assim vai fazendo…. Essa rotina de preparar se alimentar e sair, é a mais rápida nesse momento, você consegue ganhar tempo com isso, porém algum tempo depois você terá uma cozinha imunda, você não tem nem coragem de entrar nela, a sua vontade nesse momento seria eliminá-la do resto da sua casa e reconstruir uma nova, nem as baratas conseguem sobreviver mais lá.

Essa analogia, é exatamente o que ocorre com os códigos  criados de qualquer jeito, chega um momento que os programadores têm medo de fazer qualquer alteração, aquele fonte agora tem vida própria, é praticamente um hardware, é impossível alterar ele sem causar outros problemas. Durante  o seu desenvolvimento, as funcionalidades eram adicionadas sem o mínimo de cuidado, não havia refatoração nesse código, não havia o mínimo de boas práticas, havia muito CTRL+C e CTRL+V. Não podemos negar que há também outros fatores que contribuem para isso.

O TDD garante um desing limpo, ágil, produtivo no momento atual e no futuro também. Todo o seu código fonte é escrito na medida em que atende a especificação, nada além disso será necessário, em seguida você executa o teste e se ele passar, pronto, só refatorar . Quem está no comando agora são as especificações de testes que foram criadas, elas são quem guiarão o seu fonte para atingir o resultado.

Quando você usa TDD, seu resultado será um código bem testado, refatorado, limpo, onde  sua manutenção será extremamente rápida e produtiva hoje e no futuro, e não haverá funcionalidades surpresa para o usuário, o código está livre de bugs, o programador tem segurança no seu código, grandes alterações não afetarão o funcionamento do sistema.Precisamos deixar claro que o TDD não é de uso obrigatório, mas testes SÃO OBRIGATÓRIOS

Um ponto que merece ser destacado é que o TDD se utiliza dos testes para dirigir o desenvolvimento, mas o foco real é o design da aplicação, e não os testes, ou seja, no momento que você escreve um teste e o código ainda não existe, então não há testes nesse momento, o que há é uma especificação para atender um determinado requisito, no instante seguinte, você escreve o código, realiza o teste e ele passa, agora você tem um teste nas mãos, mas antes disso aquela especificação não testava nada, apenas especificava algo. 

No exato momento em que escrevo esse post (02:25 da manhã), vejo na tv uma reportagem sobre o sistema da Prodesp que está causando uma enorme dor de cabeça para unidades do DETRAN em São Paulo, o sistema trava, e não mais retorna, alunos são dispensados das aulas, outros aguardam um tempão para tentar fazer suas aulas, os funcionários estão no limite da paciência. A Prodesp se manifestou por telefone, informando que tem conhecimento do problema, e está trabalhando para corrigir. Alegam que o problema tem como causa, o grande número de instrutores que acessam o sistema simultaneamente.

Será que existe algum teste que poderia prever essa situação? Claro que sim! Será que tiveram o cuidado de fazer? Acho que a reportagem já respondeu!

Atenção! TESTES SÃO OBRIGATÓRIOS!

Referências:

 http://www.agiledata.org/essays/tdd.html

http://unplugged.giggio.net/unplugged/post/TDD-nao-existe.aspx

Abraços!

jan 29 2011

É hora de mudar

O mercado de desenvolvimento de softwares anda bastante aquecido, logo temos uma grande demanda de sistemas em desenvolvimento e a serem desenvolvidos. O que ocorre é que temos muitas tecnologias novas no mercado, e muitas outras ainda virão, porém temos um sério problema relacionado ao sucesso do projeto. Quando eu falo sucesso, me refiro a entregar no prazo previsto (ou muito próximo disso, visto que é uma previsão), dentro dos custos previamente definidos e o mais importante, entregar algo que realmente será usado.

O último item parece um pouco sem sentido, porque “como vou entregar algo que não será usado?”. A realidade é que isso ocorre com muita frequência, muita mesmo. Esse problema tem várias causas, como disse no início deste texto, as tecnologias mudaram e mudarão muito, mas a forma com que são utilizadas, permaneceu praticamente imutável.  Muitas empresas adquirem novas ferramentas apenas para transmitir a ideia de que trabalham com a última versão do “martelo”. Um amigo meu costuma usar a expressão “Martelada Design”, que não deixa de ser o mesmo que XGH (Extreme Go Horse). Claro que não podemos generalizar todo esse contexto, pois existem muitas empresas preocupadas em entregar valor para seus clientes, porém uma grande fatia do mercado ainda é assim.

Obter sucesso em um projeto de software significa atender a três critérios principais como mostra o triângulo abaixo:

Valor para o cliente – significa entregar algo que realmente será útil para ele, algo que fará diferença no seu negócio, que traga resultados para o cliente, e não algo que seja usado parcialmente, ou quase nunca;

Prazo: é necessário estabelecer datas que possam ser cumpridas para o início e fim do projeto. Hoje podemos acompanhar muitos projetos nascerem com atraso já, se começam com atraso, imagina a entrega, e isso não é exceção;

Orçamento Previsto: um projeto demanda recursos, que podem ser instalações, equipamentos, treinamentos, viagens, consultoria externa etc. É comum os projetos ultrapassarem os valores iniciais previstos, inclusive, às vezes gerando prejuízo para a empresa desenvolvedora.

Claramente podemos ver que as três pontas do triângulo estão fortemente relacionadas. Qualquer alteração em uma delas implicará claramente nas outras duas, o triângulo tem que ser flexível, ele não pode ser rígido (ou seja, adaptar o andamento do projeto e seus custos, de acordo com o contexto atual, e não em algo definido no passado). Muitas empresas não avaliam essa relação, por isso é grande o número de projetos com inúmeras falhas.

De acordo com um estudo do Standish Group, de 1994 até 2006 obtivemos uma melhora na entrega com sucesso dos nossos projetos, porém depois houve uma queda até 2009. A tabela abaixo mostra essa situação.

Acontece que o principal fator de sucesso de um projeto não é a tecnologia utilizada e sim os 2 P´s do sucesso. O quesito tecnologia, interfere em fatores como custos do projeto e facilidades extras. Umas são mais produtivas, outras nem tanto, umas exigem um esforço maior para uma atividade e outra pode fazer a mesma coisa com o mínimo de esforço, porém se você já conhece a tecnologia que você utiliza, saberá estimar corretamente (ou pelo menos deveria). Com certeza você conhece grandes projetos utilizados por grandes empresas e que foram desenvolvidos na tecnologia X ou na tecnologia Y.

 

Os 2 P´s que me refiro são: Pessoas e Processos. Esses sim são fatores que determinarão o sucesso ou o fracasso de um projeto. Mais crítico que alterar a tecnologia que uma empresa utiliza, é a mudança de cultura, essa sim, leva tempo, enfrenta resistências, gera muitos descontentamentos, pois fere algumas pessoas. A cultura de uma empresa compreende os processos empregados e o “engajamento” dessas pessoas nos processos, afinal os processos são concebidos pelas pessoas, são elas que detém essa capacidade de gerar, manter e melhorar os processos empregados na empresa.

 

Processos ultrapassados, enrijecidos, ou porque o “gerente bacana” observou que em algum momento obteve sucesso e é assim que deve ser, devem ser revistos sim, o mundo está em constante mudança, quem não se adapta acaba por ficar para trás, isso vale para empresas e colaboradores.

Hoje vimos empresas apenas querendo resultados em cima de resultados, nesse momento que elas querem é uma “aceleração” nos processos, e acreditam que se tudo for mais rápido, obterão melhores resultados. Primeiro, temos que mudar a “fonte” dos resultados, porque se querem resultados diferentes, devem ter ações diferentes, a definição de insanidade de Einsten é: “fazer sempre as mesmas coisas esperando resultados diferentes”.

 

Não chegaremos a um nível ideal de sucesso em nossos projetos se não focarmos nossas mudanças no ponto chave do negócio. As mesmas raízes geram sempre os mesmos frutos.

Referências: Standish Group

Abraços!