Disciplina X Metodologia

É engraçado como em computação as pessoas se preocupam em usar os nomes corretos. Mesmo assim, alguns nomes são trocados o tempo todo. Um exemplo clássico é o de Disciplina e Metodologia que conceitualmente possuem o seguinte significado:

Disciplina: É como uma estrutura que fornece orientação, permite a análise mesmo para itens não previstos. (O que fazer).

Metodologia: Fornece direções especificas para lidar com situações conhecidas, consiste em um conjunto de métodos, sendo um método a abordagem passo a passo para realizar tarefas. (Como fazer).

Parecem coisas como água e óleo, mas funcionam muito bem quando combinadas, um exemplo, é o próprio RUP (Rational Unified Process) que é uma metodologia divida em disciplinas, ou seja, em níveis superiores é fornecido a forma de fazer e em níveis mais detalhados é uma orientação do que fazer.

As pessoas aprendem esses termos de diversas formas e utilizam como bem entendem, eu nem sei dizer se a descrição feita acima é a mais utilizada. Agora o que fica estranho é durante uma conversa você ouvir a mesma palavra com 4 ou 5 significados diferentes vindos da mesma pessoa. Eu acredito que em conversas técnicas o ideal seria procurar manter a semântica, pois esse é o propósito do uso de conceitos. Não é mais complicado quando é necesssário explicar o que você está tentando dizer?

Utilidade X Garantia, simples?

Estava lendo um material sobre ITIL e me deparei com um conceito relativamente simples:

Utilidade (Utility): É o que o cliente precisa, caracteriza o que o serviço faz.

Garantia (Warranty): É como o cliente precisa, caracteriza como o serviço é entregue (entenda entrega como o serviço em produção).

Na prática também parece simples, a “Utilidade” é descrita pelos requisitos funcionais e a “Garantia” é descrita pelos requisitos não-funcionais.

No entanto é ai que começam alguns dos problemas. Em geral, os requisitos não-funcionais (usabilidade, confiabilidade, desempenho e suportabilidade) são descritos de forma incompleta e nesse “deslize” as promessas feitas para o cliente e para si mesmo dizendo que, dessa vez, nesse novo projeto, “tudo vai ser diferente”, devem tomar mais tempo para acontecer.

Existem desculpas para os requisitos mal escritos. Um argumento padrão é aquele “Não há como ter uma boa estimativa de carga”, mas e quanto a estimativa de capacidade do sistema? Que tipo de profissional não conhece o resultado do seu trabalho!?

Como um sistema pode ser entregue sem ao menos um conjunto de testes de confiabilidade e desempenho? Isso parece um absurdo mas é a realidade em muitas empresas no Brasil. Depois de pronto, o sistema é implantado e aos poucos os problemas surgem. O diagnóstico em produção é mais dificil do que no ambiente de testes e, em muitos casos, o cliente paga para arrumar o que ele já pagou para não estar “quebrado”.

O conceito “tão simples” do efeito da combinação de Utilidade e Garantia exige bem mais trabalho do que parece para ser posto em prática. A habilidade de entrega de um serviço com determinado nível de garantia é realmente um grande diferencial competitivo.

Links:

• http://www.baguete.com.br/blogs/post.php?id=3,246
• http://itilblues.wordpress.com/2007/12/14/itil-v3-utility-and-warranty-two-sides-of-the-same-coin/

ITIL - O que vou dizer lá em casa?

Como estou estudando para a certificação ITIL V3, um amigo me recomendou um blog chamado ITIL Blues para esclarecimento de dúvidas e curiosidades. Lá encontrei um post entitulado “Seven “ITIL is not” statements” que lista sete coisas que o ITIL não é. Veja o post original em inglês aqui e a tradução abaixo:

1. Não é tecnologia – É gerenciamento de serviço de TI.

2. Não é a palavra final – É uma referência, um bom começo.

3. Não ensina como fazer nada – É um norte sobre o que fazer.

4. Não é uma ferramenta – São responsabilidades, atividades, resultados… que precisam de ferramentas.

5. Não é instantâneo – É gradual (para humanos!).

6. Não é mágica – Apenas re-uso de senso comum.

7. Não é pacífico – Sempre aponta para mudanças organizacionais.

