Contra a Corrente

Quero É Viver

João Hugo Miranda — Thu, 11 May 2006 12:20:00 GMT

Procurar sempre mais, empurrar os horizontes sempre para mais longe. Manter a inquietação e ansiedade que me impede de parar. Beber a vida com sofreguidão. Receber com gratidão tudo o que ela tem para nos oferecer. Fazer por merecê-lo, mesmo que nem sempre seja possível. Recusar que a mediocridade, a ignorância e o egoísmo me prendam no fundo.

Hoje é um bom dia. Aproveitem-no.

por António Variações

Vou viver
até quando eu não sei
que me importa o que serei
quero é viver

Amanhã, espero sempre um amanhã
e acredito que será
mais um prazer

e a vida é sempre uma curiosidade
que me desperta com a idade
interessa-me o que está para vir
a vida em mim é sempre uma certeza
que nasce da minha riqueza
do meu prazer em descobrir

encontrar, renovar, vou fugir ao repetir

vou viver,
até quando, eu não sei
que me importa o que serei
quero é viver
amanhã, espero sempre um amanhã
e acredito que será mais um prazer

a vida é sempre uma curiosidade
que me desperta com idade
interessa-me o que está para vir
a vida, em mim é sempre uma certeza
que nasce da minha riqueza
do meu prazer em descobrir

encontrar, renovar vou fugir ao repetir

vou viver
até quando eu não sei
que me importa o que serei
quero é viver,
amanhã, espero sempre um amanhã
e acredito que será mais um prazer

Velocidade

João Hugo Miranda — Sun, 12 Feb 2006 12:30:00 GMT

Uma vez que já escrevemos um conjunto de histórias e já as estimámos, podemos começar a pensar numa release. Ok, uma mini-release, mas não se esqueçam que é um exemplo, os nossos dois programadores estão atolados em trabalho por isso vão levar tempo a concretizar as histórias... extrapolem!! ;)

O facto é que uma vez tendo as histórias, a pergunta do cliente mais natural é: "Quanto é que temos isto pronto?". Ou, talvez mais provável, já temos uma data definida à priori e temos de ver como encaixar as histórias nessa data... :) De qq das maneiras, para podermos realizar o planeamento da release, falta-nos uma peça. Como mapear as estimativas, que são realizadas em dias ideais, em dias reais, em esforço real? É aqui que entra o conceito de Velocidade.

A Velocidade é o número de dias ideais que pode ser realizada numa iteração do projecto (uma release é constituída por um conjunto de iterações, mas estamos a adiantarmo-nos...), ou seja o esforço que pode ser dispendido numa iteração. Sabendo que uma iteração costuma ter a duração de uma a quatro semanas reais, é necessário estimar o número de dias ideais que cabem neste período. Muito bem, mas então como estimamos a velocidade??

A dificuldade está na primeira estimativa, dado que não temos nada de concreto (o projecto ainda não começou) em que nos basear. Existem pelo menos três soluções: Usar dados históricos; Fazer uma primeira iteração para chegar a um valor; Atirar um número para o ar.

Utilizar dados históricos é uma boa hipótese, mas tem alguns problemas. O principal é que é relativamente raro uma mesma equipa fazer projectos muito semelhantes consecutivamente. No entanto, se esse for o caso, tire-se partido disso! Atenção que um projecto semelhante feito por uma equipa diferente pode não ser uma boa base para definir a velocidade, dado que as características da equipa podem ser diferentes.

Realizar uma primeira iteração também seria uma boa hipótese, mas não será muito realista. Quantas vezes é que já conseguiram dizer a um cliente: "Olhe, vamos trabalhar umas semanitas e depois logo decidimos como será o desenrolar o projecto daí para a frente." e ele não se desatou a rir? Bom, mas se tiverem essa possibilidade aproveitem, potencialmente pode ser a melhor solução.

Atirar um número para o ar, não é mujito agradável, mas também não é o fim do mundo. Por vezes, não há outra possibilidade. Nesta situação, o facto de utilizarmos como estimativas dias ideais ajuda bastante. Para chegar a um número para a velocidade, ajuda tentar contabilizar a foram como os elementos da equipa têm gasto o tempo ultimamente - tarefas recorrentes; outros projectos em que estejam empenhados; trabalho ad-hoc - e com base nisso chegar a um número.

É importante tentarmos chegar a um valor minimamente realista, mas não tem de ser perfeito nem este número tem de ser um dogma. Se o fosse, deixava de ter qualquer relevância... quem consegue prever o futuro com 100% de correcção são os videntes, não somos nós, pobres informáticos.

Pegando no nosso exemplo, e dado que os nossos programadores estão assoberbados de trabalho, a velocidade definida é de 4 dias ideais. Ok, a velocidade estimada é uma miséria, mas é o possível... O chefe não quer contratar mais gente, dá nisto....

Uma vez obtida uma velocidade inicial, podemos começar a pensar em fazer um release plan.

Architects Forum 2006

João Hugo Miranda — Fri, 10 Feb 2006 22:55:00 GMT

Ontem e hoje decorreu o Architects Forum 2006, em Lisboa. (Muito) infelizmente apenas consegui ir ao primeiro dia, mas posso dizer que gostei muito e saí de lá menos céptico do que quando entrei. Antes de mais, deixem-me dizer que gostei bastante do orador, Beat Schwegler. Claro, conciso, objectivo, esclarecedor, informal e humorista q.b. (gostava que fosse ainda mais, mas é questão de gosto...). Não vou entrar em muitos detalhes sobre a apresentação, estou a contar que outros o façam... hint, hint!

O tema foram as Software Factories (o nome não é brilhante, como já várias pessoas o disseram), um temo que conheço ainda muito pela rama. Confesso que não lhe dei a atenção devida porque cheirou-me muito a nova tentativa de algo requentado e com falhas de base: tentar eliminar a necessidade de escrever código, podendo fazer tudo visualmente... a ideia do arquitecto génio e os programadores meros operários... nah! Se pensarmos que sou um grande apologista das metodologias ágeis, julgo que podem compreender melhor o meu cepticismo. Por outro lado, a questão das Domain Specific Languages (DSL) é algo que me interessa e provavelmente vai interessar ainda mais num futuro mais ou menos próximo.

