Débito Técnico

Vocês sabem que as maiores reclamações do mundo em desenvolvimento de software é a famosa correria, os atrasos e a explosão de custos no final dos projetos. Geralmente para nós agilistas o final do projeto é a coisa mais tranquila do mundo. Nós corremos nas primeiras iterações e focamos em entregar valor. Nas últimas iterações é comum sobrar as funcionalidades mais inúteis do mundo a serem desenvolvidas. Quando o cliente percebe isso é comum o projeto acabar algumas iterações antes do que foi planejado.

As maiores razões para esse correria no final do projeto é:

1. A equipe não sabe desenvolver software
2. Gestão Covarde: começar a fazer o software pelas funcionalidades inúteis.
3. Escopo mal definido (assim como as métricas)

O problema com “escopo” em software é achar que desenvolvimento em cascata (waterfall) resolve a questão. Infelizmente quando falamos de escopo dentro de qualquer metodologia de desenvolvimento (FDD, Scrum, RUP como exemplo) sempre focamos que o objetivo do projeto é RESOLVER PROBLEMAS de negócio e não implementar requisitos (isso também é uma coisa que já falei umas 10 vezes aqui).

Parando de ser repetitivo, como nós documentamos esse escopo? Como nós declaramos que problemas o projeto está focado em resolver? Qual é o nível de profundidade desse escopo?

Estabelecer a Visão de um sistema é uma arte. Para este tipo de trabalho é necessário ter um grande conjunto de conhecimentos que na maioria das vezes não é natural para uma pessoa enfiada em linhas de código. Vou colocar uma pequena lista para vocês terem uma idéia. Para estabelecer uma visão é necessário:

- Desenvoltura no ambiente empresarial
- Focar-se no problema e não na solução
- Estabelecer fronteiras claras
- Saber gerenciamento de projetos (definir envolvidos, estabelecer responsabilidades, financiamento)
- Identificar usuários
- Documentar premissas e restrições
- Compreender sobre retorno e risco
- Saber escrever bem
- Ser político (conseguir concordância de todos os envolvidos)

Essas entre outras coisas formam o conjunto de habilidades necessárias para estabelecer uma boa visão. Uma visão que deixe o escopo deslizar dentro do processo iterativo mas que ao mesmo tempo dê um objetivo claro para o propósito do projeto.

Dentre essas habilidades, estabelecer fronteiras é uma das mais importantes. Quando você está desenvolvendo um grande sistema com muitos stakeholders em um ambiente corporativo é comum que a aplicação tenha suporte de outros sistemas ou processos manuais também fora do escopo da automação. Deixar claro que essas responsabilidades externas não são escopo também é um aspecto importantíssimo da visão. Responsabilidades do processo externo e integrações com outros sistemas sempre são importantes para o refinamento do escopo, assim como premissas e restrições na avaliação dessas interfaces.

Sem essa visão clara é comum que ocorram frustrações dentro de um projeto. Uma empresa tem muitos problemas e geralmente o que estamos desenvolvendo não solucionará TODOS os problemas. O escopo delimita exatamente quais problemas serão solucionados.

O RUP é um dos processos que mais valoriza o estabelecimento dessa visão. O OpenUP também nos fornece um bom material para estudo dessa importante tarefa.

No site da Aspercom nós também temos alguns exemplos:

Visão da HotMotors (Oficina de Tunning)
Visão da KrowCorp (Rede de Hotéis)
Visão da Clínica Anna Suiter (parte integrante do curso on-line grátis, é necessário se cadastrar no site)

Esses documentos tem algumas coisas que geralmente não existem em documentos reais. No caso da KrowCorp (Curso UML & UP) e da Clínica Anna Suiter (Curso Grátis “Entendendo Casos de Uso”) as necessidades dos usuários estão detalhadas demais (estão assim para os objetivos do curso). Já a visão da HotMotors está abrangente demais. O Documento de Visão documenta mais o problema do que a solução. Ele é um resumo executivo do projeto. É o documento que você leva para aquela reunião onde o Sponsor quer cancelar o projeto. A Visão prova a necessidade do software.

