timeBox

Em 2005 eu fiz um curso de extensão na PUC-Rio, que se baseou no livro UML Components, publicado em 2000. O foco do livro e obviamente do curso, era em Component-Based Design, identificação e projeto de componentes de negócio, usando uma técnica calcada em UML.
Foi na época desse curso que comecei a ver valor em alguns outros temas que eu já havia estudado, mas não conseguia ver tanta aplicação prática, como o uso de OO na modelagem de sistemas e o conceito de reuso. No entanto, o que mais me chamou atenção no curso e mudou minha forma de pensar sobre desenvolvimento de software, foi o fato de modelar classes e sub-sistemas com base no que eles representavam no mundo real, no processo de negócio do cliente.

Em 2007 comecei a ter contato com metodologias ágeis e com SOA, tudo de forma muito tímida ainda, lendo isso, aquilo, mas o suficiente pra constatar 3 coisas:

1 – Eu não precisava “modelar tudo em UML” pra depois programar de novo em algo que compilasse.
2 – Testes automatizados são tão importantes, mas tão importantes, que até pra modelar servem.
3 – SOA segue adiante o caminho iniciado pelo Component-Based Design, dando mais foco no negócio e com uma visão mais corporativa.

Em 2008 comecei a ver alguma coisa de Domain-Driven Design na internet. Mesmo sendo um cara que “curte” modelagem, não dei muita importância. Achava que era apenas um novo nome para uma mistura de CBD com SOA. Só lendo o livro do Evans em 2009, que foi publicado em 2003, é que passei a ver benefícios com DDD, devido à forma como o autor amarrou e organizou uma serie de conceitos e técnicas úteis a modelagem de domínio.

Estamos em 2010.
Perceberam alguma coisa? Não?

Eu sou um cara técnico, curto modelagem de software e não é raro eu estar lendo algo sobre isso. Mesmo assim, só fui conhecer em 2005, algo que já existia desde 2000 e só fui entender em 2007/2009 coisas que começaram em 2003.

Eu curto estudar assuntos técnicos sobre modelagem.
Mas isso não evitou que eu acumulasse débitos técnicos por anos!

Agora imagine o seu gerente e o gerente do seu gerente. Provavelmente eles não sabem o que significam 10% dos termos usados nesse post até agora.

Então, por quê você acha que vai convencê-los a deixar você usar SOA, DDD, TDD, XP, etc, etc…?
Vou piorar as coisas.
Por que você acha que toda uma empresa vai passar a adotar alguma dessas siglas, bancando custos de treinamento, mudanças culturais e perdas de produtividade iniciais?

Eu não tenho 1 ou 2 anos pra convencer meu gerente de que usar X é legal pra empresa. Pior, ele provavelmente não leu os livros que li nem fez os cursos que fiz, então eu precisaria de mais do que 1 ou 2 anos.
Seu gerente, o gerente do seu gerente e daí por diante, são pessoas que leram outros livros, que tem outras preocupações.
Você precisa falar a língua deles.
Você precisa provar que as suas idéias sobre modelagem de software são rentáveis.

Softwares não nascem ou sofrem modificações “do nada”.

Esquema de Exemplo - Telecom

Imagine uma empresa de telecom com alguns setores específicos.
Essa empresa, assim como qualquer outra, de qualquer outro ramo é movida por processos de negócio e tem metas a serem alcançadas.
Tanto os processos quanto as metas podem ser definidos nos mais altos aos mais baixos níveis de detalhe na empresa.
A figura acima destaca um processo bem macro, chamado “pagamento de conta”. Ela também mostra que existem uma serie de sistemas e serviços, construídos para fazer esse processo fluir.
Se for lançada uma meta visando a diminuição do consumo de papel na empresa e o processo de “pagamento de conta” for um dos que precisam se adequar a meta, alterações em sistemas e serviços legados serão necessárias.
Solicitações serão feitas ao pessoal de TI para atender essa demanda.

Mas, por uma triste coincidência, os sistemas envolvidos estão cheios de dependências cíclicas, redundâncias de lógica de negócio, excesso de responsabilidades e interfaces incoerentes com seus propósitos de negócio.
Sendo assim, sua equipe levou um baita tempo extra só pra entender como os sistemas funcionavam, fora o tempo pra promover as alterações em si. O que alias, acabou gerando mais trabalho, porque como os sistemas não estavam cobertos por testes automatizados, muitos bugs só foram percebidos tardiamente e um loop infinito de “corrige-e-estraga” se formou.

Você consegue mensurar quanto de $$ está sendo gasto atendendo essa demanda?
Consegue identificar uma relação entre o que está sendo gasto e o que seria gasto, caso as tais “siglas” que você queria colocar na empresa, tivessem sido usadas na construção desses sistemas?

Você consegue achar outros exemplos na sua empresa, que cheguem a conclusões parecidas?

Sim? Então você consegue provar que investir no que você fala, pode ser uma boa idéia.

Estava sem nada de interessante pra fazer ontem a noite e fui ler um livro que me emprestaram chamado Gerenciamento de Projetos – Como gerenciar seu projeto com qualidade, dentro do prazo e custos previstos.

Eu sabia que iria me estressar lendo o livro. Só pelo subtítulo já fica claro.
Mas ai pensei “o livro fala de projeto, não fala de software.”
Essa é a grande questão.
Não é que os defensores dos projetos e todas suas técnicas estejam errados, a questão é enxergar que a idéia de “projeto” não se encaixa em qualquer coisa que se produza nesse mundo.
Software é uma dessas coisas.

A idéia de software tem uma série de características muito especificas que a distancia daquilo que projetos tradicionais se dispõem a tratar.
Não é a toa que coisas com Lean, Scrum, XP e uma série de outras, apareceram focadas em produção de software.

Então por isso resolvi transcrever alguns trechos do livro, que fala de gerenciamento de projeto de forma geral, e colocar logo abaixo opiniões minhas baseadas somente na idéia de software e no que aprendi lendo e usando algumas metodologias que nasceram especificas para software.

Escopo
Controlado a partir de planejamento e documentação de itens que passam de uma área para outra, alem de procedimentos formais, formulários e sistemas de monitoração.

Se a idéia é ter um inicio, meio e fim bem definidos, alem de um custo fechado, então é razoável se preocupar tanto em identificar e formalizar o escopo.
Agora, se isso vai trazer algo de útil pro seu cliente daqui a 1 ano e meio, quando o tal projeto terminar, sem praticamente gerar um novo projeto só pra corrigir as falhas do original, aí já é outro papo.
Não é melhor esquecermos esses formalismos todos e partirmos pra uma definição de escopo gradual, algo como….”vc me diz o que quer….eu faço em algumas semanas….você diz se ficou legal….e continuamos nesse ciclo até você achar que deve parar.” ???

Prazo
O tempo é um padrão importante para avaliar o sucesso de um projeto e faz com que ele seja diferente do trabalho de natureza operacional ou de processo.

Exatamente! Projeto é um conceito que prevê a existência de inicio, meio e fim. Um processo de negócio não se encaixa nesse conceito. Processos evoluem continuamente e rodam através dos sistemas que construímos.
O que fazemos na maioria das vezes é apoiar um processo de negócio com soluções de TI. Nosso trabalho se assemelha muito mais a uma prestação de serviço do que a venda de um produto ou projeto.

Qualidade
As pressões exercidas por outros fatores, como custo e tempo, podem provocar negociações nas quais a qualidade será comprometida em favor do cronograma ou do orçamento.

Pois é. O tempo aperta, o esporro come solto, a qualidade é mandada pra você sabe onde, e os sistemas orientados a gambiarras são gerados. O mais engraçado é que muitas vezes, após ver que o produto final ficou uma porcaria, o cliente ainda paga de novo pro fornecedor criar novos softwares que corrijam o antigo. Já ouviram falar em coisas como: “batch para correção de base de dados rodando todo dia a noite” ou “Cobertor curto. Resolva um problema aqui e automaticamente crie outro ali” ?

Custo
Em última análise, os projetos resumem-se a dinheiro e gastos. O gerente de projeto é o responsável por manter os projetos dentro do orçamento aprovado.

Fechar o orçamento de construção de um prédio com X andares, cada qual com X apartamentos de X metros quadrados, usando X materiais, não chega a ser um trabalho para mágicos. É quase que uma questão puramente matemática.

Ninguém chega pra uma construtora e diz: “Eu quero fazer um prédio pra investir meu dinheiro. Não sei exatamente como, só sei que preciso investir minha grana. Tem que ficar pronto até o meio do ano. Quanto custa?”

Mas é exatamente assim que se faz software pra apoiar processos de negócio. O cliente não tem muitos detalhes do que vai solucionar o problema dele. O que ele sabe mesmo é que tem um problema e que possivelmente um software pode resolvê-lo. Fechar orçamento e prazo num cenário desse é pedir pra errar. O melhor é fechar um contrato de prestação de serviço.

Recursos Humanos
Quantas pessoas e com quais qualificações serão necessárias durante qual período de tempo, nesse projeto?

Esse modelo pressupõe que equipes são descartáveis. O que talvez influencie no uso da expressão “recurso” em muitas empresas de TI, ao invés de “pessoa” ou “profissional”.
Mas enfim, se sua empresa vive de fazer essa coisa chamada projeto, se os membros das equipes ficam cada vez mais produtivos e entrosados no decorrer dos projetos, então pra que encará-los como custo e não como investimento? Você pode ate manter os profissionais durante algum tempo após o projeto, mas vê-lo primordialmente como um custo mostra que você não enxerga muito bem as características do ramo de negócio em que sua empresa se encontra.
Um time de futebol INVESTE em jogadores, e quanto melhor o jogador, mais retorno FINANCEIRO pro time ele gera. Seja em títulos, bilheteria ou publicidade agregada.
Uma empresa de TI funciona de forma muito parecida. Ou pelo menos deveria.

Desde que vi esses comerciais…

….passei a viajar na idéia de que o espírito Apple de criar seus produtos estava de alguma forma ligado aos valores e princípios pregados pela agilidade.

Pra quem desenvolve software tradicionalmente a algum tempo, só o fato de tomar conhecimento sobre o que diz o manifesto ágil já é algo que desperta. Algo que traz uma vontade imediata de trabalhar daquele jeito.

Quando tomei conhecimento sobre a proposta de produtos e softwares que a Apple segue, senti a mesma coisa. Uma vontade imediata de passar a usar computadores daquela forma, com aquela simplicidade e elegância matadora.

Mas até ai tudo bem. O fato de imaginar coisas, ligações aparentemente inexistentes, conceitos loucos, não é novidade alguma pra mim. rsrsrsrs

Até que hoje, participando do Dev in Rio 2009, assisti duas palestras de pessoas que com toda certeza viajaram nessa mesma questão.
Primeiro veio o Akita com sua palestra sobre ruby on rails (que tem uma comunidade notoriamente interessada em seguir princípios ágeis). E como ele iniciou a palestra?
Com esse vídeo aqui…

Esse pessoal da 37 Signals é tão apaixonado pela plataforma Apple, que chegam a relacionar o sucesso dos seus produtos a inspiração adquirida ao se trabalhar com Macs.

Depois do Akita ainda teve a palestra do Jeff Patton, que relacionou técnicas ágeis com o sucesso na criação de produtos.

Jeff Patton, Dev In Rio 2009

Em determinado momento da palestra, quando ele falava sobre a quantidade, simplicidade e qualidade das features em um produto, o cara puxou um iPhone do bolso e mandou: “Aqui não tem tudo que poderia ter, como muitos reclamam, mas o que tem, é simplesmente magnífico.”

Agile é objetividade, simplicidade, satisfação por estar fazendo algo com prazer, feliz, sem burocracias idiotas, sem documentações em excesso, que só você vai ler enquanto produz, sem gerente-comando-controle, sem terno em pleno Rio de Janeiro, sem diplomas ou certificações pra inglês ver.

Hi, I’m a Mac, and you?

Muita gente já tem batido nessa tecla aqui no Brasil em blogs e revistas. Lá fora então, a décadas que esse tipo de coisa é difundida e até tem tido uma evolução no nível de aceitação.
O RUP tem isso, o XP também, o SCRUM. O que não falta é metodologia e escritor famoso defendendo esse ponto de vista. Mas aqui no nosso mercado, infelizmente, ainda estamos engatinhando com tímidas iniciativas.

Eu estou falando de ESCOPO NEGOCIÁVEL + DESENVOLVIMENTO ITERATIVO.

Não é raro eu entrar nesse assunto com alguém e ouvir de volta: “ah…muito legal, mas no mundo real não é assim”, ou então, “você está sendo acadêmico demais”.

Eu? Acadêmico? hehe….Vamos pular essa parte e partir pra alguns dados reais de mercado.

A décadas que o Standish Group vem divulgando o CHAOS Report, um conjunto de estatísticas sobre os resultados obtidos em milhares de projetos ao redor do mundo.
Só pra exemplificar, os dados de 2003 revelam que 34% dos 13.522 projetos pesquisados atingiram o sucesso, ou seja, foram entregues dentro do prazo, custo e ESCOPO FECHADO previsto inicialmente. Do restante, 15% foram cancelados e 51% tiveram prazo e/ou custo aumentados consideravelmente.

Com base nas funcionalidades que foram entregues nos projetos ditos de sucesso, foi perguntado aos clientes dessas funcionalidades, qual o grau de uso que eles estavam tendo sobre elas. A média das respostas foi a seguinte:
7% sempre são utilizadas, 13% frequentemente, 16% as vezes, 19% raramente e pasmem….45% nunca são utilizadas!

É isso aí, a maior parte estourou prazo/custo ou foi cancelada e dos que tiveram sucesso, quase a metade das funcionalidades não serve pra nada NO MUNDO REAL. Legal né???

Imagino que depois de ler isso em 2004, quem passou o ano anterior perdendo contratos ou gastando uma nota com hora extra, deva ter olhado com outros olhos essa questão de escopo negociável + desenvolvimento iterativo.

O problema de negócio que queremos resolver via software é que deve ter o escopo fechado.
As fronteiras que a solução sistémica não deverá ultrapassar é que devem ser delimitadas.

Agora, qual a real complexidade ou até mesmo necessidade dos X possíveis casos de uso, histórias, ou seja lá o que for, inicialmente imaginados pra resolver os problemas (de negócio) contidos no escopo (de negócio) de um projeto?
Não tem como responder isso com precisão ! Nem com ponto de função nem com qualquer outro ponto que seja.

Bem vindo(a) ao mundo real

Desenvolvimento ágil, aqui no Brasil, virou tema comum em vários blogs e fóruns. Até uma revista especializada nisso nós já temos (Visão Ágil). QUE BOM PRA NÓS desenvolvedores brasileiros. Mas e o mercado brasileiro? E as grandes consultorias de software que empregam boa parte de nós? É….ai a coisa complica um pouco. Colocar em prática princípios de SCRUM, XP, TDD, modelagem ágil e coisa e tal ainda não é muito fácil. Mas isso até tem uma razão de ser. Diretores de TI costumam ler publicações menos técnicas e essas ainda não estão falando muito dos benefícios (ROI) que um modelo de desenvolvimento ágil de software pode trazer. Ainda é preciso fazer esse conhecimento chegar as esferas mais altas do nosso mercado, coisa que já vem acontecendo com outros temas técnicos como BPM e SOA. Hoje em dia acredito que boa parte dos diretores de TI já tem pelo menos alguma ideia do que significa BPM e SOA. Muitos deles já estão inclusive bancando a incorporação de ambos.

No entanto, tenho visto uma certa resistência perante ao uso mais expressivo de técnicas ágeis em equipes que já estão envolvidas em projetos ligados a BPM e SOA. Muitos argumentam que implantar BPM, SOA e Agile , tudo ao mesmo tempo, seria uma quebra de paradigma muito grande e de difícil assimilação.

Humm….será que é isso tudo?

Ok….se você está a séculos desenvolvendo no modelo tradicional (gerente microsoft project/desenvolvimento em cascata/trocentos templates/pouco conhecimento) ai realmente vai ser dureza mudar tanta coisa ao mesmo tempo. De qualquer forma, não creio que nesse seu estado seja possível fazer um trabalho que atenda as expectativas do seu cliente, ainda mais algo envolvendo BPM e SOA. Não tem jeito, ou você começa a evoluir ou você começa a evoluir! Aconselho até a esquecer um pouco esses assuntos (BPM e SOA) e arrumar primeiro a sua casa. Mas se você já trabalha com desenvolvimento iterativo, já pensa em arquitetura, já conhece (de verdade) orientação a objetos, já promove o reuso em seus projetos, já conta com um cliente interessado e conhecedor do processo…cara, continuar tento tudo isso (e mais um pouco) de forma MAIS ÁGIL não vai te fazer mal algum.

O desenvolvimento ágil de software não vai atrapalhar em nada as estratégias do seu cliente ligadas a BPM e quanto a SOA, mesmo tendo que pensar de forma mais corporativa, passando por questões de governança e tudo mais, uma hora você terá de fazer coisas como ”identificar requisitos, modelar, implementar, testar, entregar”.

Essas “coisas” continuam sendo Desenvolvimento de Software.