O início da apresentação estava a confirmar os meus piores receios. O Beat começou com uma analogia com o fabrico dos aviões, como eles pensam tudo muito bem antes de avançar com a construção... como nós ainda somos artesãos (o que é verdade e é mau)... E no entanto... E no entanto, à medida que a apresentação foi avançando foi sempre a subir. As ideias subjacentes - Software Product Lines, Architectures Frameworks, Model-driven development e Guidance In Context - às Software Factories parecem-me muito válidas e perfeitamente compatíveis com as metodologias ágeis.

Um ponto fulcral das software factories é não se pretender que elas sejam uma solução para todos os problemas. Não, a ideia é criar um conjunto de artefactos orientados a um determinado domínio do problema, standardizando tudo o que é comum, mas deixando em aberto a possibilidade de configurar e costumizar de forma simples. Ok, a ideia não é nova, mas a solução parece-me ter pernas para andar.

Outros pontos muito interessantes são a correspondência directa entre código e linguagem visual - algo a que se dá muita importância e que se pode contrastar com a geração de código via UML - e o ênfase que eles parecem mostrar no campo dos deployments e das operações, algo sempre muito negligenciado.

Em resumo, para já estou convencido. Lá vou ter de ler o "Software Factories: Assembling Applications with Patterns, Models, Frameworks, and Tools". Bom, depois de ler o "Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions", que já comecei a ler... e o "Working Effectively with Legacy Code" e o "Agile Database Techniques", que já encomendei... Ai, ai... pq é que o dia não tem mais horas (mas só para mim, pq se não não servia de nada....)

Só falta o filho... "Desenvolvimento Orientado Por Objectos - Domain-Driven Design, Testes Unitários e Refactoring"

João Hugo Miranda — Tue, 07 Feb 2006 21:42:00 GMT

Notícia requentada, mas acho que chegou a altura em que sinto que pode ser dada por mim.

Este pequenino livro (ISBN: 9896150133) editado em Outubro de 2005 pela Centro Atlântico foi escrito por mim e pelo José Almeida (o blog não tem sido muuuiiito actualizado, mas quem sou eu para falar... ;) ):

O nome é "Desenvolvimento Orientado Por Objectos". Ok, o título não é o mais original, mas o importante é o subtítulo: "Domain-Driven Design, Testes Unitários e Refactoring". Um conjunto de práticas que ajudam qualquer programador a tornar-se mais produtivo e a divertir-se mais com o seu trabalho. Os exemplos são em C#, mas como é natural, os conceitos aplicam-se a qq linguagem orientada-a-objectos e, nalguns casos, mesmo a linguagens assentes noutros paradigmas.

O livro não pretende ser um estudo exaustivo destas técnicas. Para isso há livros mais completos e escritos por brighter minds than ours, a que aliás fazemos referência nos nossos escritos. O objectivo do livro é simples: oferecer uma introdução simples, muito prática, e em português sobre estes assuntos, para todos aqueles que são curiosos e gostam de aprender mas que não têm tempo e/ou paciência para ler grandes calhamaços ou não gostam de ler em inglês.

O livro está disponível nalgumas lojas on-line e também nas livrarias mais conhecidas. Comentários arrasadores são bem-vindos. Comentários bajuladores já chegam!!! ;P

Pq é que só escrevi sobre ele agora? Ainda bem que perguntam. Por uma razão idiota: dado que não escrevia há tanto tempo no blog, não me sentia bem em escrever apenas para fazer "publicidade". Agora que tenho escrito mais (vamos ver até quando...), já me senti mais confortável com o assunto.

User Stories e Planeamento - Estimativas

João Hugo Miranda — Sat, 04 Feb 2006 13:14:00 GMT

Acho que é uma boa altura para concretizar um pouco melhor esta coisa das User Stories e de como podemos realizar planeamentos (Release e Iteration Planning) com base nestas.

Consideremos um exemplo a que recorri anteriormente. Imaginemos que o cliente pretende uma funcionalidade muito comum hoje em dia: "Um potencial cliente do nosso site deve poder registar-se de modo a receber notícias, ofertas, entre outros tipos de contactos."

É possível encontrar muitas histórias, mas mesmo muitas... Vamos ser pouco ambiciosos para já, considerando as seguintes histórias (criadas numa User Story Workshop).

"Um cliente deve-se registar indicando como código de utilizador o e-mail e escolhendo uma palavra-chave alfa-numérica."
"O cliente deve receber um e-mail de confirmação do registo."
"O cliente só fica devidamente registado depois de responder ao e-mail de confirmação."
"O cliente deve poder fornecer dados adicionais, como título honorífico, morada, telefone ou idade."
"A equipa de Marketing (Mkt) deve poder criar o conteúdo, em HTML, das mensagens (e-mails, sms, mms, ...) sem auxílio da equipa técnica."
"A equipa de Marketing pode escolher os destinários das mensagens com base nas características fornecidas pelos clientes."
"A equipa de Marketing pode despoletar o envio das mensagens sem intervenção da equipa técnica."
"A equipa de Marketing deve poder definir um grupo de destinatários de teste, que receberão as mensagens antes do envio das mensagens para os clientes."
"As mensagens devem ser personalizadas com o título honorífico e o nome do destinatário."

Temos aqui muitas histórias, que exigem esforços variados. Vamos assumir que as estimativas obtidas, de acordo com o processo de que falámos anteriormente, chegamos aos seguintes valores:

História	Estimativa
"Um cliente deve-se registar indicando como código de utilizador o e-mail e escolhendo uma palavra-chave alfa-numérica."	3
"O cliente deve receber um e-mail de confirmação do registo."	2
"O cliente só fica devidamente registado depois de responder ao e-mail de confirmação."	1
"O cliente deve poder fornecer dados adicionais, como título honorífico, morada, telefone ou idade."	1
"A equipa de Marketing (Mkt) deve poder criar o conteúdo, em HTML, das mensagens (e-mails, sms, mms, ...) sem auxílio da equipa técnica."	5
"A equipa de Marketing pode escolher os destinários das mensagens com base nas características fornecidas pelos clientes."	2
"A equipa de Marketing pode despoletar o envio das mensagens sem intervenção da equipa técnica."	3
"A equipa de Marketing deve poder definir um grupo de destinatários de teste, que receberão as mensagens antes do envio das mensagens para os clientes."	2
"As mensagens devem ser personalizadas com o título honorífico e o nome do destinatário."	3

Dado que a equipa técnica é constituída por apenas por dois programadores sobrecarregados, com mais do que um projecto em simultâneo, temos aqui trabalho para algum tempo. Não se esqueçam que as estimativas são em dias ideais e os nossos dois amigos estão longe de ter dias ideais...

Nos próximos posts veremos como podemos partir daqui para o planeamento do projecto. E parece-me que o mais adequado não serão gráficos de Gantt nem Waterfalls. O tempo não está para isso...

Estimando User Stories

João Hugo Miranda — Mon, 30 Jan 2006 23:02:00 GMT

Nota prévia: Muito dos conceitos aqui descritos baseiam-se num livro muito interessante escrito por Mike Cohn e editado pela Addisson-Wesley com o título "User Stories Applied - for Agile Software Development". Os conceitos não são originais, mas este livro faz um muito bom trabalho na sua descrição.

Já vimos como as User Stories podem funcionar com a "peça de Lego" a partir da qual o cliente pode especificar as funcionalidades que pretende para o sistema. Mas as suas virtudes não se ficam por aqui, dado que também são uma óptima ferramenta para as actividades de planeamento. Comecemos por uma tarefa basilar: estimativas.

As User Stories, dado o facto de descreverem um pequeno pedaço de funcionalidade (com valor para o negócio), devem poder ser implementadas num espaço de 1 a 5 cinco dias ideais. Um dia ideal é um dia em que trabalhamos todo o tempo na implementação de uma história. Como é natural, raramente temos esta oportunidade, mas usar dias ideiais simplifica o processo. Como as histórias têm uma curta duração, torna-se mais difícil, mas não impossível, de fazer erros muito grandes de estimativas. É de realçar que o objectivo não é realizar estimativas perfeitas, até porque isso é impossível. O objectivo é termos algo para trabalhar. Os acertos e o controlo do andamento do projecto faz-se de outras formas.

Vejamos então como estimar a duração de uma história.

Estimar como equipa

Como em tudo o que é metodologia ágil, também o processo de estimação deve ser feito pela equipa e não individualmente. Note-se que não tem de ser necessariamente toda a equipa, mas o cliente e vários elementos da equipa técnica devem estar presentes. Por um lado, estimar em equipa permite obter mais opiniões e esclarecer mais dúvidas sobre as histórias. Por outro, ajuda a criar espírito de equipa e de trabalho conjunto. É necessário sentir que todos remam para o mesmo lado, todos têm a sua quota-parte de responsabilidades. Mentes iluminadas (arquitectos...) que definem estimativas para outros cumprirem não é boa ideia a este nível.

Como estimar

O processo começar com a equipa técnica a fazer todas as perguntas que considere necessárias ao cliente, de modo a poder realizar estimativas o mais sólidas possíveis (o que não quer dizer correctas) sobre uma dada história. Note-se que não deve ser o cliente a realizar estimativas, mas a equipa técnica. Uma vez esclarecidas as dúvidas, inicia-se um curto processo iterativo. Primeiro, cada elemento da equipa técnica escreve num papel a sua estimativa, sendo muito importante que ninguém divulgue a sua estimativa antes de todos terem terminado. Em segundo lugar, todos indicam a sua estimativa. O mais natural é que existam estimativas díspares, logo o terceiro passo passa por cada um justificar as suas estimativas. Finalmente, tudo volta ao primeiro ponto. Ao fim de duas ou três iterações, as estimativas tendem a coincidir.

Triangulação

Ao fim de umas quantas histórias, começa a tornar-se possível utilizar uma técnica auxiliar, a triangulação. A triangulação é muito simples. Imaginemos que temos uma história que leva 2 dias ideais a concretizar e outra 4 dias ideais. Ao considerar uma terceira história, podemos balizá-la, comparando-a com as estimativas das outras duas histórias. Por exemplo, se estimarmos 3 dias ideais, então ela deve exigir mais esforço do que a primeira história e menos do que a segunda.

Como podem ver, o processo é simples e muito intuitivo. O processo de estimação de histórias funciona como a base para a definição do planeamento do projecto, tanto para iterações como para releases... Mas isso é tema para outros posts...

Castle

João Hugo Miranda — Sat, 21 Jan 2006 23:51:00 GMT

Há uns meses atrás encontrei um projecto que pareceu interessante, mas a que não dei muita atenção: o Castle. O Castle é como que um projecto de projectos e é fortemente inspirado na Web Framework do momento, o Ruby on Rails (RoR). O RoR não é .Net, mas é muito interessante e permite aprender umas coisas. Não deixem de dar uma vista de olhos.

Como dizia, o Castle é um projecto de projectos, integrando-os de forma elegante. Os seus mentores são muito pragmáticos e tiram proveito de um conjunto de componentes (ou aplicações) já existentes. Entre os diversos componentes do Castle contam-se:

MonoRail - uma plataforma Web MVC (mais ou menos equivalente ao Action Pack do RoR).
ActiveRecord - equivalente ao ActiveRecord do RoR, implementa o padrão com o mesmo nome tal como definido no PoEAA, do Martin Fowler. Utiliza ferramentas já existentes de OR/M, como o NHibernate ou o iBatis.Net.
Aspect# - Uma framework de Aspect-Oriented Programming.
Windsor - Uma ferramenta de Inversion of Control.
DynamicProxy - um componente que facilita a criação de proxies de objectos.

