sexta-feira, 15 de abril de 2011

Problema de comunicação

Outro dia recebi, via e-mail, uma piada muito boa. Veja:

Um homem anda por uma estrada próxima a uma cidade, quando percebe, a pouca distância, um balão voando baixo. O balonista lhe acena desesperadamente, consegue fazer o balão baixar o máximo possível e lhe grita:
- Ei você, poderia ajudar-me? Prometi a um amigo que me encontraria com ele às duas da tarde, porém já são duas e meia e nem sei onde estou. Poderia me dizer onde me encontro?
O outro homem, com muita cortesia, respondeu:
- Mas claro que posso ajudá-lo! Você se encontra em um balão de ar quente, flutuando a uns vinte metros acima da estrada. Está a quarenta graus de latitude norte e a cinqüenta e oito graus de longitude oeste.
O balonista escuta com atenção e depois pergunta-lhe com um sorriso:
- Amigo, você trabalha como analista de sistemas?
- Sim, senhor, ao seu dispor! Como conseguiu adivinhar?
- Porque tudo o que você me disse está perfeito e tecnicamente correto, porém esta informação me é totalmente inútil, pois continuo perdido. Será que você não tem uma resposta mais satisfatória?
O analista fica calado por alguns segundos e finalmente pergunta ao balonista:
- E você, não seria por acaso um Gerente?
- Sim, por um acaso sou um gerente. Porque?
- Ah, foi muito fácil! Veja só: Você não sabe onde está e nem para onde vai. Fez uma promessa da qual não tem a mínima idéia de como irá cumprir e ainda por cima espera que outra pessoa resolva o seu problema. Continua exatamente tão perdido quanto antes de me perguntar. Porém, agora, por um estranho motivo, a culpa passou a ser minha...

Surpreendentemente, isto ocorre nos projetos de verdade! :)
É evidente que não ficamos andando de balão por aí, mas as circunstâncias são as mesmas de um projeto de desenvolvimento de software. É obvio, também, que nem todos os projetos são assim.
Qual é o problema neste cenário? A resposta está no título. A comunicação, assim como em qualquer ambiente corporativo, é importante para o bom andamento dos processos e manutenção da produtividade da equipe. No entanto, entender o que uma pessoa pensa, não é assim tão fácil.
Por exemplo: adivinhe no que estou pensando? Ah, difícil, né? Pois então, no conto acima, podemos supor que ou o analista não entendeu o intuito da pergunta do gerente ou então, de fato, não quis ajudá-lo.
O balonista queria uma solução ao realizar a pergunta. O que ele desejava era saber para que lado deveria ir, porém, não tinha a menor idéia de onde estava. Já o andarilho respondeu "ao pé da letra" à pergunta do balonista não atingindo o objetivo da pergunta, que na verdade era: "Para onde devo ir?"
Em um desenvolvimento de software quando não há um "entrosamento" entre os membros da equipe às vezes ocorrem situações parecidas. Isto é, a resposta não satisfaz a necessidade de informação do questionamento.
A solução deste problema está além do simples processo de desenvolvimento de software. Aliás, é um problema inerente ao convívio em sociedade. Como por exemplo: a mãe (uma pessoa da geração saúde) vê o filho tomando refrigerante e comendo alta quantidade de doces e gorduras no café da manhã. Assustada com a situação ela pergunta: "O QUE É ISSO?!" O garoto, em sua ingenuidade, responde com um leve ar de questionamento e sem entender muito bem, responde: "Café da manhã."
Sim, a resposta está sintaticamente correta e coerente com a pergunta. No entanto, a mãe esperava uma resposta como: "É só hoje, mãe." ou "Eu sei que isso faz mal, mãe."
A comunicação não se dá apenas por palavras, mas também por gestos, expressões e talvez um "sexto sentido". Pode ser por isso que as mulheres tendem a ter um melhor desempenho nas atividades de levantamento de requisitos.
Enfim, a parte engraçada é que no final da piada o analista é bastante sincero com o gerente de projetos, o que nem sempre ocorre em uma equipe.

quinta-feira, 24 de fevereiro de 2011

Processo, metodologia e ferramentas.

