Esta nunca me pareceu forma de dividir ou distinguir as habilidades das pessoas. Aliás sempre achei o nome “programador” ofensivo para quem é mais que isso, embora reconheça que sim existem programadores. O ponto é que quem desenvolve software não é apenas um “programador” ele tem outras habilidades. Eu já fiz várias entrevistas e sempre procurava determinar o quantidade de aptidões e o nível dessas aptidões nas pessoas. Existem pessoas que simplesmente têm talento para testar e nenhum para desenvolver. E outros é ao contrário. Poucos têm as duas coisas em equilibrio. Portanto, não se pode esperar tudo de todos. Mas a pergunta que ficava sempre na minha cabeça era : “afinal o que estou procurando nesta pessoa”. E não estou falando de empenho e vontade de  aprender. Estou falando de vertentes, de perfis. Afinal quantos e quais perfis existem ?

A resposta é simples. Existem quatro : Especialistas, Generalistas, Generalistas com especialidades e fanfarrões.

“Programar” é uma coisas que o desenvolvedor faz , de entre as muitas possíveis. É uma especialidade. Quem apenas sabe programar e o faz bem e apenas faz isso, então é um Programador no verdadeiro sentido da palavra. É um especialista em programação. Um especialista em programação não apenas programa, ele programa seguindo diretivas, boas práticas, padrões e convenções de forma que outras pessoas também programadores saibam ler o codigo que escreveu e o saibam interpretar ( reconhecer as razões que levaram a pessoas a escrever o codigo daquela forma). Mas um software não se faz só de código. Se faz de levantamento de requisitos, analise, design, arquitetura, modelagem, teste, grafismo, ergonomia, etc… Cada uma dessas coisas em si mesma pode ser umas especialidade. Afinal todos ouvimos falar nos DBA e AD que comandam – apenas – banco de dados, de pessoas que ficam fazendo diagramas UML ou escrevendo casos de uso, os “testers” que são – em tese- pessoas especializadas em teste, etc…

No mundo do software tradicional é muito comum dividir o trabalho pelas especialidades e esperar que cada um faça sua parte para no fim juntar tudo. O problema é que se esquecem de que “juntar tudo” também é uma tarefa em que se pode ser especializado (designer) e é por isso que os projetos tradicionais falham.

Todos sabemos o que é um “Especialista de Dominio” (domain specialist). É uma pessoa especializada no dominio. Esta especialização é bem útil durante a construção de um software dirigido a um domínio especifico, e quanto mais complexo o domínio, mais necessárias são estas pessoas. Elas não necessariamente produzem software no sentido de por a mão na massa do código, mas ajudam a todos a entender o porquês e por que nãos das coisas que o software deve fazer.

Por outro lado, um generalista é uma pessoa que sabe fazer de tudo um pouco. Não se trata aqui de que o especialista faz com mais qualidade que o generalista. Não é esse o ponto. O ponto é que o generalista sabe fazer mais coisas que o especialista. O quão bem as sabe fazer advém da experiencia , esforço e talento de cada um. Um generalista não tem que saber tudo. Não é necessário desempenhar todos os papeis para ser um generalista mas mais do que dois ou três.

O iniciantes começar no mundo do software preocupados em saber programar, usar as bibliotecas etc… sem nunca dar atenção a coisas como modelagem ou levantamento de requisitos. Muitos passam sua vida sendo apenas programadores deixando com outros especialistas as outras atividades. Isto é comum em “fábricas de software”.

Como disse antes quem trabalha no modelo de fábrica com um bando de especialistas encadeados em uma linha de produção se esquece que alguém tem que conhecer todas as partes do processo, do produto e do resultado de forma a avaliar como a linha de produção se portou. Senão ficam todos a olhar uns para os outros peguntando a cada um como a parte dele deveria funcionar. Isto causa imenso ruido na informação relevante, perda de informação e até inclusão de erros.

No modelo ágil se pede que as equipes sejam multidisciplinares. Muitos interpretam isto como “muitos tipos diferentes de especialidades”, mas significa de fato “pessoas com várias aptidões” ou seja, generalistas. Um generalista pode fazer muito mais num período de tempo que vários especialistas.  A pessoa pode conduzir o ciclo inteiro. Levantar um requisito, implementá-lo, testá-lo reportar ao cliente e começar de novo. Implementar pode significa escrever java, html, javascript, usar a biblioteca A ou B, mexer com banco de dados, SQL, configurações, produzir documentos, uml, etc… Agora imagine dois, três , quatro , generalistas e compare com equipes de dez, quinze, vinte , cinquenta especialistas.

Quando imagino especilistas imagino o cara sentado numa mesa com aqueles oculos especias com muitas lentes procurando os detalhes. Eles são excelentes nos detalhes. Eles enxergam a “small picture”. Os generalistas enxergam a imagem maior (“big picture”). De longe, como uma águia que procura o problema e desce rapidamente na terra para matar o problema.

Uma equipe para ser produtiva tem que ter uma mistura saudável de especialistas e generalistas, sendo que é melhor ter generalistas com especialidades.

Mas cuidado, não se confunda “generalista” com fanfarrão, ou com o cara que diz que faz tudo mas não é bom em nada. Para ser um generalista legitimo, ha que fazer direito várias coisas. Os famosos bombeiros ( o cara que fica apagando fogo de um lado para o outro) não necessariamente é um generalista. Especialmente se ele que começa os incêndios.

Não ha nada de mal em ser um bom especialista, seja de domínio, de tecnologia , de modelagem , etc… nem ha nada de errado em ser um generalista. Contudo imagine que tem mais chances de sobreviver num ecosistema em constante mudança ? Por exemplo, à 40 anos atrás DBA era o cara. Os sistemas existiam em stores procedures. Hoje que o banco de dados é commodity e temos o NoSQL ( Not Only SQL) esta profissão – como especialidade única – coloca a pessoa em risco de não trabalhar mais. Não ha como negar que especialidade é sinônimo de limitação. Por outro lado, um generalista está limitado pela sua capacidade de saber os detalhes. Porque ele não sabe ou procura os detalhes pode fazer as coisas mais levianamente que um especialista faria.

Ser especialista ou generalista é inerente ao profissional , mas da mesma forma que uma pessoa apenas boa no serrote ou na glosa não pode se considerar um carpinteiro, da mesma forma uma pessoa que só sabe programar ou só sabe trabalhar com bando de dados, ou só sabe modelar, não se pode chamar de desenvolvedor. Ao entrar no mundo do trabalho voce pode entrar como especialista ou como generalista, é você que escolhe. É comum ver as pessoas entrarem como iniciantes e nem saberem sequer programar, quanto mais levantar requisitos e fazer testes, mas se nunca tentar a pessoa não sabe se é boa ou não nessas tarefas.  Por outro lado, ninguém é sênior sabendo apenas programar. Maior nivel de aptidão (skill) significa também mais aptidões.

É isto que diferencia os desenvolvedores. É isto que tem que procurar durante as entrevistas. É nisto que tem que pensar ao formar uma equipe. Você quer muitos especialistas, muitos generalistas, ou é melhor ter apenas alguns generalistas com especialidades ? Por outro lado, como membro de uma equipe, como você pode ser mais útil ?

A meu ver o mundo da especialização e das fábricas está mudando para o mundo generalista com especialidades e modelo de oficina. Em uma oficina de carpintaria qualquer um sabe serra e usar uma glosa. Senão, o produto sairia muito caro. Isto não significa que de vez em quanto uma peça especifica não tenha que ser feita fora, por alguém que percebe mais : um especialista… mas não é comum.

Ora, Leader , em português Líder é alguém que tem o papel de guiar mas tem comando sobre outros. Enquanto que Lead (Condutor) é apenas o que tem papel de guiar e estar à frente. Estar à frente significa ser o porta-voz.

A cultura local absorveu o conceito de forma errada substituído aquilo que era intencionalmente apenas um Condutor para aquilo que se espera ser um Líder e expressões como Lead Architect viraram Líder de Arquitetura ou Arquiteto Líder e Lead Designer virou “Líder Técnico”. Note a dupla perda de significado já que Designer é o responsável pelo design, ou seja pelo conhecimento de como todas as partes se integram e trabalham juntas dentro do software. A palavra “Técnico” é extramente pobre para convir este significado. Quanto a mim não tem, sequer, nada que ver.

As empresas ,então, procuram lideres técnicos. Mas o que faz um lider técnico ? A resposta é simples :”lidera a equipe de técnicos” no sentido de “comanda” ou “é responsável por” ou ainda, em alguns casos , “responsável por domar a equipe de técnicos conforme os preceitos da empresa”. Ora, isto não tem nada que ver com software e o conceito de Lead Designer e sim com a arcaica hierarquia pseudo-militar que as empresas tanto gostam de usar. Tem mais que ver com o conceito de “Team leader”, que é outra coisa completamente diferente. Para começar “Team leader” não é um cargo, é um reconhecimento. Muitas vezes o erro vai mais longe e se confunde Arquiteto com “Líder Técnico” o que causa vários desastres quando o líder técnico não sabe de arquitetura ou quando o arquiteto não sabe de liderança.

Depois estas mesmas empresas não entendem porque seus projetos têm problemas e existem conflitos. É porque a hierarquia da empresa  não corresponde com as responsabilidades necessárias a fazer um software nem com as capacidades das pessoas em cada nível.

Acentuo que “líder” não é um cargo, é um direito, uma conquista. Uma conquista de respeito. As pessoas seguem a um líder não porque ele as ordena, mas porque elas confiam nele. O comando vem depois de que a pessoa já deu provas que as suas ideias, ações e valores sempre resultam em bons resultados para essa mesmas pessoas que confiam nele.

Parafraseando Platão, A força do Homem é medida por aquilo que ele faz com o Poder. Mas o carácter do Homem é medido por aquilo que ele faz sem Poder. Ou seja, líderes não se criam, eles nascem. E depois que eles provam o seu valor é lhes dado o poder de comando. Contudo, isto que é válido na vida militar ou politica, não é válido na vida técnica.  Lembre-se que nem os militares nem os políticos são técnicos - ou seja, não seguem nenhuma disciplina racional especifica. Militares seguem ordens e são bem treinados para executar qualquer tipo de ordens e Políticos simplesmente convencem pessoas pelos seus interesses. Não ha ciência por detrás destas atividades e por isso a importância de lideres que tenham a capacidade de agregar pessoas junto a eles : carisma.

Tudo bem que o carisma pode ser usado em qualquer área, inclusive em equipes de software. É especialmente útil quando a pessoa não conhece a parte técnica e se baseia na engenharia social para parecer e alcançar aquilo que não é e não tem. Ou seja, o carisma poder ser uma boa forma de enganar os tolos. Em uma equipe de técnicos o trabalho acaba se resumindo à prática da construção de algo que funciona. Ora, carisma não faz as coisas funcionarem, é o conhecimento técnico e a experiencia que tornam possível levar ideias à prática e tornar requisitos em software.

Mesmo assim, as empresas procuram pessoas carismáticas que possam ser líderes de equipe técnica, ignorando o seu conhecimento. Isto provoca um efeito comum de quem comanda a equipe não saber fazer ele mesmo o que comanda aos outros. É aqui que o paradigma de divide entre o que é o mundo corporativo, militar e politico daquilo que é o mundo tecnico e prático. Nos outros mundos as pessoas aceitam e até – de certa forma – esperam que seus superiores não saibam realizar o que pedem. O general pode ter ampla visão das consequências do seu pedido e o soldado nenhumas, da mesma forma que o general pode não ter qualquer noção do tipo de capacidade fisica e mental necessárias a levar a cabo a missão e o soldado vivê-las diariamente. Em software, o software é sempre criados pelos desenvolvedores que são técnicos que conhecem as consequências do que lhes é pedido e sabem como as realizar. Nem todos podem ser assim, mas ha muito que têm esta capacidade. Diferentemente dos soldados.

É por isto que irrita que uma equipe de software seja comparada a um exercito. Me irrita ainda mais do que se comparada a um chão de fábrica. Sempre existe o conceito de que as pessoas não sabem o que estão fazendo e apenas estão ali para seguir ordens. Se isso fosse verdade coisas como “parecer tecnico”s não existiram.

As empresas de hoje, ajudadas pela incompetência funcional dos RH em entender o mundo do software, procuram as pessoas erradas para os cargos errados. Aliás não sabem exatamente que cargos seriam necessários e os confundem com algum tipo de hierarquia militar. As empresas que não fazem isto ( ou não o fazem tão Às claras) têm mais competitividade ( vide Google que ao mesmo tempo que ha responsabilidade ha latitude). Todos se esquecem que criar software é uma atividade intelectual e cujo treino está em saber mais e pensar melhor, e não em saber pouco e pensar mais.

As equipes de software apenas precisam de um Guia. Um porta-voz que fale por elas e que faça a mediação com outros envolvidos. Alguém com mais experiencia que possa decidir impasses  técnicos e ajudar as pessoas a saberem mais e pensarem melhor. Não precisam de alguém que as comande. Precisam de um Condutor, alguem à cabeça das operações , um Lead , e não alguém que comanda cegamente , um Leader.

Tal como o problema do Junior e Sênior que foi completamente vilipendiado pelas empresas e RHs também os conceitos relativos ao papeis das pessoas em projetos de software o foram. Espero que com o tempo as pessoas cresçam mais conscientes dos seus papeis e exijam mais respeito pelas empresas contratantes e saibam escolher entre as empresas que dão valor real às qualidades realmente necessárias para trabalhar com software.

Espero que um dia exista uma expressão me português que signifique o mesmo que “Lead Designer” e não tenha conotação de hierarquia militar.

A palavra “Design” refere-se à moldagem de abstrações para alcançar um objetivo prático. Podem ser abstrações de textura e cor da roupa (Fashion Designer), as abstrações de formas de objetos (Car Designer) ou até de cabelos (Hair Designer) mas podem também ser as abstrações de construções mentais como aquelas usadas em Orientação a Objetos ou em código de programação. A palavra é de difícil tradução para o português já que não distinguimos desenho no sentido de “esboço” como “desenho animado” de desenho no sentido de plano ou projeção. O inglês e o espanhol são mais ricos com duas palavras diferentes (design/drawing e deseño/dibujo). É por isto que a expressão “design pattern” é em português “padrão de projeto“. Só que “projeto” pode significa outra coisa no mundo do software e se quisermos falar de “Project patterns” a tradução seria a mesma. Isto é um problema para os linguistas, mas nos deixa com um problema também: a falta de percepção da diferença entre fazer esboços e planejar.

Comumente ouvimos falar de arquitetos de software. Um cognome popularizado por Gates nos seus últimos momentos na microsoft e popularizado no mundo java pelo conceito de separação de papeis e com a famosa certificação. E por isso todos almejam ser arquitetos. E o que faz um arquiteto de software ?

Normalmente as pessoas ou dirão que um arquiteto faz diagramas (desenhos no sentido de esboços) ou que é responsável por decisões referentes a requisitos não-funcionais como segurança e performance. Alguns dirão ainda que são lideres ou responsáveis por equipes, mas isso não é verdade já que arquitetos normalmente atual como especialistas que finda sua contribuição ao projeto migram para outro. A visão tradicional do arquiteto como alguém que faz esboços em papel daquilo que será a realidade do software é uma imagem bem presente. Ouvimos, até, falar de “software blueprints” ou “plantas de software” no sentido de desenhos imensos que estabelecem o como as coisas serão. Esta comparação entre o arquiteto civil e o arquiteto de software é muito querida a aqueles que comparam fazer software com fazer pontes e edifícios.

No lingo do software falamos de andares e nodos que podemos comparar com edifícios , se realmente quisermos, mas essas abstrações estão muito longe daquilo que os programadores fazem no dia a dia: escrever software. São abstrações importantes para transmitir ideias como distribuição e organização de responsabilidades, mas muito pouco uteis no dia a dia. Se formos usar a comparar com edifícios temos que dizer que a planta é algo bem longe do trabalho do pedreiro que dia após dia ergue o edifício.

O Designer não está preocupado com esboços e bonecos em papel, está procurando uma harmonia entre as partes constituintes os materiais que tem à disposição e o objetivo ultimo do objeto que está desenhando. Está preocupado com um sentido estético que não apenas agradável à visão, mas principalmente à capacidade humana de entender o abstrato, as relações, e se maravilhar pela simplicidade de uma boa ideia. O objetivo do designer é que menos adições levem a mais efeitos. Em software isso significa menos código, menos classes, menos conceitos, levem aos mesmos resultados , ou a melhores resultados.

Da minha experiência projetos precisam de designers, pessoas que têm na cabeça como o software foi, é e será e como chegar lá. Arquitetos são apenas as pessoas de demonstram aos leigos como chegar lá, e programadores são quem chega lá. Sem designers na equipe os programadores não sabem que padrões seguir ou que código escrever, nem que objetivo estão tentando alcançar porque não ha um desenho, no sentido de ‘não ha um plano”. Por outro lado, muitos designers na mesma equipe pode ser problemático. Seria como dois pintores pintando o mesmo quadro ou dois escultores esculpindo a mesma pedra. Funciona se eles estiverem em sincronismo, mas se não, é um desastre.

Hoje se inventou o papel de Lider Tecnico e ha algumas coisas que esta pessoa deve alcançar, e muitas delas são as mesmas das que um Designer teria que alcançar, como derivar em termos tecnicos o significa dos requisitos e assegurar uma visão técnica clara do projeto , mas um Designer não tem atribuições de gerencia como ser responsável pelo o que a equipe é ou não capaz de fazer. Lider Tecnico é apenas uma expressão para “Responsável pelos resultados da equipe que sabe falar tecnikês com a equipe” e por isso é normalmente uma pessoa diferente do Gerente. No mundo ágil não ha tanto este sentido mais burucrático do termo, mas ainda fica a responsabilidade pelos resultados. Em termos ágeis o lider tecnico é responsável pelo débito tecnico da sua equipe. Ser um bom designer pode ajudar muito um lider tecnico, mas nem todo o lider tecnico precisa ser um designer. Pode, por exemplo, apenas ajudar a equipe a concretizar a visão do designer. Afinal estes são todos papeis, de que estamos falando, e não de pessoas. Portanto os papeis podem ser acumulados ou não.

Se um Arquiteto está para o modelo tradicional de fazer software e para as Fábricas de Software ( afinal só de pode produzir em massa o que está esquematizado em algum lugar) O Designer está para o modelo moderno de fazer software e para os Ateliês de Software. Talvez a analogia mais próxima seja a da fabricação de carros. Existe um fase de atelier onde o carro é desenhado, no sentido de conceptualizado e planejado. Isso é esquematizado em esboços e depois produzido em fábricas. A diferença é que em software só temos a parte da concepção porque o código que escrevemos para idealizar algo, já é o produto final e ‘produzir em massa” é apenas gravar mais CDs ou publicar para download. Algo que o mundo tradicional ainda não entendeu, já que continuam achando que fabricar software é um processo semelhante a uma linha de produção. Pobres coitados.

Bom, agora que sabe o que é um designer de software talvez queira reconsiderar se realmente você quer ser um arquiteto que fica escrevendo um monte de documentos e fazendo um monte de diagramas, ou se quer um de designer que sabe moldar o código à sua vontade. Afinal, a vantagem que o designer de software sobre os outros designers de outras áreas é que ele trabalha com material etéreo que ele mesmo pode criar, como, quando e quanto quiser. É muita liberdade criativa …

Ao contrário que podem lhe dizer, e podem lhe ensinar nas faculdades por ai, software não se faz em fábricas nem se planeja no papel. Se visiona e se molda, como um estilista que mentaliza o resultado que quer obter e molda o pano até que o resultado físico seja igual ao que ele mentalizou.

Bons desenhos.

Aproveitei o embalo dos cursos que fiz na Sun para programador certificado (1.4, bons tempos) e fiz um curso lá chamado OO226 que trata de Analise Orientada a Objecos. Foi muito bom porque permitiu que se forma-se em mim o conceito de como analisar com objetos é diferente de programar com objetos. Muitos dos objetos de negócio nem sempre chegam a ser objetos de código, alguns são apenas campos, propriedades ou alguns são até ações que acontecem. O curso não era baseado em nenhuma metodologia de mercado e isso foi excelente porque não me viciou a pensar em certo mecanismo como a muitos que são formados nisto e saem da faculdade com RUP na cabeça ou algo que lhe valha.

Um coisa ficou bem clara: eu estava em desavantagem nenhuma porque nem quem era da área tinha informação real e fidedigna de qual processo/metodologia seguir. Na época já se ouvia falar de XP, mas não muito se Scrum e já estavamos em 2004.

De lá para cá, tenho dedicado muito tempo a tentar aprender sobre processo de desenvolvimento. A meu ver as coisas se separam em : Levantamento de Requisitos e Desenvolvimento. Levantamento de Requisitos é essencial que seja feito e muito bem feito. Requisitos mal levantados causam verdadeiros desastres. Todos os autores advertem sobre isto. O Chaos Report mostra os numeros do que acontece e mesmo o Cone de Incerteza leva isto em consideração. Não ha desculpa para não fazer um levantamento cuidadoso.

Claro que levantamento de requisitos não é simples. Requer técnica. Por isso, um livro que acho excelente é Software Requirements Patterns em que nos é ensinado o valor do requisito bem levanto e nos é dito que uns requisitos levam a outros num padrão. Requirement Patterns são os Design Patterns do levantamento de requisitos.  Um outro é Software Requirements que nos leva a entender como se faz um levantamento de requisitos e que ferramentas existem para nos ajudar. Uma interessante é o processo Wideband Delphi que é o antepassado do Planning Poker ( e você que pensava que os agilistas tinham inventado isto… )

Tudo isto porque eu fiquei obcecado em entender porque em todos os lugares que trabalhei as pessoas teimavam em estimar horas e cobrar por hora. Um modelo que para mim nunca fez sentido até hoje. Consultando a vasta referencia bibliografica no mundo do desenvolvimento rapidamente entendi  que em lugar algum de fala ou ensina sobre este modelo. Então porque o usam ?

Os ensinamentos clássicos dos livros de muitos autores de todo o mundo é largamente conflitante com a forma como se implementa o processo de cobrança e estimativa. Mas por costume e tradição as pessoas continuam fazendo o que sempre fizeram mesmo depois de terem vários problemas com o modelo. Este não abandono irracional de costumes e tradições que não têm nada que ver com os ensinamentos clássicos nos leva a um tempo quase que de era medieval do desenvolvimento de software onde ha muito mito e pouca ciência.

Por exemplo, uma mecânica tradicional que não faz sentido algum para mim: O programador cobra por hora para desenvolver o software. Ele estima quantas horas serão necessárias e fecha um preço por hora. Se mais horas forem necessárias para completar o projeto, ou porque o escopo aumentou ou porque o prazo é fixo, é cobrado um extra. Mas se o software tem bugs e é necessário corrigi-los o programador cobra extra. Extrapole isto para empresas e entenda que as empresas sobram dos clientes a sua falta de qualidade. Porque não simplesmente cobrar mais caro para começo de conversa e não cobrar por bugs ?  A resposta a isso é, para muitos, o velho “o mercados não está bom” … hummm… algun dia esteve bom ? algum dia vai ficar bom ?  O fato é que a empresa deve ter uma imagem e um nome a zelar, mas isso é desnecessários quandos os clientes que utilizam os seus serviços são enganados todos os dias sem perceber. Se o cliente comprasse uma casa ou automóvel com defeito ele reclamaria o seu dinheiro de volta, mas com software tudo está bem, quando acaba bem ( com um software utilizável mesmo que com bugs).

Hoje em dia com o movimento ágil muitos licenciados tomam conhecimento de mecânicas e processos mais semelhantes ao que seria de esperar e mais perto dos ensinamentos clássicos. Por exemplo, quando o programador/empresa estimam o esforço em horas e tornam o prazo igual ao esforço eles estão cometendo dois erros. Primeiro, não estão separando as dimensões de escopo e tempo e segundo estão estabelecendo uma taxa de realização à priori.

Se temos 1000 horas de trabalho a realizar e nos comprometemos a realizá-las em 1000 horas, estamos estabelecendo uma taxa de 1h de esforço/ 1h de relógio. Ou seja, o programador em 1h de relógio não faz nada mais do que programar. Não bebe, não come, não lê email, não fala com ninguém, ou seja, é uma máquina. Mesmo com os 30% a mais que é tradicionalmente colocado a mais ( as pessoas nem sabem porquê) , nos daria uma taxa de 10/13 (= 0,76). Com o cone de incerteza iríamos para algo como 1/4 (0,25) que seria mais apropriado. O problema, aqui é que o prazo está relacionado ao custo e este ao preço. E o preço está relacionado à competividade. Entenda que no mercado brasileiro a competividade ainda acontece apenas no campo dos preços, ninguém olha a qualidade. E isto é sobretudo verdade em licitações. Onde ganha quem oferece fazer mais barato ( não quem oferece fazer melhor).

Em ágil esta taxa de realização é a Velocidade e é a razão entre o escopo realizado e o tempo para o realizar.  Mas mesmo aqui, com todas as ajudas, as pessoas ainda cometem erros.

Em agil o prazo é fixado por um numero fixo de sprint que equivale a dizer por uma data pré-acordada. E o esforço é estimado em pontos de estória. Como ágil é baseado em inspeção, então é facil verificar se vai caber ou não. E medidas devem ser tomadas. Contudo, perante os fatos as pessoas tomas as ações tradicionais : adicionar pessoas, cortar na qualidade, ou tentar negociar aumentar o prazo. Mas porque nunca tentam negociar os escopo ?

Basicamente porque de alguma forma se comprometeram a realizar todo o escopo. Mesmo que não por contrato mas para agradar ao cliente, ou não mostrar que as estimativas foram furadas. Ou seja, por simples medo.

É este medo que impede as empresas e as pessoas que são desenvolvedoras a alimentar mitos medievais e manter práticas tradicionais enquanto esquecem os clássicos. Hoje ha muita gente tentando pegar o trem do ágil, mas muitos com a mesma intenção que pegaram o do RUP e outros antes dele : porque é “in”, é da moda. É o mesmo que as empresas quererem ser verdes. É bem visto. Mas isso não significa que realmente cumpram com o que dizer e sejam o que publicitam. É o mercado, vale tudo. Inclusive dizer que se é o que não se é.

Depois de tudo, para mim, o jeito clássico é tem muitos prós. Alguns contras, como ser normalmente burucrático e é aí que o movimento modernos mudou o cenário mostrando que é possível aplicar o que é clássico mas sem a chata burocracia.

Talvez não saibamos, ou possamos saber o que é certo, pois tal como em ciência a verdade está por ai escondida. Contudo é fácil e simples saber o que não é certo e tal como em ciências, vamos excluindo as hipoteses erradas. Os modelos tradicionais são hipoteses erradas. São mitos com roupagens que mudam. O cara diz que fazia RUP e agora faz Scrum, mas no fim ele faz é waterfall mesmo. Mas ai de quem ouse dizer que ele faz waterfall.  O rei vai nu.

Você que ainda não enxergou , que tal passar pelo médico e ver se tem algo errados com o seu pensamento lógico. Afinal as células cinzentas não usam a lógica apenas para criar código. Se você já enxerga que o rei vai nu, o que faz no dia a dia para melhorar a situação ?

Escopo de Projeto vs Escopo do Projeto

O escopo é o conjunto de todos os requisitos que o cliente exige que estejam contemplados no software a quando da entrega final. E aqui está o problema: o que o cliente exigiu no inicio do projeto, não é o que ele exige no final. É preciso entender que  o escopo não é aquilo que o software deve ser, o que o produto deve ser, mas sim o que o projeto irá realizar. O software pode ter muitos requisitos, tantos que pode levar levar vários anos até que todos tenham sido completados. Contudo, a realização de um software pode ser partida em vários projetos.  Olhemos de outra forma. O software tem um conjunto de requisitos a serem completados e o projeto tem um subconjunto desse conjunto. Em particular, o projeto pode conter todos os itens do conjunto original (qualquer conjunto é subconjunto de si mesmo) , mas isso não é uma obrigação.

Está claro que o escopo do projeto é o conjunto de requisitos que serão realizados no âmbito (no escopo) do projeto, enquanto simultaneamente existe um conjunto maior de requisitos que compõem o escopo do produto que estamos construindo.

Quando o cliente lhe paga para você realizar um projeto de construção de software, ele lhe paga para realizar o escopo do projeto, não o escopo do produto. Se é por isso que ele lhe paga, como você cobra ? Escreva a sua forma num pedaço de papel que já voltamos a ela.

Insumos

Se você constrói algo, você sempre tem algum tipo de insumo que é usado nessa construção: matéria prima. A matéria prima de um software são idéias, transformadas em requisitos (frases imperativas) e é sensato cobrar pela inclusão dessa matéria prima no produto. Não apenas o trabalho que a colocar lá, mas o trabalho da obter e usar.  Matéria prima de melhor qualidade promove produtos de melhor qualidade, e matéria prima ruim promove um produto final ruim, não importa quanto esforço você coloque.

Quando uma noiva escolhe o tecido do seu vestido e entrega  a uma costureira para o realizar , a matéria prima é provida pelo cliente. Isso não significa que seja possivel realizar um vestido de noiva com aquele tecido. Isso apenas é possível se a noiva teve a sensatez de escolhe  um tecido adequado (vestidos de noiva de lã ? … talvez no frio… ). Da mesma forma, ao realizar um software a matéria prima é entregue pelo cliente. É ele que conhece os requisitos. Mas da mesma forma que o tecido, podem não se apropriados aos objetivos finais. A arte de adequar os requisitos aos objetivos finais é chamada “Analise”. Uma das ferramentas da analise é o Levantamento de Requisitos (também chamado Analise de Requisitos, embora esse nome não seja cronologicamente adequado pois a analise real acontece depois do levantamento). A Analise é um passo comum a todas as profissões que começam com a recepção de materia prima de outrém. Ha que avaliar a conformidade do que é recebido.

Para conseguir avaliar o quão adequado um requisito é com os objetivos finais é necessário, primeiro, conhecer os objetivos finais. Eles são como axiomas que guiam tudo o resto. Em software esses objetivos (goal em inglês) são mapeados logo no inicio durante a vida do produto. Repare que estamos falando na vida do produto ainda, não na do projeto. A Concepção (Inception em inglês) é a fase do ciclo do produto onde os objetivos são encontrados com base em um objetivo maior que é a causa da realização do software. Este objetivo maior é chamado Visão e os objetivos do produto conspiram para que esta visão seja possível.  O famoso Documento de Visão descreve a Visão (objetivo ultimo) e os Objetivos (goals) do produto. Do produto.

Da posse do Documento de Visão (que pode ser um papel de pão , embora seja simpático que não seja) e da lista de requisitos para o Produto (Escopo do Produto), será feita uma triagem para agrupar os requisitos de forma a poder realizar um ou mais projetos que os realizarão, alcançando assim os objetivos, e por consequência a Visão.

Aqui podemos ter várias opções. Podemos realizar um único projeto , vários projetos ou um projeto com múltiplos sub-projetos. A decisão que realmente importa é concluir quantas entregas queremos/precisamos para finalizar todo o Escopo do Produto.  Talvez se tivermos uma versão mais simples que possamos vender ou demonstrar no ajude a angariar fundos para as próximas. Existem decisões estratégicas, comerciais e de mercado envolvidas na decisão de como dividir o Escopo de Produto para formar um ou vários Escopo de Projeto, que poderemos então realizar.

Dado um Escopo de Projeto, depois de consciensiosamente analisado teremos que pensar em constrangimentos temporais, ou outros, que nos obrigarão a fazer ainda mais divisões. Esta decisão do escopo do Projeto, acontece no âmbito do Projeto  e é utilizada para mitigar determinadas dimensões do projeto ( como custo, ou risco) e/ou para otimizar outras ( como prazo ou retorno de investimento). Estas divisões são chamadas Release (não ha uma boa palavra portuguesa para isto, talvez a mais próxima seja Publicação?). Os requisitos que serão completados no âmbito do Release formam o Escopo de Release. A união de todos os Escopos de Release formam o Escopo de Projeto. É claro que pode ser decidido que o projeto terá apenas um Release, mas isso é um caso particular e previsto no mesmo modelo.

Portanto, uma empresa que constrói software demanda Requisitos como insumo. Faz Analise para validar ou melhorar esses Requisitos. Forma o Escopo do Produto  com esses requisitos. Ajuda o Cliente a separar o Escopo do Produto em um ou vários Escopos de Projeto e finalmente em um ou vários Escopos de Release.  Esta empresa irá cobrar pelo trabalho que realizar o Escopo de Projeto, num certo Prazo, por um certo Preço, com uma ditada Qualidade, dentro de uma margem de Risco, para conseguir obter o Beneficio (Valor) descrito pelos Objetivos e pela Visão.

Cobrando pelo Trabalho

Voltamos então ao como cobrar o trabalho. Estamos pensando que o Preço deve incluir o Custo e o Lucro ( num modelo simplista). O que me custa dinheiro ? Os meus insumos:

• As instalações da equipe (incluido equipamentos, cafezinho, faxineira, tudo o que proporciona o ambiente, inclusive a energia gasta e despesas de comunicação e transporte) .
• A velocidade. O quão depressa o escopo tem que ser convertido em funcionalidade. Veja que para que o escopo seja feito mais depressa isso é mais caro do que ser feito devagar (andar de avião é mais caro que andar de carroça, não apenas pelo veiculo, mas pela economia de tempo). E este fator não tem que ver com o item anterior e sim com a habilidade das pessoas envolvidas e o numero de imprevistos e impedimentos que possam ocorrer
• A equipe. Os salários e prémios das pessoas que realizarão o trabalho.

O custo , C, é portanto composto do custo das instalações, I, que depende linearmento do tempo ( para simplificar), do “preço da equipe” W que também depende linearmente do tempo, mas que depende também da habilidade H do seus membros ( seniors são mais caros que juniors)  e da velocidade V, que também depende da habilidade dos membros da equipe H, da frequencia r, e tamanho dos imprevistos e impedimentos , M.

C = I(t) + W(t, H) + V(H, r ,M)

Todos temos uma noção que um escopo maior (com a mesma equipe) demora mais que um escopo menor. Portanto o tamanho do escopo é um fator essencial do custo. O tempo que demora a realizar o escopo (t) é proporcional ao tamanho do escopo (E) e à velocidade em que podemos converter os requisitos do escopo em funcionalidades do software. Velocidade maior significa menor tempo.

t = E / V

O que nos dá o resultado:

C = I(E,  V) + W(E, V, H) + V(H, r ,M) = >

C = f ( E , H , r , M )

Olhe a sua anotação que fez no inicio e verifique onde o tamanho do escopo entra na sua forma de calcular o custo.
Veja que o custo depende apenas do Escopo,  da Habilidade da equipa, da freqüência de impedimentos e do tamanho dos impedimentos.

Se você é como a maioria você inclui o tamanho do escopo através de chutes que você obtém comparando com projetos anteriores ou simplesmente usando um modelo qualquer de ajustes. Ou seja, algo robotico, matemático e sem sequer ter olhado o que é o escopo realmente : quais são os requisitos; e qual é  sua equipa, então não está olhando para o que interessa.

O Tamanho do Escopo

É portanto claro que necessitamos quantificar o Tamanho do Escopo do Projeto para poderemos comparar o escopo do projeto A com o do projeto B de forma objetiva : comparando números.

O que acontece, então, quando o cliente fixa um Prazo ? Ele está, básicamente, definindo o seu tempo máximo (tmax) para um certo valor P. Isto significa que ele está lhe dando um certo Escopo de Projeto, E para ser cumprindo em um certo Prazo, P

P = E / V =>  V = E/ P

Ou seja, ele está definindo a sua velocidade mínima.  O que acontece se o escopo aumenta e o prazo continua igual ? A velocidade tem que aumentar. Isto, significaria automáticamente que a habilidade da equipa tem que aumentar ou a frequencia e/ou tamanho dos impedimentos tem que diminuir. E isso custa dinheiro. De fato um projeto de prazo fixo é mais caro que um de prazo aberto. Isto porque temos que contar com uma equipe mais capacitada ( individualmente e como equipe) e controlar riscos muito melhor ( para mitigar r e M )

O tamanho do Escopo do Projeto é essencial para planejar a execução do projeto, e esse tamanho tem que ser medido nas mesmas condições que a habilidade da equipe. É por isso que vários autores recomendam que seja a equipe que vai realizar o trabalho a estimar o tamanho do escopo. Assim o “fator de habilidade” está incluso no tamanho do escopo ( oque a equipa estima) e na velocidade( o que ela realiza de fato) , exatamente como a formula acima mostra que seria necessário.

A forma atualmente de maior sucesso para alcançar este objetivo de quantificar o escopo é o uso de uma escala de tamanhos relativos (Story Points) e Planning Poker (Poker de Planejamento) onde a equipe estima o tamanho usando a escala fixa, pré-determinada, o conhecimento nas suas habilidades e o esclarecimento dos requisitos que compõem o Escopo do Projeto, ou o Escopo do Release (quando o projeto é dividido em vários releases).

Contrato de Custo-Alvo (Target-Cost Contract)

Um modelo de contrato de custo-alvo muito interessante que faz uso das relações anteriores.  Neste modelo, após definido o Escopo do Projeto ele é estimado e se chega num Tamanho Inicial do Escopo do Projeto. Este tamanho é dado como imutável.

O Contratado de posse da velocidade por iteração da sua equipe , calcula o numero de  iterações necessário para executar esse escopo.    Por exemplo, em agile, usando sprints como iteração  o contratado indicaria quantos Sprints são necessários.  Num projeto tradicional é o numero de entregas intermediárias.  O tempo não é realmente importante já que estará ligado à determinação da iteração. O que é importante é que no fim de cada interação haja uma entrega que funcione de fato. O contratado fixa um custo por iteração e traduz esse numero  interações num valor de custo. Esse é o Custo-Alvo.

As partes acordam também um numero máximo de iterações para o projeto.

O contratante obriga-se a fazer o pagamento de um valor inicial  igual a metade do custo-alvo mais uma parcela a cada iteração conforme metade do custo por iteração. O Contratante é livre de terminar o projeto no fim de qualquer iteração. O contratante obriga-se a pagar as iterações até ao numero de iterações previsto ou até que o escopo seja completado ( o que acontecer primeiro).

O que acontece com este contrato é muito interessante. Se o contratado ( a empresa de software) pensou direito e apresentou um custo-alvo com alguma margem de lucro, então é porque espera terminar antes do numero previsto de iterações. Se isso acontece ela ganha metade do valor do custo multiplicado pelo numero de iterações que sobraram pois já foi pago com antecedência. O mesmo se o cliente desiste do projeto e nesse caso o valor restante serve de “multa”. É claro que o cliente não vai parar antes, mas como o tamanho do escopo é finito  o projeto acaba quando o escopo acabar não deixando que o cliente force o uso de todas as iterações previstas.

Se algo correr errado ou a empresa de software for “preguiçosa” e o projeto for além das iterações previstas no contratado o prejuizo é da empresa de software, mas só até ao limite das iterações máximas previstas. A partir dai o projeto é extinto ou foi completado. De qualquer forma existe um software funcionando com um conjunto substancial de funcionalidades, e todos ganham.

Repare-se que este contrato fixa o tamanho do escopo, e não o escopo em si. Ou seja, os requisitos podem mudar, ir e vir, desde que o tamanho total não seja alterado.  A adição de novas funcionalidades obviamente irá aumentar o tamanho do escopo, e por conseqüência alterar o contrato que terá que ser recalculado ( na realidade será calculado o custo extra em numero de iterações extra). O que é simples e deixa claro as alterações de escopo evitando o aumento “invisivel” do tamanho do escopo sem o aumento do custo que vemos em outros tipos de contratos. Portanto, embora parece inflexivel, este tipo de contrato é mais flexivel que o tradicional contrato de escopo fixo + preço-fixo, pois prmite alterar o que o cliente vai querer no software desde que isso não interfira no tamanho.

É preciso dizer que este tipo de contrato não é desenhado para ser usado apenas com disciplinas ageis com scrum ou XP. Ele pode ser usado em qualquer modelo que seja iterativo e que estime o tamanho do escopo do projeto numericamente.  Ou seja, sempre que você saiba o tamanho do problema …

O fracasso dos processos stage-gate usados nas outras engenharias é hoje óbvio a qualquer um que tenha tido o mínimo de interesses para ler sobre o assunto ou a hombridade para olhar os resultados dos projetos em que participou nestas últimos décadas. O conceito de que projetos grandes e complexos de software podem ser tratados da mesma forma que projetos de engenharia civil ou aeronáutica ainda assombra muitos projetos hoje em dia, mas uma nova geração de desenvolvedores está entendendo que esse não é o caminho da força. O caminho da força é exatamente a disciplina e o rigor mental de um conjunto de pessoas trabalhando para e por um mesmo propósito. Os desenvolvedores finalmente entendem que sem conversar com o cliente nada acontece, ou pior, más coisas acontecem muito freqüentemente.  Conversar é a chave para um bom software.

Mas ainda existem alguns achando que tudo isto é magia e jogo de espelhos e fumaça… Entre estes existem os que enfim são incapazes de raciocinar fora da caixinha onde vivem, mas existem bastantes que ainda pensam assim por falta de lhes ser mostrado um melhor caminho, ou por descrédito de já terem ouvido esta historia antes ou terem experimentado e falhado. Esta atitude é a mesma da pessoa que pensa que se o homem da TV engole facas, ela também pode. E ao tentar, e se cortar toda, acha que o homem da TV é uma fraude, um engano e uma estupidez. O fato é que é a esta pessoa falta a destreza para entender que para chegar naquele nivel é preciso treino, esforço, compreensão dos perigos e sobre tudo : profissionalismo e dedicação.

Como saberão as disciplinas metodológicas com Lean, Kanban, Scrum, XP e outros da linha ágil, propõem o seguimento de um conjunto de práticas. Algumas ainda propoem conjuntos de regras, cerimónias, mecanismo de temporização e papeis que as pessoas devem desempenhar. Isto é o equivalente, nas artes marciais ao ensinamento dos golpes fisicos. Como, onde e quando colocar o braço, as pernas, a cabeça, etc…  como usar a espada, a vara, a faca, etc … Mas os golpes não são a razão da arte marcial, são apenas a parte observável. Aquilo que é a essência das artes marciais está no porquê daqueles movimentos.  Da mesma forma, a essência das disciplinas metodologias está no porquê das mecanicas, regras, papeis e cerimónias. Em ultima análise existe uma filosofia que guia o desenvolvimento e uso destas coisas observáveis.  Se você é um curioso destas coisas, provavelmente já notou que a maior parte das práticas já existia antes da era ágil. O murro também existia antes das artes marciais. Isso não as torna menores. A vantagem não está no murro, mas no como, quando, onde e por quê usá-lo. O mesmo para as práticas.

A existência de uma filosofia que premeira todas as práticas de um disciplina metodológica é a grande diferença para os processos clássicos (eu disse clássicos, não disse tradicionais) baseados no stage-gate como o Unified Process e seus derivados. Estes processos se baseiam em metáforas e analogias entre o mundo do software e outros mundos, especialmente os das engenharias civil e aeronáutica. Repare que não há uma filosofia ou disciplina inerente a estas engenharias. Basicamente existe uma matemática e uma ordem de dependência e precedência entras atividades. Nada mais. O fato de que a casa se constrói de baixo para cima,  é porque simplesmente as fundações são feitas no chão, não no ar. E todo o resto vai em cima disso. É simples. É sempre assim, e é simplesmente óbvio. Não há uma disciplina envolvida, porque simplesmente não ha escolhas a serem feitas.

As disciplinas metodológicas foram criadas a partir do conceito de que construir software  é uma atividade complexa. Mais complexa que engenharia civil e aeronautica e que por isso, é necessário que siga outro tipo de princípios e regras. Mas quais regras ? Ninguém sabe. Esta que é a mudança de paradigma que é dificil explicar e demonstrar para alguém que não entende que estamos falando de disciplinas e não de um bando de regras. Isto não é um jogo onde cada um aplica as regras que mais gosta. Tente fazer isso com uma arte marcial e sairá machucado.  Ninguém são, é louco, para fazer isso. Então, porque as pessoas insistem em pensar que podemos escolher um conjunto de mecanismos, ou regras, ou cerimônias das disciplinas ágeis e simplesmente criar nosso próprio processo.  Atente, com atenção, às palavras da ultima frase. As pessoas querem escolher regras para criar seu próprio processo. É só isso que um processo é: um conjunto de regras. E quem pensa assim ainda não entendeu que os processos não funcionam. Não no mundo da construção de software.  O Mundo está indo para as disciplinas metodologicas e deixando para trás o conceito de processo de produção, mas estas pessoas insistem em querer criar um processo usando as “melhores regras” que estas metodologias usam. É como querer criar uma arte marcial usando os melhores golpes das artes marciais. É possível ? É. Mas um conjunto de golpes é uma arte marcial ? Não. É apenas marcial, não uma arte. Falta personalidade, falta alma, moral, disciplina.  Falta o por quê, a razão. E principalmente falta o Objetivo.

Porque não podemos usar um quadro kanban junto com um daily meating e não usar Scrum  ? Porque não funciona. Não está a disciplina. O daily meating é vazio sem a responsabilidade partilhada que o Scrum procura. Não ha razão para conversar, em conjunto, sobre as atividades de todos, se não ha unidade.  Porque não podemos usar planning poker num projeto waterfall ? Porque o planning poker não é um jogo de numeros, é um processo de aprendizando, dialogo e acordo. Este processo visa criar a unidade em vez da impor. Visa procurar a visão do projeto como um todo e um acordo de como o executar. A disciplina está em chegar nessa unidade através da prática, da mesma forma que a arte marcial procura a clareza da mente através do movimento físico.  Para muitos um sprint é uma unidade de tempo. Ela é uma unidade de tempo, também, mas é principalmente uma unidade de foco. É um tempo onde o desenvolvedor pode desenvolver o que estava acordado, sem interrupções ou alterações do acordo. É um período importante para criar e fortalecer a responsabilidade do desenvolvedor e o respeito dos outros para com ele. Num processo tradicional pede-se que o desenvolvedor faça algo, mas nunca se respeita o pedido inicial ou o tempo que o desenvolvedor tem que ter de paz, para realmente desenvolver. Então do que serve ter um cronometro ? Só para apressar ? ( a tradução de sprint poderia ser “apressar até à meta”).  Não. “Estamos nos sprint” é a forma educada de dizer “Estamos trabalhando. Deixe-me em paz!” Mover papeizinhos num quadro branco não é kanban, nem scrum. É apenas um quadro branco com papeis em diferentes posições. Significam algo? Claro que sim. Significam o que você quiser. As cartas do tarot também significam algo quando estão em certas posições da mesa , mas e daí ? Isso basta ? Não.  O quadro branco com os papeis não é para dar visibilidade. É para dar visibilidade, também, mas principalmente é para encontrar problemas e com isso melhorar o processo. Ah! melhorar o processo.. então o processo não é fixo ? Não. O processo não é fixo. As práticas não são fixas, as regras não são fixas, a filosofia é que é. A disciplina, os objetivos. Não o caminho. O que as disciplinas metodológicas nos dão é uma filosofia e um conjunto de regras iniciais do processo, e um mecanismo para melhorar esse processo continuamente, dependendo dos intrevenientes! É um processo adaptativo por natureza.  As regras inicias são iguais para todos, mas onde cada um vai chegar é totalmente obra de melhoria continua. Exatamente como um praticante de uma arte marcial.

Então por quê não podemos simplesmente pegar uma coleção de práticas, colocá-las no mesmo saco, baralhar, e cria nosso próprio processo ? Porque estaremos apenas criando um processo, não uma filosofia. Não uma disciplina.  Uma disciplina implica que haja coerência entre as práticas, que elas se complementem e fortaleçam umas às outras e para isso é preciso um conjunto de principio maiores que as práticas em si mesmas, e isso só podemos alcançar através de uma disciplina completa.

Finalmente, queria deixar uma palavra para quem acha que pode começar a usar uma disciplina metodologia, como Scrum, ou XP, por exemplo, sem se comprometer com ela. Sem se empenhar, e sem a seguir completamente. Se você é um dos que pensa que pode começar a usar estas disciplinas “por partes”, pense no desastre que seria tentar partir um bloco de cimento com os dedos sem o devido preparo físico e mental da disciplina marcial completa. Muitos podem emitar os movimentos que veêm um mestre de artes marciais executar, mas imitar os movimentos não é praticar a arte. A arte está em entender os movimentos. Da mesma forma, a boa forma de base software está em entender os principios por detrás das disciplinas metodologia e não em imitar os movimentos das suas práticas. Ninguém aprende a partir uma pedra com as mãos por tentativa e erro. É feito com treino. E treino é algo diferente de tentativa e erro.

Para entender as disciplinas é requerido estudo. E sem estudo, tentar praticar é um insulto. É como um cara que aprendeu a imitar meia-dúzia de golpes dos filmes querer se denominar mestre de artes marciais. Não é apenas um insulto aos verdadeiros praticantes da arte, mas ao Mundo, por querer que acreditemos nesse embuste.

Se você gosta das disciplinas metodológias modernas, se realmente vê vantagens nelas, e sente que ha algum mérito nelas, antes de mais as estude. Tente entender a filosofia primeiro, para depois começar a exercitar as práticas.

O desenvolvimento de software teve a sua pré-historia quando software e harware era virtualmente indestinguiveis mas ao mesmo tempo que se criou um mercado de software distinto do de hardware, se criou a idade média do desenvolvimento.

O software clássico, ou seja, aquele que nasceu pela diferenciação entre hardware e software nasceu das mãos de engenheiros electro-electrônicos . O software contemporâneo não mais requer o mesmo leque de capacidades. Porque o software nasceu de dentro da engenharia eltro-eletrônica a forma de fazer software nasceu com a mesma metáfora da forma de fazer hardware. Um processo chamado stage-gate de que falei no post passado, mais conhecido como waterfall.  Isso faz sentido para obras de engenharia, mas o que demorámos 50 anos a perceber, é que não faz sentido para software.

Tudo o que existe, muda

O paradigma do desenvolvimento de software está, em si mesmo, evoluindo. É um alvo em movimento. Mas antevemos hoje algumas propriedades que o desenvolvimento de software tem, que mais nenhum ramo de atividade tem, e são esas propriedades que moldam um novo paradigma de desenvolvimento.  Uma destas propriedades é :

Todo o software é baseado em requisitos não estáveis.

Esta verdade universal é o grande diferencial de um artefacto de qualquer engenharia onde os requisitos são estáveis. Muitos autores já escreveram sobre este problema. Muitos já apontaram a instabilidade dos requisitos como o grande problema do desenvolvimento de software. Nada de novo ai. Qualquer um com mais de três projetos nas costas já sabe que isto é simplesmente verdade. Isto nos leva a duas escolas de pensamento:

Escola Tradicional

Para a escola tradicional, esta fato é um problema, e a forma de resolver este problema é com uma forte pressão para evitar a mudança. Esta escola de pensamento defende que a forma de lutar contra a constante mudança de requistos é proibi-la ou torná-la tão onorosa que ninguem quer realmente fazê-la. Esta escola parte do principio errado que a instabilidade acontece por responsabilidades de agentes externos  ao processo de desenvolvimento de software ( seja ele qual for) e que tal mudança não é inerente ao software em si.

Este pensamento é muito fundamentado no pensamento da engenharia de hardware e em logica determinista em que se julga ser possivel conhecer todas as variáveis e sua evolução.

A escola Tradicional faz uso de três ferramentas principais : o levantamento exaustivo de requisitos, o plano e o mecanismo de pedido de alteração (change request). Estes três mecanismos visam, no entender desta escola, esgotar as opções de possibilidade de mudança , primeiro : garantindo que todas as opções foram pensadas e analizadas com antecedencia e as melhores foram escolhidas;  segundo, documentando tudo isso, e qual o caminho a seguir : o plano;  e , terceiro : se por uma bizzarra eventualidade for possivel que algo tenha escapado e seja necessário alterar algum ponto do plano, isso tem que ser feito com todo o cuidado e controle possivel pois pode ter reprecursões e interações com os outros requisitos não previstas com antecedência.

Escola Moderna

Para a escola moderna o fato dos requitos serem instáveis é simplesmente uma caracteristica da natureza das coisas e em particular do software. Portanto ha que aceitar essa mudança com um fato e construir mecanismos, processos e ferramentas em torno dessa realidade. Porque este fato não é um problema criado por agentes externos não é concebivel criar mecanismos para o evitar, e sim, muito mais apropriado criar mecanismos para acompanhar essa mudança.

Este pensamento é baseado na filosofia clássica grega e oriental de que a única constante do universo é a mudança.

Porque esta forma de pensar implica em constantemente estarmos acompanhando a mudança, e portanto mudando a todo o momento, ela ganhou o nome de “Ágil”. Mas o nome “Ágil” não veio daqui, veio do manifesto ágil. Foi um “batismo por proximidade” , por assim dizer.

Software é um produto da mente, não da mão

Uma outra caracteristica que está sendo sendo cada dia mais visivel é que:

Software é um artefacto criado por pessoas.

Escola Tradicional

Para a escola tradicional isto significa apenas uma simples coisa : outros animais não podem fazer software, apenas o ser humano. Logo, para fazer software temos que ter o custo de contratar pessoas. Se quisermos que seja feito mais depressa, contratamos mais pessoas. Se queremos que seja feito melhor, contratamos melhores pessoas. Os tradicionalistas se referem a isto como “braço” , significando que “mais braços, mais mãos. Mais mãos, mas rápidamente se digitam coisas no teclado, logo mais depressa o codigo é escrito e portanto mais depressa o software é completado”. Simples.

Porque os requisitos não mudarão nunca ( salvo exceções devidamente contidas nos pedidos de alteração) e o plano traça o unico caminho possivel, então, seguir o caminho não é uma questão de escolha, de livre arbitrio, de experiencia, é apenas uma questão de correr mais depressa. Logo, o prazo para criar um software pode ser facilmente modificando alterando o numero de pessoas disponiveis para o escrever.

Escola Moderna

A escolha entende este fato como significando que software não poderia ser criado por acaso pela natureza, ou pelo simples esforço fisico,  mecânico , muscular ou repetitivo. Criar software é um trabalho intelectual e não muscular. Demanda criatividade, conhecimento, raciocinio e destreza mental. Portanto para fazer mais depressa precisamos de pessoas mais critivas, com mais conhecimento , com melhor raciociono ou mais destreza mental.

Porque os requisitos mudam, é necessário constantemente exercitar as celulas cinzentas para obter novas ideias que permitam alterar o software existente para cumprir as novas funcionalidades da forma mais vantajosa possivel ( leia-se “a que custa menos dinheiro”). Porque software é feito por pessoas e elas usam ideias para o criar, a comunicação dessas ideias é vital para o seu refinamento e evolução. Portanto a comunicação é vital.  É sabido que o numero de canais de comunicação aumenta na proporção do quadrado de pessoas habeis a comunica. Para ser mais exato o numero de canais é igual a p(p-1)/2 onde p é numero de pessoas. Portanto para 3 pessoas temos 3 canais para 4 temos 6 canais ( o dobro para o aumento de uma unica pessoa), para 6 pessoas temos 15 canais ( o quintopluo para o aumento de 3 pessoas). É facil de ver que quanto mais pessoas, mais dificil a comunicação e mais dificil a evolução das ideias. Portanto, o conceito da escola moderna é ter o menor numero possivel das pessoas mais capazes possivel – a equipa – e ter várias equipas. Esta simples fato é sabido desde dos anos 60 pelo lengendário livro “The mythical man month”, mas historicamente as pessoas se negam a enxergar isto, ou são oblivias a este conhecimento.

Entra a escola Ágil

Preciso esclarece que a escola ágil é apenas uma das linhas possiveis de uma escola moderna. Não é a única. Díficil de dizer que é a melhor.

A escola ágil parte dos principios do desenvolvimento de sofware visto atrás e estabelece um objetivo comercial. É importante sublinhar bem que se trata de um objetivo comercial e nada além disso. Não ha aqui nenhum tipo de valor moral maior ou grandiosidade Humana. É apenas uma questão de balanço comercial. O objetivo é simples:

Prover valor ao cliente.

O “Cliente” aqui é a pessoa que detém o poder de decidir pelo pagamento, ou não, do software. Não necessáriamente é a pessoa que o vai usar e não necessáriamente é a pessoa que realmente via pagar por ele. Por exemplo, o filho de um casal quer um novo jogo de computador ( que é um software), quem paga é o pai , mas quem permite ou não que a compra seja feita é a mãe. Neste caso, o “cliente” é a mãe. Portanto o software tem que ter caracteristicas que agradem ao filho (para que o queira usar), mas principalmente à mãe, porque será ela a realmente levar à compra. É por isto que os jogos tem um selo dizendo o nivel etário aconselhado e o tipo de contéudo presente. Esta classificação (rating) não é para o bem da humanidade ou para proteger valores da sociedade, é apenas e só, para que o produto “jogo” seja mais aceitável por quem o compra de verdade ( no caso, as mães). Não se entenda deste exemplo, se são sempre as mães. O que se precisa entender daqui é que existe papeis diferentes do ponto de vista do uso e da compra do software. O software tem que ser agradável a quem o usa (ou será rejeitado), a quem o paga ( o custo-beneficio tem que agradar ao “dono do dinheiro” também ) mas principalemente ele tem que agradar a quem tem a autoridade de negar a compra : o cliente.

O manifesto ágil nasce daqui. Da necessidade de prover valor ao cliente. “Valor” é : “o que quer que seja que o cliente usa para dedicir se compra ou se bloqueia a compra”.

Analizemos o manifesto à luz destas informações :

(1) Individuos e Interações em vez de processos e ferramentas.

A ideia do manifesto é contrapor a escola tradicional exemplificada aqui por “processos e ferramentas” à escola moderna, da qual a escola ágil faz parte. Este item resalta a importancia das pessoas em detrimento das mecânicas. Contudo passa a ideia que não precisamos de processos ou de ferramentas, o que não é verdade ( Alguem não usa uma IDE ? Claro, mas ninguem acha esses caras normais, i.e. nos 90% da curva). O ponto aqui é realmente que software é feito por pessoas, não por mecanismos.

(2) Software funcionando em vez de documentação extensiva.

Mais uma vez, a ideia da escola moderna que o objetivo é o software, não o plano. Claro que a expressão “software funcionando” é até tautologica (de que server um software não funcionando ? E um “não funcionando” pode ser considerado um software?) mas é apenas para reforçar que o objetivo de construir um software é ter um software.  Não um conjutno de documentos que não “funcionan”, ou seja, o plano não vai resolver o problema do cliente, apenas o software – funcionando – vai.

(3) Responder à mudança em vez de seguir um plano.

Aqui, de novo, a ideia de que a mudança é inivitável e que, portanto não ha valor em seguir um plano. Esta frase da a ideia de que não devemos fazer planos, o que é falso. A palavra “plano” está implicitamente atrelada ao contexto da escola tradicional em que apenas depois do plano pronto, poderiamos começar a criar o software. A ideia não é essa. A ideia é que o conjunto de requistos é um alvo, mas um alvo em movimento. Portanto a estratégia tem que estar em conformidade.  Tem que haver um plano no sentido de “tem que existir uma estratégia” – seria suicidio comercial não ter uma – mas não precisamos de um “plano” no sentido de “um mapa feito à priori que nos mostre por onde ir”

(4) Colaboração com o cliente em vez de negociação contratual

Este ultimo item ( o terceiro na lista original) deixa bem claro ao que veio a escola ágil : agradar ao cliente. O objetivo sempre será agradar ao cliente. A contraposição aqui diz respeito a ter uma lista de requisitos fechada e pedidos de alteração versus ter uma lista alterável (dinâmica) que muda conforma o “querer” do cliente. “Negociação contratual” faz alusão Às clausulas restritivas que existem nos contratos tradicionais que proibem o cliente de fazer modificações ou o oneram por isso. É um sistema de castigo contrário ao conceito de que a mudança irá sempre acontecer, então ao colocar essas clusulas a empresa está automaticamente castigando o cliente. É apenas uma quetão de tempo para acontecer, e não uma questão de se vai acontecer ou não.

Ao ler o manifesto é preciso entender que a segunda parte da frase sempre se refere ao contexto da escola tradicional. Este ultimo item não significa que não devemos fazer contratos com o cliente – é obvio que devemos – o que está sendo dito é que esses contratos não têm que ser baseados em mecanismos de castigo e recompessa e sim em mecanismos de colaboração.

A escola ágil visa maximizar o negócio que o desenvolvimento de sfotware é ao mesmo tempo que se segue o pensamento da escola moderna. Mas a escola ágil não é a única vertente moderna. Do outro lado temos a escola artesã.

Entra a Escola Artesã

É realmente dificil arranjar um bom nome para esta vertente moderna. O conceito aqui é que, dado que os principios da escola moderna são verdadeiros, não ha que esquecer de lembrar que são pessoas que constroem o software, e num ambiente de negocios, essas pessoas têm que ser Profissionais ( com P maiusculo). Estes profissionais são chamados carinhosamente de artesãos. Isto não é para dizer que a criação de software é rude e crua, mas sim para lembrar que a criação de software é baseada nas capacidades critivas de pessoas ( como uma arte, e dai o artesão) e não na força bruta ou na repetitividade de uma máquina.

O manifesto do artesanato de software ( software craftsmanship) é mais do que um compromisso com o cliente, é um compromisso de cada um de nós com o profissional que ha em nós e ha em todos os colegas de profissão. É um compromisso de qualidade, esmero, requinte e escolha do que é certo do ponto de vista da profissão e não apenas do que é certo do ponto de vista do cliente.  Então, a escola artesão evolui o manifesto ágil para um manifesto onde a qualidade é tão importante quanto o resultado.

(1) Não apenas software funcionando, mas também software bem confecionado.

A discussão é agora o que seria entendivel por “bem” e “mal” confecionado, mas em geral o que está sendo colocado aqui é : nada de gambiarra, seguir padrões ( não apenas design patterns, mas padrões de nomenclatura, de arranjo de codigo,  de trabalho, etc…) e acima de tudo respeito pelo profisional que irá dar manutenção no software depois de um tempo( que podemos ser nós mesmos, é bem comum este caso).

(2) Não apenas responder à mudança, mas também constantemente agregar valor.

E não apenas o valor que o cliente espera, mas o valor que os outros profissionais esperam. Se um produto é louvado por todos os profissionais do ramo, é bem provável que o seja pelos clientes também.

(3) Não apenas colaboção com o cliente, mas também parceria.

Parceria é diferente de colaboração. Parceria advém dos dois entenderem que estão no mesmo barco e não que um trabalha para o outro. Sim, no contrato está escrito que um é o “Contratado” e outro é o “Contratante”, mas isso são apenas termos legais. Na realidade são pessoas com um objetivo comun: criar um software.

(4) Não apenas individuos e interações, mas também uma comunidade de profissionais

Este é talvez o mais importante item que marca a diferença entre as escolas. A escola ágil aceita e entende que as pessoas são importantes e que elas devem comunicar pois isso é o motor da critiavidade necessária ao construir um software, mas é cega à qualidade inerente dessas pessoas. Em tese qualquer pessoa poderia pertencer a uma equipa da escola ágil, numa equipa artesã isso não é suficiente, é preciso que as pessoas sejam profissionais, ou pelo menos, que aspirem a o ser. Mas a “comunidade” não se esgota na equipe. Ela traspassa barreiras de equipe, empresa, e até de país e lingua. É a procupação dos desenvolvedores se ajudarem entre si, mesmo que competindo pelos mesmos clientes, ter o respeito e o fair-play necessários entre si, fora com constrangimento do mundo dos negocios.

Infelizmente, falar de profissionalismo na construção de software ainda parece uma aberração hoje em dia. Não será por muito mais tempo, porque a cada dia que passa ser rápido não é mais sufciente, tem que ser bom e rápido.  Quem aprender esta lição antes e a executar melhor, leva o cliente. Tão simples assim.

O manifesto ágil tem como pretensão escapar da máquina monstruosa e pesada com que o software era feito nos moldes tradicionais e o seu enfoque é priorizar o cliente tendo como base as propriedades canónicas do desenvolvimento de software. A preocupação era abandonar o modelo velho.

O manifesto do artesanato de software pretende chamar a atenção que quebrar o modelo tradicional não é suficiente, que seguir o modelo ágil de foco no cliente não é suficiente a longo prazo e que é necessário nos preocuparmos com a Qualidade e  a correta confeção dos software, não porque o cliente vai achar isso lindo, mas porque é uma questão de dignidade , honra e orgulho profissional. Você pode entregar o software mais util do mundo, mas se as entranhas dele forem reles, você assumiria a autoria ?

A escola ágil critica a escola tradicional porque não enxerga as propriedades do desenvolvimento do software , não enxerga os fatos e a história, mas é ingénua aos olhos da escola de artesã ou esquecer ao que viemos. Viemos para constuir software e não para chafurdar nos bits e bytes e concordar com todas a sandices que nos pedirem. Temos um dever para com o proprio software tanto quanto temos para com o cliente e abdicar disso, no entender da escola artesã é uma irresponsabilidade.

Eu me encontro no grupo de pessoas que defendem o manifesto de artesanato de software. Agil para mim não é suficiente. É necessário, mas não é suficiente. Existe esse passo a mais a se dar. Existe a necessidade de formar profissionais ( ou seja, pessoas com honra e principios de profissão) e não apenas pessoas que conhecem a parte tecnica. O que vivemos hoje é como termos uma praça de taxis onde todos os taxistas são falsos e apenas dois ou três têm a autorização de ser taxistas. Não precisamos de condutores de fim de semana que saber conduzir uma IDE ( mal, mas sem acidentes graves) , precisamos de pessoas que saibam entender software e preservar a sua consistencia ao mesmo tempo que preservam o valor para o cliente. Não é uma questão de um ou o outro, é uma questão de que um sem o outro não interessa. Pelo menos não interessa a um Profissional de verdade.

Eu sei que o manifesto ágil, e o conceito de agilidade ainda são novos para muitos. Também sei que nas escolas oficiais a imagem que se dá do software é o da escola tradicional. E também sei, que se as pessoas ainda não entenderam a diferença entre o paradigma tradicional e o moderno, então mais complexo ainda é ver a diferença entre agilidade e artesanato de software. Mais valia pregar aos peixes … mas acreditando, como acredito, nos principios por detrás do artesanato de software, não posso, em consciencia, me abster de divuldar a mensagem e esperar que mais um se junte à causa.  Para quem está saindo da faculdade ou ainda entrando nela, é importante que pense bem se quer realmente ser um profissional de software ou apenas um tecnico, ou apenas um que sabe pilotar uma IDE. Se não é para ser a sério, mais vale não ser.

Aos que já estão na profissão, perguntem-se a si mesmos se tem vergonha do código em que estão trabalhando agora. Se você não sente nada pelo seu código, pelo seu software, você não é feito para ser um desenvolvedor, e talvez seja hora de pensar em mudar de vida. Se você sente algo, então procure melhorar-se a si e aos seus colegas, para que todos juntos possar sentir menos vergonha.

Making software is not about the money, or the ride, is about the dignity of the journey.

Fiz questão de fazer um curso não programático na finada Sun exatamente para descobrir esse outro lado. No curso que era guiado principalmente pelo Processo Unificado (Unified Process, UP) era levantada a lebre de um tal de XP. Eu tinha tido contato com o XP ainda quando fazia meu estágio em física. Afinal a física prática passa pelo processamento de sinal, e este passa por usar computadores.  Com o passar do tempo as práticas que observava na realidade não batiam com o que os livros diziam e o insucesso de vários projetos me fez entender que para entrar no mundo do software antes de saber programar é preciso saber escolher entre filosofias de desenvolvimento.  O Rational UP da  Rational Rose, depois IBM no tempo do CASE lançou o mote. A ideia era ter ferramentas onde especificar o software, apertar um botão e simplesmente teriamos um software funcionando. Não resulta. Ferramentas ainda são burras e precisam de alguém que as saiba usar.  Alguém muito esperto consegue vender esta ideia imbecil de que software pode gerar software automaticamente. Ainda hoje existem tentativas de enganar os pacóvios com esta artimanha. Repare que o engano advém de quem compra e não de quem vende. É quem compra que é muito desonesto, tapado, analfabeto ou burro para não entender a enganação.

Apenas pessoas sabem fazer software e existe uma razão muito simples para isso: fazer software é um processo criativo. Criativo aqui significa tanto ser um processo onde se cria algo, como um processo em que se precisa ter imaginação. E as máquinas não têm isso ainda.

Então por que é tão difícil fazer software? Fazer software não é dificil. O que é difícil é fazer software que alguém compre e atenda a uma demanda, a uma necessidade. Para qualquer produto comercial existem duas formas de demanda. Ou quem quer comprar, compra o produto já pronto que o produtor já criou antecipadamente (retail sell – venda a varejo) ou o interessado chega junto ao produtor e pede que seja feito um produto com certas características (tailored sell – venda sob medida). Na primeira categorias podemos encontrar muitos produtos como pão, fruta, vinho, carros, casas – e inclusive software – e no segundo podemos encontrar produtos como roupa (de alfaiataria), carros (Rolls Royce), aviões e também software. Qual é a diferença? Volume.  A primeira categoria ganha em vender barato e muito. A segunda em vender caro e pouco. Ambos têm o seu quinhão de mercado. Atenhamo-nos apenas ao software feito sob medida (sob demanda – on demand, como também é chamado) para o resto da conversa.

Em tudo o que é feito sob medida, e também num software, precisamos saber como o cliente deseja que seja o resultado final. Afinal o resultado final servirá a ele e apenas a ele. Tal como um casaco ou um terno que serve apenas a uma pessoa. Pode até ser que sirva para outros, mas nunca sem ajustes. Precisamos então saber quais são os requisitos. Requisito é um conceito muito importante neste tipo de produto, porque é à medida dele que será feito o produto final.

Um outro fator na equação é como será feito o produto. A tecnologia que será usada para realizar o produto afeta o preço, a qualidade, a durabilidade, e até o aspecto e usabilidade do produto.  Existem tecidos específicos para certos tipos de roupa e circunstâncias específicas. Existem razões técnicas de porque o mesmo casaco precisa ser de algodão em umas regiões e de lã em outras.  Se formos fazer um produto que nunca ninguém fez antes ou poucos tentaram e tenhamos que experimentar diferentes tecnologias será diferente daquele que utiliza uma tecnologia já muito entendida e aperfeiçoada.

Pondo estas duas forças num gráfico obtemos um cenários mais ou menos como o mostrado na figura a seguir.

Na zona verde estão os produtos menos complexos, os mais complexos na zona vermelha. Repare que o software é algo complexo.

Muita gente – gente demais, na minha opinião – adora comparar “fazer software” com “fazer casas, carros e aviões”. Não, essas coisas não são nem de longe tão complexas. Por quê? Porque os requisitos são muito bem conhecidos e a tecnologia também. Não há surpresas – tijolo é tijolo e metal é metal. Não há mudança de ideia no último momento. Não há uma tecnologia que surgiu no último momento e tornou tudo obsoleto.  Um pouco mais semelhante seria um carro costumizado ou um avião costumizado como Air Force One. Mais próximo ainda seria um vestido de noiva. A tecnologia é muito simples e conhecida, mas os requisitos são muito voláteis. É por isso que existem costureiros de grife cobrando caro por essas coisas. Do outro lado, temos as vacinas, aqui os requisitos são simples – evitar a doença , mas a tecnologia tem que ser criada. E algumas , como a da AIDS não tiveram sucesso até hoje.  A vacina é um exemplo muito mais próximo da complexidade de fazer um software com tecnologias novas (muitos projetos de vacinas falham, como falham os projetos de software). E talvez por isso as equipes tendam a usar tecnologias velhas. Dá-lhes uma margem maior de segurança emocional (se bem que uma plataforma de aplicação velha é um empecilho em si mesmo).  Armas de energia com o phaser do Star Trek ainda são uma ilusão, mas as armas  taser estão bem perto, e cada vez mais perto de uma arma de energia. Aqui, o requisto continua simples – desabilitar o adversário, mas a tecnologia é simplesmente desconhecida. Um exemplo de algo bem complexo de criar seria uma verdadeira  TARDIS , pois não apenas ela é um ser vivo que viaja no tempo e no espaço, como é maior por dentro do que por fora. Um desafio ao raciocínio humano mais fundamental, o que dizer ao raciocínio de engenharia.

Ao fazer software é raro que tenhamos requisitos bem conhecidos, e normalmente as empresas se encarregam de estragar a outra variável não tendo uma tecnologia padrão para desenvolver o software, o que significa que a cada projeto temos que começar de novo aprendendo novas tecnologias e refazendo funcionalidades que já tinhamos antes. Isto torna a produção de software inerentemente complexa. Não somos nós que a fazemos complexa, ela é complexa por natureza. O que podemos fazer é torná-la mais ou menos complexa, mas nunca apenas complicada ou  simples. Normalmente a tornamos mais complexa do que natural.

Aceitar este princípio básico – “princípio zero”, poderíamos chamá-lo – é fundamental para conseguir fazer software. Isto era verdade a 50 anos atrás, e com a velocidade com a tecnologia evolui,  é muito mais verdade hoje. Não é por acaso que nasceram coisas como o Java e o .NET para quebrar um pouco desse escalar de tecnologia que constantemente nos exigia mudar de ferramentas para fazer software. As plataformas virtuais nos trouxeram uma âncora que nos ajuda a diminuir a complexidade. Mas a âncora não durará por muito tempo e novas âncoras precisarão ser desenvolvidas.

Entendendo que fazer software é algo complexo, as pessoas esperam que a forma de gerenciar a produção do software tenha que ser igualmente complexa. E este é outro paradigma difícil de quebrar:  o complexo pode ser gerenciado com o simples.  O truque é mantermos os olhos nos objetivos. E são estes que têm que estar claros desde o dia um, e refinados todos os dias. Como já disse Dwight D. Eisenhower ”O plano não é nada, planejar é tudo”. Ou seja, a complexidade é tratada facilmente se o plano não for fixo e evoluir conforme as circunstâncias. Mas veja, o plano muda e é descartável, mas não os objetivos  (e se você tem algum sentido de ética, nem todos os caminhos são aceitáveis).  Algumas pessoas entendem esta frase assim: “não faça planos”. É errado. A mensagem é “Faça planos, e continue fazendo planos. Não pare de fazer  planos até chegar no objetivo”. A cada plano temos um mapa do caminho para os próximos tempos  ( horas, dias, semanas, meses, anos… não interessa), quando replanejarmos teremos um plano que vai um pouco mais à frente e assim continuamente. A mal intrepretação deste simples conceito leva a aberrações como a recusa de criar uma plataforma de aplicação coerente e coesa ou simplesmente achar que é possível levantar requisitos “on-the-fly” na medida que o projeto progride.

A complexidade do software demanda o processo criativo contínuo, e isso exige a atuação de pessoas em todos os pontos desse processo. Todo o resto são ferramentas.
Será que o processo unificado (UP) ou qualquer outro processo criado antes de 1990 se baseia nestes princípios? Quero crer que não. Todos os processos clássicos se baseiam num mecanismo Stage-Gate como o usado para construir carros e aviões (!). Este tipo de processo simplesmente não funciona quando a principal energia é a criatividade,  e é por isso que muitos de projetos de software falham.  Em qualquer outro ramo de atividade, tantos projetos falharem é inadmissível. Em software, fazemos de conta que não é verdade.

O que não é admissível é que seja possível viver construindo software sem ter um processo-base para tal.  Práticas de laboratório até temos algumas (vide práticas de XP ) e temos alguns candidatos a processos de gerenciamento realista de software como Scrum. Mas ainda aguardamos o santo graal do processo de software.  O Processo Unificado não é bom o suficiente porque ele é muito semelhante a um processo Stage-Gate  e é corrompido muito facilmente se transformado num processo que tradiconalmente é usado em empresas produtoras de software. Um processo criado “in-house”, híbrido e muito parecido com um Frankeistein , um monstro fabricado de partes de outrém.

A promessa de um processo padrão moderno, confiável, honesto, que tome em consideração a complexidade, os requisitos, as tecnologias, e as pessoas ainda está por vir.  A minha aposta é que será algo muito semelhante a uma fusão de Scrum com XP e diretivas do manifesto de software craftsmaship que apela a um certo padrão de qualidade e orgulho no trabalho que fazemos – que por exemplos os alfaiates têm – que nós,  produtores de software, ainda não temos.

Software é simplesmente complexo, e é por isso que gostamos de o fazer. Aceitemos de uma vez por todas a sua complexidade natural e façamos-o com o respeito que merece.

Existem diferentes tipos de produtora de software. Temos a produtora interna. Aqui estamos falando de um departamento da empresa que produz software para a empresa. Normalmente produz alguma ferramenta (ERP) ou um meio de comunicação com os clientes (site e-commerce). O produto de software criado assim visa ajudar a empresa no seu fim, mas o produto não é comercializado.  Temos depois as produtoras on demand que fazem software sob medida (tailored) e finalmente as que fazem software como um produto. Aqui distinguimos entre  as que fazer produtos de prateleira (compre e costumize você mesmo ) e os implantáveis (compre, e costumizamos para você antes de começar a usar). A primeira linha é muito comum para produtos ao consumidor geral (empresas e individuos) como sejam o Office, os sistemas operacionais, os anti-virus, e os tocadores de musica. No segundo bloco temos os produtos de ERP e produtos mais especializados que precisam ser condicionados ao ambiente da empresa onde serão utilizados.

Vou me concentrar nos casos dos produtos de software feitos sob encomenda e/ou sob media. Aqui temos um cliente que deseja um software, e uma empresa que provê o serviço de produzir esse software. Entre eles deverá existir um contrato. Ora, o objetivo deste contrato é a realização do software e para isso temos que saber o que “é o software?”. O software será um conjunto de funcionalidades que permitirá ao cliente atingir certos objetivos. Estes objetivos devem ser claros para cliente e produtor, ou todos estarão em problemas. Nem todas as funcionalidades que o produtor incluir no software ajudarão o cliente a alcançar os objetivos. O conjunto de todas essas funcionalidades é chamado: Escopo. Algumas funcionalidades ajudarão mais, e outras menos, e a unica forma de saber qual é qual é deixar o cliente experimentar o software e decidir.  Então como criamos um contrato que permita alcançar isso ?

Existem vários tipos de contrato no mercado. Conforme o tipo de contrato que as partes escolherem isso formará um vinculo entre eles.  Nem sempre as partes são conscientes do vinculo que estão formando e nem sempre elas se apercebem dos riscos que estão enfrentando.

É interessante olha um contrato de software à luz do Dilema do Prisioneiro sendo o cliente um dos presos e a empresa que provê a construção o outro. A “policia” seria o mercado em si. Se ambas as partes não cooperarem, ambas  terão prejuízo. Qualquer contrato de software que leve a uma relação diferente da cooperação irá beneficiar apenas um dos lados , e no extremo, nenhum dos dois.

Falarei dos contratos de forma geral, já que se aplicam no mercado a diferentes ramos e conforme diferentes objetivos, em seguida especificarei o que acontece quando usamos esse contrato para contratos de software.

O contrato mais comum  é conhecido como Time and Materials. Neste tipo de contrato o provedor do serviço de construção cobra um valor fixo por unidade de trabalho. Normalmente a hora-homem. Este contrato não impõe limite ao prazo nem ao escopo do que será feito e portanto lança todo o risco no colo do cliente. A vantagem do cliente é poder terminar o contrato quando quiser, mas a desvantagem é que o trabalho pode se arrastar indefinidamente. Este contrato cria um vinculo de indiferença. O provedor não ganha nada terminando o trabalho antes e o cliente fica sempre aguardando que o trabalho termine sem poder fazer nada. O escopo aberto parece dar ao cliente a possibilidade de cortar quando quiser, mas na prática o cliente sim tem um escopo mínimo que ele quer ver completo. No mundo do software este é o famoso “cobrar por hora e vamos ver onde chagamos…”. O produtor cobra por hora pelo resto da vida e o cliente que saiba o que quer.Se o cliente se engana e ha retrabalho, tanto melhor : mais horas. Se o produtor se engana, tanto melhor : mais horas para resolver o problema.  Porque o cliente não quer pagar pelos erros do provedor, este contrato causa muitos problemas e não cria uma relação de colaboração entre as partes – bem pelo contrário o cliente está submetido à boa vontade do provedor, porque ele pode simplesmente preferir realizar o trabalho de outro cliente que lhe paga mais por hora. Claro que o cliente pode sempre mudar de provedor, mas a realidade é que só o fará quando for realmente insuportável continuar com o atual e normalmente o provedor tem lábia suficiente para ludibriar o cliente.

Uma variante é estabelecer um teto para o custo total e fixar um escopo. Isto, claro,  funciona quando o escopo é realmente fixo. Caso contrário , porque o custo é fixo, o provedor irá resistir a qualquer alteração do escopo. No caso extremo irá cobrar extra por novas coisas, caso em que ele estimula o cliente a definir o escopo errado para depois poder cobrar alterações.  No final este tipo de contrato é ainda pior para o cliente. Para software isto é um desastre. Não apenas o provedor não tem qualquer incentivo para definir bem o escopo, ele tem incentivo para o definir mal.  O fato do custo ser fixo, que deveria proteger o cliente, acaba fazendo lhe ainda mais mal.  O resultado é o mesmo em um contrato do tipo Fixed Price, Fixed Scope , onde o cliente paga um preço, fixa um escopo e o projeto anda até que tudo esteja completo sem prazo para terminar. Mais uma vez o provedor se faz valer de uma cláusula de alterações que oneram o cliente cada vez que forem feitas. Conclusão, se o cliente não tem o escopo bem definido, o provedor não irá se esforçar para o definir, pois toda a alteração será cobrada à parte.

Alguns acham que isso pode ser resolvido fixando também o prazo. Isto nos leva ao contrato do tipo Fixed Everything em que prazo, escopo e preço estão fixos. Aqui os papeis se invertem e é o provedor que fica na mão do cliente. O cliente incha o escopo com tudo que imaginar e estabelece um prazo e um preço para tudo isso. O provedor ou aceita, ou não aceita. Se aceitar, porque o cliente que estipula o escopo, o cliente pode sempre adicionar mais detalhes ao escopo, realmente tornando-o maior na prática, mas não no papel e portanto impedindo o provedor de cobrar por isso.  Este tipo de contrato é comum em licitações em que o cliente já fixa previamente tudo, mas deixa margem para inchar os detalhes ou espera fazer pressão econômica depois, ameaçando não pagar o provedor se ele não incluir mais aquela “pequena alteração”. Em software, porque os escopo é inerentemente  variável,  o provedor está automaticamente em desvantagem. Muitos provedores aceitam este tipo de contrato com medo que a sua concorrência os aceite primeiro. Este é o erro que alimenta a prática dos clientes estipularem este tipo de contrato.  Sendo que este tipo de contrato é altamente arriscado para o provedor, o fato do concorrente o tomar deveria ser entendido como bom, já que o risco está agora no concorrente e não com o provedor. O provedor pode então procurar outro tipo de contrato com outros clientes que sejam mais proveitosos e no longo prazo desfalcar o concorrente pois ele está metido até ao pescoço num contrato sanguessuga. Mas por alguma razão juvenil de “tentar ganhar do outro” os provedores de software acham que é melhor ser sugados por clientes com contratos fixed everything do que deixar os seus concorrentes serem sugados.  Sobretudo quando estamos perante uma licitação e o cliente é o governo. Aqui todo o senso empresarial vai para o espaço, porque o provedor acha que trabalhar para o governo é seguro ( não vai ficar sem trabalho), mesmo quando  isso significa que o governo o levará à falência. No mundo do software  não existe razão comercial que suporte aceitar este tipo de contrato, seja com quem for a menos que você tiver um às na manga (mais sobre isso em outra oportunidade ).

Se reparou bem, até agora, todos os tipos de contrato oneram uma das partes. Não ha nenhum que estabeleça metas comuns. O resultado é que – no mundo do software – estes contratos sempre falharão. Cada tipo de contrato é bom para determinadas circunstâncias de escopo. Quanto mais conhecido e fixo o escopo, mais simples o contrato porque menor o risco.   O problema é que, em software, o escopo é sempre mutável.

A moral desta recapitulação é que não podemos usar qualquer contrato para serviços de construção de software. Muito menos nos podemos guiar por modelos de contratos utilizado em outros ramos de atividade onde o conhecimento dos requisitos é estável. Nada de usar contratos como se o software fosse uma casa, uma ponte ou um avião. Isso são coisas com requisitos muito estáveis, logo, com contratos mais simples.

Bom, resta então, desenhar um contrato que seja vantajoso para ambas as partes e seja compatível com um escopo variável. Para isso temos que entender que o escopo tem duas propriedades : tamanho e característica. A característica do escopo é aquilo que a funcionalidade é. O tamanho se relaciona ao esforço para  construí-lo .

A primeira aproximação é o tipo de contrato baseado em Time and Materials mas com escopo variável e custo fixo. Nste tipo de contrato o tamanho do escopo é fixo – e portanto o custo é fixo, mas a característica é variável. Ou seja, o escopo definido no inicio é a base para uma estimativa de tamanho. Essa estimativa de tamanho é usada para estimar custo e prazo, mas o cliente pode mudar a característica do escopo, ou seja, pode mudar as funcionalidades ou o que as funcionalidades fazem. Isso deve ser feito de forma controlada de forma que nunca ha aumento de tamanho. Em software, este tipo de contrato é muito usado na cena ágil porque o cliente pode modificar o escopo conforme o valor das funcionalidades e conforme vai conhecendo, vendo, e experimentando o software. Uma variante consiste em deixar aberta a possibilidade  do cliente terminar o projeto antes de utilizar todo o custo/tamanho planejado. Esta variante de Valor Máximo, divide o custo não utilizado pelo cliente e o provedor, oferecendo aos dois vantagem se o projeto não chegar no custo, e portanto, incentivo para a colaboração e o alcance do valor máximo o quanto antes. Acontece que este tipo de contrato é fortemente baseado na estimativa inicial o que significa que se o provedor estimou mal ele estará se beneficiando em detrimento do cliente.  Isto nos leva ao ultimo tipo de contrato.

Este tipo de contrato é muito semelhante mas adiciona um limite máximo de expansão do custo. O provedor estima o tamanho e o custo da mesma forma que antes, mas em seguida adiciona uma margem. Se tudo correr bem e o cliente der o projeto como terminado antes de atingir o custo, os ganhos são repartidos como antes, metade-metade. Se o projeto passar do custo estimado, e até chegar no limite da margem, o prejuízo é partilhado metade-metade. Se o custo passar do limite da margem o prejuízo é totalmente por conta do provedor (já que isso significaria que o provedor estimou mal e conduziu mal a construção).

O mecanismo de estimativa de tamanho não é relevante, o que é relevante é que o provedor tenha um bom conhecimento entre a relação desse tamanho com o custo. Em horas-homem, meses-homem ou pontos de estoria, tanto faz.  O que interessa é que haja uma unidade e uma forma de a converter em custo. Vejamos um exemplo utilizando uma aproximação mais comum hoje em dia, o custo por hora-homem.  O provedor estima o projeto em 1000 horas-homem a um custo de 80 reais por hora-homem equivale a um projeto de 80 mil reais. Se tudo correr bem, esse é preço certo do projeto. Consideremos então uma margem de 20 mill reais (250 horas-homem) . O projeto custará no máximo 100 mil reais.

No espírito do contrato anterior, temos que repartir ganhos e prejuizo até chegar em 100 mil. O cliente paga 40 mil à cabeça e 40 reais por hora-homem até atingir o valor máximo do projeto de 100 mil reais.  Veja que isso significa que se o projeto terminar no tamanho estimado, o preço pago será o estimado (40  mill + 40* 1000 horas-homem) e o cliente terá pago exatamente 80 mill reais. Se o projeto terminar antes, gasntando apenas , digamos 600 horas, porque o cliente estava pagando metade do preço-hora o projeto termina com vantagem dos dois lados. Se o projeto vai além do tamanho estimado, digamos 200 horas ambos terão prejuízo de 40*200  = 8 mil reais.

Este tipo de contrato não coloca as partes em competição mas sim em colaboração com objetivos concretos e vantagens concretas.  Repare que o tamanho do escopo é fixo, o que significa que o custo só aumenta por atraso na execução e nunca por aumento de escopo como nos outros contratos. Porque o cliente não pode aumentar o custo, e também terá prejuízo se o projeto atrasar ele é incentivado  a escolher funcionalidades mais valiosas e mais “simples”.

Obviamente este tipo de contrato só funciona se as partes  tem capacidade de entender o seu funcionamento e o conceito de que nem todas as funcionalidades têm o mesmo valor e por conseqüência as mais valiosas e importantes devem ser feitas primeiro e algumas delas não serão feitas.  Este tipo de contrato estimula também o provedor a ter que trabalhar de uma forma que lhe permita terminar o quanto antes e responder rapidamente a alterações nas características do escopo. O que é muito simples se a empresa segue práticas ágeis de gerência e desenvolvimento.

Finalmente é importante notar que o fato das empresas colaborarem obriga à comunicação sincera e isso leva à criação de vínculos de confiança que permitem novos projetos no futuro. Além disso o impacto psicológico de terminar antes do custo faz o provedor se diferenciar no mercado face a outros concorrentes e deixa o cliente contente o suficiente para recomendar aquele provedor a outros parceiros.

Se você é responsável por contratos de software, pense bem nisto, e tente melhorar a sua forma de se relacionar com o seu cliente. Ele não é seu patrão e nem você é o cafetão dele. Vocês são colaboradores.

Mas o problema vem na prática.  Na prática não é nada simples ser fiel aos 5 valores ( Compromisso, Abertura, Respeito, Foco e Coragem),  afinal, estes valores parecem escassear nos dias de hoje. Afinal não é tão simples manter backlogs. Priorizar, comparar valor, estimar tamanho… não é tão simples na prática. Afinal não é tão simples, e  o fardo começa a ficar claro quanto mais a pessoa entende scrum. Não é por acaso que “Coragem” é necessária. Sem ela a pessoa desiste antes de ver os louros.

Todos aqueles que começam a usar scrum pela primeira vez passam por este processo de ir da glória da ignorância – achando que é simples de mais- ao inferno do pesado fardo da responsabilida e do compromisso – de volta à glória da sapiencia após entender que realmente funciona.Mas é trivialmente fácil a pessoa se enganar. É muito simples a pessoa faltar ao compromisso, à responsabilidade, perder o foco, perder coragem. Afinal , qual é o castigo ? Porque perder tempo com backlogs ? porque não simplesmente mandar os rapazes fazer o que queremos ? afinal quem vai nos exigir explicações ? ora…  Porque fazer reuniões todos os dias ? afinal as pessoas têm boca é para falar, porque precisamos de uma cerimónia, porque raios as pessoas não conversam quando elas querem ?

Perguntas imbecis como estas – embecis porque existem imensos estudos e autores explicando porque essas coisas são ruins – permeiam a cabeça de todos aqueles que foram educados e tem vivencia na forma tradicional de fazer software. Daqui nasce o Scrummas. É comum , hoje em dia, ouvir respostas como “Nós usamos scrum, mas…. ” seguido de alguma desculpa esfarrapada de porque foi boa ideia eliminar algum dos principios , valorer , práticas ou cerimónias do scrum. O Scrummas  (em inglês scrum-but, que é um trocadilho com butt que significa bunda) , advém da explicita violação do primeiro valor :compromisso. Ou bem que vc se compromete a seguir o scrum, ou bem que não. E na hora que vc começa a driblar e a arrajar desculpas é uma falha no compromisso. É uma desonestidade para consigo mesmo. Se não implementamos scrum totalmente como esperamos que funcione ? Quando vc muda o pneu do seu carro vc não aperta os parafuros porque “está com pressa e tem um horário a cumprir’ ? quando vc come, vc come com os dedos porque “afinal, acabou de lavar as mãos” ?  O que é você ? Uma criança com um monte de desculpas ? E para quem são essas desculpas ? o seu pai ? … não… são para si mesmo. Para esconder a sua falta de fidelidade com os valores.

Scrummas é um cancer moral que nasce na própria mente humana. É inerente ao ser humano encontrar dualidade. Quando no caos ele procura a ordem, quando na ordem procura a revolução.  É dificil sem dúvida seguir os valores. Afinal seguir quaiquer valores é complicado. Sempre dá vontade de desistir uma hora ou outra.

A extrema simplicidade das práticas do scrum, e do agil em geral,  leva a um excesso de confiança, a uma atitude de “eu posso fazer isto, é canja”. Mas a realidade é dura, e essas mesmas práticas lhe mostrarm tudo o que ha de errado em si e nos outros , no projeto, no cliente, na sua cidade e até na sua familia. Isso é demasiado peso para uma pessoa só e quando mais ela enxerga que esse é destino final, mais ela quer desistir. Ela quer minar o sucesso do scrum porque inconscientemente ela sabe que esse sucesso será o seu fim. Ela apenas esquece que, sentir isso, é a prova que entendeu o scrum, mais: é a prova que se comprometeu com o scrum. E só então , com esse conhecimento, o mundo parecerá melhor.

Talvez a extrema simplicidade leve as pessoas a complicar a coisa um pouco “só p’ra ter graça”, ou para poder encontrar defeitos, ou auto-minar o seu sucesso. A velha conversa de “Scrum não é bala de prata” … ora, realmente scrum não é uma arma contra coisas sobrenaturais , mas sim é a forma correta de trabalhar no desenvolvimento de software. Pelo menos até que alguem imagine uma melhor. Porque este desdem, essa “falsa modéstia” ? Se temos monstros que comem o nosso lucro, a nossa paciencia, e nosso tempo, não é de uma bala de prata que precisamos ? Bom… visto assim, realmente o scrum não é uma bala, ele não mata os monstros. Ele está mais para lente de aumento ou espelho, que mostrar onde e quais são os monstros.  Tanta metáfora … Falta de abertura. Falta de dizer a verdade pura e simples : Scrum dói. Scrum é dificil. Scrum vai mudar a sua vida. Scrum precisa que você tenha coragem, que os tenha no lugar, a todo o momento. Vc vai sofrer, mas depois vai ser recompensado… e não ha garantia que esse depois chegue, então vá se preparando para o pior. E o pior é : você voltar a fazer software como fazia antes do scrum!

Os valores do scrum, não são apenas palavras, são coisas que cada desenvolvedor deve sentir e seguir. Como profissional e como pessoa. Só assim poderemos acabar com o  Scrummas e a forma imbecil de fazer software que a esmagadora maioria das empreas utiliza.

Sempre que ouvir “Fazemos scrum , mas…” e tiver um arrepiu, isso é o sinal de que você é um desenvolvedor de software moderno. Não desista agora. Porque agora  vai  ficar ainda mais dificil mas também muito mais interessante ….