Nota importante: Ainda está muito orientado para .Net 1.1, à semelhança da maioria dos projectos Open Source.

Infelizmente ainda não tenho experiência prática com o Castle (nem sei quando terei tempo para tal), mas pelo que li, promete!

Mais sobre as User Stories (Histórias)

João Hugo Miranda — Sat, 21 Jan 2006 22:49:00 GMT

No meu post anterior descrevi o conceito de user stories, mas acho que faltou realçar um ponto importante.

Toda a filosofia subjacente às metodologias ágeis exige comunicação, comunicação, comunicação. O cliente e a equipa de desenvolvimento têm de construir uma relação de confiança e abertura. Por vezes, como sabemos, isso é bastante complicado, mas é dever da equipa de desenvolvimento (e também do cliente, mas este não podemos controlar) fazer tudo ao seu alcance para que essa relação se estabeleça. Sobretudo não deve encarar o cliente como alguém que só está ali para dificultar a vida nem pensar que quanto mais longe ele estiver melhor. A atitude de "eu e o código", do programador-cowboy, é fatal.

A definição das histórias não deve ser feita pelo cliente e formalizada num documento que depois é entregue à equipa de desenvolvimento. Essa atitude mata a comunicação e dificulta (para não dizer que impede) que uma relação saudável e de cooperação seja estabelecida. Se for realmente necessário - para obedecer a normas ou exigências de certificação, por exemplo - as histórias podem ser formalizadas num documento, mas este deve ser sempre um produto da comunicação profícua entre cliente e equipa de desenvolvimento.

Aliás, os proponentes das user stories defendem que apenas a descrição e os testes de aceitação devem obrigatoriamente ser escritos algures (as hipóteses são muitas, mas a mais defendida é a do papel e lápis...). As conversações que permitem compreender melhor a história devem ser sobretudo orais, precisamente para obrigar à comunicação entre cliente e equipa de desenvolvimento. É claro que isto nem sempre é possível e como sempre, devemos adaptar as recomendações ao nosso contexto.

User Stories

João Hugo Miranda — Thu, 19 Jan 2006 23:27:00 GMT

Um dos maiores... desafios (a palavra é muito maltratada, mas enfim) do desenvolvimento de software é a especificação de requisitos. É uma tarefa muito complicada devido a múltiplos factores.

Do meu ponto de vista, e na opinião de gente muito mais brilhante do que eu, o maior problema é que é tremendamente difícil, impossível mesmo, para o cliente descrever o que pretende, de for objectiva e não ambígua, apenas com o esforço da imaginação. A linguagem natural é naturalmente (pun intended) ambígua. O cliente, ou um seu representante como um gestor de produto, muda de ideias a meio do percurso, como é natural e desejável. Num ambiente em constante mudança, temos de entrar na onda e não contra ela.

Se a isto juntarmos uma relação contratual entre cliente e fornecedor, baseada na especificação de requisitos de uma coisa tão volátil como o software, temos meio caminho andado para o desastre: uma luta feroz na interpretação de umas folhas de papel. Não é por acaso que as empresas de software não costumam ser demasiado bem vistas...

Bom, mas então não temos solução? Como é que vamos conseguir manter o rumo com tantas nebulosas pelo caminho? Como vamos saber o que temos de construir, como acompanhamos a construção, como estimamos a data de entrega? Para quem conhece a filosofia que eu sigo, a solução provém de algumas práticas das metodologias ágeis, especialmente Extremme Programming.

User Stories

A primeira peça do puzzle são as user stories. Uma história não é mais do que a descrição de uma pequena funcionalidade que o cliente pretende ver desenvolvida no sistema. Estas são a unidade atómica da especificação de requisitos, no sentido em que não é possível partir as user stories em conceitos mais pequenos e é a partir delas que se define todo o planeamento.

Uma user story é constituída por:

Um pequena descrição da história, utilizada como lembrete e para as actividades de planeamento.
Conversações sobre a história, entre clientes e programadores, de modo a detalhar a história e esclarecer dúvidas.
Um conjunto de testes de aceitação.

Um ponto muito importante, e comum a todos os métodos de especificação de requisitos, é que as histórias devem ser escritas pelo cliente ou por um seu representante e nunca pela equipa de desenvolvimento. As histórias devem apresentar claramente algo de valor para o cliente.

Analisemos cada um dos pontos com base numa funcionalidade muito comum: "Um potencial cliente do nosso site deve poder registar-se de modo a receber notícias, ofertas, entre outros tipos de contactos." A possibilidade de se registar como utilizador de um site é uma característica cujo desenvolvimento pode ser muito complexo, pelo que convêm dividir a tarefa em algo mais pequeno, em várias user stories.

Pequena descrição

A primeira parte de uma história é uma pequena descrição, de uma ou duas frases, de modo a que nos possamos referir à história de forma simples sempre que necessário, nomeadamente no planeamento. Para o nosso exemplo, é possível encontrar muitas histórias, cujas descrições podiam ser:

"Um cliente deve-se registar indicando como código de utilizador o e-mail e escolhendo uma palavra-chave alfa-numérica."
"O cliente deve receber um e-mail de confirmação do registo."
"O cliente só fica devidamente registado depois de responder ao e-mail de confirmação."
"O cliente deve poder fornecer dados adicionais, como morada, telefone ou idade."

De certeza que vocês podem encontrar muitas outras, mas acho que dá para perceber a ideia. A história deve ser uma coisa simples, passível de completar em pouco tempo, idealmente de 1 a 5 dias.

Conversações sobre a história