É importante ressaltar que dependendo do projeto a Visão pode ser menos ou mais abrangente. Isso depende do que você considera escopo. De qualquer forma nenhuma metodologia iterativa considera que os requisitos do software detalhados são o escopo. O escopo em software sempre é mais abrangente que “requisitos de software detalhados”. Existe diferença entre o problema, as necessidades dos usuários e os requisitos de software.

Dean Leffingwell e Don Widrig explicam mais sobre essa diferença no livro “Managing Software Requirements“.

Um dos problemas do “Escopo de Alto Nível” é que na maioria das vezes o medo do gerente covarde ou a gestão de projetos tradicional não aceita este tipo de escopo como válido. Para eles “tudo tem que estar explicadinho e assinado” por conta de escopo, prazo e custo serem fixos no processo Waterfall. Isso nos leva ao anti-pattern “Big Requirements Up Front” e a uma dispendiosa e irracional Gerência de Mudancas.

O escopo focado no problema é suficiente para o controle dos objetivos do projeto. Determinados replanejamentos de custo, prazo ou funcionalidades podem ocorrer durante a execução. Isto é previsto no processo iterativo. Porém, se o seu cliente desejar que novos problemas façam parte do escopo aí sim teremos impactos maiores de escopo e um replanejamento geral do projeto pode ser necessário (talvez uma nova concepção/iniciação do projeto ocorra gerando impacto em custo e prazo). Isso sim seria uma mudança de escopo e não a inclusão de um campo a mais numa tela.

Muitos desses assuntos são explorados no nosso curso de Levantamento e Especificação de Requisitos.

Um pouco atrasado mas vamos lá. Na edição “atual” da MundoJava (maio-junho) escreví sobre o ciclo ágil de um dia envolvendo as práticas do XP e da TDD. Parte deste artigo já está publicado aqui no blog no post “O Anti-Pattern Caso de Uso – UML – Codificação – Teste”.

Neste artigo tivemos a participação do Carlos Vilella da ThoughtWorks. Segue um trecho muito interessante do texto dele.

“Tive a sorte de participar em um projeto aqui na ThoughtWorks onde todas as estórias eram analisadas por um analista de negócios extremamente competente, e um cliente que entendia mais do que eu poderia esperar sobre a operação e funcionamento da empresa. Em conjunto com os desenvolvedores e testadores, ditou-se no início do projeto que usaríamos testes de aceitação “executáveis” de forma a aumentar a produtividade. Fizemos isso juntando Fit, Fitnesse e Selenium, que ainda não são ferramentas perfeitas, mas que estão evoluindo bem.

Funciona assim: Matt, o analista de negócios, se reúne com Jane, representando o cliente, em uma sessão de uma ou duas horas por semana. Eles então descobrem tudo o que é importante ser feito na próxima iteração, e listam tudo que eles conseguem imaginar para cada estória ser considerada pronta.
Depois que essa reunião termina, Matt corre pra mesa do Richard, analista de testes, e eles passam algumas horas formatando tudo dentro do wiki do projeto. É aí que está a grande sacada: o wiki do projeto, rodando no Fitnesse, sabe entender os critérios de aceitação e rodá-los, efetivamente tornando-os casos de teste do mais alto nível possível.

Com estes casos de teste na mão, Richard corre pra minha mesa, me mostrando que nessa próxima estória em que eu vou trabalhar, existe uma validação de números de cartões de crédito da qual nunca havíamos precisado antes. Com essa informação em mãos, eu sei que preciso adicionar um pouquinho de código aos fixtures do Fit para que ele entenda como acessar a aplicação usando Selenium e manipular a parte que lida com os números de cartão de crédito. De dentro da minha IDE, eu não vejo muita diferença: é só código que lê um número e tenta entrá-lo numa caixa de texto. Para o cliente, é uma oportunidade de finalmente ver que o que ele ajudou a digitar num wiki está se tornando realidade, e é por isso que ele está investindo no software.”