Esta lista me serviu para esclarecer o que era ITIL para pessoas que nunca tinham ouvido falar nisso e para aqueles que ouviram e entenderam errado. Como quando somos crianças e aprendemos o conceito de certo ouvindo nossos pais nos dizerem de forma incansável a palavra "não". E não é que funciona? :)

Referência: http://itilblues.wordpress.com/

Quem é responsável pela qualidade de software?

Sempre que trabalhei com desenvolvimento de software, ele era realizado internamente nos modelos comuns de demanda de automação para serem utilizados pelo cliente-patrocinador ou como um produto da empresa. A qualidade sempre foi uma grande preocupação e, em alguns casos, os custos das atividades relacionadas com “qualidade” foram maiores que a implementação do software. Dentre essas atividades, temos: auditoria de documentos, revisões de projeto, revisões amostrais de código, testes manuais e automotizados, etc. Acredito que o mínimo esperado de um software de qualidade deve ser que os usuários finais realmente tenham condições de utilizar o software, ou seja, nenhum erro nas principais funcionalidades, bom desempenho e interface amigável.

Essa realidade ficou no passado, pois agora por motivos diversos estou diante da necessidade de contratação de fornecedores. Fornecedores que fazem mil promessas durante a venda do serviço e, ao serem questionados sobre a dificuldade de se construir o sistema que está sendo negociado, adoram "bater no peito" e dizer frases como: “isso é muito simples”, “fazemos isso o tempo todo”, “acabamos de entregar algo parecido para outro cliente”, “temos um desenvolvedor que entende tudo dessa tecnologia”, e muitos profissionais dessa área se sentem confortáveis ao ouvir esse tipo de coisa mas esquecem que depois da entrega, o suporte, muitas vezes, será feito pela sua equipe interna.

Após a entrega os problemas começam, em alguns sistemas já na fase de implantação. Ao precisar fazer alguma simples alteração ou correção de algum bug pequeno, olhamos para dentro do código e vemos que algumas partes foram feitas com ‘preguiça de pensar’ e em entregar algo bem construído. Agora o que vejo nessas outras empresas é algo que se parece com um pacto em que, por vezes, qualidade é atropelada pelo tempo, “nunca há tempo para fazer bem feito” ou para realizar todos os testes.

Entendo que “qualidade” é um conceito subjetivo, mas se as empresas em modo geral, não apenas da área de TI, ignoram isso é como se ignorassem o próprio cliente. Existem vários modelos, metodologias e processos a respeito, porém acho difícil serem usados com essa cultura de que os gastos com esse tipo de atividade são opcionais ou desnecessários.

Porque quando desenvolvemos softwares internos eles geralmente têm uma ótima qualidade? Logicamente porque as reclamações vêm dos colegas ao lado e de si mesmo, é o chamado dog food. A qualidade é cobrada na hora do almoço ou do cafézinho, talvez não seja o melhor meio, mas é uma forma de exigir qualidade.

É verdade que existem milhares de empresas atualmente com este tipo de serviço no Brasil, mas o que para alguns é visto como um mercado já saturado e concorrido, eu vejo como um mercado cheio de oportunidades e a busca do diferencial pode ser basear-se em um ponto elementar: a qualidade do que é entregue ao cliente. Parece muito simples mas. Infelizmente, não é uma realidade.

Então quem é responsável pela falta de qualidade em software em um país onde temos as várias competências necessárias? Muitos diriam que é um problema de gestão dentro dessas empresas fornecedoras mas eu não acredito nisso. Penso que é de responsabilidade do cliente em não mais aceitar esse nível de serviço, porque só assim pode ocorrer uma mudança fundamental no mercado, cortando a fonte de receita dessa empresas. Obviamente isso não é algo simples, ainda mais para clientes sem uma boa área de TI para realizar esse tipo de avaliação. Portanto, cabe a nós enquanto clientes exigir que tenha qualidade e, claro, pagar o preço justo por isso.

Desenvolvimento Ágil

Esta semana um amigo me emprestou a revista TIDigital, edição novembro 2009, que possui uma matéria bem interessante sobre desenvolvimento ágil. Após ler a matéria, resolvi escrever um post a respeito do assunto.

Em conversa com esse mesmo amigo sobre a aplicabilidade de metodologias ágeis, chegamos a conclusão de que tais práticas funcionariam melhor em uma equipe de sêniors, não em registro, mas sim em maturidade.

Conheça o Manifesto Ágil aqui.

Além do manifesto, existem 12 princípios a serem seguidos para o desenvolvimento ágil de software:

1° princípio:

“Nossa maior prioridade é satisfazer o cliente através de entregas rápidas e contínuas de software usual”.

Sabe-se que a entrega é um dos maiores desafios da industria de TI, dado o atual grau de insucesso dos softwares. Confira o Chaos Report confeccionado pelo Standish Group:

Repare que o Standish Group entende como fracassado (vermelho) um projeto cancelado ou entregue e nunca utilizado e como desafiado (amarelo) um projeto que atrasou, custou mais ou entregou menos. O gráfico demonstra que em 2009 os projetos considerados sucesso (verde) somam aproximadamente 30% contra 70% de softwares fracassados ou desafiados. Imagine se mudássemos o cenário, e que ao invés de software, estivéssemos falando de carros, isso significaria que a cada 10 carros que você comprasse, apenas 3 funcionariam e 7 não funcionariam ou funcionariam com inúmeros problemas.

2° princípio:

“Seja bem vindo à mudança de requisitos, mesmo que tardiamente, no desenvolvimento. Processos ágeis aproveitam a mudança para a vantagem competitiva do cliente”.

3° princípio:

“Entregar software utilizável frequentemente, e algumas semanas a alguns meses, com preferência e menores escalas de tempo”.

Pequenas entregas aumentam muito a chance de sucesso de um software. Quando o software é colocado em produção é que pode-se verificar se ele atende a necessidade daquele negócio ou não de forma menos abstrata. Confira o gráfico do Standish Group para o uso das funcionalidades de um software:

Note que apenas 7% do software é utilizado sempre e 13% utilizado frequentemente, e que 64% do software é nunca ou raramente utilizado. Isso significa dizer que em um projeto de 1 milhão de reais, o cliente pagaria 640 mil por funcionalidades talvez desnecessárias.

4° princípio:

“Executivos e desenvolvedores devem trabalhar juntos diariamente durante o projeto”.

5° princípio:

“Construa projetos em torno de indivíduos motivados. Dê-lhes o ambiente e a ajuda de que eles precisam e confie neles para ter o trabalho concluído”.

6° princípio:

“O método mais eficiente e eficaz de transmitir informações para uma equipe de desenvolvimento e dentro dela é a conversa face a face”.

Por experiência própria posso confirmar que o método mais eficaz para transmitir informações é pela conversa face a face. Geralmente escrevo melhor do que falo, coisa que faz meus emails ficarem formais demais e, por consequencia, ríspidos, isso pode causar no receptor um certo desconforto, insegurança, raiva, etc.

7° princípio:

“Software funcional é a medida primordial do progresso”.

8° princípio:

“Processos ágeis promovem desenvolvimento sustentável. Os patrocinadores, desenvolvedores e usuários deveriam ser aptos a manter um ritmo constante indefinidamente”.

É comum ouvirmos piadas a respeito da inconstância no desenvolvimento de software. Costuma-se dizer que “os primeiros 90% do software levam 90% do tempo para ficarem prontos e os 10% finais levam mais 90% do tempo para serem concluídos”.

9° princípio:

“Atenção contínua à excelência técnica e bom design aumentam a agilidade”.

10° princípio:

“Simplicidade – a arte de maximizar a quantidade de trabalho não feito – é essêncial”.

11° princípio:

“As melhores arquiteturas, requisitos e design surgem de um time auto-organizado”.

É tempo de as fábricas de software passarem da versão 1.0 para a 2.0, pois assim como a web, devem ter um caráter colaborativo mais intenso.

12° princípio:

“Em intervalos regulares, o time reflete sobre como tornar-se mais eficiente, então sintoniza e ajusta seu comportamento”. (Lembra da consideração inicial sobre a equipe de sêniors?)

Deseja saber mais sobre o assunto? Clique aqui e leia uma reportagem completa sobre SCRUM, um dos métodos ágeis mais utilizados atualmente e que vem se popularizando no Brasil, publicada na revista TIDigital na edição de abril/09.