Como é natural, não é possível construir a funcionalidade apenas com as mini-descrições. Bom, possível será sempre, mas o mais provável é que o resultado final seja bastante diferente do pretendido pelo cliente. Sendo assim, é fundamental que cliente e equipa desenvolvimento discutam entre si a história de modo a esclarecer tanto quanto possível o pretendido.

Peguemos na história "O cliente deve receber um e-mail de confirmação do registo.". Existem um conjunto de questões que saltam imediatamente à vista. O cliente (o nosso, não o do site) deve poder alterar o conteúdo do e-mail sem intervenção da equipa de desenvolvimento? O e-mail deve ser personalizado? Deve ser enviado em texto puro, RTF, HTML? Todas estas questões devem ser debatidas e esclarecidas entre cliente e equipa de desenvolvimento antes e durante a construção da história.

Estas conversações também têm por objectivo permitir à equipa de desenvolvimento estimar o tempo de construção da história, um ponto importante mas que vou deixar para outra altura. ;)

Testes de aceitação

Os testes de aceitação têm uma finalidade semelhante à dos testes funcionais, confirmar que o sistema funciona de acordo com a especificação. No entanto, seguem uma filosofia muito diferente. A cada história estão associados um conjunto de testes de aceitação, que devem ser definidos pelo cliente, antes da construção da história. Apesar de ser o cliente o primeiro responsável pela definição dos testes, a equipa de desenvolvimento, especialmente se tiver experiência no tipo de sistema a ser desenvolvido, também pode contribuir com a definição de alguns testes.

O nome, testes de aceitação, tem como objectivo indicar que estes são os testes que o cliente definiu como sendo necessários o sistema passar de modo a que a história possa ser dada como concluída. Assim, temos uma forma clara e objectiva de saber se temos o trabalho pronto ou não, uma vantagem importantíssima.

Imaginemos a história "Um cliente deve-se registar indicando como código de utilizador o e-mail e escolhendo uma palavra-chave alfa-numérica.". Que testes de aceitação podemos definir? Não é difícil de imaginar alguns:

"O código de utilizador deve ser validado que tem o formato de um email, tanto quanto possível. Por exemplo, o código de utilizador joao.hugo.miranda@pardaisaoninho.com deve ser válido mas o código de utilizador joao não."
"Uma palavra-chave não deve aceitar caracteres que não os A-Z, a-z e 0-9."
"Depois de registado, o cliente deve receber uma confirmação provisória do registo."
"Se o código de utilizador estiver errado, o cliente deve ser informado do motivo."

O mais bonito, é que muitos destes testes podem ser automatizados. A framework mais famosa é o Fit\Fitnesse.

Em resumo, as histórias são o ponto de partida para resolver muitos dos problemas associados ao planeamento e à especificaçãod e requisitos. São simples, estabelecem critérios bastante objectivos de conclusão, são facilmente entendíveis por todos os envolvidos.

Há muito mais para dizer sobre histórias, mas... não é para já. Se estiverem interessados, leiam o livro que indiquei acima ou outro sobre Extreme Programming. Entretanto, espero escrever mais algumas coisas sobre isto mas não tenho sido muito regular nos últimos... meses!!! ;P

Voltei a programar - Construção do Sistema (Logging)

João Hugo Miranda — Thu, 07 Jul 2005 22:26:00 GMT

Neste quinto post irei falar um pouco sobre uma parte que costuma ser muito negligenciada, pelo menos no desenvolvimento de aplicações servidor: Logging. Não terá muitoa ver com agilidade, mas também aqui existem alguns pontos importantes.

O componente de logging que utilizei foi o log4net (inspirado no log4j), do qual tomei conhecimento pela primeira vez através de um post do Pedro Santos. Outras possibilidades são o componente da Microsoft Enterprise Library ou o NLog (que nunca experimentei). O componente é muitíssimo bom e recomendo-o vivamente.

Desde o início do projecto, defini que a lógica de logging seria cidadão de primeira classe. A generalidade dos sistemas com os quais me deparei tem uma infra-estrutura de logging fraca... algumas vezes miserável ou inexistente mesmo! Este é um problema gravíssimo no momento em que o sistema passa a produção, como tenho a certeza que todos vocês reconhecem. O padrão habitual da infra-estrutura de logging, pela minha experiência tem as seguintes características:

Utilização de apenas dois níveis de log: Erro e Debug. Nível de Aviso, Info ou outros, apesar de estarem disponíveis, são ignorados.
O nível de Erro regista excepções (ou Err.Raises no VB6). O nível de Debug regista entrada e saída de métodos.
As outras, poucas mensagens, são do tipo: "Estou aqui 1...", "Estou aqui 2...", "Passei, carago!".

Quando a aplicação passa a produção e começam a surgir os primeiros problemas, o resultado é o óbvio: horas infindas à procura do problema; adição de mensagens de forma totalmente ad-hoc e à pressão. Estou convencido que os problemas com as mensagens de log são fortes indutores do síndrome de abstinência do programador: "Eu preciso de acesso a Produção! Preciso! Dá-me acesso a Produção! Se não me deres acesso, amuo! Como é que eu sei o que se passa com o MEU sistema?"

Eu sou tão culpado disto como todos os outros. No meu primeiro projecto, necessitei de pegar em código legado. A minha primeira decisão? Apagar todas as mensagens de log que o componente continha. Quando chegou a Produção é que foi o bom e o bonito... um episódio muito revelador da minha "verdura" e da preocupação com a qualidade da empresa para que trabalhava...

Bom, neste projecto as coisas foram muito diferentes. Defini diversas linhas de orientação:

Abandonar os logs "mecânicos" no início e no fim de cada método.
Pensar em cada momento quais as mensagens de logs necessárias. Qual o texto da mensagem, e quais os dados a "loggar", tendo o devido cuidado com dados potencialmente sensíveis.
O texto da mensagem de log deve estar sempre o mais próximo possível da linguagem do domínio, com as excepções em que a parte realmente importante é a técnica (detalhes de pedidos HTTP/XML, por exemplo).
Utilizar todos os níveis de log de forma construtiva. Decidir conscientemente qual o nível de log a que uma dada mensagem pertence.
Periodicamente, nos code reviews, analisar especificamente os logs. "Se a aplicação falhasse neste ponto, conseguia perceber o que se tinha passado até ao momento?", "Este log deve ser um info, um debug, um warning?"
Tomar em atenção o potencial impacto na performance das mensagens de log.
Criar testes unitários para as mensagens de log.