Outro dia durante uma aula de Engenharia de Software surgiu a discussão sobre o que é processo, metodologia e como as ferramentas se encaixam neste contexto.
Surgiu-me um ideia paralela interessante. Até eu fiquei surpeendido com tamanho improviso. Comparei um sistema de informação (software) com nosso sistema digestivo.
Um sistema é por definição um conjunto de partes, cada uma com sua respectiva responsabilidade, que juntas e interconectadas atingem o objetivo final do dito sistema. (Tenho que colocar as referências bibliográficas aqui depois).
Oras, se um sistema é um todo formado por partes, um software é um conjunto de funcionalidades que executam suas respectivas funções de modo a cumprir o papel deste software. Assim é também com o sistema digestivo: temos o mastigador, o deglutidor, o canal que liga o deglutidor com o triturador etc. Ambos são sistemas.
Mas onde está o processo e a metodologia? Vamos por partes:
Processo é um conjunto ordenado de atividades. O processo digestivo é uma sequencia de tarefas executadas pelas suas partes. No desenvolvimento de software, o processo é também uma sequencia de atividades excutadas pelas suas partes, neste caso, o pessoal da equipe.
Voltando ao exemplo do sistema digestivo: o processo digestivo de um humano é diferente de um processo digestivo de um boi (espero que sim). Logo estes dois seres possuem um processo diferente para executar a digestão. No entanto, dois humanos possuem o mesmo processo digestivo, mas cada um pode ter uma metodologia diferente. O que influencia nesta diferença são as ferramentas.
Mesmo com ferramentas iguais, um humano pode utilizar uma metodologia diferente que outro humano. Quando digo ferramentas estou falando do mastigador, do deglutidor, do triturador etc.
Se um humano possui somente os dentes molares, supõe-se que a metodologia do processo digestivo será diferente de um outro humano que possua somente os dentes incisivos. Logo, ambos executam processos iguais, mas com metodologias diferentes, pois suas ferramentas são diferentes.
Se trouxermos este exemplo para o desenvolvimento de software, poderemos entender o que é processo e metodologia, bem como as ferramentas influenciam nesta última. Ferramentas no desenvolvimento de software, entendo como linguagens de programação, arquiteturas de software, design patterns etc.
Este foi o paralelo que fiz para poder tentar expor o que é processo, metodologia e ferramentas de desenvolvimento de software.

Até a próxima, pessoal.

P.S.: eu sei que no sistema digestivo humano não chamamos a boca de mastigador, a língua de deglutidor, o estômago de triturador. Mas também não vamos discutir biologia aqui, né! :)

quinta-feira, 10 de fevereiro de 2011

Qualidade x Garantia

Pessoal, o objetivo desse post é lançar uma discussão sobre qualidade, garantia e riscos de um projeto. Concordando com o que eu disse ou não, vamos discutir!!

Muito se fala sobre os transtornos que a falta de qualidade de um projeto causa ao usuário. Alguém ai já parou para pensar no prejuízo (financeiro e de imagem) que isso causa em um fornecedor?!

Imaginem a seguinte situação hipotética: Uma fábrica sofre pressão para entregar projetos dentro do prazo e custo previstos e o escopo já foi reduzido ao mínimo. O que acontece na maioria dos casos? Os testes são ignorados negligenciados e o projeto é entregue "daquele jeito" cheio de bugs.

 Imaginem também que o cliente não tem maturidade suficiente e aceita o produto da forma como ele foi entregue, assinando toda papelada e dando inicio a tão sonhada fase de garantia!

O fornecedor na maioria das vezes não recebe um centavo pela garantia, então qualquer recurso alocado a estes projetos dão prejuízo. Como o projeto foi entregue cheio de bugs, é possível ter recursos alocados 100% do tempo durante o período total da garantia! O fornecedor tem que bancar o salário da equipe sem receber nada por isso.

Agora eu pergunto: Será que abrir mão da qualidade faz sentido? É melhor entregar o software de qualquer maneira e arrumar na garantia? Vale a pena manter recursos caros com conhecimento profundo do projeto ou contratar recursos mais baratos sem conhecimento do negócio?

domingo, 6 de fevereiro de 2011

Processo de engenharia de software

Para entendermos o que é um processo de engenharia de software, primeiro temos que saber o que é um processo e o que é engenharia de software. Vamos aos conceitos.

Processo 

Segundo o dicionário Houaiss, processo é o modo de se fazer alguma coisa, um método, uma maneira. Essa explicação é muito simples e fácil de compreender, porém não atende completamente a nossa realidade. Pela etimologia da palavra, processo vem do latim processus que quer dizer ir para frente, êxito. Ok! Juntando os dois significados temos que processo é um modo de se fazer alguma coisa para obter um êxito. Agora sim condiz mais com a realidade de uma fábrica de software. 

Engenharia de Software

                A engenharia de software é uma disciplina da engenharia relacionada com todos os aspectos da produção de software. Abrange desde os estágios iniciais de especificação do sistema até sua manutenção, depois que este entra em operação (SOMMERVILLE, 2007). De forma geral, engenharia de software é a utilização de sólidos princípios de engenharia a fim de obter softwares de maneira econômica, confiável e que trabalhem eficientemente em máquinas reais (BAUER, 1969). Pasmem, a Engenharia de Software é mais velha do que parece.
Juntando os termos temos: Processo de Engenharia de Software.
Modelo Cascata - Fonte: Thiago FP Blog

                De uma forma bem simples, um processo de engenharia de software é um conjunto de atividades e resultados associados que produz um produto de software: Especificação, Desenvolvimento, Validação e Evolução de Software.
Com base no processo de engenharia de software começam a aparecer diversos modelos de engenharia de software. Esses modelos são apenas descrições simplificadas e abstratas de um processo. Contemplam as atividades, os produtos de software e os papeis das pessoas envolvidas na engenharia de software. Existem basicamente dois modelos: Cascata (Cleanroom) e Interativo (Rational Unified Process – RUP). Outros modelos também são conhecidos, mas não fizeram tanto sucesso quanto os dois citados.
Modelo Iterativo - Fonte: Devmedia