Já nas bancas!!!!

Dessa vez foi no início do torneio. Não deu pra puxar muitas fichas pois os blinds ainda estavam baixos.

Mas foi interessante. Eu já estava com o three-of-a-kind no flop e fui dando raise de 80 em 80. Todo mundo foi pagando. Quando virou o river fui obrigado a dar all in. Nosso amigo skyline7K quase pagou, mas fugiu com 2 pares. Terminei o torneio em terceiro lugar.

To skyline7K: Sorry buddy… not bluffing this time!!!

(Por que essas coisas não acontecem quando estamos na eliminatória do WSOP??)

Nesta semana estive ministrando os treinamentos de Levantamento de Requisitos e Scrum para o pessoal do Instituto Municipal de Tecnologia da Informação da Prefeitura de Campo Grande.

Antes de mais nada gostaria parabenizar a cidade de Campo Grande. Campo Grande é uma cidade linda! É uma das capitais mais bonitas que tive o prazer de visitar aqui no Brasil. É uma cidade muito bem estruturada e limpa. São largas avenidas (5 pistas) com grandes calçamentos que cruzam simetricamente toda a cidade. Todas as ruas são arborizadas com jardins bem cuidados. É uma metropole em pleno desenvolvimento. Com um passeio na Av. Afonso Pena e uma volta no Shopping também pude notar como o povo lá é gentil e acolhedor.

(Eu preciso comprar um celular com uma câmera melhor…)

O nosso treinamento de Levantamento de Requisitos é focado em técnicas para captura de requisitos e estabelecimento da Visão do Projeto. Definir e documentar uma Visão é uma tarefa não muito valorizada na maioria dos projetos de clientes que tive contato, porém, o escopo macro do projeto é importante para focar o desenvolvimento naquilo que resolve os reais problemas do cliente. A maior pergunta que respondemos neste treinamento é que desenvolvimento iterativo tem escopo!

Mais um treinamento e mais uma empresa buscando trilhar o caminho do sucesso com Agilidade.

Os produtos e serviços da YMF são utilizados por Asset Managers, Hedge Funds, Custodiantes, Private Bankers, Seguradoras, Fundos de Pensão, Family Offices e Investidores Individuais. Com cerca de 70 clientes que controlam mais de R$ 1 trilhão em 14.000 Portfólios e 4.000 fundos, a YMF é o provedor líder de sistemas e serviços de Asset Management da América Latina.

Em 2007 a YMF passou a ser controlada pela Datasul.

Treinamento com uma vista exuberante para a Vila Olimpia em São Paulo.

Como nosso amigo Scott Ambler diria: “This is an Agile Model.”

Um bom plano geralmente é produzido com bons modelos.
Um bom modelo não é necessariamente bonito e nem UML compliant.

O fruto do planejamento: Um plano altamente visível a todos.

Parabéns a todos da equipe YMF!!!

Desde 2006 nós promovemos o “Agile Beer Drinking”. É um evento formado às pressas na lista UML-BR e Agile-Brasil. Geralmente marcamos num lugar bem divertido e com Double Drink. Os outros eventos foram igualmente divertidos, porém, este em especial foi bem animado. Até tiramos fotos!!!

Marcio Tierno… ele existe!!!!

Eu, Rodolpho Ugolini e Alexandre Magno.

(Eu e o Alexandre Magno somos amigos! Por conta de nossas discussões nas listas alguém criou uma fococa que a gente se odeia… he he he).

Toda a galera de caneco na mão.

Para sentar na mesa principal é necessário fazer uma prova de conhecimentos de Engenharia de Software. Quem montou a prova foi o Prof. José Paulo Papo. Infelizmente ele não pode estar presente.

Tudo que um desenvolvedor de software precisa para crescer forte e saudável.
(Este celular tem 10 cm, é um bife considerável).

Tentou acompanhar a gente no Chopps mas se deu mal. No minimo ele deve desenvolver em cascata!

O Adalberto Abade apareceu lá. Pelo que contei o Dimas tomou 15 caipirinhas importadas. Tinha uma mulherada presente. Pena que são casadas (comigo e com o Rodolpho, he he he).

Estamos melhorando cada vez mais o Agile Beer Drinking: teve evento simultâneo em Porto Alegre!!!

http://mudandoumapequenaempresa.blogspot.com/2008/06/porto-alegre-agile-meeting-1.html

Vamos marcar o de julho?

Surgiu uma discussão na UML-BR sobre como modelar um Jogo da Memória. O rumo da conversa foi sobre pensar nas classes e modelar antes, influenciados por um post anterior. A thread sobre o jogo da memória está aqui:

http://br.groups.yahoo.com/group/UML-BR/message/9936

Eu comecei a pensar nesse problema e até pretendí mandar um diagrama de classe demonstrando uma provável solução, porém, este “mini” sistema é muito mais direcionado a comportamento do que a classes propriamente dito.

Atualmente tenho estudado bastante Ruby. Concordo com o Rodrigo Kumpera quando ele diz que Java “educou a grande massa sobre bom desenvolvimento OO” mas “cheira naftalina”. A linguagem continua em evolução, porém, algumas coisas no Java me irritam muito. A maior delas é o turnaround imenso. Volta e meia precisamos reiniciar o servidor. No Ruby as coisas são mais fáceis. A comunidade Ruby faz as coisas serem mais fáceis. Para resolver o problema do Jogo da Memória quis usar o RSpec. Para instalá-lo bastou:

gem install rspec


No Java já me imaginaria instalando uns 20 jars irritantes.

Voltando ao assunto “Jogo da Memoria” iniciei esse desenvolvimento pensando: “O que é necessário para jogar?” Por sorte sou pai de 2 filhas pequenas e tinha um Jogo do Mico aqui. Não é exatamente um Jogo da Memória mas serve pois são cartas aos pares. Com as cartas na mão me lembrei do nosso amigo Kent Beck e a “Spike Solution”: “Eu não preciso de 15 pares para testar o Jogo da Memória. Eu só preciso de 2 pares para ter uma solução plausível que diz que minha aplicação funciona.”

Uma mesa, um jogador e dois pares de cartas: Tudo que é necessário para um Jogo da Memória completo.

Com essa metáfora e esses “elementos” na mão o próximo passo seria como montar a “partida” focado em comportamento. Pensei no meu próprio comportamento quando montei esse cenário para a foto.

Este seria o comportamento esperado do jogo logo ao iniciar. Pense no objetivo do jogo. Nós queremos ganhar certo? Logo no ínicio nós precisamos ter um parâmetro palpável para saber se ganhamos ou não. Logicamente no ínicio do jogo ele não está ganho. A implementação desses comportamentos nesse momento está listada abaixo:

A prática do BDD é extremamente próxima do TDD. BDD não é nada novo. É apenas uma visão unificada de TDD e DDD fornecendo uma Ubiquitous Language para essa abordagem de desenvolvimento.

OK. Neste momento temos um Jogo montado. Um aspecto importante para este jogo é saber comparar cartas. Vamos adicionar este requisito como comportamento.

Vamos agora implementar isso na classe Carta.

Cada vez que faço um passo desses eu tenho requisitos (comportamentos) e implementações em paralelo. Minha especificação (jogo_memoria_spec.rb) vai direcionando o desenvolvimento da minha aplicação (jogo_memoria.rb). Cada passo é mensurável e pode ser avaliado como válido. Além disso, minha aplicação possui as características de um design emergente. Dados e comportamentos só são adicionados quando realmente há embasamento em requisitos.

Com a capacidade de saber quando cartas são iguais, o próximo passo seria poder “virar” uma carta e em seguida virar outra carta que não seja par com a primeira. É um critério de falha com relação ao objetivo de ganhar o jogo. O comportamento e a implementação do comportamento estão abaixo:

Vamos agora definir o comportamento e a implementação para o sucesso de virar duas cartas encontrando o par:

Com esses últimos comportamentos seria possível avaliarmos a nossa implementação do Jogo da Memória com 4 cartas. Para efetuar o download da aplicação completa acesse os links abaixo:

jogo_memoria_spec.rb
jogo_memoria.rb

O que eu tenho gostado muito em aplicar técnicas de TDD é ter requisitos executáveis. O BDD só nos traz mais ferramentas conceituais. O BDD tem foco no próprio comportamento e não em testes dos comportamentos. A evolução de ferramentas como o próprio RSpec poderá nos trazer a um mundo novo onde nunca mais teremos documentos de requisitos desatualizados.

Cada dia que passa a especialização e a divisão do trabalho fazem menos sentido no desenvolvimento de software.

(amigos rubistas: não sejam muito rigorosos com meu código, estou aprendendo ainda)

Na edição 19 da Revista MundoJava em meados de 2006 iniciei a publicação dos meus trabalhos na coluna MundoOO. Este primeiro artigo publicado teve um impacto extremamente positivo e até hoje muitas pessoas comentam sobre esta publicação.

Eu já ministrava treinamentos UML há algum tempo e participava de muitos fóruns de discussão como o UML-BR e o GUJ. O mercado tem um entendimento muito ruim sobre UML e modelagem em geral, assim, o que eu já pregava nos cursos transformei em literatura.

O artigo “UML não é Documentação” demostra o uso da UML de maneira prática e concisa, bem próximo da visão de modelagem ágil de autores como Scott Ambler e Martin Fowler.

Numa iniciativa conjunta do Blog Débito Técnico e o pessoal da MundoJava, estamos deixando este artigo disponível para download no site da Aspercom na página do projeto HotMotors. Este projeto com fins acadêmicos que anda parado (e com uma arquitetura que apesar de popular em 2006 não me dá muito orgulho) ainda será reativado um dia. Minha idéia é portar isso para Seam e também Rails. Seria um ótimo comparativo! Alguém da comunidade se habilita?

No dia 31/05 estive em Belo Horizonte ministrando o nosso Workshop Gerenciamento de Projetos com Scrum para uma turma de aproximadamente 20 pessoas.

Neste treinamento a Aspercom iniciou uma “Cruzada Estudantil” oferecendo 25% de desconto para estudantes e professores. Nós queremos disseminar no meio acadêmico um pouco mais sobre Agilidade e levaremos este treinamento a outras cidades com a mesma política de descontos.

“O processo é empírico!!!!”

Mesa dos nossos amigos da Universidade de Itaúna e muitos Index Cards…

O farto Coffe Break com muito pão de queijo!!!

Mesa dos experientes…

Sempre rola os papos de arquitetura Java, Domain-Driven Design, Seam, Ruby e etc…

Obrigado a todos que participaram. Todas as discussões foram muito ricas (aliás, foram tantas que vocês até ganharam mais de 1 hora de carga horária!).

Se você estiver interessado em organizar um Workshop desses na sua cidade ou na sua Universidade entre em contato comigo no mail rodrigoy@aspercom.com.br.

Uma das perguntas que mais respondo na minha vida é “Como é que você fala tanto sobre Agilidade e dá cursos de UML?!?!”. Um dos pontos que defendo muito nos meus artigos e também nos meus cursos é que Agilidade não exclui modelagem. De fato vejo muitos agilistas modelando bastante seja nos “whiteboards”, no papel ou em ferramentas UML.

Nosso amigo Adail Retamal postou na lista Agile-Brasil um excelente artigo de Scott W. Ambler e Celso Gonzalez publicado na Better Software. Segue o link:

http://www.nxtbook.com/nxtbooks/sqe/bettersoftware0608/

No artigo citado os autores dizem que a modelagem ocorre principalmente na concepção ágil, no planejamento da iteração e homeopaticamente durante o desenvolvimento. Modelar é uma atividade em grupo focada principalmente na comunicação. Modelar algo sozinho não faz sentido na maioria das vezes.

Será que modelar está tão fora de moda assim? E a UML? O que podemos dizer sobre ela?