O resultado final, do meu ponto de vista, é muito satisfatório. Ao ler os logs no nível Info, é possível compreender facilmente o fluxo de execução do programa, os seus blocos lógicos. Aumentando o nível para Debug é possível, para além disso, recolher um manancial de informação, detalhada, que permite compreender o que realmente se passou durante a execução do programa.

Os logs foram úteis também numa outra situação. Por vezes, quando criamos testes, é dificíl testar determinados comportamentos internos (privados) de um objecto, existindo múltiplas técnicas para lidar com a situação. Algo de que tomei consciência neste projecto é que em algumas situações os logs permitem testar de forma indirecta esses comportamentos, o que representa uma vantagem adicional. É claro que este deve ser uma espécie de último recurso (ou recurso complementar), mas é mais uma ferramenta que podemos utilizar.

No próximo post... acho que será sobre performance counters. Também é algo muito engraçado.

Voltei a programar - Construção do Sistema (TDD)

João Hugo Miranda — Wed, 06 Jul 2005 21:55:00 GMT

Este é o quarto post sobre um projecto em que tive de conciliar formalidade com agilidade, no qual abordarei a Construção do Sistema do ponto de vista do programador.

O príncipio orientador de todo o processo foi utilizar o Test-Driven Development (TDD), o que implica escrever os testes unitários antes do código em si (A parte "Red, Green" do mantra) e fazer Refactoring intensivamente (A parte "Refactor" do mantra). Consegui seguir a prática em toda a sua pureza? Não, por duas razões principais.

Em primeiro lugar, devido aos constrangimentos relacionados com a necessidade de ter um desenho detalhado antes de avançar para a construção, naturalmente que não pude escrever os testes antes do código, pelo menos a 100%. No entanto, estes constrangimentos não me impediram de alterar o desenho sempre que necessário e não me impediram de criar os testes antes de criar o corpo do método (se bem se recordam, a API foi criada na fase de desenho, mas os métodos estavam todos vazios, sem código). De certa forma, confirmou-se aquilo em que acredito: o peso de definir a API previamente não compensa os ganhos, na maior parte dos casos. O BUFD (Big Up-Front Design) não compensa, especialmente nos casos em que os requisitos são mais voláteis. É claro que sou parcial, mas é a minha convicção, baseada na minha experiência e na de projectos que acompanhei de fora.

Em segundo lugar, ainda me falta alguma prática. É um método muito diferente do habitual e que exige prática. Nomeadamente, sinto que os meus testes podem ser simplificados, ou seja, nalguns casos crio testes demasiado grandes, que verificam demasiadas coisas. Apesar disso, este é um ponto em que acho que estou bastante melhor agora do que há uns meses atrás. Seguir o mantra "Red, Green, Refactor" - criar o teste, fazê-lo passar o mais depressa possível, arrumar o código - exige prática e concentração. Sinto que ainda posso melhorar um bocado, especialmente na separação entre o Green e o Refactor. Nalgumas situações mais complexas, ainda tendo a misturar as duas coisas e é importante mantê-las separadas.

No entanto, os efeitos do TDD são dramáticos, algo que senti desde que comecei a praticá-lo. Mesmo quando ainda tinha muito pouca (ou nenhuma) experiência na prática, mas muita vontade de aprender, a sensação de liberdade e segurança é extraordinária (às vezes demasiada...). O TDD liberta-nos do constragimento que costuma agrilhoar o processo de desenvolvimento: o medo de mexer (If it ain't broke, don't fix it). Com o TDD o software fica realmente soft, como diz o Fowler ou o Beck, a sua manipulação torna-se possível e deixa de ser uma coisa rígida... a comparação da programação com a engenharia civil perde um pouco o sentido... ;)

Ao longo do processo de Construção o desenho do Sistema sofreu múltiplas alterações. Diversos conceitos, que estavam escondidos, apareceram e foram explicitados em objectos. O desenho final do Sistema é bastante melhor do que o inicial, algo que é muito raro acontecer com os métodos tradicionais. A liberdade de experimentar e moldar, com a segurança e disciplina do TDD, é algo que uma vez experimentado não se quer voltar a perder.

Sem o TDD conseguiria toda esta flexibilidade? Não, não e não. A qualidade do desenho decairia à medida que se ia dando uma marteladinha ali, outra acolá, "só mais este toque aqui". Expressões como "Sei que é uma martelada, mas agora não há tempo", é algo que tende a desaparecer de uma forma totalmente natural, sem esforço. Claro que nunca desaparece totalmente, afinal o mundo real é cheio de imperfeições.

O TDD liberta-nos da necessidade de testes funcionais (ou de aceitação)? Não, de maneira nenhuma. Os testes funcionais abordam um problema diferente. Os testes unitários orientam o Programador, ajudam este a seguir o caminho que pretende. Os testes de aceitação certificam que o Sistema faz o que o Cliente pretende. Podem ser duas coisas diferentes... mas práticas como realizar iterações de desenvolvimento muito curtas, de que falei no post anterior, garantem que a dessincronização entre Programador e Cliente é negligenciável.

No próximo post continuamos com a saga, para não tornar o post demasiado grande e maçador...

Voltei a programar - A Construção do Sistema (Gestão de Projecto)

João Hugo Miranda — Tue, 05 Jul 2005 07:23:00 GMT

Se bem se recordam, nos dois posts anteriores abordei o modo como ataquei o problema de ter de realizar um projecto de forma ágil, como eu acredito que é mais produtivo e motivador, num enquadramento mais tradicional, de quatro fases: Concepção, Elaboração, Construção e Transição. Nos outros dois posts abordei as duas primeiras fases, vou agora falar da terceira.

A Construção

A fase de Construção foi aquela em que se tornou mais simples conciliar a agilidade com a formalidade.

Iniciei esta fase com a definição do planeamento detalhado de toda a fase de Construção (+/- 2 meses), o que não é muito ágil... No entanto dividi o planeamento em iterações semanais, tendo por base duas linhas orientadoras:

As user stories. As tarefas foram definidas em termos de implementar user stories, utilizando sempre a Linguagem Ubíqua e evitando termos técnicos. Por exemplo, não dividimos as tarefas em termos de camadas (UI, Negócio, BD), mas em termos de "Implementar Repositório de Templates", ou "Gerar documentos Word Mono-Conteúdo".
Obter um aplicação funcional em permanência. No fim de cada iteração, a aplicação teria de ter qualidade para passar a produção se necessário.... e fazer algo de útil.

Estas duas linhas orientadoras permitiram que a aplicação estivesse num estado "controlado", quase em permanência, e permitiu também que a aplicação estivesse "usável" quase desde a primeira iteração. Reparem que estas duas características, pelo menos na minha experiência, são difíceis de conseguir numa aplicação desenvolvida através do modelo tradicional, simplesmente porque estas duas características não fazem parte dos objectivos definidos ao longo do projecto, mas apenas no fim do projecto.

Para além disso, no início de cada iteração, ou seja, semanalmente, tinha uma reunião com o meu chefe, onde analisávamos a iteração anterior e, em função dessa iteração e das anteriores a essa, ajustávamos o planeamento. Neste caso em concreto, a diferença em relação ao normal não é muita. A diferença é que ajustávamos sempre o planeamento tendo como regra dividir as tarefas em iterações de uma semana. Tarefas que não estivessem terminadas numa dada iteração eram partidas em duas, sempre que possível.

Do ponto de vista de gestão do projecto, estas eram as grandes linhas. Por exemplo, no que diz respeito ao relacionamento com o cliente não havia grandes questões porque os clientes eramos nós... Posso afirmar que as duas linhas orientadoras que definimos tiveram uma importância fundamental no controlo (e sucesso) do projecto. É algo que recomendo vivamente, seja qual for (bom, já sabemos que hão-de existir algumas excepções...) o tipo de metodologia utilizada.

No próximo post abordarei a parte mais técnica do projecto, ou seja, a construção propriamente dita.

Voltei a programar - A Elaboração do Sistema

João Hugo Miranda — Tue, 28 Jun 2005 07:21:00 GMT

Se bem se recordam (não foi assim há tanto tempo), estou a meio de uma história sobre a conciliação entre formalidade e agilidade... Entremos nas fases mais interessantes. No post anterior descrevi a fase de Concepção que não tem muito que saber. Avancemos para a próxima.

Elaboração

O Problema

Na fase de elaboração realiza-se a análise funcional e técnica: elaboramos o caderno de requisitos; definimos a arquitectura do sistema; enquadramo-lo com os sistemas e a infra-estrutura existente; fazemos um desenho detalhado do sistema entre outras tarefas. O objectivo é ter tudo o mais planeado possível para diminuir o impacto dos imprevistos... bla, bla, bla. Todos sabem como é, não vale a pena estar a repetir-me. Como provavelmente saberão, as metodologias ágeis não favorecem esta aproximação, pelo que me encontrei num dilema: o facto é que tinha de apresentar aqueles deliverables, mas eu queria à viva força tentar mitigar os problemas deste modo de trabalhar. Como conciliar as duas coisas?

A Solução

A resposta passou pelo aproveitamento do ambiente .Net e das ferramentas que a comunidade disponibiliza e, claro, pela aceitação dos chefes desta... experiência. Uma coisa que defini à partida foi que não queria fazer documentos Word inúteis, como aqueles que especificam o desenho do sistema, já que me parecem uma violação flagrante do princípio DRY (Don't Repeat Yourself). Por outro lado, queria tentar montar desde o início um mecanismo iterativo, que me impusesse um ritmo saudável.

Os meus (três?) leitores regulares do meu blog irregular provavelmente já sabem a resposta: montar a Integração Contínua já nesta fase e programar desde o princípio. E foi mesmo a primeira coisa que fiz nesta fase. Montei todo o ambiente de Integração Contínua:

Criei imediatamente a estrutura do projecto no sistema de controlo de versões;
Criei a solução no Visual Studio.Net;
Configurei um projecto no CruiseControl.Net;
Criei o script de build, com o Nant;
Muito importante nesta fase, montei desde logo o FxCop e o NDoc no processo de build;

Depois de tudo montado, iniciei a especificação do código (ou desenho, ou modelação, ....), tal como necessário de acordo com os nossos métodos em vigor. Comecei por analisar os requisitos (que tentei criar em forma de user stories) e procurar os conceitos principais (não sei se alguma vez falei da Linguagem Ubíqua ou não... um dia mais tarde) e depois parti para o desenho detalhado do modelo de objectos.

Foi neste momento que realmente comecei a tirar partido do ambiente de Integração Contínua. No modelo tradicional, o desenho detalhado faz-se através de especificações em documentos Word (eventualmente com UML à mistura) que depois são transformadas em código na fase seguinte. Eu saltei os documentos e comecei logo com o código, mas obedecendo ao facto de esta fase ser somente de desenho:

Criei apenas os objectos e as suas interfaces. Não criei o corpo dos métodos.
Utilizei intensivamente os Xml Docs.

O facto de ter realizado o desenho detalhado em código ofereceu-me várias vantagens:

Obedeci a todos os requisitos, já que o código é apenas uma outra forma de documentação;
Adiantei trabalho, já que a Integração Contínua ia ser montada de qq das formas;
Graças ao NDoc, gerei documentação em HTML e CHM de forma automática, sendo que é possível criar um formato de documentação Word, pelo que temos essa documentação à mesma. O ponto importante é que a fonte é comum, pelo que não existem dessincronizações.
Como o desenho foi realizado directamente no código, foi possível ir compilando tudo a cada momento, validando desde logo uma série de situações.
Graças ao FxCop, em cada momento da "especificação" foi possível validar o desenho contra as guidelines da Microsoft.

Um dos riscos desta abordagem, pelo menos do ponto de vista de quem defende uma fase de desenho separada da construção, é que a tendência dos programadores para começarem imediatamente a codificar tudo (dar comportamento aos objectos) e não apenas as interfaces é demasiado grande. Na minha experiência, apesar de ser totalmente a favor desse modelo (com algumas regras, naturalmente), consegui evitar a tentação, não foi difícil. Acho que na prática, não é um problema muito grande.

Em resumo, apesar de ter de seguir uma metodologia por fases, foi possível introduzir alguma agilidade no processo. Pouca, é verdade, mas com algumas vantagens que me parecem evidentes. O desenho detalhado que fiz tornou a fase de construção mais simples? Ajudou-me mesmo que não tenha me tenha impedido de redesenhar o modelo nalguns locais?

Na fase seguinte, da Construção foi possível introduzir bastante mais agilidade no processo, com resultados (mais uma vez) muito satisfatórios, mas estou a pôr o carro à frente dos bois...

Voltei a programar - Como conciliar agilidade com formalidade?

João Hugo Miranda — Sun, 26 Jun 2005 21:24:00 GMT

Nos ultimos meses, voltei a fazer uma coisa que não fazia há bastante tempo: fiz um projecto de software do princípio ao fim. A questão é que o meu papel na empresa não é programar, é mais uma mistura de arquitectura, metodologias e processos, administração... uma série de tretas, mas o principal é mesmo metodologias e processos (pelo menos para mim).

Há uns meses, surpreendentemente, o meu chefe (ou melhor, o chefe do meu chefe) atribui-me um projecto, um gerador de documentos (os pormenores são pouco importantes, não vem ao caso.). No essencial, tive de fazer tudo: análise e planeamento, desenho, programação, testes.

Foi muito interessante porque o meu chefe é a favor de se realizar uma análise e um desenho detalhado, desde a arquitectura, passando ao modelo de objectos, até ao nível dos métodos e respectivas assinaturas, tudo devidamente documentado. Por outro lado, eu sou a favor das metodologias ágeis, como talvez ainda se lembrem. O meu desafio foi conseguir conciliar as duas coisas...

Regra geral, a nossa metodologia é a tradicional, por fases: a Concepção, a Elaboração, a Construção e a Transição. Diga-se em abono da verdade que tem tido os seus resultados.

Concepção

A fase de concepção é aquela em que se define qual o problema que pretendemos resolver e justificamos o investimento na sua resolução. Pensamos também, de modo muito geral qual a melhor forma de o resolver. Esta é uma fase que me parece que tem sempre de existir, porque não faz sentido resolver um problema que não existe! As diferenças começam daqui para a frente...

As próximas fases (e o sumo de toda esta história) continuam no nos próximos posts, espero.... Agora tenho mais algum tempo do que tenho tido nos últimos (largos meses), vou tentar retomar o fio à meada. Não sei se alguém sente a falta, mas eu sinto. ;)

Common People

João Hugo Miranda — Sat, 12 Mar 2005 18:48:00 GMT

Tenho tanta coisa para falar, mas tão pouco tempo para o fazer, como devem ter reparado (espero!!!)... :( Performance Counters, Visual Studio.Net Templates, Word, Domain-Driven Design?

Nos entretantos...

'She came from Greece she had a thirst for knowledge,
she studied sculpture at Saint Martin's College,
that's where I,
caught her eye.
She told me that her Dad was loaded,
I said "In that case I'll have a rum and coca-cola."
She said "Fine."
and in thirty seconds time she said,

"I want to live like common people,
I want to do whatever common people do,
I want to sleep with common people,
I want to sleep with common people,
like you."

Well what else could I do -
I said "I'll see what I can do."
I took her to a supermarket,
I don't know why but I had to start it somewhere,
so it started there.
I said pretend you've got no money,
she just laughed and said,
"Oh you're so funny."
I said "yeah?
Well I can't see anyone else smiling in here.
Are you sure you want to live like common people,
you want to see whatever common people see,
you want to sleep with common people,
you want to sleep with common people,
like me."
But she didn't understand,
she just smiled and held my hand.
Rent a flat above a shop,
cut your hair and get a job.
Smoke some fags and play some pool,
pretend you never went to school.
But still you'll never get it right,
cos when you're laid in bed at night,
watching roaches climb the wall,
if you call your Dad he could stop it all.

You'll never live like common people,
you'll never do what common people do,
you'll never fail like common people,
you'll never watch your life slide out of view,
and dance and drink and screw,
because there's nothing else to do.

Sing along with the common people,
sing along and it might just get you through,
laugh along with the common people,
laugh along even though they're laughing at you,
and the stupid things that you do.
Because you think that poor is cool.

Like a dog lying in a corner
They will bite you and never warn you
Look out.

They'll tear your insides out

`cos everybody hates a tourist
Especially one who thinks it's all such a laugh
Yeah and the chip stain and grease will come out in the bath

You will never understand
How it feels to live your life
With no meaning or control
And with nowhere left to go
You are amazed that they exist
And they burn so bright whilst you can only wonder why.

Rent a flat above a shop
Cut your hair and get a job
Smoke some fags and play some pool
Pretend you never went to school
But still you'll never get it right
`cos when you're laid in bed at night
Watching .... roaches climb the wall
If you called your Dad he could stop it all, Yeah.

Never live like common people
Never do what common people do
Never fail like common people
Never watch your life .... slide out of view

And then dance, and drink, .... and screw
Because there's nothing else to do'

Pulp