Atualmente existe uma forte tendência no uso de modelos de desenvolvimento ágil. Esses modelos vieram para quebrar alguns paradigmas do desenvolvimento de software que os modelos “tradicionais” implantaram. Porém isso não está sendo feito da melhor forma. Mas isso é assunto do meu outro post. É importante ressaltar que o modelo ágil não está errado. Errado é a forma como as pessoas os têm implementado. Bom, o importante aqui é ressaltar a existência desses modelos, que eles estão se tornando cada vez mais fortes e propondo “mudar” o mundo. Cumpre lembrar que os outros modelos já citados também tentaram fazer isso.


Modelo Ágil - Fonte: EMC Consulting


Bibliografia
SOMMERVILLE, I. Engenharia de Software. 8a edição. São Paulo: Pearson Addison-Wesley, 2007.

quarta-feira, 19 de janeiro de 2011

Ágil não é bagunça

Antes de divagar – arduamente, morosamente e penosamente – sobre o tema abordado no título, gostaria de apresentar uma pequena história com os motivos que me fizeram escrever sobre o assunto.

Bom, era uma vez há mais ou menos três meses estou trabalhando em um novo emprego e tive algumas oportunidades de atuar em melhoria de processo e artefatos. Esse contato me motivou a estudar mais sobre o assunto, o que me levou aos processos ágeis. Em uma conversa de cafezinho com um líder de projetos aqui da empresa, concordamos que as pessoas confundem processos ágeis com agilidade – confesso que já fui um desses. Esse é o principal foco do texto. Além desses fatos, há umas duas semanas participei de um treinamento formal em SCRUM, com foco nas características e aspectos de processos ágeis.

Passados os contos da carochinha, vamos ao que interessa. Atualmente, no mercado, temos uma quantidade grande de processos e métodos ágeis. São eles:

·         Programação extrema (XP);
·         Scrum;
·         Feature Driven Development;
·         DSDM;
·         Adaptive Software Development;
·         Crystal;
·         Pragmatic Programming e
·         Test Driven Development.

Mas o que todos esses processos têm em comum?
Apesar de apresentarem focos diferenciados (gestão de projeto, desenvolvimento de software) eles possuem valores em comum. Esses valores contrapõem os valores existentes nos processos “tradicionais”.

Bom, como vocês podem ver o manifesto ágil prega que o software em funcionamento tem maior valor que a documentação do mesmo. Entretanto, em momento algum, diz para não documentar. É como no desenvolvimento de um carro. Quem pede para ter o projeto, o manual e a especificação de arquitetura do carro? Nós clientes queremos o carro pronto e funcionando. Claro que o manual é importante, mas você não consegue sentar no manual e guiá-lo por aí.

Ok, ok... Eu sei que a analogia não foi das melhores, mas o que eu quis dizer é que o mais importante para o cliente é um produto, um resultado que agregue valor ao seu negócio. Casos de Uso, Documentos de Arquitetura, Planos de Teste, Solicitações de Mudança, entre outros artefatos não agregam valor ao negócio do cliente. São importantes para o projeto e, principalmente, para a manutenção do software; mas apenas esses artefatos não atendem as necessidades dos clientes (melhoria em vendas, aperfeiçoamento de processos, entre outros). Ele precisa – e quer o software.

Então como desenvolver um software sem documentação e que não dê dor de cabeça para a manutenção?
Como diria o Jack, vamos por partes.

Como dito agora a pouco, os processos ágeis apóiam a elaboração de artefatos que sejam essenciais ao desenvolvimento do produto. Contudo, eles não dizem que é proibido fazer documentação. Levando em consideração esses aspectos, acredito que os projetos ágeis funcionariam da seguinte forma:

Modelo de Desenvolvimento Ágil


Repare que no nesse modelo existe documentação antes e após o desenvolvimento do produto. Na etapa de Pré-produto temos a modelagem do negócio, o entendimento do problema (Visão) e um estudo de viabilidade como exemplo de documentação. Esses três passos são fundamentais, é nesse momento que saberemos se as metodologias ágeis serão bem empregadas na construção do produto, ou se o modelo tradicional será a melhor escolha.

No meio do modelo é onde colocamos a mão na massa. Nesse momento todo o esforço é concentrado para desenvolver o produto com agilidade e qualidade. Nessa etapa o projeto deverá seguir a técnica ágil definida com o cliente. Veja o modelo do SCRUM:
O processo Scrum.

Cada uma dessas etapas é bem definida e segue regras rígidas de o que fazer. Ou seja, cada uma dessas etapas deve acontecer. É preciso existir o “Product Backlog”, o “Sprint Backlog”, as “Sprints”. Sem esses passos, o produto não será entregue de forma incremental. Importante lembrar que quando se entrega um pedaço do sistema não quer dizer que esse pedaço deve em produção, mas que essa parte do produto é reconhecida pelo cliente, tem que ser algo tangível. Já no final do modelo, temos as atividades que envolvem a documentação do produto.

Após toda essa lengalenga, podemos concluir que metodologias ágeis não é essa bagunça toda como dizem. E que pode sim ter todo o sistema documentado da forma que o cliente exige.

Leia mais: