PAULO FERNANDO VASCONCELLOS NOGUEIRA

Blog

  • Os Dois donos do Projeto (Totó)

    Série “De Brooks a Berkun” – Continuação da 2ª Parte.

    Fred Brooks encerra “O Time Cirúrgico”, terceiro capítulo de “The Mythical Man-Month”, falando que um sistema deve ter total Integridade Conceitual, e que isso só seria possível através da dedicação integral de um Arquiteto (System Architect, no texto original). Logo depois, em “Por que a Torre de Babel falhou?”, ele fala de dois líderes em um projeto: o Arquiteto (ou Diretor Técnico) e o Produtor. Mas o dito popular não ensina que “Totó com dois donos morre de fome”? Como um projeto pode ter dois líderes e não parecer uma organização confusa?


    Segundo Brooks, o Produtor é o cara que monta o time, divide as tarefas e elabora o cronograma. Também é ele quem cuida da aquisição de recursos durante todo o projeto. Portanto, na maior parte do tempo, o Produtor estaria interagindo com entidades externas ao projeto. Ainda assim, é ele quem estabelece padrões de comunicação e relatórios com o time.

    Já o Arquiteto (ou Diretor Técnico) é responsável pelo desenho do sistema a ser construído, seus módulos e também seu aspecto exterior. Interage principalmente com o time, resolvendo questões técnicas.

    Considerando que os dois perfis são necessários em projetos de qualquer porte, Brooks aponta três relacionamentos possíveis entre eles:

    • Arquiteto e Produtor são a mesma pessoa: possível em pequenos projetos (para Brooks, de 3 a 6 programadores). Mas uma combinação arriscada em projetos maiores. Brooks justifica: “Pensadores são raros; executores são raros; pensadores-executores são raríssimos”.
    • O Produtor é o chefe e o Arquiteto o seu braço direito: a dificuldade aqui, segundo Brooks, é o estabelecimento da autoridade do Produtor em questões técnicas. Ele diz que o entrosamento entre o Produtor e o Arquiteto é fundamental. E que o primeiro deve respeitar muito o valor do arquiteto.
    • O Arquiteto é o chefe e o Produtor o seu braço direito: segundo Brooks, este seria o arranjo ideal para equipes pequenas, enquanto o anterior (Produtor é o chefe) funcionaria melhor em projetos maiores.

    É impossível evitar o paralelo das sugestões de Fred Brooks com aquelas apresentadas por Jeff Sutherland (depois de Takeuchi e Nonaka ) em seu método chamado Scrum.

    Jeff Sutherland, ao contrário de Brooks, não deixa dúvida sobre quem ‘fala mais alto’ em um projeto. O Arquiteto, que no Scrum é chamado de Product Owner, tem a palavra final. Enquanto o Coordenador (Produtor), ou Scrum Master, trata de eliminar riscos e obstáculos que estejam impedindo o time de obter sua melhor performance. São, respectivamente, o “Navegador” e o “Piloto” em uma equipe de rally, uma analogia criada pelo próprio Sutherland.
    Este desenho faz lembrar também uma colocação de Tom DeMarco em um de seus principais trabalhos, “Peopleware”:

    “A função do gerente não é fazer as pessoas trabalharem e sim tornar possível que elas trabalhem.“

    Antes de encerrar o tema uma observação: Fred Brooks, assim como Scott Berkun, trabalhou na indústria, desenvolvendo ‘produtos’. Falta em seus ‘job descriptions’ do Arquiteto e do Produtor (Coordenador) a preocupação com um Cliente. Parece óbvio que o chefe, seja ele o Arquiteto ou o Coodenador, seja a principal interface da equipe do projeto com o cliente. Eu prefiro deixar que o Coordenador seja sempre o canal de contato principal com o cliente, independente de ter ou não a ‘palavra final’ no projeto. As questões técnicas e funcionais, na maior parte das vezes, deveriam ser solucionadas (ou direcionadas) pelo Analista de Negócio, apresentado no sub-capítulo anterior.

    A Outra função da Organização

    Quando falamos em Organização, Estrutura, a primeira imagem que aparece é a de um organograma. Nos preocupamos, quase que exclusivamente, em saber quem é que manda no pedaço e quem deve (ter o juízo de) obedecer. Fred Brooks diz que precisamos aprender a desenhar estruturas e processos que incentivem, e não que inibam a criatividade e a iniciativa. E lembra: “a Criatividade vem dos indivíduos e não das estruturas e processos”.

    Scott Berkun segue linha parecida dizendo que os “projetos dependem muito da habilidade do time em fazer uso do conhecimento de seus membros, de compartilhar idéias e trabalhar em sincronicidade, ao invés de seguir restritivas linhas de autoridade, uma rigorosa disciplina e uma compulsão a seguir ordens sem nenhum tipo de questionamento”.

    Esse embate é muitíssimo bem documentado por Domenico de Masi no livro “Criatividade e Grupos Criativos”. Domenico afirma que atravessamos uma fase caracterizada por um Cultural Gap, um fenômeno que “constrangeu os atuais knowledge workers, os trabalhadores do conhecimento, a se organizarem segundo os velhos princípios industriais”.

    Que seja só uma fase. Mas ainda não há muitos indícios de que esteja para terminar. Por exemplo, o termo “fábrica de software” é de uma infelicidade incrível. Um oxímoro, no meu ponto de vista. Por outro lado temos a consolidação de produtos como Linux, Apache, Eclipse e Firefox, que são criados em ambientes onde parece imperar o caos. Deve haver um meio termo, não?

    ===

    Na próxima semana, “Castelos de Areia…”, sobre engenharia de requisitos, integridade conceitual, especificações e trabalho criativo. (Título com bula, atendendo a pedidos, hehe).

    1. Takeuchi e Nonaka, “The New New Product Development Game”, Harvard Business Review (Jan-Fev/1986).
    2. Tom DeMarco e Timothy Lister, “Peopleware – Productive Projects and Teams”, 2ª edição – Dorset House (1999, 1987).
    3. Domenico de Masi, “Criatividade e Grupos Criativos”, Editora Sextante (2003).

  • Como montar Times e influenciar Projetos

    Série “De Brooks a Berkun” – 2ª Parte

    A experiência prática de Fred Brooks, como citado anteriormente, foi com projetos mastodônticos: 1000 pessoas envolvidas ou mais. Mas ele lembra que desde aquela época os ‘gerentes de programação’ preferiam “pequenos e ‘agudos’ times formados por pessoas de ‘primeira classe’”. Brooks cita um estudo (de Sackman, Erikson e Grant) que mostra que um programador de ‘primeira classe’, que recebia US$20.000/ano, podia ser até 10 vezes mais produtivo que um programador de US$10.000/ano. Mas um pequeno grupo de ‘estrelas’ seria capaz de desenvolver um OS/360? Talvez em 10 ou 25 anos, segundo cálculos do autor. Por outro lado Brooks lembra que times grandes, orientados para a execução de um trabalho na base da ‘força bruta’, são “lentos, caros, ineficientes, e produzem sistemas que não possuem ‘integridade arquitetônica’. OS/360, Exec 8, Scope 6600, Multics, TSS, SAGE, etc. A lista é longa”. E “o dilema é cruel”, escreve Brooks. Haveria solução?

    A sugestão de Brooks, baseada em uma proposta de Harlan Mills , dá título para o terceiro capítulo do seu livro, “O Time Cirúrgico”. Segundo ele, o time ideal é formado por:

    • Programador Chefe (Cirurgião)
    • Co-Piloto
    • Administrador
    • Editor
    • Secretárias (duas)
    • Bibliotecário
    • Almoxarife
    • Testador
    • Advogado (da Linguagem)

    Reparem bem. Nós temos praticamente 9 pessoas trabalhando para o programador! Dando-lhe “todo suporte que fará aumentar sua eficácia e produtividade”. Lembram-se que o Brooks também sugeria que alocássemos apenas 1/6 de nosso cronograma para tarefas de codificação? Outro mundo, não é mesmo? Pode e deve ser factível em um time cirúrgico de verdade mas aplica-se a equipes montadas para o desenvolvimento de sistemas?

    O ‘cirurgião’ seria responsável pela execução de todas as tarefas principais daquela parte do projeto: sua especificação, design, codificação, testes e documentação. Não difere muito de alguns job descriptions e anúncios de vagas que ainda vemos por aí. Seria um “analista-programador” que, segundo Brooks, deveria ter 10 anos de experiência.

    O mundo da programação mudou muito desde os tempos do COBOL e da PL/I. A complexidade e abrangência de nossas linguagens e arquiteturas de aplicações aumentaram ‘para os lados e para baixo’. E é cada vez mais comum que cada uma das tarefas listadas acima seja atribuída a um especialista. Uma divisão que é nítida em ‘fábricas de software’, por exemplo. Em caminho oposto, alguns advogados de métodos ágeis enaltecem a importância de um time formado por ‘generalistas’.

    A analogia com equipes médicas reaparece em um artigo de Peter Drucker publicado pela Harvard Business Review em 1988, “O Advento da Nova Organização” . Segundo Drucker, “informação é dado investido de relevância e propósito. Por conseguinte, a conversão de dados em informação requer conhecimento. E conhecimento, por definição, é especializado. (Com efeito, as pessoas realmente detentoras de conhecimentos tendem ao excesso de especialização, qualquer que seja seu campo de atuação, exatamente porque sempre se deparam com muito mais a aprender).”

    Apesar de ser simpático aos chamados métodos ágeis, não acredito na possibilidade ou eficácia de um time composto por ‘generalistas’. Prefiro apostar em uma formação que valorize o perfil e a experiência de cada um de seus membros. No diagrama abaixo apresento um exemplo de um time desenhado para desenvolver uma aplicação web (ou ‘cliente/servidor n camadas’, como queiram):

    O arquiteto é o novo ‘cirurgião’. É o dono e principal responsável por aquele projeto ou módulo. Mas só coloca ‘a mão na massa’, codificando, para transferir conhecimentos. Ocupa-se com a concepção e manutenção da integridade arquitetônica da solução. Ele é diretamente apoiado por cinco especialistas:

    • Analista de Negócios (biz): cuida da coleta e organização dos requisitos, e apóia seu desenvolvimento, fazendo a ponte entre os usuários e a equipe de desenvolvimento;
    • Desenvolvedor de Interfaces (front): é especialista em usabilidade e ‘manda bem’ em conceitos de arquitetura de informações. Hoje deve ‘brincar’ com AJAX (Javascript), Flash, HTML, CSS, ASP, JSP, JSF e afins.
    • Desenvolvedor de Serviços (srv): domina orientação a objetos, componentização e, mais recentemente, serviços. É um programador clássico que, como tal, não leva o menor jeito com as ‘frescuras da camada de apresentação’.
    • Arquiteto de Informações (data): uma versão remoçada dos DBA’s (administradores de bancos de dados). Domina o desenho e desenvolvimento de bases tradicionais, transacionais, mas também sabe quando lançar mão de sistemas gerenciadores de conteúdo e bases analíticas.
    • Nosso antigo inimigo (infraestrutura): são os responsáveis por nossos servidores, redes, firewalls e outros brinquedinhos. Tê-los como parte da equipe de projeto desde os primeiros dias é uma prática que, com certeza, minimiza aquele ‘jogo de empurra’ que costuma acontecer um pouco antes ou um pouco depois do delivery da solução.

    Mas… e o coordenador? No próximo sub-capítulo falo especificamente sobre ele e sua convivência com o arquiteto.

    Agora, seguindo com o time cirúrgico proposto por Fred Brooks. O co-piloto que ele sugere é o ‘alter ego’ do cirurgião, capaz de executar qualquer tarefa atribuída à este. A única diferença é que o co-piloto seria menos experiente. Mas, ainda assim, funcionaria como um backup do cirurgião, inclusive representando-o em reuniões com outras equipes. Porém sua principal função é avaliar e discutir as idéias do programador-chefe. Lembra uma das práticas sugeridas pelo método conhecido como eXtreme Programming (XisPê – para os íntimos), a Pair Programming. A prática é polêmica e eu não disponho de dados que confirmem ou não as promessas de produtividade. Quero crer que a qualidade do código gerado realmente seja superior. Mas tenho algumas considerações que, por questão de tempo e espaço, tratarei em outra oportunidade.

    O ‘Administrador’ sugerido por Brooks é um tipo de Coordenador do Projeto. Apesar do cirurgião ter a palavra final em todas as questões, é o administrador que cuida do dia-a-dia da gestão financeira, de pessoal, suprimentos etc. Mais sobre o assunto no sub-capítulo seguinte.

    O ‘Editor’ é o responsável pela documentação. O cirurgião, segundo a proposta de Brooks, gera os documentos principais, tanto técnicos quanto aqueles para os usuários finais. Mas seria o editor o responsável pela compilação final, anexação de referências, bibliografia etc. É um luxo. Porém, ainda hoje brigamos para obter bons documentos de bons programadores, inutilmente.

    O ‘Bibliotecário’ – ‘escriturário’, ou program clerk, como sugerido por Brooks, não faz muito sentido nos dias de hoje. Mas parecia ser crucial nos tempos dos cartões perfurados e das intermináveis listas impressas em formulários contínuos. No entanto eu acredito que toda organização que esteja buscando o reuso de seus ativos de software, ou implantando uma SOA (Arquitetura Orientada a Serviços), demandará a presença de um bibliotecário, um especialista que em outro artigo eu chamei de GBA (Gestor da Biblioteca de Ativos).

    Se prestarmos atenção na complexidade dos atuais ambientes integrados de desenvolvimento (IDE’s – Integrated Development Environment), com seus frameworks, testes automáticos, integração com ferramentas de modelagem etc, veremos que pode fazer sentido o papel do ‘Almoxarife’, ou toolsmith, na nomenclatura original utilizada por Brooks. Um profissional especializado nas ferramentas e na sua adequação para cada tipo de projeto e função. Em equipes grandes ou em ‘fábricas’, parece ser uma função de grande utilidade.

    O ‘Testador’ é o nosso “Engenheiro de Testes”, uma função que aos poucos vai se tornando mais comum. Pena que muitos ainda o confundam com um ‘programador que não deu certo’. Teste é coisa séria, tanto que Brooks, como mostramos na 1ª parte desta série, dedicaria 50% do esforço de um projeto exclusivamente para ele.

    Por fim Brooks sugere a alocação de um ‘Advogado da Linguagem’. Creio que nossos espertíssimos e modernos IDE’s, nossos ‘testadores’ e, lógico, o arquiteto, eliminam a necessidade de um ‘language lawyer’. Advogado não, né?

    continua…

    ===

    1. Mills, H., “Chief Programmer teams, principles, and procedures”, IBM Federal Systems Division Report FSC 71-5108, Gaithersburg, Md., 1971.
    2. Artigo republicado em “Gestão do Conhecimento” (Harvard Business Review on Knowledge Management), Editora Campus, 2001.

  • Questão de Confiança

    Série “De Brooks a Berkun” – Continuação da 1ª Parte

    Berkun diz que o problema com nossos projetos não está nos cronogramas mas sim na forma como eles são elaborados e usados. O coordenador deve confiar nas estimativas apresentadas pelos programadores e demais membros do time. Se cada estimativa apresentada for bem justificada, não há porque desconfiar delas. Uma questão de validação: quão prováveis são os prazos fixados? “Se nenhuma probabilidade é oferecida e nenhuma pré-condição é colocada, então a realização do cronograma pode até ser possível, mas não é provável”.

    Que base de comparação, quais referências nós possuímos para avaliar corretamente as estimativas apresentadas? Tanto Brooks (em 75!) quanto Berkun insistem: só o domínio do nosso histórico, tanto de equipes quanto dos indivíduos, permitirá um julgamento justo. Qual a nossa produtividade, nossa ‘performance histórica’? Qual o índice de incidência de bugs? Existem estimativas para módulos/projetos semelhantes? Como elas foram elaboradas e quais fatores elas consideraram? Não há mágica!

    Por outro lado, os programadores devem confiar no plano, no cronograma apresentado. Como? Entendendo a lógica que o criou.

    O tema me faz lembrar duas provocações daquelas, feitas por Watts Humphrey:

    “Por que profissionais competentes concordam com cronogramas quando não têm a menor idéia sobre como irão cumpri-los?”

    “Por que executivos racionais aceitam tais cronogramas quando os engenheiros não oferecem a menor evidência de que poderão respeitá-los?”

    Berkun fecha o tema apresentando uma série de pequenas dicas muito úteis:

    • A duração de uma iteração deve ser coerente com a volatilidade do projeto. Quanto mais volátil, menor** deve ser a duração da iteração;
    • Devemos ser otimistas na elaboração do Documento de Visão (que será apresentado posteriormente) e pessimistas no cronograma*;
    • Devemos apostar no Design;
    • E planejar pontos em que as alterações de escopo serão permitidas;
    • Tornar pública a ‘filosofia’ do Plano – Cronograma;
    • Considerar a experiência da equipe no tipo de projeto que estamos tratando;
    • Assim como seu entrosamento;
    • E antecipar os riscos. Sempre! (o ‘Sempre’ foi meu).

    Só então, estabelecido um compromisso entre todos aqueles que se envolverão diretamente no desenvolvimento do projeto, é que o cronograma deveria ser Negociado com o cliente. Choque de realidade: muitas equipes são estruturadas após o ‘fechamento do negócio’. É triste, mas temo que não seja uma exceção.

    Não é difícil entender o ‘outro lado’. Normalmente, quando um projeto sai da área de negócios para aquisição, via departamento de TI, ele já está atrasado. Já é ‘para ontem’. Normal…

    … O problema começa quando a aquisição é fechada, o cronograma é apresentado desprovido “da menor evidência de que poderá ser cumprido”.

    Aos poucos estamos aprendendo que a Aquisição Progressiva é uma alternativa muito superior para contratações de projetos de software. Em linhas gerais: um projeto é fatiado em fases (normalmente todos já são); e as partes negociam apenas a fase imediatamente seguinte, aquela que apresenta o menor grau de incerteza. As partes começam com um grande número e um cronograma ‘genérico’, e concordam em refiná-lo no decorrer do projeto. O contratante pode optar por abrir uma nova concorrência a cada iteração/fase, mostrando independência e, principalmente, muita maturidade (em seus processos de desenvolvimento e aquisição de sistemas).

    Cronogramas: Um Meta-Modelo

    No texto original de “The Mythical Man-Month” Fred Brooks apresenta um ‘meta-modelo’ que deveria guiar a construção de todos os cronogramas. As regrinhas:

    • 1/3 – Planejamento
    • 1/6 – Codificação
    • 1/4 – Testes individuais
    • 1/4 – Testes de integração

    No capítulo 19 da edição especial do livro, “… after 20 years”, Brooks admite que seu modelo é muito waterfall (cascata). Pode ser, mas também pode ser adaptado para modelos de ciclo de vida mais modernos, iterativos (cíclicos) e incrementais.

    Mas… que luxo! Gastar 33% do tempo do projeto só em em planejamento!! E 50% do tempo do projeto em testes!?!

    Scott Berkun não deixa por menos e nos apresenta a “regra dos terços”:

    • 30% – Design
    • 30% – Programação
    • 30% – Testes

    Provavelmente gastamos os 10% que restam tentando justificar o cronograma, não é mesmo? Brincadeirinha…

    A simplicidade e objetividade das duas sugestões acima assustam um pouco. Mas, pense um pouco: Elas são válidas! Ambos começam concordando que devemos consumir cerca de 30% de todo o tempo do projeto apenas em seu planejamento e arquitetura. Isso não significa que, em um projeto de 9 meses, os três primeiros serão consumidos exclusivamente em atividades de planejamento e design. Em um processo de desenvolvimento mais moderno (apresentados na última parte da série), você planeja cada iteração. Mas se trata de um número justo. Eu diria ‘generoso’, se considerarmos diversos de nossos projetos.

    Berkun é também um desenvolvedor. Brooks nunca foi. Talvez isso explique o fato de Berkun dar o dobro de tempo para as atividades de codificação. Um pouco mais de 15%, como sugerido por Brooks, realmente é muito pouco. Mesmo com todos os frameworks e geradores de código ‘da vida’.

    Por fim temos as atividades tão ignoradas em tantos cronogramas: os famigerados Testes. Brooks pesa a mão e destina 50% de um cronograma exclusivamente para eles. Berkun se contenta com 30%. (Por favor, tentem esquecer por alguns instantes que ele trabalhou na MS, no projeto Windows, ok?).

    Régua, Esquadro e Bom Senso

    São os três elementos que devem existir entre o relógio-cronograma e a bola de cristal que apóia nossas estimativas. A Régua é nosso histórico de métricas, nossos índices de produtividade e coisas do tipo. Concordo que a máxima “não se gerencia o que não se mede” não se aplica totalmente em nossa área. Mas ignorar nossos números, definitivamente, não ajudará em nada.

    O Esquadro deve representar nossas ferramentas de apoio e ajuste. Se estamos em uma fase inicial do projeto, talvez os Use-Case Points sejam úteis. Já temos informações suficientes para municiar estimativas baseadas em Análise por Pontos de Função? Lancemos mão dela! Desde que não ignoremos o que a Régua nos ensinou.

    Por fim o mais importante: o tal Bom Senso. Na boca de muitos e em tão poucos projetos! O cliente não forneceu informações suficientes para uma boa estimativa? Então seja sincero e diga para ele que a estimativa apresentada é de ‘baixa qualidade’. Você suspeita que os requisitos são muito voláteis? Por que não sugerir um contrato de Aquisição Progressiva? Você não tem uma mínima equipe apoiando-o na elaboração das estimativas? Cobre o chefe. Ou contrate a mãe Diná, sei lá…

    —

    ** (update, 15/mar): estava aqui o erro apontado pelo Jonas Fagundes nos comentários. Tks!

    * Tem outra ‘regrinha’ que brinca com o equilíbrio “Otimismo X Pessimismo” que gosto bastante: tenha um Arquiteto pessimista e um Engenheiro otimista. Contradiz a regrinha do Berkun, mas costuma funcionar bem. Mas isso é assunto para o próximo post.

    Semana que vem: “Como montar equipes e influenciar projetos“.

    ps: Não, não sou fã do pai de todos os livros de auto-ajuda, “Como fazer amigos e influenciar pessoas”. Nada contra. Até já ganhei umas três cópias de alguns ‘amigos’. Mas, sei lá, entende? É uma questão de confiança.

  • Entre o Relógio e a Bola de Cristal

    Série “De Brooks a Berkun” – 1ª Parte

    No segundo capítulo de “The Mythical Man-Month”, homônimo, Fred Brooks mostra um fac-símile do cardápio do Restaurant Antoine, de New Orleans. Destaca um Avis au Public, que aparece logo no cabeçalho do menu:

    “Good cooking takes time. If you era made to wait, it is to serve you better, and to please you.”

    Brooks apresenta cinco razões para nossos constantes e intermináveis atrasos. O primeiro é o incurável otimismo de programadores e afins. Ele diz que nossas técnicas de estimativas são pobres e refletem uma situação irreal: de que tudo vai dar certo. Esse mesmo otimismo nos faria negligenciar, particularmente, a fase de testes de um projeto.

    O segundo motivo seria a confusão entre “Esforço” e “Progresso”. Tal confusão nasceria com a falsa crença de que Homens e Meses (Horas) são intercambiáveis. Brooks reforça que só conseguimos trocar alguns ‘meses’ por um monte de ‘gente’ em um conjunto de atividades que não exijam nenhum tipo de interação entre as pessoas. Acho que nem panha de café se encaixa…

    A terceira razão relacionada por Brooks para os atrasos em nossos projetos é chata e provocativa: nós não somos sinceros como o chef do Antoine. A facilidade com que damos ‘chutes’ e apresentamos cronogramas sem um mínimo de embasamento é realmente assustadora. Pior: apresentando-os como ‘sérios’. E a responsabilidade é tanto de quem pede quanto de quem dá. Já vi empresa muito grande solicitar uma proposta para um projeto de milhões apresentando um documento de 7 (sete!) páginas e fazendo uma reuniãozinha com os possíveis contratados. Tamanha negligência em qualquer outra área deve ser caso de polícia. Na nossa parece normal.

    A forma como acompanhamos e monitoramos a evolução de nossos cronogramas seria a quarta razão. A impressão que grande parte dos projetos nos transmite é que, assim que eles ‘ganham ritmo’, perde-se o controle.

    “Adicionar pessoas a um projeto de software atrasado só adiará a sua entrega.“
    – A Lei de Brooks

    Por último Brooks cita sua lei como outra grande razão para nossos atrasos. Segundo ele, adicionar pessoas a um projeto atrasado é como “tentar apagar um incêndio com gasolina”. Cada novo membro pode significar uma nova cadeia de interações e restrições. A quantidade de meses de um projeto dependeria de suas restrições sequenciais. O número máximo de pessoas dependeria do número de sub-tarefas independentes. Podemos elaborar um cronograma mais ‘demorado’ utilizando menos pessoas. Mas não podemos encurtar seu prazo ‘natural’ adicionando mãos!

    Recentemente Scott Berkun publicou uma série de exceções à Lei de Brooks. Alertando que não queria, de maneira alguma, sugerir o abandono da lei. O próprio Brooks já reconheceu que sua lei é “ultrajantemente super-simplificada”. Abaixo as exceções apontadas por Berkun:

    • Depende da pessoa: lógico! O acréscimo de uma ou mais pessoas mais experientes que aquelas da equipe atual pode, eu disse Pode, gerar um efeito positivo no projeto.
    • Alguns times podem assumir mudanças mais facilmente: sinceramente não vi relação direta com a lei. Mas claro, cada time, assim como cada pessoa, é único.
    • Há coisas piores que estar atrasado: com certeza, como entregar algo totalmente diferente daquilo que o cliente espera. Berkun lembra bem: “a única coisa que a lei fala é que o projeto atrasará ‘mais’ com a adição de mais pessoas”. Mas tal acréscimo pode ser benéfico ou crucial para o resultado final do projeto.
    • Há diferentes maneiras de adicionar pessoas à um projeto: mas Berkun lembra bem que nossa ‘tradição’ é ‘jogar gente lá para ver no que é que dá’. Se bem pensada, a adição (ou troca) de pessoas em um time pode ser benéfica.
    • Depende da razão do atraso do projeto, para começo de conversa: claro! Se o(s) motivo(s) não for(em) bem identificado(s), de que adianta jogar mais pessoas na frigideira?
    • A adição de pessoas pode ser combinada com outras ações do coordenador: de novo e pela última vez: Claro!

    Cronogramas são só um tipo de Previsão

    Mas há quem os trate como se fossem ‘documentos sagrados’. Para Scott Berkun os cronogramas “não são remédio para um projeto (design) ou práticas de engenharia ruins e também não podem proteger um projeto de uma liderança fraca, objetivos obscuros e comunicação pobre”. Independentemente do tempo gasto e do capricho com que um cronograma foi elaborado, “no final das contas eles são apenas uma lista de palavras e números”. Uma lista que, segundo Berkun, deve ter três objetivos bem claros:

    • Descrever quais tarefas devem ser executadas, quando e quais produtos serão gerados;
    • Funcionar como em elo de ligação da equipe, indicando dependências e amplificando os compromissos mútuos; e
    • Fornecer para o time uma ferramenta que possibilite o acompanhamento da evolução do projeto e que permita estruturá-lo em etapas mais gerenciáveis.

    E não é que tem cliente que, inconscientemente (quero acreditar), prefere ver um cronograma atualizado do que software rodando? Querendo ou não, os cronogramas viraram o ‘grande’ documento de um projeto de software. Responsabilidade demais para algo que deveria ser só mais uma ferramenta. Pior: para algo que deveria evoluir junto com o projeto.

    “A elaboração do melhor cronograma, usando as mais capacitadas pessoas e as melhores ferramentas, também será uma tentativa de prever o futuro. Algo que nossa espécie raramente faz bem.”
    – Scott Berkun

    É impossível gerar um cronograma com um mínimo de acuracidade no momento inicial de um projeto. Berkun afirma e milhares de projetos confirmam esta ‘lei’. Mas continuamos insistindo. Berkun adaptou “Software Engineering Economics”, de Barry Boehm, e gerou o gráfico abaixo. Nos momentos iniciais de um projeto nosso ‘chute’ pode ter uma variação de 400%. Há quem arrisque 4 dígitos…

    Berkun afirma que a volatilidade dos requisitos, dentre outros fatores, pode gerar estimativas de baixa qualidade. E que não há nada de errado com elas desde que sejam apresentadas como tal: Estimativas de Baixa Qualidade. E sugere a adoção de Níveis de Confiabilidade para nossas estimativas:

    • 40% – é só um chute
    • 70% – uma boa estimativa
    • 90% – estudamos e detalhamos (quase) tudo

    Uma boa estimativa dependeria principalmente de dois fatores: bons requisitos e um bom design (temas que serão tratados posteriormente).

    E Berkun ainda pede: confie em seus programadores como você confiaria em um neuro-cirurgião. Se este falar que aquela operação no cérebro demorará 12 horas, você tem coragem de pedir para que ele reduza para, digamos, 4 horas? Você seria o louco o suficiente?

    continua…

  • De Brooks a Berkun – Prólogo

    No ano passado comemorou-se 30 anos do lançamento da primeira edição de “The Mythical Man-Month“, de Frederick P. Brooks Jr. O livro pode ser considerado o primeiro clássico das áreas de Engenharia de Software e Gerenciamento de Projetos. Fred Brooks trabalhou por 8 anos na IBM, entre 1956 e 1964. Seu último ano foi dedicado ao desenvolvimento do OS/360, um empreendimento que envolveu mais de 5 mil homens/ano. Surge então a provocação que o levaria ao livro, uma ‘pergunta básica’ de Thomas Watson (CEO da IBM na época):

    “Por que programação é tão difícil de ser gerenciada?”

    Três décadas de avanços tecnológicos e de consolidação das ciências Engenharia de Software e Gerenciamento de Projetos não foram suficientes para tornar o texto obsoleto. Muito pelo contrário: até hoje o livro é considerado uma referência obrigatória. Em 2004, quando questionado sobre a razão da longevidade de sua obra-prima Fred Brooks respondeu: “Eles falam que o livro é a Bíblia da Engenharia de Software… é por isso que todo mundo o lê mas ninguém o usa!”.

    No ano em que comemorou seu trigésimo aniversário, “The Mythical Man-Month” ganhou um tipo de upgrade, de complemento. Trata-se de “The Art of Project Management“, de Scott Berkun. Não é só uma coincidência de temas, afinal existem milhares de títulos sobre Gestão de Projetos e Engenharia de Software. Mas vários outros aspectos aproximam as duas obras. Scott Berkun trabalhou por dez anos na Microsoft, em projetos como Windows, MSN e Internet Explorer. Ou seja, Berkun reviveu experiências parecidas com aquelas de Brooks em uma corporação de porte e relevância quase idênticas. Não é por acaso que os dois livros possuem linguagem e estrutura muito parecidos. São chamados “histórias de guerras”. Ambos são muito fáceis de ler e seguem uma ordem própria, em detrimento de padrões, nomenclaturas e sequências que caracterizam 9 em 10 títulos sobre gerenciamento de projetos lançados nos últimos tempos.

    Esta série de artigos foi concebida originalmente para comemorar os 30 anos de “The Mythical Man-Month”. Compará-lo ao recém lançado “The Art of Project Management” é só uma maneira de tornar a homenagem e, por que não dizer, as provocações, um pouco mais ricas.

    Estruturei a série em 5 grandes partes:

    1. Entre o Relógio e a Bola de Cristal
    2. Como Montar Times e Influenciar Projetos
    3. Castelos de Areia…
    4. … e a Inevitabilidade das Marés
    5. A Receita e o Bolo de Fubá

    Semanalmente publicarei aqui um novo capítulo ou sub-capítulo. Ao término da série, com a compilação das (esperadas) contribuições externas, será disponibilizado um arquivo PDF com seu conteúdo integral.

    Por incrível que pareça, nem “The Mythical Man-Month” nem “The Art of Project Management” mereceram uma edição em ‘português do Brasil’. Um lapso que ainda pode ser corrigido. E deveria. Como são best sellers, mesmo por aqui, razão comercial não há. Como Gestão de Projetos está na moda, resta-nos torcer para que, no meio daquele tanto de livro lançado para “ajudar a gente a passar na prova”, apareçam mais títulos como os de Brooks e Berkun.

    Este artigo não deve ser visto, de forma alguma, como uma alternativa aos textos originais. Ele deve servir como um incentivo para a leitura de ambos. Ou releitura, por que não? A última edição de “The Mythical Man-Month” comemorou seus 20 anos em 95. Ele traz uma série de artigos e capítulos complementares. Mas o texto original, como era de se esperar, foi mantido.

    Minha motivação parece ser a mesma de Berkun, resumida nessa provação de Douglas Adams:

    “Seres humanos, que são quase únicos em sua capacidade de aprender com as experiências dos outros, também se caracterizam por sua resistência em fazê-lo.”

  • SOA :: On the Road

    Update (27/out): Finalmente liberado o arquivo da apresentação.

    Há quase 3 meses liberei um draft do artigo “SOA: Novos e Velhos Desafios” neste espaço. Confesso que esperava um mínimo de interação via blog, mas minhas 4 dúzias de leitores (que viraram uns 400 visitantes únicos – tnx!), definitivamente, não gostam deste tipo de ‘bate papo’. Tudo bem. Até pq conversa não faltou nos últimos tempos. E tem sido tão boa e rica que tem me feito postergar a publicação da versão final do artigo. Compilo abaixo, de maneira irresponsavelmente resumida, algumas conclusões, dúvidas, chutes e problemas:
    • Pra variar há um descompasso entre fornecedores de tecnologia e seus usuários. Parece que 2006 será um ano ‘chave’ para a consolidação de SOA nos EUA. Pelo que percebi, nós tupiniquins aguardaremos mais 2 ou 3 anos. Os poucos early adopters brasileiros não terão o que mostrar no ano que vem, não ao ponto de motivar adesões.
    • Nas palestras, o pessoal com um pouco mais de estrada (desenvolvendo sistemas) percebe rapidamente as vantagens de uma SOA. Como apresento na 1ª parte do evento os conceitos básicos, é natural que se inicie ali um debate sobre “Arquitetura”.
    • É uma pena que eu tenha que atirar um balde d’água fria no ânimo do pessoal no mesmo instante. Faço-o (sem querer) ao lembrar que ainda temos muitas pendências (linguagens para os contratos: WS-*; ferramental de desenvolvimento; um processo para gestão e desenvolvimento e as eternas “questões semânticas”).
    • E compenso tudo mostrando a maior pendência de todas: o Arquiteto (que não existe). Digo, sem o menor medo de errar, que será a profissão com as melhores ofertas e melhores salários nos próximos 5 anos. E nesse ciclo sádico (1 tapa, 1 beijo), apresento um anúncio real para contratação de um Arquiteto. Desanimo uns e provoco todos ao comentar que no próximo ano a Microsoft lançará a nova certificação MCA (Microsoft Certified Architect), um processo que lembrará (muito) a defesa de uma tese de doutorado. (Com um programa que cita o IBM Websphere mais de 1 vez!!!).

    Ou seja, só a primeira parte (que dura uns 30-40min) da palestra já gera assunto para 2hs de debate. E, dependendo do público (falo principalmente da estudantada das faculdades), trata-se de uma tsunami de siglas e conceitos novos. Um show de terror ou um show de tédio, dependendo do aluno. Mal sabíamos (na primeira execução pública) que o evento ainda duraria mais 2hs…

    • Uma iniciativa SOA deve ser gerida como um Programa, ou seja, um conjunto (nada pequeno) de projetos. Gosto muito da estrutura do Comitê Gestor que sugiro. Mas fiquei devendo um processo de gestão. Cito o Meta-Scrum (que é uma proposta muito recente) e uma série de ferramentas / frameworks / Padrões (Mapas Estratégicos, MDA, RAS). Todos mereciam mais tempo e espaço. E, principalmente, Estudo!
    • Mas meu maior erro (no artigo – foi corrigido na apresentação) foi citar o RUP e não o EUP (Enterprise Unified Process) como processo básico. O EUP contempla várias disciplinas (totalmente ignoradas pelo RUP) vitais para a gestão do Programa SOA: Enterprise Business Modeling, Portfolio Management, Enterprise Architecture e Strategic Reuse.
    • A audiência parece assimilar bem os conceitos básicos do método Scrum para o gerenciamento dos projetos SOA. Mas deixo (e destaco) aqui outra imensa pendência: um processo “meet-in-the-middle“, fundamental para a análise e projeto (design) dos Serviços. Explico a necessidade: enquanto um Analista de Negócio absorve os requerimentos do projeto, um Analista de Sistemas deve descobrir e mapear todos os ativos de software que podem ser revitalizados pelo novo Serviço. Seu encontro (meet-in-the-middle), intermediado pelo Arquiteto, deve gerar a primeira visão conceitual (lógica?) do Serviço.

    Conclusão: é muito mb pro meu hd (ou: “muita areia pro meu caminhãozinho”). E olha que nem me meti em temas como “Governança SOA”, “Segurança SOA”, “Gerenciamento de Transações em uma SOA”… urgh! Preciso “focar” (blergh!) meus estudos se eu quiser parar de gerar “nata” (com alguns metros quadrados de área e 2cm de profundidade). Lógico que meus interesses, desde o início dos estudos, são:

    • Gestão de Projetos (Gestão do Programa em 2º plano);
    • Processos de Gestão e Desenvolvimento;
    • Agilidade; e
    • Perfil dos futuros projetos de TI (onde SOA se encaixa).

    Eu e o finito voltamos para eles tratando-os de forma mais específica. Lógico que partindo do ponto que estamos: tudo que sugerimos para Programas e Projetos SOA são úteis em outros tipos de projetos. Vamos maturá-los enquanto SOA não vem…

    This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 2.0 Brazil License.

  • Projetos SOA :: Novos & Velhos Desafios

    Este post é um “índice” para os (até então) 8 capítulos que compõem o artigo “Projetos SOA – Novos & Velhos Desafios”.

    Trata-se de um trabalho em desenvolvimento e sua publicação aqui visa obter outras colaborações, críticas e sugestões. A intenção é promover um bate-papo (presencial, obviamente, além de uma provável apresentação) até o final do mês de agosto. Seguem abaixo os links para as 8 partes do artigo:

    #1 – Introdução
    #2 – Conceitos Básicos
    #3 – É o Negócio, Estúpido!
    #4 – O Programa SOA
    #5 – Processos
    #6 – MDA (Model Driven Architecture)
    #7 – Os Projetos SOA
    #8 – Processo de Gestão e Desenvolvimento

    Além de uma série de outros motivos que não merecem tratamento aqui, a amplitude e complexidade do tema me levaram a desistir de inscrever o artigo nos eventos “V Seminário Internacional” do PMI e “Gestão de Projetos” da SUCESU-SP, do qual participei nas duas últimas edições. Há muito por fazer!

    E estudar. Olhando especificamente para a “Gestão do Programa SOA” e “Gestão de Projetos SOA” dá para destacar as seguintes disciplinas:

    . Mapas Estratégicos – Para a Gestão de Portfólios
    . MDA (Model Driven Architecture) – Como complemento do Processo de Desenvolvimento e como framework
    . RUP (Rational Unified Process) – Como base do Processo de Desenvolvimento.
    . Scrum – Que selecionei como processo de Gestão dos Projetos. Um Meta-Scrum seria utilizado para gestão do Programa SOA.
    . Formação de Equipes – Apresento duas estruturas, uma para o Comitê Gestor e outra para as Equipes de Desenvolvimento. Há vários perfis (oportunidades?) novos!

    Se considerarmos que as “Arquiteturas Orientadas a Serviços” são, em si, uma macro-disciplina bastante nova, instigante e complexa… Pois é: há muita coisa nova (e boa) a ser estudada e, claro, IMPLEMENTADA!

    Espero que o Finito seja uma boa ferramenta para que a gente possa trocar idéias e experiências. Espero mais ainda que o conteúdo apresentado seja um bom “estopim”. Let’s talk about it?

  • [SOA # 8] – Processo de Gestão e Desenvolvimento

    Uma implementação SOA não deve significar a adoção de um conjunto totalmente novo de processos e métodos. Principalmente se a empresa contar com uma equipe relativamente estável e um conjunto de melhores práticas comprovadamente eficazes. O processo existente deveria ser customizado de forma a implementar atividades, perfis e produtos específicos de um programa SOA. A principal barreira para a adoção de um processo atual seria o fato deste não prover um ciclo de vida de desenvolvimento que seja iterativo e incremental. Um modelo waterfall, definitivamente, não é adequado para o desenvolvimento de Serviços SOA. Também é desejável que o processo utilizado seja :

    • Cooperativo: aproxime a equipe de projeto com os futuros usuários dos serviços;
    • Direto: o método deve ser de fácil aprendizado e bem documentado;
    • Adaptável: fácil de ser customizado de forma a atender particularidades de determinado projeto;
    • Escalável: de forma que possibilite sua adoção em projetos dos mais variados portes e níveis de complexidade;
    • Orientado pela Arquitetura: ou seja, pressupõe que os produtos dos projetos em desenvolvimento fazem parte de algo maior e devem, conseqüentemente, respeitar os padrões fixados; e
    • Incentivador do Reuso de Ativos: uma conseqüência direta de sua orientação à arquitetura.

    Não há um único processo no mercado que, em seu formato padrão, atenda todos os requisitos listados acima. Os 3 primeiros itens da lista mais as características “iterativo e incremental” configuram o que se chama de um “Processo Ágil”. Porém todos os mais conhecidos são indicados para pequenas equipes ou seja, não escalam. Já processos que atendem os 3 últimos requisitos da lista, como o Rational Unified Process (RUP), raramente são considerados “Cooperativos” ou até mesmo “Diretos”.

    Uma combinação do RUP, Scrum e eXtreme Programming (XP) pode gerar um excelente processo para a gestão e desenvolvimento de Projetos SOA. Abaixo é apresentada uma visão geral deste modelo customizado.

    Visão Geral de um Processo Customizado

    Dos 3 processos listados acima, o RUP é o mais completo. Por isso muitas vezes é tido como excessivamente burocrático e “pesado”. Seus críticos, na maioria das vezes, desconsideram o fato dele ser bastante customizável. O RUP é a base desta sugestão exatamente por sua completitude e adaptabilidade. Geralmente ele é apresentado, em alto nível, da seguinte maneira :


    As disciplinas do RUP mais afetadas em uma customização para atendimento dos requisitos de um processo SOA são:

    • Modelagem de Negócios: que passa a gerar, como principal produto, o Contrato do Serviço que, por sua vez, é a base para elaboração do Backlog do Serviço (Produto, na terminologia Scrum). A captura de indicadores de qualidade e níveis de serviço esperados também merece destaque;
    • Implementação: que deve incorporar algumas práticas XP, particularmente a liberação de produtos em ciclos curtíssimos;
    • Teste: que incorpora testes específicos de uma Arquitetura Orientada a Serviços, como a validação da abrangência das interfaces expostas, potencial de reuso, dentre outros;
    • Implantação: que deve assimilar também todas as atividades de publicação dos Serviços, dentre elas o encapsulamento final dos artefatos e o agendamento da publicação;
    • Gerenciamento do Projeto: que é totalmente trocada pelo método Scrum. Veja mais abaixo.

    Gerenciamento de um Projeto SOA

    Como adiantado no sub-capítulo “Equipes de Projetos” acima, a responsabilidade pelo Gerenciamento de um Projeto SOA é compartilhada pelo Coordenador do Projeto e pelo Dono do Serviço (Product Owner, na terminologia Scrum original). O primeiro cuida de todas disciplinas previstas no PMBoK (Project Management – Body of Knowledge) exceto a “Gestão do Escopo”, que seria de responsabilidade exclusiva do Dono do Serviço*. Mas a adoção do Scrum como método para a gestão de um projeto SOA implica em mudanças ainda mais profundas na rotina de trabalho do coordenador de projetos.

    Sua principal atividade pode ser vista como uma “obsessiva (extrema) gestão de riscos”. Ele deve buscar e eliminar todas as barreiras que estejam impedindo a equipe de atingir seu ponto máximo de performance. O diagrama abaixo expõe uma visão geral do processo Scrum adaptado para o desenvolvimento de projetos SOA:


    Na etapa de Planejamento é compilada a primeira versão do Contrato do Serviço. Em tempo de desenvolvimento é desejável que este contrato seja a principal ferramenta de controle e acompanhamento do projeto. Para tanto ele deve contemplar também :

    • Estimativas de Custos e Prazos para o projeto;
    • Plano de Desenvolvimento e das Iterações (Sprints);
    • Definições de sincronismo com outros projetos;
    • Plano de Testes; e
    • Plano de Publicação.

    O contrato é desenvolvido a partir dos requerimentos coletados pelo Analista de Negócios e de definições prévias oriundas do Comitê Gestor do Programa SOA. O contrato deve respeitar integralmente os Padrões SOA definidos por este comitê nos momentos iniciais do programa. É parte integrante do Contrato um desenho em alto nível da arquitetura do serviço. Por isso ele é elaborado em conjunto pelo Dono do Serviço e pelo Analista de Negócios.

    A negociação final do contrato com as áreas usuárias é conduzida diretamente pelo Dono do Serviço. O processo pode prever uma etapa de revisão de contratos pelo Comitê Gestor, que ocorreria antes da elaboração do Backlog do Serviço. Esse backlog é desenvolvido pelo Dono do Serviço. Sua elaboração é acompanhada pelo Coordenador do Projeto, que pode discutir prioridades e definir a estrutura de divisão de tarefas. É também neste momento que as estimativas de prazos e custos podem ser refinadas, com apoio de integrantes das equipes de desenvolvimento.

    A partir do Backlog do Serviço o Coordenador do Projeto elabora o Backlog do Sprint (Iteração), que é o plano de trabalho da próxima iteração a ser executada. Um sprint, na concepção original do método Scrum, é uma iteração com duração fixa de 30 dias. Apesar dos benefícios da fixação de um prazo comum para todas as iterações de todos projetos, entende-se que em muitos casos tal “regra” pode se tornar uma barreira a ser derrubada pelo Coordenador de Projetos. Um serviço, dependendo de sua granularidade, pode demandar ciclos de duração mais curta. No entanto trata-se de um excelente balizador para projetos mais complexos.

    Um sprint contempla todas as fases tradicionais de um processo de desenvolvimento de sistemas, ou seja: engenharia de requerimentos, análise, modelagem, codificação, testes e liberação. No entanto, é vital que ao término de cada sprint aja uma nova versão do serviço em condições de uso, mesmo que ainda não estejam satisfeitos todos os seus requerimentos fundamentais.

    Como mostrado anteriormente, a construção de um serviço normalmente envolverá o trabalho de dois times distintos: os desenvolvedores dos Frontends das Aplicações e os desenvolvedores dos Serviços propriamente ditos. É crucial que o backlog do Sprint contemple a total sincronização destas duas frentes de trabalho. O gráfico a seguir mostra um zoom de como deve ocorrer o Sprint :


    O processo prevê a realização de scrums diários, breves reuniões que ocorreriam sempre no mesmo local e horário. Nelas o Coordenador afere os progressos obtidos desde o dia anterior, refina a lista de riscos e impedimentos e ajusta o planejamento de atividades do dia. Radical, a proposta original do Scrum sugere que estas reuniões tenham a duração máxima de 15 minutos. O coordenador pode optar por realizar duas reuniões diárias, uma com cada time de desenvolvimento.

    No último dia do sprint realiza-se uma reunião de revisão com a presença do Dono do Serviço, Analista de Negócios e representantes das áreas usuárias. O Coordenador e a equipe de desenvolvimento apresentam as realizações do último sprint. Neste momento o Dono do Serviço e o Coordenador do Projeto revisam o Backlog do Produto, registrando mudanças ou novas solicitações. A partir desta atualização o Coordenador elabora o Backlog do próximo sprint.

    Quando todos os itens do Contrato do Serviço estiverem satisfeitos inicia-se a terceira e última fase do projeto, que na versão original do Scrum é chamada Postgame Phase. Neste momento o Serviço e respectivo Cliente são submetidos ao processo de certificação, que deve garantir a total adequação dos novos artefatos aos Padrões SOA.

    Por fim temos o processo de Publicação, que envolverá o encapsulamento de todos os artefatos gerados e o agendamento da publicação do Serviço.

    Representantes do Comitê Gestor do Programa SOA envolvem-se em três momentos de um projeto:

    • Validando o Contrato elaborado na primeira fase;
    • Acompanhando as Reuniões de Revisão, que no formato padrão ocorrem mensalmente; e
    • Certificando e Publicando a versão final do Serviço.

    O processo Scrum sugere que as equipes de projeto se auto-gerenciem, promovendo a livre interação entre todos os membros. O Coordenador do Projeto, mais que um “controlador”, é um Facilitador. Outra característica marcante do processo é a “blindagem” da equipe, que em seu dia-a-dia fica livre de influências externas. Este desenho valoriza todos os integrantes da equipe e pode representar consideráveis ganhos de produtividade.

    Evolução do Processo

    O Scrum é um modelo organizacional desenhado para a execução de projetos cuja previsibilidade é limitada . Os princípios básicos que levaram ao seu desenvolvimento foram Flexibilidade, Adaptabilidade e Produtividade. A coincidência com os meta-requerimentos fundamentais de uma iniciativa SOA é total. Mas ambas propostas, tanto o Scrum quanto as Arquiteturas Orientadas a Serviços são relativamente recentes. Praticamente não existem referências do uso do Scrum em projetos SOA.

    O trabalho mais recente de Jeff Sutherland descreve a última evolução do Scrum, chamada “Tipo C”. As principais alterações referem-se à adoção de sprints simultâneos e a elaboração de um MetaScrum. Este meta-processo pode ser muito útil na gestão do Programa SOA, como sugerido neste artigo. E a habilidade de gerenciar múltiplos sprints pode ser crucial em uma iniciativa SOA que se encontre em um estágio mais avançado de maturação.

    =================

    3. “Enterprise SOA – Service-Oriented Architecture Best Practices”, Dirk Krafzig, Karl Banke e Dirk Slama
    Prentice Hall (PTR) (2005).
    14. “Future of Scrum: Support for Parallel Pipelining of Sprints in Complex Projects”, Jeff Sutherland
    Artigo (2005)
    16. “Rational Unified Process”, IBM Corp.
    http://www-306.ibm.com/software/awdtools/rup/

    * Na realidade, a versão original do Scrum prevê a existência de um terceiro gestor, não considerado nesta proposta.

  • [SOA # 7] – Os Projetos SOA

    Como apresentado anteriormente, uma iniciativa SOA deve ser conduzida como um Programa, um conjunto de projetos interdependentes. Mas se trata de um programa bastante particular já que a ligação entre os projetos, assim como ocorre com os serviços que formam uma SOA, deve ser fraca. Quer dizer, é fator crítico de sucesso de uma SOA que seus projetos não criem nenhum tipo de impedimento para a realização de outros.

    É natural que cada Serviço seja visto como um Projeto em si. O fato de ser uma tradução direta de um processo de negócio facilita a comunicação com as áreas usuárias. Mas como definir um Serviço?

    Normalmente as organizações e seus sistemas são vistos como estruturas hierárquicas. Departamentos são estruturados verticalmente, e os sistemas que os apóiam acabam se transformando em silos de informações. Mas os processos e atividades de negócio ocorrem horizontalmente, podendo envolver várias áreas e departamentos em sua realização completa. Um processo de venda, por exemplo, pode envolver os departamentos financeiro, almoxarifado e logística, além da própria área de vendas.

    No início dos anos 90 Michael Hammer e James Champy lançaram o livro “Reengenharia – Revolucionando a Empresa” , onde propunham a visualização da empresa como um conjunto de processos. Partiam do pressuposto que apenas uma visão completa e única dos processos poderia ajudar a organização na otimização destes e, conseqüentemente, na obtenção de vantagens competitivas. Hammer e Champy não criaram esta visão, mas a tornaram popular e presente nas agendas das mais diversas organizações.

    Apesar da “onda reengenharia” ter resultado em grandes desastres corporativos, a criação de uma visão da parte realmente dinâmica de uma corporação – seus processos – ainda é um fator de diferenciação no mundo dos negócios. Tanto que além da proposta SOA, outras tendências como BPM (Business Process Management) e BAM (Business Activity Monitoring) são fortemente baseadas nesta visão.

    Todo processo de negócio possui uma hierarquia . Ele é composto de sub-processos que são seqüências de atividades que por sua vez são divididas em duas ou mais tarefas. Voltando ao exemplo de um processo de venda, podemos dizer que a elaboração de uma proposta é um sub-processo; a logística de entrega é uma atividade; e a verificação do crédito do comprador é uma tarefa.

    Relacionando essa hierarquia com os tipos de Serviços existentes em uma SOA podemos dizer que os serviços Básicos representam as tarefas e atividades, enquanto os serviços dos tipos Processo e Público representam processos e sub-processos de negócio. Portanto, um programa SOA pode ser formado por projetos de portes bastante distintos.

    Além do desenvolvimento dos Serviços propriamente ditos há outro projeto em um programa SOA: o desenvolvimento e evolução da Infra-estrutura tecnológica que deve suportar a nova arquitetura. Esta infra-estrutura é composta pelo Repositório e pelo Bus de Serviços.

    Equipes de Projetos

    As equipes que executam os projetos SOA devem ser formadas a partir do modelo do Comitê Gestor. Uma formatação padrão teria as seguintes funções:


    Como será detalhado adiante um dos processos que serviu de base para este estudo foi o Scrum . Portanto a estrutura de equipe apresentada na figura acima reflete, de certa maneira, uma equipe padrão Scrum.

    O Dono do Serviço é equivalente ao Product Owner do Scrum, com algumas diferenças. Ele não é escolhido pelo Scrum Master, o Coordenador do Projeto da estrutura sugerida, e sim pelo Comitê Gestor. Ele deve ser um Arquiteto SOA e suas principais responsabilidades são: i) a Elaboração e Negociação do contrato do serviço com as áreas usuárias; ii) Transformação deste contrato em um Service (Product) Backlog, principal meio de controle e comunicação com o Coordenador e os Desenvolvedores alocados no projeto; e, iii) Gerencia o escopo e define as prioridades do projeto. É o Dono do Serviço que responde pelo projeto perante o Comitê Gestor e toda a organização.

    Já o Coordenador do Projeto equivale, em termos, ao Scrum Master. Ele é indicado pelo Engenheiro do Processo (PMO) que integra o Comitê Gestor. O Coordenador deve garantir que a equipe esteja respeitando o processo de desenvolvimento. E, como prega a metodologia Scrum, é responsável pela eliminação de qualquer impedimento que esteja impactando na performance da equipe.
    Visando facilitar a compreensão dos dois papéis acima, pouco comuns em equipes tradicionais de projetos, Jeff Sutherland apresentou uma feliz analogia com uma equipe de rally . Enquanto o Coordenador do Projeto (Scrum Master) é o “Piloto”, o Dono do Serviço (Product Owner) é o “Navegador”.

    O Analista de Negócio é nomeado pelo Arquiteto de Negócio para representar a equipe perante todas as áreas de negócio envolvidas com o serviço em questão. É ele quem captura os requerimentos e os transcreve de forma a facilitar a compreensão pela equipe de desenvolvimento. Assim como o Arquiteto de Negócio no comitê gestor, o Analista de Negócio deve defender e garantir a satisfação dos requerimentos pelo serviço desenvolvido.

    O grupo de Apoio é populado por integrantes que são alocados esporadicamente na equipe, visando atender necessidades específicas. Um representante do time de Infra-Estrutura Tecnológica pode ser alocado, por exemplo, para garantir que o Serviço será atendido pelos recursos computacionais existentes.

    O Gestor da Biblioteca de Ativos fará uso desta mesma estrutura quando o serviço se encontrar em estágio final de construção, visando sua Certificação (CQ – Controle de Qualidade) e preparação para Publicação, de acordo com o ciclo de vida estipulado no processo.

    Os Desenvolvedores são estruturados em dois grupos: Frontend Apps, que trata do desenvolvimento das interfaces para os usuários dos serviços; e Serviços, que é a implementação do serviço propriamente dito. Tal divisão deve fazer sentido na construção de praticamente todos os tipos de serviços, independente de seu porte. Como será apresentado a seguir, é uma boa prática que tais elementos sejam desenvolvidos em separado, dadas as consideráveis diferenças que existem entre eles e a necessidade de agilidade em sua construção.

    Considerações sobre as Estruturas Propostas

    É interessante notar que uma Equipe de Projeto é um tipo de instanciamento do Comitê Gestor. Assim como é fortemente sugerida a adoção de um Meta-Processo para o Programa que tenha o mesmo formato e atenda os mesmos padrões do Processo adotado para o desenvolvimento e gestão dos projetos, é salutar que as equipes de projetos SOA sejam uma representação (de certa forma abreviada) do Comitê Gestor. Percebem-se duas inequívocas vantagens neste enfoque:

    • Clara distribuição de responsabilidades que respeita, principalmente, as áreas de especialização; e
    • Formação de “Comunidades de Prática” , ou seja, profissionais são agrupados por área de interesse. A troca de conhecimentos pode se dar de maneira mais natural e freqüente.

    >>>>>>>>>> SOA #8 – Processo de Gestão e Desenvolvimento

    11. “Reengenharia – Revolucionando a Empresa”, Michael Hammer e James Champy
    Editora Campus (1994)
    12. “Aperfeiçoando Processos Empresariais”, H. James Harrington
    Makron Books (1993)
    13. “Agile Software Development Methods – Review and Analysis”, Pekka Abrahamsson, Outi Salo, Jussi Ronkainen e Juhani Warsta
    VTT (2002)
    14. “Future of Scrum: Support for Parallel Pipelining of Sprints in Complex Projects”, Jeff Sutherland
    Artigo (2005)
    15. “Aprendizado Inter-Projetos”, Paulo F. Vasconcellos
    Artigo publicado em Out/2004.

  • [SOA # 6] – MDA (Model Driven Architecture)

    Outra iniciativa relativamente recente que pode agregar alto valor a uma implementação SOA é a Arquitetura Guiada por Modelos (MDA – Model Driven Architecture), proposta e mantida pelo OMG (Object Management Group) . MDA é um framework para o desenvolvimento e manutenção de aplicações fortemente baseado em modelos e, conseqüentemente, na UML (Unified Modeling Language), que também é um padrão mantido pelo OMG. MDA propõe separar a especificação das funcionalidades de um sistema da especificação de sua implementação. Além da portabilidade obtida, haveria considerável ganho nas tarefas de construção e atualização das soluções. Várias ferramentas realizam, de certa forma, esta visão, automatizando as tarefas de modelagem e, principalmente, a transformação entre modelos. Esta “automatização” do processo de desenvolvimento geraria reduções de até 50% nos esforços e custos de desenvolvimento .

    Mas o primeiro impacto positivo que a adoção da MDA pode trazer para a implementação de uma Arquitetura Orientada a Serviços é a adoção de modelos que, utilizando variações de um mesmo padrão de linguagem, podem facilitar a visualização e compreensão das arquiteturas vigentes na organização e daquelas a serem realizadas.

    Um Serviço em uma SOA, como descrito anteriormente, é a representação fiel de um Processo de Negócio. A correta assimilação deste processo, seus sub-processos e atividades, requerimentos e restrições são cruciais para o seu desenvolvimento na forma de um Serviço. MDA fornece dois tipos de modelos que podem facilitar a absorção, desenho e eventualmente até mesmo o redesenho do processo de negócio. São os modelos CIM (Computation Indenpendent Model) e PIM (Platform Indenpendent Model).

    O CIM, como o próprio nome indica, pode representar o processo de negócio em sua forma mais pura, sem a influência da estrutura de sistemas que eventualmente o suporta. Este modelo, também conhecido como Modelo de Domínio, utiliza diretamente o vocabulário do negócio, meta-requerimento fundamental em uma implementação SOA.

    Já o PIM pode mostrar o processo de negócio devidamente apoiado por recursos computacionais sem no entanto entrar em detalhes de sua implementação. A indicação dos recursos necessários para a realização do Serviço conforme especificado em seu Contrato pode facilitar o trabalho dos arquitetos na seleção da melhor estratégia de implementação, que é desenhada na forma de um PSM (Platform Specific Model), outro tipo de modelo MDA. O framework MDA possibilita a execução de simulações na conversão dos modelos, o que pode facilitar e apoiar o processo de tomada de decisões pelos arquitetos.

    Observação: há um quarto modelo no MDA, chamado PM (Platform Model). Ele provê uma visão de uma plataforma específica, seus elementos e serviços oferecidos. Se devidamente enriquecido de forma a representar as peculiaridades daquela plataforma na empresa ele também pode ser muito útil nas tarefas de simulação citadas acima. Além, é claro, de ser base para a modelagem do Bus que é um dos 4 principais elementos de uma SOA.

    >>>>>>>>>> SOA #7 – Os Projetos SOA

    8. “MDA Guide V1.0”, OMG – Object Management Group
    OMG (2003). (http://www.omg.org/mda)
    9. “Executive Justification for Adopting Model Driven Architecture (MDA)”, Stanley J. Sewall
    Artigo (2003).
    10. “What Senior Management Need to Know About the Value of MDA”, Louis J. Eyermann III
    Artigo (2004).