finito

Aviso aos Assinantes (RSS)

2008-01-24T14:28:00.001-02:00

Prezadas e Prezados,

Bem que eu gastei um tempinho tentanto livrá-los desta chateação. Mas realmente ficou um pouquinho complicado. Explico: você recebe meus posts através de um agregador (Google Reader, Outlook, Yahoo e outros). Acontece que o endereço dos posts vai mudar. Tentei evitar a mudança, mas o novo finito apresenta novas possibilidades de assinatura (por tema, calendário e integral), o que dificulta a conversão.

Por isso peço, encarecidamente, que você altere o cadastro em seu leitor de feeds. Para continuar recebendo o conteúdo integral do finito, basta apontar para o endereço abaixo:

http://www.pfvasconcellos.eti.br/blog/feed/

Agora, se você quiser personalizar sua assinatura, escolhendo assuntos específicos, visite o novo site. Se sobrar um tempinho, me envie críticas e sugestões sobre ele, ok?

Certo de sua compreensão agradeço.

Paulo Vasconcellos

finito 4.0

2008-01-16T18:21:00.000-02:00

Finito! Já está no ar a 4ª versão do finito:

Ok. Como é impossível testar todas as funcionalidades, vou falar que se trata de uma versão beta. Mas, por favor, atualizem seus bookmarks e leitores de feeds. Para os primeiros, vale apenas para quem armazena diretamente o endereço do blog (finito-log.blogspot.com). Quem utilizava meu endereço oficial (pfvasconcellos.eti.br) não precisa mudar nada.

Já em relação aos feeds... Mudou tudo. Agora o finito oferece feeds para assuntos específicos. E também para a agenda de eventos (presentinho para o pessoal do RH, hehe). Porém, depois de uma semana, vou alterar o feed gerado pelo Feedburner. Assim não perco assinantes (nem o histórico).

O conteúdo é praticamente o mesmo deste site velhinho. Também portei todos os posts. E aproveitei o momento para organizá-los nas novas categorias. Ficou mais fácil navegar por todo o histórico.

Agora alguns comentários sobre a nova plataforma: o Wordpress é a 8ª maravilha do universo do software livre! Quanta flexibilidade! Quanta estabilidade! PHP+MySQL, infra do produto, é uma combinação e tanto. Ok, estou uma década atrasado. Mas não poderia deixar de manifestar minha imensa satisfação. O último gelo na barriga era a importação do conteúdo que está aqui no Blogger. Pois bem: em menos de 10 minutos, estava tudo lá. Artigos e comentários. Sem um único probleminha!

Pronto. Agora baixando a bola. Alguns bugs conhecidos (no finito, não no Wordpress):

Os posts estão com um rodapé indevido, com uma licença Creative Commons para cada um. Será removido (quando sobrar tempo).
Pra variar, o site não vai funcionar muito bem no MS Internet Explorer. Mas a Microsoft prometeu que vai respeitar padrões no IE8. Oremos!
Alguns caracteres da língua portuguesa não serão respeitados nas duas barras laterais.
Os links para posts do próprio finito ainda remetem para o velho blog. Terei que editar todos os posts, um por um. Ou então me aventurar um pouco mais e escrever um "find-replace" em PHP. Peraí... deve existir algum plugin, hehe...
O Wordpress, espertinho, não importou as imagens. Manteve-as nos servidores da Google. Sem problemas, não vou excluir este blog tão cedo. Explico: o mecanismo de buscas Google levou um tempão para indexar e classificar estas páginas. Não vou jogar fora tão valioso ativo, né?

Bom, isso aí é o que sei até agora. Com certeza você pode encontrar outros probleminhas. Temo que apareçam, principalmente, na parte de comentários e emails. Por favor, me avise sobre qualquer problema que você encontrar, ok? Serei imensamente grato. Sugestões e críticas também serão muito benvindas.

.:.

FAN no Sul, Modelagem de Negócios e outras novas [Atualizado]

2008-01-14T10:05:00.000-02:00

Atualização em 15/jan: Link que faltava para o evento "Análise e Modelagem de Negócios".

Antes de mais nada: que 2008 seja um ano muito jóia para todos, cheio de realizações. E, principalmente, de muita paz e saúde.

Em 2008, finalmente, o FAN (Formação de Analistas de Negócios) começa a ultrapassar as fronteiras de São Paulo. RJ e PA* estão na mira, mas a "estréia" acontecerá na Região Sul, mais precisamente na belíssima Florianópolis.

A colega, promotora e organizadora, será a Innovit. E o evento chegará em seu formato completo, ou seja, dividido em dois módulos. O primeiro é "Análise e Modelagem de Negócios", programado para o dia 29/fev.

No dia 28/mar (um dia após o lançamento oficial do livro) acontece o "Engenharia de Requisitos". Floripa receberá o novo formato do FAN, desenhado para ser extremamente prático. As oficinas (conhecidas como 'workshops' antes daquela proposta do deputado) são compostas assim: 50% de teoria e 50% de exercícios. Os ares de Floripa farão muito bem ao conteúdo. Espero retribuir da melhor maneira possível.

.:.

Mas Sampa segue Sampa e, claro, eu sigo por lá. No próximo dia 31/jan acontece a 2ª turma da oficina "Engenharia de Requisitos". Via Tempo Real Eventos, como sempre.

E a estréia da oficina "Análise e Modelagem de Negócios" ocorrerá em São Paulo, dia 26/fev.

Como a turma que passeia por aqui já sabe, esta é a parte mais "polêmica" da Formação de Analistas de Negócios. Há aqueles que pregam que essa atividade ocorra ANTES de um projeto de TI. E, mais ainda, que não seja uma responsabilidade da área de TI. Procuro mostrar neste evento que não é bem assim. E traço o limite que separa a Análise e Modelagem de Negócios de iniciativas de reengenharia e afins. O objetivo aqui, para dizer de maneira bem resumida, é a compreensão do problema, o entendimento do negócio. O programa do evento está nesta página.

.:.

Bye Bye, Blogger

Pois é, este é o penúltimo post do finito neste espaço. Passou da hora dele ter um espaço um pouco mais "nobre". E bem mais rico. Estou maravilhado pelo Wordpress e portando todo o blog para um domínio próprio. Todo o histório de quase 4 anos será transportado para lá. Mas eu não desativarei este endereço tão cedo. Acontece que o Google favorece seus endereços em alguns casos. Mas.. penúltimo? Sim. O último será a comunicação dos novos endereços. Novos? Pois é, terei variações de feeds RSS por assunto (categoria). Por isso serão vários endereços. Mas prometo uma transição tranquila.

.:.

* Região Sul, Rio, Pará. Gostaria muito de descobrir também um parceiro no nordeste. No próximo dia 31, por exemplo, terei um participante da Microsoft de Recife! Pô, ele gastará mais com avião e estadia do que com o evento.

Mas, o que mais me chateia é a confirmação de que "santo de casa não faz milagre". Não tenho nada programado para minha querida terra natal, Minas! E olha que, tirando São Paulo, é o estado que mais participa dos eventos. Já tive gente de BH, Uberlândia, Lavras, Santa Rita do Sapucaí e Alfenas nos eventos. Pena, mas seguirei procurando um bom parceiro mineiro.

.:.

EPBE: Processos de Negócio

2007-12-20T09:41:00.000-02:00

3ª parte da série sobre EPBE (Eriksson-Penker Business Extensions). A série começou com "EPBE: Introdução" e seguiu com "EPBE: O Negócio e sua Estrutura". Para um melhor aproveitamento do artigo, talvez seja interessante a leitura de outro pequeno artigo: "Processos de Negócio: São Todos Iguais?". Eles não são (iguais), e cada um pode demandar estudos e modelos bastante diferentes. Ao contrário do que ocorre em algumas proposições, como BPMN por exemplo, a EPBE oferece toda a flexibilidade necessária para a correta e completa modelagem de processos de negócios.

.:.

A visão dos processos de negócio é a mais complexa das 4 visões propostas na EPBE. É aquela que demandará mais trabalho do Analista de Negócios (AN). Claro, ela é o núcleo da modelagem de negócios. No artigo anterior foram apresentadas a visão do negócio e a visão da estrutura. Ao modelar processos, damos sentido para aquelas vistas, explicando como os recursos (visão da estrutura) são consumidos, utilizados e gerados para satisfazer os objetivos do negócio (visão do negócio).

Na EPBE, utilizamos um Diagrama de Processo para a representação básica de um processo. Veja a imagem acima: trata-se de uma extensão (um tanto radical) do diagrama de atividades da UML. Indicamos nele todos os principais recursos utilizados ou gerados, diferenciando-os através de estereótipos (Info, Físico, Pessoa). Se a visão da estrutura foi corretamente desenvolvida (em uma ferramenta CASE), todos os recursos estão disponíveis na forma de "classes". Ou seja, ao elaborar o diagrama acima, o AN simplesmente "arrasta" para o diagrama todos os recursos consumidos, utilizados ou gerados por um determinado processo.

Há outro estereótipo no gráfico acima: Objetivo. São informações que foram obtidas no desenvolvimento da visão do negócio. Todo processo, por definição, possui (ou deveria possuir) objetivos bem claros. Mas, neste ponto, podemos ser mais específicos. Como sugerido anteriormente, podemos atrelar ao processo metas, indicadores e iniciativas planejadas na elaboração de Balanced Scorecards e Mapas Estratégicos. Ao formalizá-las em um diagrama de processos, o AN está registrando os primeiros requisitos de um projeto, por exemplo.

Se o projeto exigiu uma análise mais profunda do processo de negócio, também é neste diagrama que registramos os principais achados. Repare na figura do Processo: 4 atributos representam algumas características básicas de um processo. No exemplo acima, Tempo de Ciclo, Custo, Eficácia e Eficiência. Se o projeto demandar, o AN pode desenvolver um diagrama que retrate a situação atual do processo ("as is") e outro que aponte o cenário desejado ("to be").

No entanto, como aprendemos com Goldratt [1] (depois de vários outros), melhorias locais podem gerar desastrosos efeitos colaterais em outras partes do negócio. Um processo de negócio sempre se relaciona com outros. Por isso, o AN desenvolve mapas que mostram a interação entre processos. São derivações do diagrama acima, que podem inclusive mostrar as áreas envolvidas.

O diagrama acima pode ser utilizado tanto para a elaboração de um grande mapa de processos quanto para o detalhamento de um processo específico. Neste caso, a figura (estereótipo) que representa um processo (o pontiagudo hexágono) é utilizada para representar partes menores do processo, um sub-processo, atividade ou tarefa (dependendo do nível de detalhamento necessário).

.:.

É raro encontrar um processo de negócio que não esteja minimamente amparado por sistemas de informação. Um AN não pode ignorar a influência dos sistemas existentes, mesmo quando um projeto tratar exatamente da substituição destes. Utilizamos então outra variação do diagrama de processos para ilustrar a relação de um processo com os sistemas. Trata-se do Diagrama de Linha de Montagem (Assembly-line):

No exemplo acima estão representados o processo e dois sub-processos (ou atividades, não importa). As "linhas de montagem", representadas por pacotes da linguagem UML, são os sistemas. Os pequenos círculos brancos representam informações fornecidas pelas aplicações. Os círculos escuros são as informações geradas e "gravadas" pelo processo. Assim, de uma maneira bem simples, mostramos como o processo está automatizado atualmente.

Trata-se de um momento muito importante para o AN. Atenção para as elipses entre o processo e as "linhas de montagem". São Casos de Uso. Se estiver executando uma engenharia reversa, por exemplo, o AN começa aqui o desenvolvimento de requisitos.

.:.

Os três diagramas apresentados acima, como tudo na EPBE (e na UML), não são mandatórios. São ferramentas que auxiliam na compreensão dos processos de negócio e dos requisitos de um projeto. Todos eles são, de certa forma, de "alto nível". Ou seja, não representam os detalhes da execução de um processo. O menor bloco de construção de um processo de negócio, sua única parte indivisível, é a tarefa. Vários tipos de projetos exigirão que o AN analise e modele um processo no nível "mais baixo" possível. Para tanto, é difícil fugir do nosso velho e bom fluxograma.

Na EPBE utilizamos o diagrama de atividades tradicional da UML. Se necessário, podemos estendê-lo para fornecer informações coletadas nos diagramas desenvolvidos anteriormente, como metas, recursos específicos (e críticos) etc. Outra alternativa, dependendo do projeto, é a utilização da BPMN. Trata-se do único ponto em que BPMN substitui um diagrama da EPBE.

.:.

Um projeto pode exigir um estudo ainda mais minucioso da dinâmica de uma organização, do comportamento de recursos e / ou processos. Para tanto, o AN lança mão da 4ª e última visão (básica) proposta pela EPBE: A Visão do Comportamento do Negócio. Não está no escopo desta série o detalhamento desta visão. Mas vale a pena citar que entre seus principais diagramas estão: Diagrama de Estado, Diagrama de Seqüência, Diagrama de Comunicação (muito parecidos com os originais da UML) e variações dos diagramas de Processo e Linha de Montagem.

.:.

O principal objetivo desta série, que se encerra aqui, era apresentar o básico da EPBE. Espero que, no mínimo, a adoção da EPBE seja mais debatida. É importante reforçar dois pontos: i) UML já é um padrão de facto para a modelagem de sistemas. Reaproveitar o investimento em ferramentas e treinamento faz muito sentido. Adotar um padrão único para a modelagem do negócio e de sistemas faz mais sentido ainda; ii) BPMN e afins não são suficientes para uma completa e correta modelagem de negócios.

.:.

Notas:

"A Meta" - 2ª Edição, Eliyahu Goldratt e Jeff Cox. Nobel (2002).
Considerei seriamente colocar algumas pitadas de TOC (Teoria das Restrições) em meu trabalho para a formação de AN's. Queria, particularmente, desenvolver algumas extensões para a EPBE. Talvez o cronograma não permita. Mas fica aí o desafio e um requisito do tipo "idéias para implementações futuras".

.:.

EPBE: O Negócio e sua Estrutura

2007-11-29T14:12:00.000-02:00

Finalmente a continuação da série que começou em "EPBE: Introdução". Neste artigo vou apresentar duas das quatro visões propostas: a Visão do Negócio e a Visão da Estrutura. Lembrete importante, não mencionado no capítulo anterior: as 4 visões propostas pela EPBE [1] (Processos e Comportamento completam a lista) são básicas, mas não mandatórias nem fixas. Podemos suprimir alguma, dependendo das necessidades e do projeto. Também podemos criar novas visões, como "Papéis e Objetivos das Pessoas", "Visão dos Efeitos Econômicos", etc. A EPBE, assim como seu alicerce, a UML, é extensível. Por exemplo, veja neste artigo do IEEE (pago), até onde levaram a EPBE.

Como colocado anteriormente, o objetivo desta série é apresentar a EPBE e seus elementos básicos. Quem sabe, num futuro próximo, possamos explorar outros usos e extensões. Hoje vou mostrar um pequeno exemplo. Vou incorporar dois elementos que não existem na EPBE original: Balanced Scorecard e Mapas estratégicos. Eles nos ajudarão a documentar a estratégia da empresa.

.:.

A Visão do Negócio guia a modelagem das outras três visões. Isso porque é nela que aprendemos e registramos quais são os objetivos do negócio. Portanto, a construção da visão do negócio é o ponto de partida do processo de modelagem do negócio. Das 4 visões básicas propostas pela EPBE, esta é a única que não se consolida na forma de diagramas. Na realidade, em alguns casos, criamos apenas um grande modelo conceitual que destaca os principais elementos (ou conceitos) do negócio. Veja o exemplo (rabiscado) abaixo:

Por favor, não espere que o desenho acima derive para um diagrama de classes ou algo do tipo. O AN lança mão dessa ferramenta para facilitar sua compreensão do negócio. E, ao consolidá-la, pode utilizar o mesmo desenho para explicar o negócio para outros interessados. Só (isso tudo).

Crucial no desenvolvimento da visão do negócio é a compreensão de seus objetivos. Na proposta original da EPBE, essa parte principal é registrada na forma de texto. Os principais pontos a destacar são: Missão, Objetivos, Forças, Fraquezas, Oportunidades, Ameaças (obs: as 4 últimas são conhecidas também como matriz SWOT), Fatores Críticos, Estratégias, Competências Principais, Perfis, Unidades de Negócio e Processos-chave. Ao detalhar as estratégias pode ser necessário que também destaquemos: Clientes, Concorrentes, Ambiente, Lucratividade, Potencial de Crescimento e a Percepção que o mercado tem da empresa. O nível de detalhamento deste documento vai depender bastante das necessidades da empresa ou do projeto em questão. Quanto mais estratégico for o projeto, maior a necessidade de um estudo mais minucioso das variáveis listadas acima.

A EPBE não cita, mas eu gosto de completar o estudo acima com duas informações adicionais: a Proposição de Valor da empresa e o seu Modelo Operacional. Dois artigos publicados anteriormente neste espaço apresentam com um pouco mais de detalhes os dois estudos:

Parto do princípio de que 90% dos novos projetos abertos pelas organizações têm um cunho estratégico. É raro vermos hoje em dia projetos que lidem com processos de negócio secundários, como folha de pagamento, contabilidade e afins (que, se não estão terceirizados, já foram devidamente informatizados). Sendo assim, a grande maioria dos projetos está vinculada à alguma iniciativa estratégica. Aqui nasce o alinhamento *estratégico* de TI com o negócio. Compreender e se comprometer com a estratégia do negócio é fundamental para o sucesso do projeto.

Por isso sugiro a incorporação de duas ferramentas que têm se mostrado bastante eficazes na elaboração, execução e acompanhamento das estratégias de negócio: o Balanced Scorecard e seu co-irmão, o Mapa Estratégico [2]. Se a empresa não for usuária destas ferramentas, ou seja, se eles não estiverem disponíveis em sua forma tradicional e "bonitinha"...

... ainda assim, o AN pode desenvolvê-las:

Aliás, mesmo que eles existam em sua forma tradicional, é recomendável a elaboração do diagrama acima, em UML. Ao utilizar uma ferramenta CASE, e não o meu tosco rabisco, o AN ganha a facilidade de vincular objetivos, iniciativas e indicadores aos processos (como veremos no próximo capítulo desta série).

Minha sugestão não deve ser vista como uma substituição àquela da EPBE original, mas como um complemento. Se ela substitui alguma coisa, é o diagrama "Objetivos/Problemas" proposto por Eriksson e Penker. Trata-se de uma extensão, como prometi no início do artigo. Cabe relembrar outra coisa: a Visão do Negócio servirá como *guia* para o desenvolvimento das outras 3 visões. Veremos agora mais uma delas.

A Visão da Estrutura do Negócio

Quando falamos de Estrutura do Negócio estamos falando de todos os seus Recursos. No capítulo anterior vimos que recurso é tudo o que a empresa utiliza, consome ou produz. Portanto, com esta visão, detalhamos como a empresa organiza seus produtos e serviços, suas informações e também a si mesma, na forma de unidades de negócios, departamentos, cargos etc. Normalmente utilizamos apenas uma variação do tradicional diagrama de classes da UML para representar todos os tipos de recursos. As informações, por exemplo, são representadas em um grande modelo conceitual que lembra muito um tradicional modelo E-R. Aliás, para ser franco, é o mesmo cara.

Já o organograma da empresa pode ser traduzido num diagrama mais ou menos assim:

Estamos falando de documentos que normalmente o AN já encontrará em uma empresa. Portanto, a única justificativa para a sua (re)construção em UML é a facilidade que uma ferramenta CASE pode proporcionar quando o AN entrar na parte "dura" da modelagem de negócios: seus Processos. Assunto do próximo capítulo. Inté.

.:.

Bibliografia:

Business Modeling with UML - Business Patterns at Work
Hans-Erik Eriksson e Magnus Penker. Wiley (2000).
Para quem quiser conhecer o básico sobre Balanced Scorecards e Mapas Estratégicos, recomendo dois títulos:
a) Medindo o Desempenho Empresarial - Harvard Business Review. Campus (2000).
b) Mapas Estratégicos - Robert Kaplan e David Norton. Campus (2004).

.:.

Rendiconti: Dose Dupla

2007-11-14T13:49:00.000-02:00

2.600km em 3 semanas. Tudo via asfalto (e buracos). Nos últimos 15 dias, dois workshops em Sampa: a 4ª turma do FAN (Formação de Analistas de Negócios) e a 1ª turma do 1º filhote do FAN: Engenharia de Requisitos. O cansaço é grande, mas valeu o esforço. Valeu bem mais do que eu esperava.

A 4ª turma do FAN marcou a despedida de um formato. Quando ele voltar, em fevereiro de 2008, será direcionado para coordenadores de projetos e gerentes de TI. A intenção será mostrar a criticidade e importância dos Analistas de Negócios (AN's) em projetos e organizações de TI. Será o primeiro de uma nova série sobre Alinhamento Estratégico. A série será composta de maneira 'bottom-up': começarei dos AN's, passarei por processos de desenvolvimento até chegar em arquitetura corporativa. (Estou pensando alto, mas é meu primeiro plano para 2008).

E a prestação de contas (rendiconti) da 4ª turma (07/nov)? Sem querer, ela serviu como experiência para um novo formato. A turma era menor. As interações foram mais freqüentes e ricas. Aliás, minha grande "derrota" foi a terceira turma. Não consegui criar "liga" com a platéia, e o evento terminou com uma hora de antecedência. Na 4ª, repetindo o mesmíssimo roteiro, o resultado foi consideravelmente superior. O problema com a redução do número de participantes é o custo. E, sinceramente, não queria que esses eventos ficassem caros. Estamos, Tempo Real Eventos e eu, analisando possibilidades.

Uma certeza: a "oficina" de Engenharia de Requisitos merecerá uma 2ª turma já em janeiro, dia 18. O FAN, em 2008, aparecerá como dois eventos "levemente acoplados": Modelagem de Negócios (1ª turma dia 31/jan) e Engenharia de Requisitos. Como no evento de ontem, pelo menos 50% da carga horária será composta de exercícios. Ou seja, "oficina" de verdade.

Não preciso esconder, temia muito pelo evento de ontem. Lotação esgotada, era a primeira aparição pública do "Engenharia de Requisitos". Na quinta-feira da semana passada, retornando para Vga, deu um "estalo" e resolvi remontar todo o evento (que até então pegava carona nos exercícios que eu havia elaborado para o curso completo de Formação de Analistas de Negócios). Minha preocupação: o negócio e respectivo projeto-exemplo eram relativamente complexos. Eu temia que tal complexidade desviasse o foco de meu principal objetivo: reforçar conceitos, práticas e métodos que formam a Engenharia de Requisitos. Passei sexta e sábado remontando praticamente metade dos 120 slides do evento.

Para minha satisfação, o workshop foi um grande sucesso. O que não significa que foi perfeito. Três participantes reclamaram a não execução integral do roteiro que estava no site do evento. Na revisão, acabei reforçando os exercícios em detrimento de algumas partes exclusivamente teóricas. Mas, na conta final, os participantes gostaram muito. Os exercícios, simulando entrevistas, workshops, sessões de brainstorming e a elaboração de casos de uso, se provaram bem legais. Eficazes no reforço de conceitos e práticas. Em outro post (que só virá depois que eu pagar uma certa dívida com a série sobre EPBE) comentarei um "acidente" que enriqueceu demais a "oficina". No meio do acidente, perdidos numa imensa nuvem de fatos, idéias e requisitos, um participante concluiu: "Isso acontece em todo projeto!". Sem perder muito tempo, vimos como é possível "domar" o projeto mesmo naquela fase mais "selvagem". Mesmo em projetos que requerem muita "selvageria" (aka Criatividade). Mas, como eu disse, é assunto para outro post.

Para a realização do workshop pedi o reforço de 5 "monitores": pessoas que haviam participado de turmas do FAN e que me ajudariam nos exercícios. A turma foi dividida em 5 grupos. O evento não teria o mesmo resultado não fosse a imensa colaboração de Celso Cândido, Jean Streleski, Nilton Nakate, Rafael Kiss e Reinaldo de Oliveira Castro. Registro aqui meu sincero agradecimento. Devo agradecer também toda a turma que participou. O nível era excelente, o que ficou evidente logo nas primeiras discussões. Eles enriquecem demais os eventos relatando suas experiências, dores e necessidades.

Portanto, nesta reta final para a liberação de todo o material desenvolvido para a Formação de Analistas de Negócios, só tenho uma coisa a lamentar: a não realização do curso de Modelagem de Negócios que estava previsto para o início de novembro. Como eu não seria nada honesto se 'podasse' o material, fazendo com que o curso tivesse uma carga horário menor que 35 horas (70 no total, considerando o módulo II sobre Engenharia de Requisitos), tenho que rever a oferta. Realizá-lo aos sábados? Oferecer como treinamento remoto? Sinceramente, ainda não descobri o melhor formato. Mas, tenho certeza, ele sairá ainda no início de 2008.

.:.

E ainda não fechei a agenda de 2007 para os eventos gratuitos em escolas, faculdades (públicas ou privadas) e entidades sem fin$. Para minha felicidade, talvez eu finalmente consiga promover um deles em minha terra natal, Minas. Mais precisamente em Lavras (UFLA). Tô torcendo muito por isso. Outra oportunidade é São Carlos. Estou torcendo para o Reinaldo achar uma data. Final de ano é difícil, mas estamos brigando para viabilizar outras viagens do FAN. Mais 2 mil e tantos kilômetros de asfalto farão muito bem para o conteúdo.

.:.

EPBE: Introdução

2007-10-25T10:14:00.000-02:00

Chororô só não basta. E não dá para esperar que todo mundo com um mínimo de curiosidade compre o único livro* que documenta a EPBE (Eriksson-Penker Business Extensions) ou participe dos meus eventos. Então, começo agora uma pequena série com um objetivo muito simples: explicar o básico da EPBE e compará-la com outras propostas.

.:.

A EPBE (Eriksson-Penker Business Extensions), como o nome indica, foi desenvolvida por Hans-Erik Eriksson e Magnus Penker. Foi apresentada no ano 2000, no livro "Business Modeling with UML - Business Patterns at Work". Como o título indica, o livro tem objetivos bem maiores. Mas a compreensão da EPBE está em seu núcleo. Mas o que é, afinal, a EPBE?

A EPBE é uma extensão da UML (Unified Modeling Language). Foi desenhada para possibilitar o uso da UML na modelagem de negócios. A UML é extensível, e várias outras especializações existem: sistemas Web, modelagem de bases de dados, sistemas embarcados etc. Estendemos a UML através de três elementos: estereótipos (stereotypes), valores nomeados (tagged values) e restrições (constraints). Quando uma organização ou equipe faz um uso maduro da UML, ela cria suas próprias extensões. Evita-se a "reinvenção da roda" quando se parte de uma extensão existente, como a EPBE, por exemplo.

Mas a EPBE "reinventou a roda", não? Afinal, no ano 2000, já existiam diversos padrões de notação para a modelagem de negócios. A justificativa para sua criação é exatamente essa: existiam diversos padrões - o que é o mesmo que dizer que não existia padrão nenhum. A mesma razão, em outro domínio, motivou Grady Booch, Ivar Jacobson e James Rumbaugh a criarem a UML. E por que utilizar a UML como base para a modelagem de negócios?

Segundo os criadores da EPBE, a primeira motivação são os "conceitos similares: um negócio pode ser descrito em termos de processos que satisfazem objetivos através da colaboração de diferentes tipos de recursos. Regras definem condições e restrições sobre como os processos e recursos devem se relacionar e como devem se comportar. Tudo isso pode ser mapeado em objetos, relacionamentos e interações entre objetos" [1].

Outras razões apontadas por Eriksson e Penker são: i) a maturidade da UML (e da orientação a objetos); ii) a notação padrão (de facto); iii) o aprendizado rápido; e, iv) a nova e fácil maneira de ver a organização e o negócio. Vale reforçar a motivação descrita no parágrafo anterior com outra leitura: negócio e TI teriam uma mesma linguagem padrão de modelagem. Os benefícios são óbvios.

Do mesmo parágrafo podemos extrair os 4 elementos fundamentais que utilizamos para descrever qualquer negócio:

Recursos: é tudo o que a empresa utiliza, consome ou produz. São as pessoas, materiais, informações e produtos. Recursos são manipulados através de processos, ou os manipulam e gerenciam. E são classificados como: físicos, abstratos e de informação.
Para ficar um pouco mais claro: uma nota fiscal é um recurso abstrato, assim como uma ordem de compra ou um "bilhete azul". Quando uma nota fiscal é registrada em uma base de dados, por exemplo, torna-se um recurso de informação.
Processos: são as atividades realizadas pelo negócio. Eles descrevem como o trabalho é executado na empresa, e são delimitados por regras.
Regras: são as definições ou restrições de algum aspecto do negócio. Regras determinam como um negócio deve ser gerenciado ou como os recursos devem ser estruturados e utilizados. Elas podem ser criadas pela própria empresa ou são impostas por entidades externas (governo, associações, sindicatos etc).
Objetivos: representam a razão da empresa, ou os resultados que o negócio espera atingir. Objetivos podem ser divididos e distribuídos entre os diversos processos da empresa. Objetivos expressam o estado desejado de determinados recursos (caixa, estoque, market share - por exemplo), e são atingidos através dos processos. O conjunto dos objetivos de alto nível forma a estratégia da empresa.

A lista acima pode ser resumida da seguinte forma: Os objetivos do negócio são atingidos através da execução de processos que usam, transformam e geram recursos, sempre respeitando e seguindo um conjunto de regras. O diagrama ao lado representa esta lógica.

Para entender e aceitar a EPBE, além de compreender os elementos fundamentais descritos acima, é necessário entender o que é a Modelagem de Negócios e para que ela serve. Modelamos um negócio com o objetivo de simplificá-lo. Criamos abstrações ou analogias de uma forma que facilite a compreensão, a documentação e a comunicação de todos os aspectos principais de um negócio. Nós modelamos um negócio para:

Fornecer uma base que apóie a criação de sistemas de informação;
Criar um ponto de partida para iniciativas de melhoria da estrutura e dos processos de negócio;
Experimentar novos conceitos e desenhos;
Identificar oportunidades de outsourcing; e
Facilitar a integração com entidades externas.

Tratando especificamente de projetos de sistemas de informação, podemos dizer que a modelagem de negócios também serve para [2]:

Entender a estrutura e a dinâmica da organização;
Compreender os problemas da organização e identificar oportunidades de melhoria;
Garantir que clientes, usuários e desenvolvedores compartilham uma mesma visão do negócio; e
Extrair requisitos do sistema.

Do que consiste um modelo de negócio? Ele é formado por três partes principais:

Visões: é impossível descrever completamente um negócio sob um único ponto de vista. Existem quatro categorias de visões: Visão do Negócio, Visão dos Processos, Visão da Estrutura e Visão do Comportamento.
Obs.: nas próximas partes desta série as visões serão apresentadas de forma mais detalhada.
Diagramas: toda visão é representada por um ou mais diagramas, que representam partes específicas da estrutura ou da dinâmica do negócio. Diagramas são compostos por objetos e processos.
Objetos e Processos: Objetos representam todos os recursos, enquanto os processos representam qualquer atividade ou função executada no negócio.

.:.

A mensagem mais importante até aqui é a seguinte: Modelar é Simplificar. Modelamos um negócio para facilitar sua compreensão, entender seus problemas correntes e identificar oportunidades de melhoria. Em projetos de sistemas de informação, a modelagem de negócio é lançada para municiar da melhor forma possível a equipe que criará a solução. A EPBE é "só" um padrão de notação. É diferente de outras propostas porque: i) Usa o mesmo padrão dos sistemas, a UML; e, ii) É completa.

A EPBE não é um processo ou metodologia nem pretende sê-lo; O uso da EPBE não implica necessariamente em BDUF (big design up front) ou na utilização de processos "waterfall"; A EPBE não concorre com BPMN e afins - na realidade estes podem ser utilizados como um sub-conjunto da EPBE.

No próximo artigo veremos como a EPBE descreve a Estrutura de um negócio. E no seguinte, como ela é utilizada para modelar Processos de negócio.

.:.

Bibliografia:

Business Modeling with UML - Business Patterns at Work
Hans-Erik Eriksson e Magnus Penker. Wiley (2000).
The Rational Unified Process - An Introduction (2nd Edition)
Philippe Kruchten. Addison-Wesley (2000).

Observação:

* - Para não cometer uma total injustiça: o livro "UML 2.0 - Do Requisito à Solução", de Adilson da Silva Lima, tem um capítulo inteiro dedicado à EPBE. Pelo que sei, é o único em língua portuguesa que toca no assunto. Se tudo der certo, ele perderá o monopólio em março de 2008, quando meu livro deve chegar em algumas prateleiras. Eu disse lá em cima que o livro de Eriksson e Penker é o único porque o Adilson limita-se, como eu aqui nesta série de artigos, a dar um overview da EPBE. Ou seja: EPBE na íntegra, só no original.

.:.

EPBE: Quem usa?

2007-10-23T18:03:00.000-02:00

Desde a semana passada estou envolvido em debates sobre a EPBE (Eriksson-Penker Business Extensions), uma extensão da UML para modelagem de negócios. O provocador das discussões foi o mesmo, José Augusto Agnello. O primeiro debate, no grupo UML-BR, começou com BUC's (Business Use-Cases). Já no grupo BPM o Agnello foi direto: alguém usa? Como ela se compara com BPMN?

Sem querer o Agnello me possibilitou duas coisas: validar a recepção dos AN's e da EPBE em um grupo "pesado", o UML-BR. Poder debater e trocar idéias com José Paulo Papo, MTierno, Juan Bernabó, Rodrigo Yoshima e outros é sempre enriquecedor. O outro "brinde" veio hoje: a "desconfiança" de que ninguém utiliza a EPBE. O grupo BPM tem 500 e poucos participantes. Há duas horas eu só penso nisso.

Caramba, baseei boa parte do meu trabalho para formação de analistas de negócios na EPBE e nos conceitos apresentados por seus idealizadores, Hans-Erik Eriksson e Magnus Penker, no livro "Business Modeling with UML". Nessa altura do campeonato, na reta final e de certa forma cansado do tema, a última coisa que eu preciso é de dúvidas sobre uma das partes principais de minha "tese". Não estou falando das dúvidas e críticas dos outros. Estou falando que eu não posso duvidar de minhas sugestões. Mas, no cansaço e com um probleminha chato nas costas, confesso que hesitei por alguns minutos: "caramba, ninguém usa isso!".

Me lembrei que já passei por isso antes. No final de 98, por exemplo, quando falava que ia utilizar UML em um grande projeto, um monte de gente me olhou com cara de interrogação, tipo: "que p**** é essa?". Dali até os primeiros diagramas de seqüência com algum sentido passou um certo tempo. Dali até uma certa aceitação da UML foi outro tanto de tempo. Mês que vem a UML completará 10 anos de existência. Sob um prisma - caramba, é uma linguagem! - ela é muito nova. Por outro - pô, informática! - ela é velha. Mas a EPBE é do ano 2000. E parece não ter aceitação nenhuma*! O que pode estar errado?

Richard Lingner, em sua participação na thread do BPM, apresentou algumas razões: "a EPBE não é mantida pelo OMG e também não é difundida ou suportada por empresas e ferramentas". Seria outro caso de uma boa idéia carente de um bom marketing.

Mas quem a considera uma boa idéia? Definitivamente, eu não estou sozinho. Vejam, por exemplo, as avaliações que os leitores do livro "Business Modeling with UML" no site da Amazon. Surrupiarei alguns trechos:

"The 'Eriksson-Penker extensions for business modelling' are important because several UML-based case tools have now implemented them as an emerging standard for business process modelling with UML. If you want to fully understand how these work, this is the book to read."
- A.K. Johnston

"Sometime ago I have been wondering if somebody will try to bridge the gap between business modeling (the one used by consultants) and software engineering. It would certainly make it easier for people to understand and explain business operations. This book is an application of the UML into the realm of business modeling. It is very good in the sense that it explains and goes through the patterns that form business models."
- J. Chong

Claro, tem também algumas críticas negativas (ao livro). Mas sua média é 4 estrelas! As avaliações que citei são de 2003 e 2000, respectivamente. E, sabe-se lá a razão, parece que pouquíssimos conhecem a EPBE.

Suspeito que o buraco é mais embaixo. Como eu disse no post anterior, a análise e modelagem de negócios é a disciplina mais ignorada em nossos projetos. E quando ela aparece, em modelos RUP-like, é meio capenga**. Se a disciplina é negligenciada, o que esperar das ferramentas que devem suportá-la? Correndo o risco de ser (muito) chato, vou reforçar minha suspeita: currículos, processos e metodologias dão atenção desproporcional para o domínio da solução; Parecemos adorar "analistas-programadores"; Esquecemos que sem o correto domínio do problema podemos gerar falsas e caras soluções.

Essa questão me preocupa bem mais que a aceitação ou não da EPBE. A EPBE é só uma extensão de uma linguagem. É só uma ferramenta. Ferramentas passam. Mas eu acho que o OMG e todos os fornecedores de ferramentas CASE que ignoram a EPBE estão perdendo uma bela oportunidade. O OMG, por exemplo, poderia incorporar a extensão e adicionar a opção BPMN à ela. Reforçariam assim a UML, expandindo consideravelmente o seu público. Sendo chato (de novo!), reforço as motivações para sua utilização:

UML já é uma linguagem madura e consolidada;
Utilizada amplamente no domínio da solução;
Por que não utilizá-la também para a modelagem do problema?
Assim, TI e negócio teriam pela primeira vez em sua história uma mesma língua - mesmo que ela seja "só" para modelagem.

Pronto, minhas dúvidas já se dissiparam. E as suas?

.:.

Observações:

* Os workshops para formação de analistas de negócios já contaram com mais de 150 participantes. A EPBE é apresentada neles, mas de forma breve. Então, só depois do treinamento que ocorre agora em novembro poderei dizer se a EPBE ganhou novos adeptos.

** Adjetivos pouco nobres (como o "capenga" acima) vivem me criando problemas. Um dia foram as "bullshitagenzinhas ágeis". Hoje foi o BPMN "bonitinho". Não adianta, não me livro deles. Não acho sinônimos que passem exatamente o que quero expressar naquele momento. Até me arrependo depois. Mas, na hora - na lata, não edito não. Também não edito depois, a menos que alguém se diga ofendido. Nunca aconteceu.

No UML-BR, "brigando" com o MT na questão "BUC's X EPBE", eu usei "fraquinho" no lugar do "capenga". É a mesma coisa. Fica feio do mesmo jeito. Peço desculpas.

Mas aqui cabe uma explicação: sou fã do Jacobson. Seu "The Object Advantage - Business Process Reengineering with Object Technology" é fonte frequente de consulta para desenvolvimento do meu material. Mas, definitivamente, casos de uso de negócio e modelos de objetos de negócio não são ferramentas legais para a análise e modelagem de negócios. Probleminha básico: assim como a BPMN, são incompletos. A arquitetura de um negócio é descrita em quatro visões: Negócio, Estrutura, Processos e Comportamento. Qualquer proposição que vise a análise e modelagem de negócios deve cobrir as 4 visões. Ponto.

.:.

Dica levemente acoplada: não percam o artigo de hoje do Philip "Shoes" Calçado, no Fragmental.

.:.

Quem Paga a Dolorosa?

2007-10-18T10:46:00.000-02:00

O negócio não interessa. O que interessa, isso sim, são os maravilhosos badulaques, frameworks, caixinhas-caixões e código. Adoramos esquecer que, no final das contas, quem 'morre com a dolorosa' é o tal do negócio. Há mais de uma década o Gartner estampa no Top 5 das preocupações dos CIO's: "Alinhamento Estratégico". Perdemos o novelo ou o papo sobre alinhamento não é sério?

É claro que é sério. Na maioria das empresas é. O problema é mudar uma cultura de décadas de "cara-caixa-preta". Não são poucos os exemplos de modelos, processos e metodologias que colocam TI como um fim e não um meio. Não por acaso, a Análise e Modelagem de Negócios é a disciplina mais ignorada em projetos de TI, particularmente em iniciativas para desenvolvimento ou implantação de sistemas. É comum que a Modelagem de Negócios seja vista como papo furado, desperdício ou algo do tipo.

.:.

A edição 903 da revista Exame (10/out/2007) apresenta uma série de artigos especiais. Mostra como o Brasil mudou nos últimos 40 anos. Alguns números são tão espetaculares que nos fazem questionar essa eterna mania de achar que tudo por aqui está ou dá errado. Ops... o assunto mudou ou o editor viajou? Não.

Pense nas empresas que estão aí há 40, 20 ou 10 anos. Como elas passam por tantas ondas de mudanças? Processos de negócio envelhecem e adoecem. Quando o mesmo ocorre com recursos da empresa, máquinas por exemplo, eles são trocados. E o que acontece com os processos de negócio?

Em grande parte das vezes eles são ajustados ou remendados. Várias empresas optaram pela implantação de ERP's - grandes sistemas corporativos que em seu conceito original propunham a adoção de novos processos. Grande parte dos problemas com a adoção desse tipo de solução acontece exatamente na diferença entre processos existentes e os novos desenhos.

Mas a questão está longe de ser uma exclusividade das empresas mais velhas. Mesmo empresas muito novas convivem diariamente com a pressão por mudanças em parte de seus processos de negócio. A demanda ocorre, particularmente, nos processos primários - aqueles que lidam diretamente com o mundo exterior, com os clientes.

Processos ultrapassam as fronteiras de uma organização. Para frente, na direção dos clientes, e para os outros lados, no sentido dos fornecedores e parceiros de negócios. Na economia atual, têm nítida vantagem as empresas que oferecem processos abertos e flexíveis. Então, testemunhamos o surgimento de propostas muito boas para a realização dos requisitos de abertura e flexibilidade, notadamente SOA (Arquitetura Orientada a Serviços) e BPM (Gerenciamento de Processos de Negócio).

Mas, como quase sempre ocorre em TI, caixinhas e ferramentas monopolizam discursos, press-releases e budgets. Passa desapercebido o fato de que processos remendados, velhos e doentes seguirão remendados, velhos e doentes numa SOA ou sob os cuidados de um BPMS. É muito velha a máxima que diz que "engessamos processos equivocados". Tão antiga quanto nossa teimosia em ignorá-la.

.:.

A Análise e Modelagem de Negócios, uma das duas macro-disciplinas que formam o corpo de conhecimentos dos Analistas de Negócios (AN's), está longe de ser papo-furado ou desperdício. Na realidade, quando bem executada, pode ser a diferença entre um projeto de sucesso e o total fracasso.

A correta compreensão dos requisitos do negócio - seus objetivos e as metas específicas de seus processos - possibilita que projeto e produto tenham um horizonte e escopo bem definidos. Por isso a modelagem de negócios é bem mais que o mapeamento de processos. Ela pode compreender o estudo da estratégia da empresa, suas oportunidades e limitações, estrutura e relações.

O que não pode significar, de maneira alguma, que projetos de TI devem ficar 'congelados' por um bom tempo, aguardando a realização da tal Modelagem do Negócio. Trata-se de um mito bastante comum que acompanha a disciplina. Uma primeira visão, a primeira iteração, pode demandar apenas alguns dias. E ela ocorre de forma simultânea com sua co-irmã, a Engenharia de Requisitos (a outra macro-disciplina que forma BoK do Analista de Negócios, aquela que mereceu maior atenção do BABoK).

Ao incorporar práticas de Análise e Modelagem de Negócios em seus processos para desenvolvimento ou implantação de sistemas de informação, a organização fortalece equipes e projetos. Indica que está falando sério quando fala em alinhamento estratégico. Entende que o negócio é tudo o que importa. Afinal, quem paga a dolorosa?

.:.

Modelagem de Negócios é o primeiro módulo do curso para Formação de Analistas de Negócios, que o finito realizará em conjunto com a Tempo Real Eventos. Conheça mais detalhes sobre o curso, e veja aqui o seu conteúdo programático.

.:.

O Último Sprint

2007-10-04T13:13:00.000-03:00

Como eu disse no último post, começo agora o último sprint do processo de redação do livro "É o Negócio, Beócio!". De acordo com o cronograma, no dia 31/dez entrego os originais para a gráfica. Como previsto, preciso aumentar o número de stakeholders-colaboradores. Por isso a agenda de eventos ganha outras datas, novas praças e novos formatos.

Para o dia 7 de novembro (quarta-feira) está programada a 4ª edição do FAN - Formação de Analistas de Negócios - em seu formato tradicional. Quarta edição em Sampa, novamente no Centro de Convenções Pompéia. Provavelmente será a última turma do ano em terras paulistas.

A turma da região Sul terá outra oportunidade. A Innovit promoverá uma turma do FAN em Floripa-SC, no dia 5 de dezembro (quarta-feira). Provavelmente o workshop será encaixado em um evento maior. Com desconto para a estudantada e tudo o mais. Em breve divulgo maiores detalhes.

Antes dele, brotará em Sampa o primeiro filhote do FAN: um workshop sobre Engenharia de Requisitos, também promovido pela Tempo Real Eventos. Está agendado para o dia 13 de novembro (terça-feira), no Centro de Convenções Pompéia. Engenharia de Requisitos ocupa 50% do material de Formação de Analistas de Negócios. Mereceu um workshop exclusivo para que a disciplina seja explorada com maior profundidade (uma antiga solicitação). Será repleto de exercícios de desenvolvimento e gerenciamento de requisitos. Simulações de entrevistas, workshops e sessões de brainstorming estão previstas. A confecção de casos de uso e documentos auxiliares também. Os participantes terão a chance de usar vários "bonés" durante o evento: Analistas de Negócios (claro!), usuários, desenvolvedores, coordenadores... O workshop deve ser encerrado com a elaboração de um belo, memorável, objetivo e "vendedor" Documento de Visão.

Mas a parte prática da outra metade do FAN, a Análise e Modelagem de Negócios, não foi esquecida. Ainda em novembro, também em Sampa, acontecerá um treinamento de 35 horas (!). Imersão total nesta disciplina que é tão negligenciada em projetos. Maiores detalhes sobre o treinamento eu divulgarei em breve. Mas anote aí na agenda: será em novembro (apesar dos 3 feriados!).

.:.

Apesar da agenda meio lotada, segue disponível a oferta de levar qualquer variação dos eventos acima para escolas, faculdades e universidades. Vascão* (ou seja: na faixa, grátis, zero800...). Quem se interessar, por favor, fale comigo.

* Depende da localidade e de não causar nenhum tipo de prejuízo para outros profissionais ou empresas.

.:.

Rendiconti: FAN - 3ª Turma + Anhembi Morumbi

2007-09-29T12:19:00.000-03:00

FAN = Formação de Analistas de Negócios.

Na última quinta (27) rolou a terceira turma do workshop promovido pela Tempo Real Eventos. Incrível como as 3 edições foram muito diferentes. Na primeira acertamos na mosca (a duração). Como era a primeira execução, foi sorte pura (e um cadinho de administração do tempo). Aí pintou a síndrome da 2ª vez: atrasei em 30 minutos seu encerramento. Mesmo assim, para a 3ª turma, coloquei uns 20 slides adicionais. Surpresa: o workshop terminou 1 hora antes do previsto!!

A explicação mais óbvia foi a seguinte: um número menor de interações com a platéia. Teve menos debate, o que torna o evento um cadinho mais pobre. E a responsabilidade é só minha. A platéia, só para variar, era muito boa (sem demagogia, please! Se eu pudesse revelar o perfil das pessoas e empresas participantes...)

A maior reclamação nas fichas de avaliação foi a de sempre: profundidade. Realmente é muito assunto para apenas 1 dia (7 horas). Como sobrou uma hora, eu poderia ter mergulhado mais em algum assunto. Mas qual? Desta vez "Casos de Uso" foi o tema que mereceu mais tempo. Ganhou alguns slides a mais também. Depois do evento (ah, se houvesse prorrogação!), caiu uma ficha: parte do debate (sobre casos de uso) aconteceu porque ainda há uma certa confusão entre requisitos e especificações. Ainda é difícil entender que "caso de uso" é um meio, não um fim. De novo: falha minha. Mas acho que já descobri o caminho das pedras. E vou usar um "liquidificador" para triturá-las. Em um futuro artigo eu explico.

.:.

Aproveitando uma oferta que fiz aqui no finito, aconteceu ontem (sex, 28) uma palestra para uma turma da Anhembi-Morumbi (Vila Olímpia). Deveria ser só uma versão "diet" do workshop, com 1h30 de duração. Não passei da 1ª parte, apresentando apenas o perfil, habilidades e responsabilidades do Analista de Negócios. Mas foi muito jóia. É uma experiência muito diferente. O prisma da estudantada é diferente daquele público que participa dos workshops. Daí minha oferta: espero atender parte das expectativas de estudantes e professores no livro. Uma bela parte, diga-se de passagem.

A grande maioria da turma já trabalha (em TI, claro). Tem gente na Tata e na EDS.. Mas, ainda assim, o prisma e as necessidades deles são um tanto distintas. Assim como a interação. Há um certo ceticismo e até uma certa agressividade (palestra na 6ª é barra, né?). Mas foi muito divertido. Não dispensei nem o tradicional arremesso de giz (que carimbou o note de um dos rebeldes).

Espero que parte da turma ingresse no grupo de discussão. Quero ver o caldo que dá.

.:.

Aliás, se você quer conhecer melhor o trabalho FAN, o conteúdo elaborado e também participar do grupo de discussão, fale comigo.

Começo agora o sprint final: 90 dias para encerrar a redação do livro. Ainda acontecerão, no mínimo, 2 workshops e 1 curso. E todo apoio será muito bem vindo.

.:.

Repensando o Papel do Analista de Negócios

2007-09-21T12:32:00.000-03:00

Mas já? Pois é, como o papel do Analista de Negócios (AN) ainda é relativamente mal definido, não faria mais sentido "pensá-lo"? Acontece que, apesar das incertezas, não estamos falando de nada novo. Li em algum lugar (perdão.. faltará o link-lembrança) que nos EUA já existem mais de 600 mil AN's! Não tenho como validar o número. Me limito a confrontá-lo com o número de AN's certificados pelo IIBA: 70. Isso mesmo, só setenta! Mas quem propõe a revisão é Scott Ambler, que participou da revisão da versão 1.6 do BABoK. Entre o pensar e o repensar, vou aproveitar a oportunidade para comentar o artigo do Scott Ambler.

Para começar, a forma muito legal que o Ambler apresenta o AN:

Na teoria, a idéia de ter AN's tradicionais envolvidos em um projeto deve funcionar muito bem, e na prática isso frequentemente acontece. Os melhores analistas são organizados e grandes comunicadores, têm a habilidade de destacar as informações críticas fornecidas pelos stakeholders do meio de toda aquela "poluição informativa" - lançando mão de várias técnicas de modelagem. Para muitas organizações a adição de AN's claramente aumentou a qualidade dos requisitos e modelos. E também abriu um canal de comunicação entre os "tech weenies" de TI e os "business morons" para os quais o sistema é construído.

Jóia né? Mas aí apareceram os "poréns". Comento abaixo cada um deles, na seqüência original:

AN's não apresentam as habilidades corretas
pv: Natural, afinal ainda não temos um mínimo 'corpo de conhecimentos' consolidado. Como já escrevi antes, considero o BABoK incompleto. Se não há consenso acerca da formação e habilidades requeridas em um AN, como exigir que eles as apresentem?
AN's são uma derivação não programada dos Analistas de Sistemas, que por sua vez substituíram (sem querer) os Analistas de Organizações e Métodos (O&M). No entanto, os AN's não vieram para substituir os Analistas de Sistemas. São um tipo de contraponto aos "analistas-programadores". Voltam seus olhos para o domínio do problema, enquanto aqueles tratam do domínio da solução.
AN's podem ter uma influência muito negativa no projeto
pv: Todo mundo pode, né? Mas, falando sério: insisto que um bom AN tem uma postura pró-ativa. Então, ele deve criticar requisitos. Porém, não deve nunca recusá-los sem consultar os stakeholders. Outra preocupação do Ambler me pareceu descabida: a influência do AN na arquitetura? Oras, ele não desenha a solução. Acho o risco mínimo, se é que ele existe. Já a última parte do alerta é sério: AN's que não funcionam como canais, mas sim como uma "parede" entre os usuários e os desenvolvedores. O AN facilita o processo de comunicação, mas nunca impede o contato direto. Por exemplo, quando ele organiza e facilita um workshop, desenvolvedores e usuários estão em contato direto.
AN's podem ficar desatualizados
pv: Sim, todo mundo fica. Mas o foco do Ambler nesta questão é um tanto estranha: parece que ele considera que todo AN foi um dia um desenvolvedor. Nada mais errado. Um AN pode ter uma formação 90% em negócios, ser formado em administração ou economia, por exemplo. Naquele grande banco que citei em um post anterior, tem gente de Letras! Por outro lado, não vejo problemas em um desenvolvedor se tornar um AN. É tudo uma questão de gosto. E jeito... muito jeito.
AN's podem ser uma barreira para a comunicação
pv: Sim, como colocado no tópico 2 acima. Típica situação perde-perde-perde em um projeto. Perdem os usuários, desenvolvedores e os próprios analistas. Infelizmente é mais comum do que a gente imagina. E, tão nociva quanto a barreira, é a "tradução livre". Explico: o AN começa a contar apenas "boas notícias" para ambos os lados. Por isso a comunicação aberta e o contato frequente entre todos os stakeholders é fundamental para o sucesso dos projetos.
AN's podem reduzir a influência dos stakeholders
pv: Sim, mas nem sempre isso é uma coisa negativa. Se ele filtrar as influências negativas, permitindo que a equipe performe, ele estará realizando seu trabalho. Mas é o tipo de ação que deve estar sincronizada com o coordenador do projeto e com a equipe. Se bem combinado, o AN se torna uma espécie de "firewall" para a equipe.
AN's analisam MUITO
pv: Até que essa apareceu tarde na lista. É o tal do BDUF (big design up-front). Ou o temor da "analysis-paralysis". Simplificando: se o AN for jogado em um processo baseado no ciclo "cascata" (waterfall), o risco é real e imediato. Se o processo for iterativo e incremental (de verdade), o risco não existe.
Aqui cabe um detalhe interessante (e uma brincadeirinha): o AN é o cara que mais trabalha no projeto. Veja o gráfico abaixo [1]. Se ele resolver executar seu trampo "numa tacada só", só ele vai trabalhar e o projeto se encerrará com uma série de documentos, descrições de casos de uso e protótipos. Ao distribuir suas atividades* entre as diversas etapas e iterações de um projeto, o AN faz bem seu trampo e permite que todos trabalhem.
* São atividades de um AN: B (Business Modeling), R (Requirements), uma bela fatia do T (Tests) e uma fatiazinha do C (Change Management).
AN's reduzem o feedback
pv: Pouco provável, se o AN acompanhar todo o ciclo de desenvolvimento, guiando particularmente os testes e as entregas intermediárias. Ambler insiste nos problemas de comunicação, de certa forma factíveis. Afinal, o AN é outro nó na rede de comunicações. Ou, como diz Karl Wiegers [2], um cara entre a voz do usuário e os ouvidos do desenvolvedor. Se, ao invés de facilitar as comunicações, o AN emperrá-las, não estará fazendo seu trabalho.
AN's reduzem as oportunidades para os desenvolvedores melhorarem suas habilidades de comunicação
pv: Uau.. eu nunca tinha pensado nisso. O Ambler realmente não consegue "tirar o pé da jaca". Ou, colocando d'uma forma menos agressiva: "não tira o boné de jeito nenhum". Como eu disse acima, o AN não impede o contato direto dos desenvolvedores com usuários e demais stakeholders. Reduz o número de contatos, é certo. Mas é para o bem do projeto. Prefiro ver de outra forma: os desenvolvedores podem exercitar bem suas habilidades de comunicação (e pugilismo) com os AN's. E aprender muito com os bons AN's.

.:.

Notas:

Agility and Discipline made Easy: Practices from OpenUP and RUP
Per Kroll e Bruce MacIsaac. Addison-Wesley (2006).
More About Software Requirements
Karl Wiegers. Microsoft Press (2006).

.:.

Sobre o Livro (e uma Oferta)

2007-09-11T10:14:00.000-03:00

Quando decidi escrever meu primeiro livro, não tinha a menor idéia de como seria o processo. Escrever artigos, mesmo aqueles longos, é uma coisa. Um livro é totalmente diferente. Seth Godin e Scott Berkun, em seus blogs, costumam contar um pouco sobre seu processo. Ariano Suassuna, Chico Buarque e Luis Fernando Veríssimo me assustaram um tanto com seus depoimentos sobre o trampo. Mas, no final das contas, cada um tem seu processo, suas manias e traumas. Resolvi desenvolver meu próprio processo (e manias). Espero não colecionar muitos traumas. Mas sei que alguns serão inevitáveis.

Começando do começo, fixei alguns princípios:

Liberdade total, tanto no conteúdo quanto no formato de distribuição, precificação etc. O livro sairá com uma variação da licença Creative Commons, algo que uma editora tradicional dificilmente entenderia. Principalmente porque haverá uma versão digital (eBook), mais fácil de ser copiada.
O livro será um meio, não o fim. Será a principal peça de marketing do finito por um tempo. Ou seja, não tenho a ilusão de fazer grana com o livro. Se ele se pagar, já será um belo feito.
Peça de marketing não pode significar um livro "marketeiro" (no mau sentido). O conteúdo do livro deve ser prático, útil, rico e bem fundamentado.
O livro é um esforço "solo". Mas deve ser amplo em experiências e pontos de vista. A bibliografia consultada até agora, mais de uma centena de livros, não é suficiente. A área (Análise de Negócios) é relativamente nova. O risco de lançar um livro "míope" (ou "caolho") é muito grande.
Apesar de conhecer a tendência, o livro não será do tipo "como passar na prova". Se ele ajudar na obtenção de certificações, particularmente a CBAP do IIBA, tudo bem. Mas este, definitivamente, não é um objetivo do texto.

Na seqüência desenhei a extensão do livro, uma visão de "alto nível". Para se ter uma idéia, ainda não sei se ele terá 9 ou 10 capítulos. A versão com 8 capítulos já é conhecida por umas 120 pessoas (114 participantes dos workshops e 6 "convidados"). No plano original, ainda seguido, espero que ele alcance um mínimo de 400 pessoas. Quanto mais heterogêneo for esse grupo, melhor (veja oferta abaixo).

Por isso os workshops que estou realizando com a Tempo Real Eventos são tão importantes. Não pelo contato de 1 dia, mas pelas conversas que acontecem depois. Por isso montei um grupo de discussão "fechado". Ali posso receber críticas e sugestões. Ali nós trocamos idéias sobre o conteúdo, práticas, processos...

Pois é, adotei um processo Iterativo & Incremental para o desenvolvimento do livro. Sendo assim, posso dizer que nos encontramos na fase de construção, na 7ª iteração. O produto, o texto, já está na versão 0.6. Chegamos em uma fase em que as iterações precisam ser mais curtas. Mas o cronograma segue rigorosamente em dia.

O trabalho de escrita, com todas as revisões, se encerra em dezembro. Já divulguei até a data oficial de lançamento: 27/mar/2008 (quinta-feira) Um dia eu explico a data e o codinome do rebento, "É o Negócio, Beócio".

.:.

Do mesmo conteúdo gerei uma palestra (1h30), o workshop (7hs) e um curso (80hs, dividido em dois módulos de 40hs: Modelagem de Negócios e Engenharia de Requisitos).

Segue aqui uma oferta para escolas, universidades e entidades sem fins lucrativos (de Sampa ou Varginha): quem quiser levar a palestra ou workshop para suas organizações (em outubro ou novembro), não terá custo nenhum. Demais localidades podem ser incluídas, dependendo da distância e das despesas de deslocamento. Todos os participantes receberão uma cópia (digital) do livro (que ainda é [só] uma apostila) e outros artefatos. Se interessou? Então, fale comigo.

.:.

(Requisitos) Levanta aí que eu Coleto daqui

2007-08-31T14:03:00.000-03:00

Seqüência de "Tácitos & Explícitos".

Neste artigo vou tratar especificamente das formas como coletamos, descobrimos, inventamos e entendemos requisitos. Karl Wiegers, em "More About Software Requirements" [1], faz um importante alerta sobre a forma como chamamos esta atividade em um projeto de software. O termo coletar, segundo Wiegers, é enganoso. Nos leva a entender que os requisitos estão lá, estáticos, esperando a hora da colheita. Por isso falei que "coletamos, descobrimos, inventamos e entendemos". Espero ter passado a correta amplitude do trabalho.

No post de ontem falei que temos dois grandes grupos de técnicas de aprendizado: a Socialização (interação pessoal) e a Internalização (interação com documentos dos mais diversos tipos). Vamos estruturar as técnicas de levantamento (e descoberta, invenção...) de requisitos nestes dois grupos. Veja o gráfico abaixo [2]:

As técnicas de socialização, ou seja, aquelas que empregamos para a absorção e troca de conhecimento tácito, são as seguintes: Workshops / JAD, Entrevistas, Observações e Brainstorming. Coloquei o "Fone" ali só para fins ilustrativos (e para possibilitar outro nível de comparação). Cabe uma breve descrição sobre cada técnica:

Workshops / JAD: reunião com um número relativamente grande de participantes. É um evento estruturado, possui agenda, duração e temas pré-definidos.
Um Analista de Negócios (AN) pode ser alocado para planejar e organizar o evento, além de funcionar como um facilitador durante a sua execução. Neste caso é importante que exista outra pessoa (outro AN), registrando as discussões e decisões.
Entrevistas: igualmente estruturado (ou seja, com agenda e pauta pré-determinados), é executado com um número menor de pessoas. Sua vantagem em relação aos workshops é uma certa facilidade em se manter o foco das discussões. Mas a falta de pontos de vista divergentes pode ser um fator negativo.
Novamente o cenário ideal exige a presença de dois AN's, um conduzindo a reunião e outro registrando os achados.
Observações: técnica particularmente importante quando executamos a análise e modelagem do negócio e seus processos. Existem duas variações principais: i) Ativa, quando o AN executa as tarefas de um usuário; e ii) Passiva, quando o AN se limita a observar o trabalho do(s) usuário(s).
Brainstorming: polêmica técnica que pode ser útil quando o projeto exigir criatividade, inovação. É complicada sua condução porque não há uma pauta pré-definida. O AN deve cuidar para que as idéias fluam sem nenhum tipo de interferência ou crítica. Sua eficácia depende muito do perfil e do humor dos participantes.

Todas as técnicas de socialização aparecem no quadrante de alta eficácia e riqueza. Os "agilistas" não erram quando dizem que nada substitui o "tête-à tête". Um bom AN não se limita, em todos esses eventos, a registrar as conversas. Sinais, gestos e expressões podem ser muito relevantes também. O "mapeamento psicológico e sociológico" dos stakeholders também pode ser executado, de forma implícita e nada intrusiva. Para a execução e condução de todas as técnicas acima exige-se do AN grandes habilidades "sociais" (soft skills): comunicação, negociação, intermediação, e por aí vai.

Ao contrário das técnicas de internalização, que exigem habilidades bastante distintas. São elas: Código Fonte, Código Executável, Pesquisa e Documentação. O "Email" aparece no gráfico acima apenas para fins de ilustração. Vamos entender um pouco mais sobre cada uma delas:

Engenharia Reversa: aparece na figura acima em três formatos, já que cada um deles possui uma classificação diferente.
Código Fonte: sua análise é a mais rica de todas, já que permite um diagnóstico completo de um dado sistema. Também conhecida como "análise Caixa-Branca". Dependendo da formação do AN, ele não terá condições de executar este tipo de análise. Dependerá de desenvolvedores.
Código Executável: ou "análise Caixa-Preta", mais factível de execução por um AN. Ele usa a aplicação e extrai idéias (casos de uso e requisitos).
Documentação: deveria figurar em um lugar mais nobre no gráfico. Mas todos sabemos que muito raramente encontramos uma documentação boa (quando encontramos alguma documentação! Atualizada então...)
Pesquisas: podem envolver algum tipo de socialização mas, neste caso, entrariam como uma variação dos "workshops" (acima). Estamos tratando aqui de pesquisas onde não há um contato pessoal. As pesquisas são muito úteis quando o usuário não é conhecido ou o número de usuários é grande demais. Existem dois grandes modelos:
Questionários: pesquisas normais, onde uma população amostral é previamente selecionada. Os questionários podem ser abertos ou fechados (múltipla escolha). Podem nortear o desenvolvimento de um novo produto ou serviço.
Versões de Testes: ou o "processo Google" de validação, com suas quase eternas versões "beta". Um produto ou serviço, em versão de testes (ou protótipo), é disponibilizado para um grupo de pessoas pré-selecionado. Suas observações (na maioria voluntárias) são requisitos que devem ser coletados e analisados pela equipe.

Quero crer que assim ficou clara a diferença entre conhecimento tácito e explícito, e como ambos podem ser importantes em um projeto de software (ou de qualquer natureza). Como eu disse anteriormente, a ênfase no conhecimento tácito (conforme interpretada e proposta por alguns "agilistas") gera um certo tipo de miopia no projeto.

Um AN "completo" desenvolve habilidades para selecionar e aplicar as melhores técnicas para cada tipo de projeto. Primeira habilidade obrigatória: humildade para reconhecer determinada limitação e pedir ajuda.

.:.

Notas:

More About Software Requirements
Karl E. Wiegers. Microsoft Press (2006).
Gráfico foi inspirado neste, extraído de
The Enterprise Unified Process: Extending the Rational Unified Process
Scott Ambler, John Nalbone e Michael J. Vizdos. Prentice-Hall (2005).

.:.

Tácitos & Explícitos

2007-08-30T15:28:00.000-03:00

Há uns 6 anos me 'cansei' do estudo de engenharia de requisitos. Técnicas e métodos mudavam, mas mantinham uma sensação de déjà vu. As mudanças eram cosméticas ou uma questão de nomenclatura. As propostas "ágeis" (aspas não tornam o termo pejorativo) colocaram o Conhecimento Tácito na "coluna esquerda" (leia-se: nomearam-no o mais importante). Essa talvez tenha sido a mudança mais significativa nos últimos 10 anos da disciplina. Mas, basta olhar os métodos e técnicas sem muita paixão para descobrir que tem muito 'revival' ali, pouca coisa original.

Foi quando decidi olhar a estranha disciplina "gestão do conhecimento" com um pouco menos de ceticismo. Pouquíssimos trabalhos fazem a relação desta com a engenharia de requisitos, o que acho estranho. Na época encontrei apenas uma excelente tese sobre "Gestão de Conhecimentos Inter-Projetos" [1], que acabou inspirando meu trabalho sobre "Aprendizado Inter-Projetos". Surrupiei algumas teorias para orientar também minha nova imersão na disciplina engenharia de requisitos.

O trabalho que me 'pegou' foi o clássico "Theory of Organizational Knowledge Creation", de Hirotaka Takeuchi e Ikujiro Nonaka [2]. Foi ali que conheci os 4 modelos de conversão de conhecimentos (figura acima). Prometo ser breve (na explicação das 4 formas):

Socialização: pessoas trocando idéias, de forma direta, conversando. É um canal rico, já que nossa comunicação não se limita a palavras, gestos e desenhos. Um sorriso pode ter n significados.
Externalização: pessoas transferindo seus conhecimentos para o papel (ou disco rígido, não importa). Estamos registrando idéias e experiências, de forma que elas possam ser úteis para outras pessoas.
Internalização: quando são (úteis), acontece a internalização. Ou seja, as pessoas aprendem ao ler um documento, diagrama ou rabisco.
Combinação: por fim temos a combinação, a transformação de um conhecimento explícito (texto, por exemplo), em outra forma de conhecimento explícito (diagrama ou código, por exemplo).

Quando trato especificamente de engenharia de requisitos, gosto de dividir o diagrama acima em duas partes: o hemisfério esquerdo trata da coleta, descoberta e invenção de requisitos (estamos aprendendo). O hemisfério direito cuida de como analisamos, modelamos e comunicamos* os requisitos.
* Observação: a comunicação também envolve o quadrante 'socialização'.

Está aqui uma daquelas idéias que chamo de bullshitagenzinhas das propostas "ágeis". É inocente ou, melhor dizendo, ingênuo pensar que apenas através da socialização nós aprendemos tudo o que precisamos para executar um projeto. Sei que o princípio, em sua origem, não diz "apenas". Mas, infelizmente, muitos interpretam assim.

Há tempos é raríssimo um projeto de software que não envolva algum tipo de integração com um sistema existente. E não aprenderemos as entranhas daquele sistema com um usuário sentado ao nosso lado. Ou seja, temos que aprender de uma forma diferente, com a chamada internalização. Estudaremos documentos e, na maioria das vezes, código-fonte mesmo. Em iniciativas SOA, onde a sobrevida aos sistemas legados é um grande objetivo, a internalização se faz obrigatória. Um método de análise recomendado é chamado "meet in the middle":

Enquanto uma parte da equipe interage com clientes e usuários, aprendendo o negócio e seus requisitos, outra parte analisa os sistemas existentes. Em um momento "mágico" eles "se encontram no meio do caminho", confrontando requisitos, realidades, verdades, mentiras e restrições.

Cada forma de aprendizado exige um conjunto bastante distinto de habilidades soft e hard. Uma distinção que, infelizmente, o BABoK (ainda) não faz. No próximo post falarei um pouco mais sobre socialização, internalização e as principais técnicas de levantamento e descoberta de requisitos de cada uma delas. Lógico, além das habilidades requeridas para executá-las. Habilidades que devem caracterizar um bom analista de negócios.

.:.

Notas:

Knowledge Management in Inter-Project Learning
Daniel Fitzek. ITEM-HSG Universität St.Gallen (2002).
Theory of Organizational Knowledge Creation
Hirotaka Takeuchi e Ikurijo Nonaka.
Publicado em "Knowledge Management - Classic and Contemporary Works". MIT Press (2000).

.:.

Hot Commodity

2007-08-24T13:15:00.000-03:00

Hot Commodity! Jeito legal de dizer que a profissão "Analista de Negócios" está em alta. Foi assim que a revista CIO da Alemanha apresentou o AN, em artigo do último dia 16/ago. Em novembro, também na Europa (Barcelona), acontece o "Project World & World Congress for Business Analysts". Em 9 meses, o IIBA conseguiu certificar pouco mais de 70 profissionais. Um neozelandês, o resto dos EUA e Canadá. Ou seja, é tudo muito novo.

Ao mesmo tempo em que é tudo muito velho. A função existe há muito tempo, com nomes e responsabilidades um pouco diferentes, mas nova ela não é. Pode ser vista como uma releitura dos saudosos "Analistas de Organizações, Métodos e Sistemas", uma profissão que ficou esquecida depois da 'ascensão' dos "Analistas de Sistemas" (AS). Veio a inevitável 'queda' dos AS's, vieram os métodos ágeis e muito mais água debaixo da mesmíssima ponte, até que (re)descobrimos a importância desse cara que, na maioria das vezes, é apresentado como uma "ponte entre todos os stakeholders". No artigo da CIO o job description é o seguinte:

"O AN é uma ponte entre o negócio e TI, trabalhando em ambos os lados para propor mudanças em processos e sistemas, visando satisfazer as necessidades do negócio."

Definição meio perigosa, já que pode levar à falsa impressão de que um AN é um tipo de tradutor; que suas funções são um tipo de retrabalho; um passo ou uma fase adicional no processo de desenvolvimento. Enfim, um custo ou, pior ainda, um desperdício.

Em meu trabalho, logo no primeiro capítulo, reforço que um AN passivo não é um AN de verdade. Vira quase um "garoto de recados". A razão para o rótulo "hot commodity" ficou, de certa forma, implícita na descrição acima: "trabalhando em ambos os lados para propor mudanças em processos e sistemas". O ponto de vista de um AN é super-privilegiado. Ao navegar entre TI e o negócio, ele pode desenvolver uma perspectiva única, caríssima para qualquer empresa que fale seriamente sobre "alinhamento estratégico".

Há dois dias estive em um dos maiores bancos brasileiros. Eles têm quase 150 AN's, alocados em um departamento independente. Seu esforço: fazer com que os AN's compreendam e assumam sua responsabilidade estratégica.

Não tem nada a ver com o banco, mas é por essa e outras que reafirmo: o BABOK, mesmo com as alterações previstas para a versão 2.0, está um tanto distante do alvo correto. Sua ênfase em documentação, no desenvolvimento e gestão de requisitos, cria uma visão um tanto equivocada das responsabilidades dos AN's. Oportunamente, e com uma maior freqüência, espero explorar melhor o tema por aqui.

Por enquanto vale o registro da tendência: AN é um hot job. Resta torcer para que ele não seja recebido como um 'salvador da pátria'; que sua certificação não se torne uma indústria com fim em si mesma; que os livros e cursos não mirem exclusivamente as provas de certificação; que os AN's, fortalecidos, não tentem se fechar em "Escritórios de Análise de Negócios"... Enfim, que o AN aprenda com os erros dos outros.

.:.

Momento "Oportunista, eu?"

A próxima turma do workshop "Formação de Analistas de Negócios" acontece no distante 27/set. Quem se inscrever até a próxima sexta, 31/ago, receberá 50% de desconto. Quem se inscrever e falar comigo antes receberá a versão eletrônica da apostila e um passe para o grupo de discussão exclusivo. A próxima versão da apostila, 0.7, será disponibilizada para os participantes das turmas anteriores no dia 20/set. Será a primeira versão com a formatação mais próxima da versão final do livro. Aliás, já está acertado que o livro será lançado em 27/Março/2008.

Até lá, melhor dizendo, até dezembro, é tratar de amadurecer e enriquecer o texto. Daí os workshops e o grupo de discussão. Daí que, logo, serão lançados os treinamentos. Espero falar sobre eles muito em breve.

.:.

D.E.V.A.G.A.R.

2007-08-16T13:29:00.000-03:00

Como apresentei no post anterior, DEVAGAR é um acrônimo para um conjunto de princípios que deveriam nortear um processo de desenvolvimento 'business-centric'. Confesso, não deixa de ser uma provocação. E um contra-ponto ao ABCDEF que, segundo seus autores, seria 'business-centric'. Na minha opinião, mais que 'business-centric', aquele conjunto de princípios - que, aliás, é muito legal - é mais 'agile-manifesto-centric' ou, em outras palavras, 'developer-centric'.

Mas, mais do que criar polêmica (essa cansa), eu queria descrever com mais detalhes os 7 princípios [1] que compõem o DEVAGAR:

D)emonstrar Valor de maneira Iterativa
Deveria ser, Iterativa & Incremental. Parece frescura, mas faz diferença. Iterare, no latim, significa repetir. Aqui indicamos que repetimos diversos passos (no processo de desenvolvimento), mas a cada repetição nós agregamos real valor. Numa leitura "ágil", é o mesmo que dizer "entregamos software rodando" em cada ciclo (ou iteração). Não curto o radicalismo: nas primeiras iterações, ou exclusivamente na 1ª iteração, software rodando pode ser menos importante que uma boa compreensão do negócio. Da mesma forma que ele pode ser muito importante para a equalização de visão entre todos os stakeholders. Mais do que um processo, o que determina o Real Valor a ser entregue em uma iteração é o projeto. E cada projeto é único. Mensagem mais importante (para o negócio e seus usuários): se uma iteração se encerra e você não consegue perceber o Valor, algo errado aconteceu. E é verdade: software rodando tem muito mais valor que uma série de modelos UML ou afins.

E)ntender (e Melhorar) o Negócio
É difícil aceitar que um projeto seja tocado sem que boa parte da equipe tenha uma mínima compreensão sobre o negócio que está sendo automatizado. É difícil entender a razão para tal alienação ser tão comum em nossa área. Mas o princípio aqui vai além: além de uma boa compreensão do negócio e dos projetos afetados pelo projeto, um processo 'business-centric' incentiva a busca por melhorias.

V)alorizar os Ativos de Software
Está aqui um princípio que, salvo engano, não vi formalizado em nenhuma proposta de processo. Ele deveria ter dois efeitos:

Garantir a qualidade do software que está sendo produzido. Se bem empacotada (documentada e difundida), a aplicação ganha sobrevida. Vale apelar para um velho chavão: ativos de software, ao contrário dos ativos físicos, ganham mais valor quanto mais são utilizados. Todo software (de negócio) deveria ser construído para durar... muito.
Dar sobrevida aos ativos existentes (também conhecidos como sistemas legados). Trata-se de um dos principais alvos das iniciativas SOA. Mas, hoje em dia, serão raros os projetos que não estabeleçam um mínimo relacionamento com software existente. Combater a síndrome NIH (Not Invented Here) e dar valor para aplicações (conhecimentos!) existentes é uma boa prática.

A)daptar o Processo
Taí um princípio que, se adotado pela (IBM) Rational desde o início (do RUP), teria evitado uma série de problemas. Se todo projeto é único, como acreditar em um único processo? Toda organização possui e vive seus valores e costumes. Algumas sobrevivem a eles (hehe.. brincadeirinha). Essa base, mais um conjunto de princípios (ou boas práticas, como as descritas aqui), dá forma à um meta-processo. Um framework que seria posteriormente adaptado para cada tipo de projeto e também para cada projeto.

No nível mais baixo (um projeto), quatro variáveis principais afetam a configuração de um processo: O Negócio (sua estratégia, processos, departamentos e pessoas afetados); o Tipo de Aplicação (Transacional, Analítica ou Utilitária); a Tecnologia e o perfil da Equipe. Claro, várias outras questões (regulatórias, SOX, Bacen, Basiléia... por exemplo) também podem gerar considerável impacto no desenho dos processos de desenvolvimento e gerenciamento do projeto.

Gerenciar Requisitos (e Mudanças)
Vira e mexe, há tempos, o dado pipoca por aí: requisitos (e mudanças) estão de alguma forma relacionados com 80% dos problemas dos projetos que fracassam. Como eles (os projetos fracassados) não são poucos, é inaceitável que este princípio não conste de um processo para desenvolvimento de software. Pode parecer chatice (de certa forma o é), mas "balancear prioridades dos stakeholders" não é o termo adequado. Parece até "forçada de barra" para arrumar uma letra B (e assim compor o perfeito ABCDEF). E por falar nisso, gerenciar requisitos não significa lotar paredes com post-its coloridos.

A)tacar os Riscos
Assim como os requisitos, o mau gerenciamento de riscos também está entre as principais causas das falhas em projetos de software. Como Grady Booch já falava em 96 [2], "se você não atacar os riscos, eles o atacarão". O verbo é este mesmo: Atacar (a redação de um princípio deve ser clara e direta). E é equivacada a impressão de que riscos são questões exclusivas de arquitetura. Um bom entendimento do negócio (princípio #2 acima), significa também a descoberta de riscos e até uma possível antecipação de mudanças. Aliás, os riscos de negócio são mais perigosos que os riscos de arquitetura (por mais que algumas péssimas aplicações tentem nos provar o contrário).

R)espeitar os Usuários
É chato que algo assim tenha que aparecer numa lista de princípios. Mas, infelizmente, se fez necessário. É bom que seja o item de fechamento da lista. Força a revisão de muitos fatores que podem ter ficado implícitos. Por exemplo: vamos ouvir e gerenciar todas as expectativas dos usuários. Mas não fugiremos da responsabilidade de sugerir melhorias, ou de alertá-los sobre riscos em potencial. Respeitaremos a inteligência e o tempo dos usuários estudando seu negócio, falando sua língua. E, mais importante, nos comprometendo com seus objetivos de negócio.

Por tudo isso eu gostei do DEVAGAR. "DEVAGAR & SEMPRE", como naquela fábula da tartaruga. Taí, já arrumei até mascote para o 'business-centric'...

.:.

Notas:

Os princípios desenham o perfil de um processo. Quanto mais genéricos forem, mais maleável é o processo. Por isso é preciso ter muito cuidado com processos que se apresentam como de uso geral, mas apresentam princípios que, de certa forma, são 'intrusivos'. Reparem: trata-se de uma crítica que se aplica à listinha DEVAGAR acima. Com certeza ela não atenderá qualquer tipo de negócio. O que dizer então de projetos?
O mais importante é ter um bom ponto de partida. E ninguém pode ensiná-lo melhor do que seu próprio negócio.
Object Solutions - Managing the Object-Oriented Project
Grady Booch. Addison-Wesley (1996).

.:.

Business-Centric

2007-08-14T10:49:00.000-03:00

Quem participa do ótimo grupo UML-BR (Yahoo!Groups) deve ter visto uma discussão em torno da liberação da versão 1.0 do OpenUP. Em determinado momento, ainda lá nas primeiras mensagens, o debate virou "Architecture Centric X Business Centric". Enquanto o RUP estaria mais para o primeiro, o OpenUP seria uma representação do segundo. Não é uma definição amplamente aceita. O RUP vem alterando seus princípios desde sua criação. Tanto que no verbete RUP da Wikipedia ele também é apresentado como "business centric".

Para entender: quando lançado, eram apresentados como princípios (ou grupos de melhores práticas) do RUP [1]:

Desenvolver software de maneira iterativa
Gerenciar Requisitos
Utilizar arquiteturas baseadas em componentes
Modelar o software
Verificar continuamente a qualidade dos artefatos gerados
Controlar mudanças

Com o tempo os princípios foram mudando. Em determinado momento, o "espírito do RUP" consistia em [2]:

Atacar os grandes riscos o quanto antes, continuamente
Entregar valor para o cliente
Direcionar seus esforços para gerar software executável
Assimilar mudanças o quanto antes no projeto
Definir uma arquitetura o quanto antes
Construir o sistema com componentes
Trabalhar como uma equipe
Fazer da qualidade um modo de vida

A pressão do "Agile Manifesto" e por um processo menos "pesado" continuou, o que nos trouxe para o mais novo conjunto de princípios que, segundo Per Kroll e Bruce MacIsaac [3], norteiam tanto o RUP quanto o OpenUP. São eles:

A)daptar o Processo;
B)alancear Prioridades dos stakeholders;
C)olaboração entre os times;
D)emonstrar valor de maneira iterativa;
E)levar o nível de abstração; e
F)ocalizar continuamente a qualidade.

Este último conjunto seria, segundo seus criadores, "Business-Centric", enquanto os dois anteriores, particularmente o primeiro, seria nitidamente "Architecture-Centric". No grupo de discussão, respondendo ao Marcio Tierno e Rodrigo Yoshima, eu falei que não concordava com o rótulo "Business-Centric". É um rótulo adotado pelos próprios criadores da lista de princípios. Se fosse um rótulo colocado por gente de fora, um consenso, tudo bem. Mas ao batizar suas idéias e sugestões de práticas de "business-centric", os autores, imho, pesaram a mão. Eu disse que a lista parece mais "Agile-Manifesto-Centric", enquanto o Tierno sugeriu "User-Centric". Mas a crítica não basta.

Desde então ando pensando em quais seriam os princípios de um processo "Business-Centric" de verdade. Meus 7 cents:

D)emonstrar valor de maneira iterativa
E)ntender (e Melhorar) o negócio
V)alorizar ativos de software
A)daptar o processo
G)erenciar requisitos (e mudanças)
A)tacar os riscos
R)espeitar os usuários

Ops... D.E.V.A.G.A.R.... não deve pegar muito bem. Talvez com sobrenome: "Devagar e Sempre!" hehe..

Mas, apesar do nome, gostei da idéia. No próximo post falo um pouco mais sobre cada princípio.

.:.

Bibliografia:

The Rational Unified Process - An Introduction
Phillipe Kruchten. Addison-Wesley (2000 - 2ª Edição).
The Rational Unified Process Made Easy
Phillipe Kruchten e Per Kroll. Addison-Wesley (2003).
Agility and Discipline Made Easy - Practices from OpenUP and RUP
Per Kroll e Bruce MacIsaac. Addison-Wesley (2006).

.:.

Formação de AN's - 3ª Turma

2007-08-09T15:52:00.000-03:00

Pois é, já vamos para a 3ª turma do workshop "Formação de Analistas de Negócios". A Tempo Real Eventos já abriu a página de inscrições. Contando as duas turmas, já tivemos 114 participantes. 79 estão participando de um grupo de discussão exclusivo.

Honestamente, eu não esperava um retorno tão positivo. O tema é relativamente novo. Ainda não vejo tanta demanda. Mas, a necessidade, por incrível que pareça, é uma "tendência". Foi isso que li na divulgação de outro treinamento com tema similar. Que seja!

Então seguem aqui algumas dicas e palpites aleatórios:

Atenção escolas, quem lançar um curso que mire a certificação CBAP (do IIBA) pegará um belo filé. Mas, por favor, cursos sérios! Sem gambiarras.
Aliás, não sei como se tropicaliza um 'chapter'. Quem trouxe o PMI para o Brasil deve ter o caminho das pedras. Em se confirmando a demanda, o IIBA precisará de uma representação em solo tupiniquim.
Profissão em fase de criação sofre com muita desinformação. Como já registrei aqui, o BABoK (do IIBA) se concentra em Engenharia de Requisitos. IMHO, Modelagem de Negócios é tão importante quanto. Mas vão existir muitas variações de currículo, tenham certeza. No início, tudo bem. Desde que saibamos a hora de 'desacoplar' (coisa que o PMI, IMHO, não soube fazer).
A primeira especialização nítida: Desenhista de Processos (com ênfase em BPMS). O nome, com certeza, não será esse. Mas será um cara com muita demanda. Aliás, já é. Mas, cabe ressaltar, não dou muito espaço para ele no workshop. Falta tempo.
[to be continued...]

.:.

Rendiconti - Formação de AN's (2ª Turma)

2007-08-04T12:22:00.000-03:00

Aconteceu na última quinta (2/ago), a 2ª turma do workshop "Formação de Analistas de Negócios", promovido pela Tempo Real Eventos. 60 participantes! 10 além do limite esperado. Um tanto além das expectativas iniciais. Ainda não recebi a compilação das avaliações mas, pelos papos pós-evento, tudo indica que foi tão legal quanto a 1ª turma. Uma coisa posso dizer: foi mais dinâmico. O que acabou gerando um pequeno atraso. Felizmente a greve do metrô não nos atrapalhou muito.

[Aos participantes: consegui a proeza de informar o endereço errado do grupo de discussão!! Céus... Por favor, aguardem até a próxima semana (quando receberei a lista com seus emails), para que eu repasse endereços e arquivos. Quem não quiser esperar, me mande um email.]

Como na turma anterior, aguardarei as avaliações para fechar esta prestação de contas. Por enquanto me limitarei a apontar coisinhas que devo providenciar para as próximas turmas (devemos ter pelo menos 3 em setembro, 2 em Sampa):

Iterativo & Incremental: ainda é uma dificuldade para muita gente. Acho que facilito a vida de todo mundo se levar um exemplo prático completo. Tenho certeza de que o Sr Antonio voltou para casa com a mesma opinião: "É uma cascata disfarçada". Infelizmente não sobrou tempo para brigar com a certeza dele. Mas, se ele ficou com um pouquinho de dúvida, já me considerarei um pouquinho satisfeito.
Vou reduzir descrições de processos (particularmente o RUP) e deslocá-los para a parte final do workshop. Espero assim abrir mais espaço para exercícios.
Aliás, vou forçar um pouco mais os exercícios. Alguns deixarão de ser opcionais. Talvez eu até monte algumas "dinâmicas de grupo" (argh!). O único problema é realmente o tempo.
Foram vários participantes, de ambas as turmas, que sugeriram que o evento aconteça em 2 dias! Passei a bola para a turma da Tempo Real Eventos. Talvez a gente lance uma versão diferente: um dia só para Modelagem de Negócios e outro só para Engenharia de Requisitos. Talvez! Antes disso vou buscar a redução dos temas "menos relevantes". A redução do espaço dos processos é meu primeiro alvo.
Mas não deixarei de brincar com o POREM e outras bullshitagenzinhas ágeis.
Tipo: "É difícil saber por onde começar" (trecho de um livro sobre User Stories).
Se a turma sai com boas pistas (sobre onde começar), considero que parte dos meus objetivos foi atingida.
Talvez assim fique mais fácil entender e aceitar o "É o negócio, Beócio!"

.:.

Proposições & Modelos

2007-07-19T09:50:00.000-03:00

Em "Processos de Negócios: São todos iguais?" eu escrevi que o classificação básica dos processos e a identificação da proposição de valor da organização são algumas das primeiras informações que um Analista de Negócios (AN) aprende para guiar seus trabalhos. Neste post vou explorar um pouco mais o tema, acrescentado outro dado que pode ser muito importante, dependendo do tipo de projeto: o Modelo Operacional da organização.

.:.

É mandatório que o AN conheça o perfil da empresa - aquele pequeno conjunto de características que a torna única. A parte que é (ou deveria ser [6]) mais evidente é a proposição de valor, dado que norteia praticamente todas as estratégias da empresa. Para Michael Porter [1] existiriam duas proposições básicas: baixo custo ou diferenciação. Robert Kaplan e David Norton [2], depois de vários autores, fixaram a existência de quatro proposições de valor:

Baixo custo total;
Liderança do Produto (ou Inovação);
Soluções Completas; ou
Aprisionamento.

Utilizei o "OU" (um XOR - OU Exclusivo) para mostrar que o natural é que a empresa apresente apenas uma proposição de valor. Seria uma questão de identidade. O que não significa que uma empresa reconhecidamente inovadora (Apple, por exemplo), não tenha preocupação com custos ou que ela não lance mão de táticas de aprisionamento (iPod + iTunes + DRM, por exemplo). O fato é que a primeira identificação (Apple = Liderança do Produto, seguindo no exemplo acima) é a sua proposição de valor. Algo como: "a primeira impressão é a que fica".

Qual a relevância desse aprendizado para o AN e para o projeto em questão? Acontece que a proposição de valor [3]:

Determina o desenho dos processos de negócio da organização. Afinal, é através deles que ela cria valor;
Influencia diretamente a forma como a empresa administra seus recursos;
Caracteriza suas regras de negócio; e
Direciona seus objetivos e metas.

Por exemplo: se a empresa se caracteriza por oferecer "Baixo custo total", o AN se concentrará na extrema eficácia e eficiência dos processos de negócio. Gargalos, estoques de segurança e retrabalho são alguns dos principais sintomas que o AN procurará identificar [4]. Assim como o AN deverá dar especial atenção à integração de dados (particularmente de clientes e parceiros), quando a proposição de valor da empresa for oferecer "Soluções Completas".

Mas a proposição de valor é apenas uma parte da equação. Ela nos diz o QUE a empresa levará para seus clientes e para a sociedade, mas não explica COMO o fará. É aqui que entram os Modelos Operacionais.

Um modelo operacional indica "o nível necessário de integração e padronização dos processos de negócio para que a empresa possa entregar seus produtos e serviços para os clientes" [5]. Trata-se de um conceito relativamente novo, que ainda carece de muitas pesquisas. Ou seja, será difícil encontrar uma empresa, particularmente em solo tupiniquim, que tenha institucionalizado seu Modelo Operacional. No entanto, mesmo que 'sem querer', toda empresa possui um modelo operacional (assim como toda empresa apresenta uma proposição de valor, por dúbia que seja).

Na definição acima ficou claro que o modelo operacional possui duas dimensões: Integração e Padronização. O diagrama abaixo mostra as 4 combinações possíveis [5]:

Diversificação: a empresa possui poucos (ou nenhum) processos integrados e padronizados. As unidades de negócio são autônomas e, geralmente, cuidam de suas soluções de TI (que são descentralizadas). Clientes, produtos e parceiros também não são compartilhados entre as unidades.
Replicação: processos não são integrados, mas são padronizados, o que garante escalabilidade. Normalmente os clientes não são compartilhados (como em modelos de franquias, por exemplo). O desenho dos processos é centralizado, mas as unidades de negócio são semi-autônomas. TI, na maioria das vezes, é totalmente centralizada.
Coordenação: processos não são padronizados, mas são altamente integrados. Isso indica que as unidades de negócio compartilham clientes, produtos e/ou parceiros de negócio. As unidades de negócio são autônomas, normalmente cuidando também de suas soluções de TI.
Unificação: integração e padronização plena dos processos de negócio, o que normalmente é obtido através do uso de sistemas de gestão centralizados (ERPs ou afins). TI também é centralizada.

Não há um modelo melhor. Cada negócio pode exigir uma combinação única, ou até mesmo a adoção de combinações diferentes para alguns conjuntos de processos de negócio. Também não parece ser possível fazer uma vinculação direta da proposição de valor com um modelo operacional. Não de maneira arbitrária. Podemos encontrar, por exemplo, empresas que oferecem "baixo custo total" e utilizem o modelo "diversificação" ou o modelo "unificação" - os dois extremos da matriz acima.

Ou seja, o AN deve levantar as duas informações: descobrir a proposição de valor da empresa e também o seu modelo operacional. Quanto tempo ele deve gastar em tamanha descoberta? Se a empresa for 'organizadinha', uns 10 minutos. Caso contrário, meia hora deve ser suficiente. Sem exageros. Como eu disse anteriormente, são informações muito básicas. Mas caríssimas em várias decisões do projeto. Em um futuro artigo tentarei demonstrar essa relevância toda na prática.

.:.

Notas:

Competitive Advantage: Creating and Sustaining Superior Performance
Michael Porter. Free Press (1985).
Mapas Estratégicos
Robert S. Kaplan e David P. Norton. Editora Campus (2004).
Reparem nos itens em negrito daquela lista: Processos, Recursos, Regras e Objetivos. Através destes 4 elementos básicos devemos ter condições de descrever qualquer negócio. No workshop 'Formação de Analistas de Negócios', mostramos como eles podem ser representados em diagramas UML.
Para alguns, o AN deveria ser um mero "coletor de requisitos". Outros, como este que os aporrinha, crê que um AN pode ser mais útil como um mix de palpiteiro e enfermeiro de processos: um cara que não faz vista grossa para processos de negócio doentes.
Aliás, ao detectar processos "dodói", o AN aumenta consideravelmente as possibilidades de antecipar mudanças, reduzir riscos do projeto, etc etc
Enterprise Architecture as Strategy
Jeanne W. Ross, Peter Weill e David C. Robertson. Harvard Business School Press (2006).
Menos de 10% (chute meu) dos participantes da 1ª turma do workshop não souberam dizer qual a proposição de valor de suas organizações. A turma que representava órgãos públicos (principalmente prefeituras) titubeou um pouco, mas logo (eu acho) concordaram: Prefeituras = Soluções Completas.

.:.

Código = Documentação?

2007-07-16T13:10:00.000-03:00

Na pequena série sobre o "Agile BA" eu prometi um post para falar especificamente sobre Documentação - o 2º maior pesadelo dos programadores.

Nick Malik, do Inside Architecture, chegou antes, e no último dia 11/jul publicou 4 razões para não acreditarmos que código é documentação suficiente para processos de negócio.

O excelente artigo do Nick não me isentará de voltar ao assunto. Acontece que eu quero ir um pouco além, tentando entender ou explicar o trauma que é a tal "documentação". Enquanto trato de outras prioridades, fica a provocação:

"Software is the leaky abstraction. It makes poor documentation for a business process."

.:.

Agile BA Parte III - Criando Caso

2007-07-11T12:52:00.000-03:00

Última parte de uma pequena série que tratou dos problemas da Anne, uma Scrummaster que foi ligeiramente afetada por um curso de Análise de Negócios. Como adiantei na semana passada, vou criar caso questionando algumas estórias.

.:.

Como já reclamei aqui em outras ocasiões, nossa área adora reinventar algumas coisas. Começar do zero, ao invés de melhorar algo que já existe. Assim nasceram as User Stories, peça fundamental da metodologia-religião[1] popularmente conhecida como XP (eXtreme Programming). Segundo um de seus apóstolos[2], as User Stories são formadas por três elementos:

Cartão: onde escrevemos as estórias [3];
Conversas: que nos levariam a entender e detalhar as estórias; e
Confirmação: o 'the end', o fim da estória.

A motivação para tamanha invenção gira em torno da palavrinha 'documentação' (um dos pecados mortais, segundo aquela doutrina). Por isso outro apóstolo [4] reforça: "os cartões representam os requisitos do cliente, mas não os documentam". Vai na linha de um mestre-pacificador (mezzo tucano) [5] que vive insistindo: "gente, modelagem não é documentação... modelagem não é documentação... isso é um mito". Documentação parece um trauma incurável. Mas falarei mais sobre isso em outras oportunidades. A história aqui são as estórias.

No post anterior eu destaquei um probleminha com o processo adotado pela Anne: "Nós organizamos as cento e poucas estórias por processos de negócios...". Vai na linha do problema reconhecido por aquele primeiro apóstolo (que escreveu um livro só sobre estórias) [2]: "É difícil saber por onde começar".

[Nuvens negras fecham o céu. Dois relâmpagos, como flashes do último modelo da Nikon, iluminam a figura de longas barbas esvoaçantes que, do alto da montanha, proclama: "Véio, se tu não sabe por onde começar, já começou errado!"]

Se o trabalho começa por uma correta análise do negócio e seus processos, não devem existir dúvidas sobre o ponto de partida. Ao organizar os trabalhos de coleta e análise de requisitos a partir dos processos de negócio, não existe o trabalho de "organização de estórias". Assim, não há justificativas para adoção do POREM (Post-it-Oriented Requirements Elicitation Method).

Ironias à parte, o fato é que as user stories, apesar de bem intencionadas, trazem mais problemas (inclusive alguns que não existiam antes) do que soluções. Sua granularidade e a doentia independência dificultam o gerenciamento; Tornam as atividades de priorização e planejamento das iterações bastante confusas. Ou seja, sua utilização em projetos médios e grandes deve ser um pesadelo [6].

.:.

Se começamos do começo, ou seja, pela análise do negócio e seus processos, é mais natural a adoção dos Casos de Uso como técnica para coleta, organização e análise de requisitos. Segundo seu criador [7], "um caso de uso é o nosso constructo para um processo de negócio"; "[os modelos de casos de uso] descrevem o negócio e o seu ambiente".

A adoção de casos de uso não significa, de maneira alguma, deixar de ser ágil. Aliás, se bem adotada, a técnica deve promover maior agilidade do que as estórias. As 6 qualidades das boas estórias também devem caracterizar os bons casos de uso [2]:

Independentes: até o limite onde a independência é desejável, ou seja, até o ponto em que ela não gere surpresas e omissões no projeto;
Negociáveis: se o cliente e demais stakeholders não puderem negociar os casos de uso, o que sobra?
Valiosos para Usuários e Clientes: óbvio? Nem tanto. Vide o tanto de caso de uso descrevendo CRUD's e afins por aí.
Estimáveis: ok, UCP's são frágeis. Tanto quanto todos os outros métodos conhecidos. Mas, independente do método, casos de uso são (ou deveriam ser) estimáveis.
Pequenos: não tanto quanto uma história, mas o suficiente para representar uma unidade significativa para o negócio (seja ela uma tarefa, atividade ou processo). Se um caso de uso for grande ou de difícil leitura ele está errado - regrinha básica;
Testáveis: wow. Outra regrinha: se não pode ser testado então não é um caso de uso. Deriva de outra regrinha que diz que [8]: "Se um requisito não pode ser testado então ele não é um requisito".

Resumo da ópera cômica: sejamos ecologicamente responsáveis: post-its e cartões são feitos de árvores; vamos parar com esse papo de 'casa de ferreiro... espeto de bambu' (bambu solta farpas); municiemos nossas equipes e stakeholders com informações consistentes, bem pensadas, analisadas e estruturadas...

... começando do começo: o Negócio.

.:.

Notas:

Não tenho (quase) nada contra XP e afins. Meu problema é só com os fundamentalistas mal educados e donos da verdade suprema. XP e afins foram úteis, representaram um avanço, chacoalharam o status quo. Ou seja, foram um mal necessário.
User Stories Applied: For Agile Software Development
Mike Cohn. Addison-Wesley (2004).
Obs: Mesmo autor do artigo sobre UCP referenciado acima.
Lembram-se daqueles livrinhos da Ediouro que sempre traziam uma discussão sobre "estória versus história"? Pois é, me lembrei deles na hora de traduzir stories.
The Power of Stories
Rachel Davies. XP 2001.
Debunking Modeling Myths
Scott W. Ambler. Software Development (Agosto/2001).
Deve ser (um pesadelo). Nunca testei e nunca terei coragem para tanto.
The Object Advantage - Business Process Reengineering with Object Technology
Ivar Jacobson. Addison-Wesley (1995).
Requirements-Led Project Management
Suzanne e James Robertson. Addison-Wesley (2005).

.:.

Agile BA Parte II - Os Problemas da Anne

2007-07-05T11:11:00.000-03:00

Seqüência deste post, onde a Anne, uma Scrummaster, tenta justificar seu desejo por um pouquinho de 'planejamento up front' em seu projeto. Reforço o 'pouquinho' para dizer que não se trata do combatido BDUF (Big Design Up Front). BDUF, BPUF, SPUF... ufs...

.:.

Um sintoma que indica que o trabalho da equipe da Anne começa 'muito solto' pode ser identificado na seguinte sentença: "Nós organizamos as cento e poucas estórias por processos de negócio..."

Parece que as estórias são coletadas de uma forma aleatória. Os tais 'workshops para coleta de estórias dos usuários' não são orientados por um estudo anterior. Parece natural que, com uma granularidade tão fina (estórias são ou devem ser pequenas), o trabalho de planejamento das iterações e priorização das estórias fique bastante confuso.

Se o AN começar seu trabalho "do início", ele não terá o trampo de "organizar estórias por processos de negócio". Ele[1] realizará a coleta por processos ou atividades de negócio. Além do levantamento e classificação básica dos processos, que comentei brevemente neste post, o AN também deve determinar (claro - em conjunto com os clientes e usuários) a priorização dos processos e / ou atividades de negócio. Depois, cada workshop (ou qualquer outra técnica de levantamento) é programado para cuidar especificamente de um processo ou atividade.

Claro, as coisas nunca são assim tão simples. Processos se relacionam; atividades geram impactos em outras atividades. O AN deve ter uma clara visão dos relacionamentos e restrições. E essa visão só é possível depois de um estudo e mapeamento dos processos. Antes que gritem: não se trata de nada detalhado, de nenhum tipo de estudo que custe 2 ou 3 meses ao projeto. Um mapa em alto nível, que considere apenas os fatores fundamentais, é suficiente. E pode ser gerado em poucos dias de trabalho.

Me desculpem o rabisco[2], mas usando uma variação da UML[3] o mapa de processos pode ficar mais ou menos assim:

Os objetivos ou metas de cada processo são praticamente os primeiros requisitos que um AN conhece. Eles derivam dos grandes objetivos do negócio, que podem estar documentados em planos estratégicos ou em coisinhas mais modernas como Balanced Scorecards e Mapas Estratégicos. Nossa área é estranha: já vi várias equipes de projetos trabalhando sem a mínima noção de quais eram os objetivos daquele processo de negócio que eles estavam automatizando ou otimizando. Para que exigir um mapa quando a viagem não tem destino?

Nota: Mapa = um 'pouquinho' de planejamento up front'.

.:.

Mas este não foi o único probleminha que vi no depoimento da Anne. Encuco também com as 'estórias'. Em outro post eu falarei sobre elas e as vantagens dos casos de uso.

Observações:

Não se trata de um trabalho isolado. O AN pode ou deve estar acompanhado de outros membros da equipe no momento da coleta, análise ou refinamento dos requisitos.
Todos os diagramas da apostila/livro, por enquanto, estão no padrão "rabisco". Birra minha: queria mostrar um trabalho totalmente isento de ferramentas e seus diversos sabores.
EPBE, ou Eriksson-Penker Business Extensions, documentadas no livro "Business Modeling with UML", de Hans-Erik Eriksson e Magnus Penker - Wiley/OMG (2000).

.:.

Agile BA

2007-07-03T19:12:00.000-03:00

ou AN Ágil. Acontece que boa parte deste post estará em inglês. Há cerca de uma semana está rolando uma discussão muito boa no grupo APM (Agile Project Management - Yahoo). Anne, Scrummaster, fez um curso para Analistas de Negócios. Aproveitou uma thread para dizer mais ou menos o seguinte: "logo depois do curso bateu uma vontade danada de fazer um pouco mais de planejamento antes de cair na 'sangria desatada' do projeto".

Pronto, virou prato feito para extremistas-desastrados-alérgicos-a-planos. Depois de um tanto de mensagens, algumas bem mal educadas (pra variar), Anne apareceu com a seguinte resposta:

"To clarify what I said about wishing we had done more planning up front, what we did do was jump right in with a user story writing workshop. We organized the 100+ stories by business processes and the product owner prioritized enough for the first few sprints. After two complete sprints, our sprint retrospectives reflect that for the customers are pleased with the Scum process. However, the product owner said 'adjusting to agile methodology without the complete picture of project' was a frustration.

"Now, don't jump on me. 'Complete picture' doesn't have to mean a fully verified, validated humongous requirements package. I think we haven't sufficiently defined the scope of the project, which means we haven't sufficiently set customer expectations or figured out how our project impacts other ongoing processes and projects. In addition to better scope definition, I would like to do some simple operational concepts and/or modeling of current processes to (1) help all the customers understand their work processes and be able to explain them better and (2) help them generate ideas for improving the processes, especially with the new and exciting capabilities of the system we're developing. We are replacing an internal data-intense management system in our public sector agency. An agile project in the private sector may not have time for this level of planning. We do, and I think it would be time well spent, as long as we keep in mind the goal of a production-ready system in an acceptable amount of time."

.:.

"Dont jump on me"! Hehe. Ninguém deveria. Anne foi didática e precisa. É claro que você pode fazer análise de negócios de uma maneira ágil. Pode não. Deveria fazer. A coisa talvez chegue em um ponto em que a gente tenha que distinguir: ágil adjetivo ou "ágil" substantivo? tsc, tsc..

.:.

Processos de Negócios: São todos iguais?

2007-07-03T16:35:00.000-03:00

Essa é a impressão que se tem quando vemos algumas discussões, referências e tendências: processos de negócio são todos iguais. É uma perigosa armadilha que todo analista de negócios (AN) deve perceber logo no início de seus estudos e trabalhos. Os processos são diferentes, e deveriam merecer um tratamento diferente.

A mais básica distinção é o tipo do processo: Primário, de Apoio ou de Gestão? Só essa diferenciação pode alterar drasticamente a estratégia de análise adotada pelo AN.

Processos de gestão são todos aqueles que a organização utiliza para coordenar os processos primários e de apoio. Podem ser um tanto informais, marcados pelas características individuais dos ocupantes dos altos escalões da empresa.

Os processos de apoio são aqueles que suportam a execução dos processos primários. Sua baixa contribuição para a realização ou diferenciação do negócio os tornam os primeiros alvos de iniciativas de terceirização. Compras, contratação de pessoal, administração de recursos humanos e contabilização são alguns exemplos clássicos de processos de apoio.

Por fim temos os processos primários, aqueles que lidam diretamente com os clientes da empresa. Formam o que os entendidos chamam de Core Business, e a qualidade da sua execução determina a identidade da empresa: é cara, é lenta, é burocrática, é uma bagunça...

Segundo Kaplan e Norton[1], podemos classificar os processos primários em 4 sub-tipos:

Operacionais: produção e entrega de bens e serviços para os clientes;
Gestão de Clientes: todas as atividades ligadas ao relacionamento com o cliente;
Inovação: pesquisa e desenvolvimento de novos produtos, serviços ou processos; e
Regulatórios e Sociais: conformidade com as regras e expectativas do setor, legislação ou comunidade.

Cada tipo ou sub-tipo de processo de negócio pode alterar consideravelmente o escopo, forma e ritmo de trabalho do AN. Pode significar também uma estratégia totalmente diferente para a coleta e análise de requisitos. Portanto, tal classificação deveria ser uma de suas primeiras preocupações.

A classificação pode ser consolidada em um simples mapa de processos, um diagrama que indique, em alto nível, seu escopo de trabalho.

Praticamente no mesmo momento o AN pode descobrir (inferir ou perguntar*) qual a proposição de valor da empresa. Parece coisa boba, mas essa informação também fornece um belo norte para o trabalho do analista. Há uma certa discussão em torno do tema - proposição de valor -, mas Kaplan e Norton[1] chegaram em um classificação simples e útil:

Baixo custo total (Casas Bahia, Gol);
Inovação (Embraer, Apple);
Soluções completas (Bradesco, IBM); e
Aprisionamento (HP, MS).

Se a empresa tem a intenção de ser barata o tempo todo, seus processos são desenhados para ser extremamente eficientes e enxutos. Organizações que se posicionam como inovadoras possuem um conjunto de processos que não gostam de ser vistos como "processos". Empresas que oferecem soluções completas exigem um altíssimo nível de integração (entre processos e entre sistemas). E assim por diante.

Tipo dos processos que formam o escopo e o perfil da organização são informações que o AN levanta muito rapidamente. São baratas e simples. Mas podem influenciar praticamente todas as tomadas de decisão no decorrer de um projeto.

.:.

Mapas Estratégicos
Robert S. Kaplan e David P. Norton. Editora Campus (2004).

* É um dos primeiros exercícios do workshop: qual a proposição de valor da sua empresa? A pergunta é simples. As quatro respostas possíveis também. Mas muita gente não sabe responder. Então vai aqui um exercício genérico: qual a proposição da valor da Natura? E d'O Boticário? São iguais?

Mais um: se a Apple usa estratégias de aprisionamento (iPod + DRM + iTunes), por que ela figura na lista acima como inovadora?

Fáceis, não?

.:.

Rendiconti do Workshop - Parte II

2007-06-27T09:33:00.000-03:00

"O Workshop pode ser definido como um banho de esclarecimento acerca do papel do Analista de negócios".
Rodrigo C Maia
Blueeye Web Solutions
Diretor Administrativo

"Todos os tópicos abordados são relevantes e principalmente aplicáveis, podendo melhorar os resultados no desenvolvimento de novas soluções de negócios".
Marlene Aparecida da Silva
Gerente de Informática
Química Amparo

"Esta especialização é uma evolução, tanto na carreira do analistas, tanto na qualidade do produto entregue. No momento em que o mercado entender e demandar por estes profissionais, o ciclo de vida de um projeto, e principalmente a fase de manutenção, mudará radicalmente".
Marília F P Lima
Analista de Sistemas
FUNDAP

"Atual e Necessário para os profissionais de TI. Trouxemos toda nossa equipe".
Umberto Nanini
Diretor de Informática
Prefeitura Municipal de Sorocaba

"O tema é importantíssimo e realmente esclarecedor. Servirá como orientação daqui pra frente".
Fernando Reballo
Diretor de Tecnologia
SHC

.:.

"Algumas das práticas abordadas no curso eu já vinha estudando, porém ainda não havia conseguido definir com clareza todo o ciclo que envolve o processo, bem como encaixa-la na metodologia de desenvolvimento que havia estudado com mais profundidade até então, o OpenUP/Basic.

À partir disso, adotar algumas dos pontos abordados no curso, está sendo um pouco mais tranquilo.

Na questão da Modelagem de Negócios, estou estruturando melhor a Visão do Negócio, utilizando de diagramas para representar os processo de negócio, já que o Core Business do meu projeto envolve muito a interação com terceiros. Aí estou usando o diagrama que contempla metas e saídas do processo, bem como os envolvidos no mesmo (chamados de parceiros no modelo conceitual).

Estou em vias de apresentar um projeto de integração de nossos sistema com alguns fornecedores envolvidos no processo. Para isso, já estou elaborando um mapa estratégico e estudando melhor o modelo de balanced scorecard.

Na parte de Engenharia de Requisitos, já reescrevi meus casos de uso, incluindo as informações adicionais relacionadas a ele, tais como Ponto de Vista, Fonte, Tipo, Status, etc....

Quanto ao orçamento e elaboração das iterações do projeto já vinha utilizando análise por casos de uso e iterações definidas tais como apresentadas no OpenUP/Basic.

É evidente que alguns pontos ainda não estão maduros e faltam alguns pontos a acrescentar no processo todo, porém , consegui sair do workshop com uma leitura total do projeto, bem como todos os artefatos e pessoas envolvidas no processo."

.:.

Este último depoimento eu surrupiei do grupo de discussão que criei exclusivamente para a turma que participou do workshop. Eu havia registrado aqui, há quase três anos, minha tristeza quando ouvi de uma participante de um evento em Floripa: "Pena que o que a gente vê neste tipo de evento não dá para aplicar no nosso dia-a-dia." Virou uma provocação que me acompanha em todo evento que participo. Por isso o depoimento acima é muito valioso.

Assim como todos os outros, que estão também numa página da Tempo Real Eventos, em conjunto com outras fotos do workshop. Como eu disse na primeira parte da rendiconti, a turma era muito boa. Isso enriqueceu demais o evento.

.:.

Surpresa

2007-06-23T14:19:00.000-03:00

Abro o workshop e o livro falando do Analista de Negócios (AN), dizendo que ele praticamente não existe. Profissão ou função mal definida, muito mal apresentada e representada. Mas reforço: ao lado do Arquiteto (ou Arquiteto Corporativo), é a profissão mais promissora da área de TI. Aposta que faço há algum tempo.

Engraçado é que o estopim para todo esse trampo veio da noção do fundo do poço: num grupo de discussão, no 2º semestre do ano passado, alguém falou que o AN não serve para nada. Ou, em outras palavras, disse que "não via utilidade nos AN's".

Contei a "estorinha" no workshop e muitos pegaram carona na provocação: "você acredita nos AN's e em sua aposta?" Eu disse que a melhor evidência estava na sala: lotada. Quando a Tempo Real Eventos lançou o workshop não tínhamos a menor idéia sobre qual seria a aceitação. Foi uma aposta mesmo. Seguida de uma gratificante surpresa.

"Abrir a 'caixa preta' que é a organização de TI das empresas"
- Gilson Silva [1]

"Alinhar TI com o negócio"
"O Alinhamento deve mostrar evoluções no plano de negócios"
"O Alinhamento se mantém atualizado na medida em que o negócio evolui"
"O Alinhamento ultrapassa obstáculos aos seus propósitos"
"O Alinhamento é planejado"
- Paul Strassmann [2]

E aí vieram SOA, BPM, ITIL, SOX... todas buscando, de uma forma ou de outra, o tal "alinhamento". Por isso eu acredito tanto nos Arquitetos e Analistas. Arquitetos Corporativos (ou De Negócios) e Analistas de Negócios. Por isso eu acho que o BABoK desperdiça uma grande oportunidade. E que os trabalhos que falam que AN's e AN's de TI são "negócios" diferentes estão um tanto equivocados [3]. Negócio é negócio. Ponto.

.:.

Momento "Catorze Zero Meia"

Leitores do finito interessados em participar da próxima edição do workshop "Formação para Analistas de Negócios" acabam de ganhar um belo incentivo: desconto de 10% em cima do preço promocional* (para inscrições realizadas até o dia 13/jul).

Para tanto, basta informar o código promocional (cpvfan) na página de inscrições.

1406 + "modelito vivarina": todos os participantes terão acesso ao exclusivo grupo de discussões, e terão garantia de atualização da apostila até ela se transformar no prometido livro.

"Desgraça pouca é bobagem", como a gente costuma falar aqui nas Geraes.

.:.

* Válido para os 20 primeiros.
(ps: Nunca pensei que fosse utilizar as detestáveis letrinhas miúdas...)

.:.

Talvez seja o primeiro AN de facto do Brasil. É um dos melhores, não tenho dúvidas. Aliás, ele é bem mais que um AN. Não sei se foi sorte dele ou azar nosso, mas alguns de seus maiores trabalhos foram realizados em Portugal, Espanha, Austrália, Nova Zelândia, África do Sul...
The Squandered Computer
Paul A. Strassmann - The Information Economics Press (1997).
UML for the IT Business Analyst
Howard Podeswa - Thomsom / PTR (2005).

.:.

Rendiconti - Workshop "Analistas de Negócios"

2007-06-22T14:43:00.000-03:00

Maratona das boas. Que começou com um exercício de verdade. O mineiro aqui só tinha ido uma vez ao Centro de Convenções Pompéia, num evento da SUCESU-SP. Ficou com a falsa lembrança de que o centro era "pertinho" da estação Vila Madalena do metrô. Como eu falei para o Anderson da Tempo Real Eventos, gosto de andar um pouco antes d'uma apresentação - preparação final. Mas era para andar "um pouco"... não uns 2,5km!!! Pior: tem um morro 'a la Minas' nos últimos 500mts... Resultado: cheguei bufando e transpirando. O "logo ali" de mineiro realmente é um perigo...

Mas tudo bem.. quase ninguém percebeu. E assim teve início uma maratona de 7 horas.

Com 55 participantes. Participantes de verdade, que enriqueceram bem o evento (inclusive corrigindo o palestrante em alguns furos). A diversidade da platéia (indústria, comércio, serviços, prefeituras e outros órgãos públicos...) ajudou bastante. Mas tenho que rever minha estratégia de "nenhum exemplo pré-formatado".

A intenção era reforçar os conceitos, e forçar uma maior interação do pessoal. Funcionou parcialmente. Em alguns momentos, minha memória me deixou na mão. "Brancos" assim são muito ruins. Percebi também, pelas fichas de avaliação, que tenho que maneirar em alguns 'cases'. Mas tenho que registrar: só deu Ótimo e Bom em mais de 90% das avaliações. Saber que cada real investido foi compensado não tem preço. Mas tem muita coisa para melhorar...

Uma é o meu ritmo. Acertei o "tempo" dos temas na mosca. Mas regulei mal o ritmo. Quando cheguei no último quarto, estava muito cansado. A voz (apesar dos 3 Marlboros), não falhou. Mas o cansaço era visível.

E uma vou ter que aprender com a própria turma que, a partir de hoje, faz parte de um grupo de discussão fechado. Fora o exagero nos 'cases', alguns reclamaram da "falta de profundidade". Em um evento de 7 horas, é coisa crítica.

Acontece que o tema é imenso. Foram 8 "capítulos". Vou entender e depois registro aqui, numa segunda parte da "rendiconti". Fotos e alguns depoimentos também pintarão na 2ª parte.

Por enquanto é isso: o evento e o material didático utilizado (versão beta do meu livro) foram muito bem recebidos. 3 dias de alívio e satisfação. Na segunda começa tudo de novo. Agora com 55 pessoas muito legais participando do processo. Será divertido...

.:.

O Giro em Falso das Rodas Reinventadas

2007-06-14T09:29:00.000-03:00

Há quem ache que a síndrome NIH (Not Invented Here) é uma exclusividade dos desenvolvedores. Não é. Parece que toda a nossa área adora reinventar rodas, eixos e padrões. O tempo todo.

Foto de Tom@HK.

Eu poderia citar n exemplos, como a mal explicada briga da MS com o padrão UML; as metodologias que adoram dar novos nomes e símbolos para coisas que já existem; "oceanos azuis" e outras metáforas criativas para diferenciação; sistemas de help-desk que viram, da noite para o dia, soluções de CRM... Pois é, não é só uma questão de reinvenção. As segundas intenções (as verdadeiras motivações para a "reinvenção") são ainda mais perigosas.

Mas a motivação para este post veio de outro lugar. Do BABoK (Business Analysis Body of Knowledge), que é uma das minhas referências para o livro e o workshop/curso para formação de Analistas de Negócios.

O BABoK é novo. A versão que estou utilizando é apresentada como um "draft 1.6", de julho do ano passado. Como eu disse em outro post, o BABoK se concentra quase que exclusivamente na Engenharia de Requisitos. Mas trata a disciplina como se fosse algo totalmente novo. Parece que o tema não foi estudado anteriormente e compilado em propostas como o CMMI, SWEBoK etc etc. O padrão da SEI, por exemplo, só aparece como "CMM" em algumas poucas referências. No corpo do "corpo" ele é sumariamente ignorado.

Caramba, o CMMI tem duas áreas-chave que tratam especificamente de requisitos: REQM (Gerenciamento de Requisitos) e RD (Desenvolvimento de Requisitos). A vinculação do BABoK com ele deveria aparecer, no mínimo, como uma matriz que mostrasse como as práticas ali recomendadas auxiliam na realização dos objetivos do CMMI.

Mas os "agilistas" não têm motivo para comemorar. Suas práticas e métodos também não existem no BABoK. Aparecem pequenas referências e alertas, dizendo, por exemplo, que "em projetos ágeis e iterativos os requisitos não são baselined (sorry) ao mesmo tempo". Não há quase nada além disso.

Acho que nem preciso dizer que "gestão do conhecimento" e "aprendizagem organizacional" também não foram consideradas na elaboração do BABoK. Pois é, infelizmente, a versão atual é só uma compilação de práticas 'levemente acopladas'. Apresentadas de forma linear, estruturadas de acordo com este diagrama. Como as práticas são relativamente bem documentas (propósito, descrição, técnicas, processo, stakeholders e deliverables - toda prática ou tarefa é apresentada com esta estrutura), o BABoK deve se tornar apenas um tipo de "guia de referência rápida". Um excelente template para elaboração de provas de múltipla escolha. E talvez, numa versão 3.0, apresente uma disciplina nova chamada "integração" ou algo do tipo.

Talvez fosse só esse mesmo o seu objetivo. Mas acho que todo mundo espera mais de algo que se apresenta como um "Corpo de Conhecimentos da Análise de Negócios". A primeira coisa que eu sempre espero é que ele não ignore os conhecimentos existentes. Rodas reinventadas giram em falso.

.:.

Rendiconti: Escrever dá Trabalho

2007-06-12T15:33:00.000-03:00

Algumas notas levemente acopladas sobre o livro para analistas de negócios e o workshop da Tempo Real Eventos.

Eu escrevo e rabisco desde que me conheço como gente. Gosto de escrever, mas vira e mexe eu passo do ponto. Não tem muito tempo que eu me divertia com propostas técnicas de 66 páginas. Escritas do zero, sem 'copy+paste' e afins. A diversão se multiplicava quando eu conseguia encerrar uma frase com um ponto de exclamação! Era o fim...

Sempre convivi com os prazos. Antes eram os prazos da professora de português, depois o "deadline" para a entrega de propostas. Sempre curtíssimos, insuficientes, assustadores.

Daí que eu estava curtindo muito esse negócio de escrever um livro sem um prazo determinado. O editor será meu mano caçula, Guz Vasconcellos, e ele tem outras preocupações. Aí pintaram os workshops, e a insana idéia de aproveitá-los como plataforma de testes para os meus escritos*. Pronto: há pouco estava o Anderson da Tempo Real me lembrando: "dia 15 eu preciso dos originais!"

.:.

A apostila será uma versão 'draft' do livro. Adaptada. Ela contempla exercícios e economiza um pouco nos exemplos. O livro deve ter o inverso, mais estudos de caso e nada de exercícios. Referências teóricas e devaneios acadêmicos serão mais explorados no livro, e quase que totalmente censurados na apostila.

E assim vai. É o desenvolvimento simultâneo de "variações do mesmo tema": Apresentação (versão Palestra e versão Workshop), Apostila, Livro, Caderno de Campo, Guia de Referência "Ágil", marcador de livro, caneca de chá...

Segundo o Cacá, é uma "boa prática" recomendada em "Pai Rico, Filho Pobre" ou algo do tipo. Não conheço.. acho que nem quero conhecer... Mas esse negócio de sugar um negócio até o último negócio parece ser mesmo um bom negócio (pobre filho pobre).

.:.

Três dos caras que mais admiro na literatura tupiniquim são péssimos exemplos quando o assunto é o "processo de escrita". O Chico Buarque só entrega seus livros quando o editor ameaça suicídio. O Ariano Suassuna tá escrevendo sua obra prima desde 1981. E o Luis Fernando Veríssimo deu uma entrevista desanimadora n'O Globo do último domingo:

É mais difícil começar ou terminar?
LFV: Começar e terminar. O meio também não é muito fácil.

Pura verdade.

.:.

No último dia 31/mai esgotaram-se as vagas para a primeira edição aberta do workshop. Não é muita coisa - afinal são só 50 vagas. Mas ficamos muito satisfeitos. Tanto que o pessoal da Tempo Real Eventos já programou o próximo para o dia 2/agosto, uma quinta-feira. Novamente em Sampa.

* Aos inscritos e interessados: 'draft' não que dizer mal feito, ok? A diferença da apostila em relação ao livro, além daquelas citadas acima, é o número de revisões. Estou utilizando um processo "iterativo e incremental". E conto com o apoio de todos na maturação do material. Como já divulguei em outro local, os participantes receberão uma garantia de upgrade (a la cupons da MS). Só não sei dizer se o livro sairá ainda no final deste ano ou apenas no início de 2008. O editor tem outras preocupações...

.:.

Meme #016 - Diversidade faz Bem

2007-05-29T15:35:00.000-03:00

When solving problems, diversity may matter as much as, or even more than, individual ability.

- Scott Page (professor na Universidade de Michigan e autor de "The Difference: How the Power of Diversity Creates Better Groups, Firms, Schools and Society").

.:.

Meme achado-forçado, que ajuda no debate sobre 'Especialistas Generalistas'.

.:.

Help Wanted: Especialistas Generalistas

2007-05-26T13:39:00.000-03:00

Perdão. Não, o finito não está contratando 'especialistas generalistas'. O help necessário é outro. Preciso de ajuda na definição do termo. Queria entender as certezas que aparecem com certa freqüência em algumas listas de discussão e artigos. Normalmente o pessoal cita um artigo do Scott Ambler. Ele fala em 'Generalizing Specialists'. Tropicalizado, o termo virou 'Especialistas Generalistas'. Só a ausência do gerúndio já me deixa encucado. Mas o problema não está só na tradução não. Começa no próprio artigo do Mr Ambler. Ele cita Robert A. Heinlein, um escritor de ficção científica:

A human being should be able to change a diaper, plan an invasion, butcher a hog, conn a ship, design a building, write a sonnet, balance accounts, build a wall, set a bone, comfort the dying, take orders, give orders, cooperate, act alone, solve equations, analyze a new problem, pitch manure, program a computer, cook a tasty meal, fight efficiently, die gallantly. Specialization is for insects.

"Especialização é para insetos!". O romântico manifesto de Heinlein, em mãos erradas, pode causar um estrago e tanto. Vou surrupiar a réplica de alguém que não tem nada a ver com sci-fi, Peter Drucker [1]:

... 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.

A organização baseada em informações exige, em geral, muito mais especialistas do que as empresas tradicionais do tipo comando e controle.

Mixando os dois autores podemos concluir que as empresas baseadas em informações são verdadeiras colméias ou formigueiros, certo? A analogia é interessante, mas não vou brincar com metáforas. Como eu disse em um rendiconti, meu problema é com os 'especialistas generalistas'. Lá eu disse que um melhor termo seria 'especialistas não-alienados': i) Profissionais que reconhecem e respeitam as outras especializações; ii) estão comprometidos com os objetivos do negócio (do projeto); e iii) sabem trabalhar em equipe. Acho que isso não deveria ser um diferencial - em lugar nenhum. É pré-req em qualquer profissão, não?

Mas a tese de Mr Ambler vai um pouco além. Para ele, 'reconhecer' as outras especializações é conhecê-las de fato. Ele chega a sugerir a seguinte trilha de evolução (é só um exemplo fictício, ele diz):

Não tenho nada contra um profissional buscar outras áreas de conhecimento. Muito pelo contrário. Mas a evolução acima é possível? Se Java, .Net, tecnologias de bancos de dados, metodologias de gerenciamento de projetos e de modelagem fossem congeladas - parassem de mudar e de evoluir, talvez. Mas, definitivamente, não é esse o caso. Alguém que tenha parado de estudar Java há 3 anos seria considerado um especialista hoje? Algumas das áreas de conhecimento citadas por Ambler se entrelaçam. É natural que o especialista em uma delas seja também muito bom em outra. Java e modelagem, por exemplo. Aliás, dependendo da ferramenta, trata-se de uma tarefa só. Um melhor exemplo talvez seja Java e testes, ou Java e deployment. Btw, neste último quesito, muita gente fica devendo. Mas essa é outra história.

O maior problema com a tese, em minha opinião, é a forma como ela desconsidera a dinâmica que vivemos. Alguém que tenha aprendido Cobol lá nos anos 80 até que poderia se dar bem hoje, com um mínimo de esforço de atualização. Podemos dizer o mesmo em relação ao VB ou Java, por exemplo?

O fato é que, para ser um especialista hoje em dia, gasta-se muito tempo. As plataformas tecnológicas cresceram muito, para os lados e para cima. A complexidade dos ambientes aumentou exponencialmente. E, pior, ainda são relativamente imaturas. Ou seja, mesmo que o cara não durma e seja um mestre em 'leitura dinâmica', é difícil se manter um especialista. O que dizer então de um 'especialista generalista' conforme proposto por Ambler? Só se ele já estiver contemplando o uso de um plug como o do Neo em Matrix.

.:.

O post ficou longo e, como eu previa, receberá uma seqüência. Quero colocar a questão dos 'especialistas generalistas' no contexto dos projetos. Tirando o lado individual, que procurei destacar aqui, trata-se do maior risco. Equipes multi-disciplinares viraram, em alguns lugares, equipes de profissionais multi-disciplinares.

Sei que a maior parte dos colegas defensores da tese do Ambler são muito bem intencionados. Juan Bernabó, por exemplo, apresenta-a de uma forma muito legal. Mas, infelizmente, não consigo ignorar um tom meio 'facista' de alguns. Me desculpem o termo - mas é assim que interpreto. Quando falam de 'super-desenvolvedores' que sabem fazer tudo no projeto, e ainda se auto-gerenciam... Sei lá, parece que querem dizer: "o mundo é nosso". Aliás, achar que dá para ser bom demais em tudo é uma baita falta de respeito com outros especialistas. Mas esse papo fica para a próxima semana.

.:.

O Advento da Nova Organização
Peter F. Drucker. Artigo publicado originalmente na edição de jan-fev/88 da Harvard Business Review. Republicado no livro "Gestão do Conhecimento - HBR", da Editora Campus (2001).

.:.

Especialistas Generalistas

2007-05-22T13:30:00.001-03:00

If Specialization is Good, More of it is Better, Right?

Aquecimento para meus próximos posts.

.:.

O Analista de Negócios e o tal BABoK

2007-05-18T11:39:00.000-03:00

Faz pouco tempo que descobri o BABoK (Business Analysis Body of Knowledge). Quem cuida dele é o IIBA (International Institute of Business Analysis). A descoberta aconteceu por acidente, no meio das minhas pesquisas. Usando o Google, não consegui achar nenhuma referência em língua portuguesa. Estranhei. Afinal, a versão atual (1.6) está disponível para download desde 12/jul do ano passado. A versão 2.0 está programada para este trimestre. Mas, como escrevi no meu material, "o analista de negócios não existe. Particularmente aqui no Brasil". Normal. Quantos gerentes de projetos existiam há uns 10 anos? E quem conhecia o PMI?

O IIBA segue os passos do PMI. Ou seja, lança um 'guia para o corpo de conhecimentos' e, na cola, uma certificação. Tenho minhas restrições ao formato, mas elas ficam para outra hora. O lado bom é que a iniciativa pode ajudar a divulgar e, de certa forma, consolidar a profissão. Em tempos de altas ondas (SOA e BPM), passa da hora de percebermos que o Analista de Negócios desempenha funções cruciais.
[Meu próximo post falará sobre BDUF e a perigosa insistência de alguns que acham que 'super-programadores' generalistas dão conta do recado - dispensam os AN's].

.:.

Mas o BABoK me assustou um pouco e decepcionou um tanto. Ainda não vi as alterações previstas para a versão 2.0, mas a versão 1.6 cobre, na minha opinião, apenas 50% do trabalho de um AN. Dos seus 8 capítulos, 5 cobrem exclusivamente as atividades de planejamento, desenvolvimento e gerenciamento de requisitos. O gráfico abaixo ilustra as áreas de conhecimento cobertas pelo BABoK:

"Enterprise Analysis", segundo capítulo do BABoK, é descrita como "uma coleção de atividades pré-projeto que servem para capturar uma visão futura do negócio, formando assim uma base a a elicitação de requisitos e para o desenho da solução [...]".

Como já comentei aqui, e talvez seja uma falha minha, mas não consigo dissociar a Modelagem de Negócios da Engenharia de Requisitos. Lógico, são duas disciplinas diferentes. Mas elas compartilham "momentos", independente do modelo de processo utilizado. E o BABoK não fala nada sobre Modelagem de Negócios. Se ela não é uma responsabilidade do AN, então é de quem?

Quero crer que, com a demanda gerada pelas 'ondas' BPM e SOA, o BABoK passe a contemplar atividades para modelagem de negócios e de processos de negócios em suas futuras versões. Melhor seria se a incorporação fosse motivada pela percepção de que o trabalho do AN não se restringe à coleta, análise e documentação de requisitos.

.:.

Como mostra o conteúdo programático do workshop promovido pela Tempo Real Eventos, a primeira metade do evento tratará exclusivamente da modelagem do negócio e seus processos. Apresentarei algumas práticas sugeridas pelo BABoK na segunda parte do evento.

.:.

Onde Mora o Analista de Negócios?

2007-05-15T07:06:00.000-03:00

Fiz uma breve pesquisa e continuo sem uma resposta clara. Para muitos, o AN não deveria estar diretamente vinculado ao departamento de TI. O problema com tal definição é, ao que tudo indica, sua maior justificativa: seria uma forma das áreas de negócio recebê-lo melhor. Ou seja, se ele fosse um profissional da área de TI seria visto com desconfiança.

Mas, se a única função do AN é promover a ligação entre TI e as demais áreas da empresa, parece lógico que ele responda para alguém de TI. Evitaria assim uma certa burocracia (e perda de tempo) toda vez que um AN fosse alocado em um projeto.

Nos meus achados & escritos proponho uma terceira forma: o PMO++. Um escritório de projetos (PMO) oferece um 'pool' de gerentes de projeto. Ele é, de certa forma, uma unidade independente. Alocar ali os AN's pode fazer muito sentido.

Antes de fechar o tema, com os prós e contras de cada modelo, pretendo fazer mais pesquisas. O problema é a (falta de) população amostral.

.:.

Pequenas Mudanças no Workshop

A data do workshop, "Formação para Analistas de Negócios", mudou: será no dia 20/junho, quarta-feira (ou zeca-feira, vocês mandam. Tem gente que gostou da notícia, hehe). E gostará ainda mais de saber que o preço sofreu ligeira queda! Aproveite. São poucas (50) vagas.

.:.

Meme #015 - TI Centrada na Informação

2007-05-14T14:18:00.000-03:00

In the existing IT environments, I believe we moved from being Server-centric to OS-centric to Application-centric. In the next generation, we become more network-centric but fundamentally (for the first time I might note) start building Information Technology actually around the Information. This is powerful. It means that Information is no longer captive to a single application but can be leveraged across any number of applications.

- Mark S. Lewis, VP da EMC

Vale a pena ler toda a sua série chamada "Flat IT".

.:.

Para que serve o Analista de Negócios?

2007-05-08T09:13:00.000-03:00

A pergunta acima, colocada num fórum de discussão há pouco tempo, foi o último empurrão que eu esperava. Volta e meia ouvimos que problemas com a compreensão do negócio e com requisitos respondem por cerca de 80% das causas das falhas em projetos. Com uma freqüência ainda maior, somos comunicados de que uma das maiores prioridades das áreas de TI nos últimos tempos é o alinhamento com o negócio. Mas, por incrível que pareça, um dos profissionais mais importantes no atendimento dessas duas demandas é pouco conhecido. Afinal, quem é o Analista de Negócios (AN)? Qual a sua formação? Quais as suas habilidades? E, mais importante, quais as suas responsabilidades em uma organização de TI e em projetos para desenvolvimento ou implantação de sistemas?

Há muito tempo o tema me persegue. Em 98, logo que cheguei em Sampa, entrei numa briga surreal para conseguir justificar, contratar e treinar 2 Analistas de Negócios. Minha primeira palestra aberta, realizada nos idos de 2002, foi sobre um dos dois principais conjuntos de disciplinas que devem ser dominados por um AN: a Engenharia de Requisitos. Nos últimos tempos, com a confirmação das propostas SOA e BPM, a importância e a necessidade de Analistas de Negócios cresceram ainda mais. Ainda assim, suspeito que pouco se sabe sobre eles e suas funções.

Por isso comecei a compilar minhas experiências e meus achados com o intuito de lançar um workshop e um treinamento. Eles apareceram no meu 'cardápio' deste ano. O primeiro workshop aberto, chamado "Formação para Analistas de Negócios", será realizado pela Tempo Real Eventos. Acontecerá no próximo dia 19/junho (uma terça-feira), em Sampa. Dura o dia todo e tem 50 vagas.

Update: a data mudou. O workshop será no dia 20/junho (quarta-feira).

.:.

Há tempos um pessoal mais próximo me cobra: "por que você não escreve um livro?". Minha resposta era sempre a mesma: "não tenho assunto". Caramba, nesta semana completo 3 anos de blogs. Só no Graffiti são mais de 1400 posts. Mas eu realmente nunca tinha achado uma "lacuna". Não iria "chover no molhado" com mais um título sobre gerenciamento de projetos, apesar de achar que existem boas oportunidades e áreas pouco cobertas (TOC, OpenUP, Scrum), particularmente em língua portuguesa. Também não tenho como escrever sobre reuso e gerenciamento de ativos de software. Careço de mais e melhores experiências.

Mas quando vi que a minha apostila para o curso "Formando Analistas de Negócios" estava ficando grande demais - o curso tem 80 horas - a ficha caiu. Caramba, está aí meu primeiro livro. Era tão óbvio, estava tão 'colado no nariz', que quase perco a oportunidade.

Utilizarei um 'draft' do livro como apostila, tanto para o workshop quanto para os treinamentos. Será uma forma legal de validar os escritos - um tipo de "versão beta". Alguns exercícios e exemplos que pintarem nos eventos devem ser incorporados ao texto final. E, claro, utilizarei este blog para breves pesquisas, sugestões, críticas e também para documentar o andamento do processo.

Conteúdo programático e outras informações sobre o workshop já estão no site da Tempo Real Eventos. Se quiserem conversar comigo sobre o evento ou o livro, fiquem à vontade.

.:.

Novo Berkun

2007-05-04T09:28:00.000-03:00

No próximo dia 15/mai será lançado o novo livro de Scott Berkun, "The Myths of Innovation". É só o segundo. O primeiro foi "The Art of Project Management", best seller e um dos melhores do gênero. Há pouco mais de um ano publiquei um "resumão" dele, comparando-o com o clássico "The Mythical Man-Month".

Berkun escreve de forma aberta. Há tempos ele escreveu em seu blog qual seria o tema do livro e passou a documentar a evolução. Usou o blog como fonte de pesquisas e para validação de seus achados. O novo livro é pequeno (192 págs) e o tema um tanto espinhoso. O melhor livro sobre inovação e criatividade que conheço é "Criatividade e Grupos Criativos", de Domenico de Masi. Pelas breves descrições do novo Berkun já disponíveis, dá para perceber algumas coincidências:

Why all innovation is a collaborative process
How innovation depends on persuasion
Why problems are more important than solutions
How the good innovation is the enemy of the great
Why the biggest challenge is knowing when it's good enough

Sairá um "De De Masi a Berkun"? hehe.. Não creio. Não só porque o título seria horrível, mas porque tenho outras prioridades. Logo elas aparecerão por aqui. Mas, com certeza, o novo Berkun deve dar o empurrão definitivo para que eu encerre aquela série sobre o "Gerenciamento do Trabalho Criativo".

Mas fica a tentação: De Masi, em "Criativade", conta toda a história da humanidade e pára em meados do século XX. Berkun conta a história das inovações olhando tudo o que veio depois, TI, software etc. Deve ser um belo complemento.

.

Watts Up

2007-05-02T18:23:00.000-03:00

Watts Humphrey, papa do CMM e do TSP (Team Software Process), agora também é blogueiro. Ele lançou o Watts Up no último dia 27/abr. Referência obrigatória para todo mundo que lida com desenvolvimento de sistemas, mesmo para a turma que não gosta muito das crias do Watts.

Em seu penúltimo post ele tá falando sobre estimativas e 'chutadores automatizados'. 371 projetos foram analisados. 371% foi o tamanho médio dos furos! Watts:

...I am really disappointed and surprised that even very bright and otherwise well-informed people could be so slow to understand how their current practices are hurting their own performance, careers, and quality of life.

CRUISE: Primeiros Passos

2007-04-19T14:30:00.000-03:00

Em uma das partes da série que desenvolvo sobre Ativos de Sofware e Reuso eu comentei minha estranheza em relação ao trabalho do RiSE (Reuse in Software Engineering), um grupo do CESAR (Centro de Estudos e Sistemas Avançados do Recife). Fiz contato com o grupo tentando obter referências e dicas. Um membro me direcionou para o site do IEEE (onde eu deveria comprar as tais referências!).

Estranhei porque, salvo engano, parte da grana que sustenta o CESAR é pública. Mesmo que eles fizessem da venda de artigos uma fonte de receita alternativa, não faz sentido que a venda seja feita em dólar e intermediada por uma entidade dos EUA. Não entendi e também não obtive nenhum tipo de retorno. Ok. Registrei a crítica e esqueci a questão.

Mas eis que agora recebo a notícia do lançamento do CRUISE (Componente Reuse in Software Engineering), uma compilação dos achados do RiSE. O livro foi lançado sob licença Creative Commons (by-sa-nc) e, claro, é distribuído gratuitamente. A porta que parecia fechada a 7 chaves agora está escancarada (no melhor sentido).

Ainda não tive a chance de ler o livro - acabo de baixá-lo. Mas creio que será muito útil na conclusão do meu trabalho. Um trabalho que pode ganhar novo rumo: o pessoal do RiSE, com o lançamento do livro, convoca-provoca participações. Reclama inclusive que nosso meio acadêmico deveria ter mais iniciativas como essa.

Jóia. Mas como tenho que manter minha reputação de "muito chato", antecipo aqui uma crítica: por que em inglês? Sei que existirão mil justificativas do tipo: "é nossa língua universal!". Sorry (haha).

Nossa língua oficial é o português. Todo trabalho gerado em universidades públicas deveria estar em sua língua oficial. Depois viriam as traduções. Engraçado é que no e-mail de divulgação eles falam: "contribuições para melhorar a versão original são muito bem vindas. Inclusive porque inglês não é a língua nativa de nenhum dos autores." Dá pra entender?

De resto, agora é mergulhar no texto, aprender (muito) e colaborar (sempre que possível). Pela iniciativa, parabéns ao pessoal do RiSE. Que seu exemplo seja seguido por muitos.

.

Rendiconti*: O Seminário da Tempo Real

2007-04-16T10:37:00.000-03:00

* Rendiconti = Prestação de Contas

Apesar da minha desastrada abertura, uma palestra 'quebra-gelo' (54 slides em 20 minutos!), o evento do último sábado foi muito bom. Cerca de 260 participantes. Algumas empresas chegaram a mandar mais de 10 pessoas. Pelo retorno que já recebi, quero crer que todo mundo aproveitou bem as 7 horas do evento.

Destaquei na abertura de minha palestra 'de verdade' uma característica não-intencional do evento: nenhum dos 4 palestrantes estava "vendendo" um processo, metodologia ou afins. Novos tempos: estávamos todos compartilhando Princípios e Práticas. Lembrei que isso combinava com uma proposta que Ivar Jacobson havia publicado no Dr. Dobbs há pouco mais de um mês ("Enough of Processes: Let's do Practices"). Adail, em sua palestra, categorizou os processos de uma forma nova: são Ferramentas. Facilitou a justificativa de que sempre existirá uma mais adequada para determinada organização, cliente ou, principalmente, projeto. Jóia!

Uma questão que se repetiu tanto no auditório quanto nos 'breaks' dizia respeito ao porte das empresas. Ou seja, como utilizar / viabilizar aquelas idéias em empresas de pequeno porte? Reforço aqui o que disse no painel de discussão: utilize as idéias que mais agradaram como modelos de crescimento. Ao contrário de várias grandes empresas de TI que existem por aí, permita que sua empresa cresça e não fique simplesmente inchada. Acho que uma colocação de minha palestra que mais motivou a questão foi um modelo para formação de equipes (já apresentado aqui no finito em mais de uma oportunidade). Repito a mensagem: valorize a especialização. Copio Drucker: veja os hospitais e orquestras.

Está aqui um dos poucos pontos em que havia um pouco de discordância entre os palestrantes, particularmente entre a visão do Juan e a minha. Para ele, há espaço / necessidade de "especialistas-generalistas". Entendo o que ele quer dizer, mas acho que o termo gera confusão. Talvez a gente possa falar de "especialistas não-alienados", hehe. Ou seja, estamos falando de profissionais que:

entendem e se comprometem com o seu negócio e o negócio do cliente;
conhecem e respeitam os papéis e a importância de cada colega de equipe;
mas que são especialistas - têm foco e entendem que "conhecimento, por definição, é especializado" (Drucker).

Quem não pôde ficar para o painel de discussão perdeu algumas valiosas dicas. Infelizmente não conseguirei reproduzir todas aqui, então destacarei uma belíssima provocação do Adail: programação se aprende no curso técnico. Vamos valorizar os cursos técnicos e, conseqüentemente, forçar uma modernização do currículo de nossos cursos superiores. A questão que motivou a colocação foi a última do painel, e tratava do futuro da indústria de software no Brasil. Além da preocupação com a educação, vale destacar também o alerta do Juan: precisamos de mais e melhores empreendedores. (Na foto, da direita para a esquerda, Adail, Juan e este que vos escreve).

Em resumo: o evento foi excelente. A qualidade e amplitude das perguntas que recebemos comprovavam o alto nível do público, suas dores, traumas e interesses. Pode parecer estranho ou interesseiro, mas o evento confirmou que precisamos de mais eventos assim. Por fim, eu queria destacar aqui o grande trabalho da Tempo Real Eventos e a atenção do pessoal de apoio da FIAP.

.:.

Crédito: As fotos são do Anderson (Tempo Real). As outras podem ser vistas aqui.

Para a estudantada que estava lá: aguardo as suas fotos, particularmente daquele colega refrescando a cuca na casinha de bonecas, hehe..

Última Chamada

2007-04-11T10:35:00.000-03:00

Consegui montar uma agenda bem legal e estou em Sampa desde o último domingo. Acho que gasto os 2 primeiros dias úteis só me adaptando ao novo fuso horário (é sério!*) e aos novos temperos. Meu estômago é muito mal acostumado...

* Boa parte de Sampa acorda mais tarde e dorme MUITO mais tarde. A diferença, comparando com Vga, dá umas 3 horas. É muita coisa. Outra constatação (já meio antiga): preciso de 12 horas em Sampa para fazer o que faço em 8 horas em Minas. Não tô falando só de deslocamento não. Mas outro dia eu falo mais sobre 'trabalho em casa', produtividade, a crescente desimportância das distâncias...

Fiquei sabendo que já temos cerca de 250 pessoas inscritas no Seminário Gestão de Projetos de Software, da Tempo Real Eventos. Considerando que o evento tomará todo o sabadão (o próximo, dia 14), o número me surpreendeu. Restam poucas vagas. Quem quiser participar deste bate-papo que deve ser muito rico, ainda tem chance.

A gente se vê lá.

Engenharia de Requisitos: O Projeto Aslam [atualizado]

2007-03-30T10:41:00.000-03:00

Uma turma da universidade Anhembi Morumbi está realizando uma extensa pesquisa sobre Engenharia de Requisitos, particularmente técnicas de levantamento.

Repasso aqui o convite para que todos os *praticantes* participem da pesquisa. O 1º questionário já está disponível no site que eles desenvolveram especificamente para o projeto.

Parabéns para a turma. Trata-se de uma importante iniciativa. Rarírissima por essas bandas. Espero ter a chance de conhecer os resultados e comentá-los aqui no finito.

Update: Prazo foi prorrogado para 12/Abril.

UML e BPMN: Mutuamente Exclusivas?

2007-03-23T13:55:00.000-03:00

Nossa área parece ter uma 'quedinha' especial por polarizações. Algumas são necessárias (REST vs SOAP). Seriam menos chatas se fossem breves e mais produtivas (Open Source vs Software Proprietário ou Agile vs Classic). Mas alguns embates parecem não fazer nenhum sentido. Um que descobri só recentemente é o duelo UML ou BPMN. Taí uma discussão muito 'nada a ver', na minha opinião. Vamos aos fatos.

A UML, particularmente sua versão 2.0, é muito extensa? Muito genérica? Sim. Mas isso não é um acidente - um defeito. O ponto mais forte da UML, fora a coerência e legibilidade de seus artefatos, é a sua extensibilidade. Qualidade óbvia, já que ela é genérica. Tipo: "não faz mais do que a obrigação". Várias extensões foram desenvolvidas desde o nascimento da linguagem, no final da década passada. Uma delas é muito relevante para esta discussão: a EPBE, ou "Eriksson-Penker Business Extensions".

Apresentada por Hans-Erik Eriksson e Magnus Penker no livro "Business Modeling with UML" (Wiley, 2000), a EPBE cobre todos os aspectos da modelagem de negócios. Ou quase todos. É curioso, por exemplo, que ela não contemple diagramas de casos de uso. Na visão dos autores, tanto o diagrama de casos de uso quanto os diagramas de componentes e de distribuição (deployment) "são utilizados na análise e projeto de sistemas de informação, mas são pouco relevantes na modelagem de negócios". Por não conseguir dissociar a modelagem de negócios da engenharia de requisitos (falha minha), coloquei aquele "quase" acima.

Mas a EPBE realmente cobre o essencial na modelagem de negócios, estruturando-se em torno de 4 visões:

Visão do Negócio: uma visão geral do negócio, destacando aspectos estratégicos e táticos (problemas a combater ou oportunidades a aproveitar);
Processos de Negócio: mostra a dinâmica da organização, inclusive seu relacionamento com entidades externas.
Estrutura do Negócio: apresenta a estrutura da organização, a divisão de recursos e a carteira de produtos e/ou serviços;
Comportamento do Negócio: o comportamento individual de cada recurso ou processo no modelo do negócio.

Apenas nesta breve descrição já fica claro que não é possível comparar UML com BPMN. Seria algo como comparar uma bela melancia com uma simpática jaboticaba. BPMN, como o próprio nome indica, é uma Notação para Modelagem de Processos de Negócio. Ou seja, cobre apenas 1/4 do que é possível realizar com a UML devidamente extendida. Mas a questão não se encerra aqui.

Muitos lembrarão: "ah, mas o debate verdadeiro é BPMN versus o Diagrama de Atividades da UML". De forma simples e direta: não há nada que eu faça em BPMN que eu não consiga representar em UML. Sim, com BPMN eu consigo diagramas mais 'bonitinhos', mas acho que este, definitivamente, não é o caso. Agora vamos elencar algumas coisas que conseguimos representar em UML e que não estão previstas na especificação BPMN:

Know-Why: um processo de negócio bem documentado justifica sua existência. Precisamos conhecer os objetivos e metas atrelados àquele dado processo. É fácil extender o diagrama de atividades para armazenar essas informações. Mas para que reinventar a roda? O Diagrama de Processos da EPBE já prevê e obriga a inserção desses atributos do processo.
Métricas: apelando para a batida máxima, "não se gerencia o que não se mede". Pode não ser verdadeira para tudo mas, em se tratando de processos de negócio, a afirmação é mais que verdadeira. Cada tipo de processo pode ter um conjunto muito específico de medidas relevantes. Mas existem duas que deveriam estar em todo mapa de processo: Custo e Tempo de Ciclo. Para conhecer os custos de um processo é imperativo que mapeemos todos os recursos utilizados em sua realização. BPMN simplesmente ignora-os.
Informação: na EPBE as informações são tratadas como um tipo de recurso que municia um processo. BPMN, como dito anteriormente, não se preocupa com recursos.
Pessoas: ou stakeholders, também são recursos na notação EPBE.
Requisitos: sim, a EPBE também não contempla artefatos para a captura e gerenciamento de requisitos. Mas ela, ao contrário da BPMN, não ignora sua existência. Há um diagrama muito útil na EPBE, o Diagrama de Linha de Montagem (Assembly Line - veja exemplo abaixo), que permite associar processos de negócios (diretamente de seu respectivo diagrama), com pacotes de objetos (ou serviços!) e casos de uso. Ou seja, consigo rastrear - navegar entre o domínio do problema e o domínio da solução. Com uma vantagem imbatível: usando a mesmíssima linguagem: UML.

Conclusão

Não é o caso de simplesmente dizer que BPMN não é útil. Suas boas idéias, particularmente o maior detalhamento de alguns elementos (só obtidos através do uso de estereótipos no Diagrama de Atividades), podem e devem ser aproveitadas. BPMN e UML estão sob os cuidados do OMG. Acredito que num futuro próximo veremos uma mixagem das duas especificações. Ou então a transformação de BPMN em uma extensão da UML. Algo fácil e natural.

Se BPEL é o seu sonho de consumo, saiba que já existem tradutores de diagramas de atividades para ela. Portanto, BPEL não é desculpa para a adoção da BPMN.

Por fim é arriscado mas necessário dizer que não podemos confundir Modelagem de Negócios com a Modelagem de Processos de Negócios. A primeira é uma disciplina muito mais ampla e complexa. Que é muito importante em projetos para desenvolvimento de sistemas. E nada menos do que VITAL em iniciativas SOA.

Meme #014 - Tecnologia é só 1% da Solução

2007-03-22T12:20:00.000-03:00

Qualquer combinação de software e hardware pode ser vista como um sistema de informação que pode ser dividido, literalmente, no sistema propriamente dito e a informação, suas propriedades e contexto que trata (incluindo aí regras de negócio, gente, problemas, oportunidades…).
O sistema, por sua vez, é uma composição das tecnologias usadas para sua construção e a capacidade de aplicação das mesmas em um dado ambiente de informação. O que normalmente significa que um grande especialista em sistemas financeiros, por exemplo, vai estar perdido se o problema à sua frente for desenvolver um sistema de e-mail. Depois de quase 30 anos fazendo software, acho que descobri as porcentagens que regem as divisões acima: um sistema de informação é 10% sistema e 90% informação. E o sistema é 10% tecnologia e 90% aplicação, o que faz com que a tecnologia, de fato, seja apenas 1% da solução.
- Sílvio Meira (em "Mudando o Mundo. Como?")

Que Futuro estamos Codificando?

2007-03-21T11:22:00.000-03:00

I’d like to predict that the current stacks of software by 10-15 years are going to be in a much worse legacy and more of a nightmare to maintain. You’re going to have employment forever maintaining this stuff. C++, Java code, C# code, this stuff is very complicated and very brittle with all these class libraries and frameworks. We’re digging ourselves in a really big hole and there will be a lifetime of opportunities for you people to maintain this stuff that you’re creating.

- Dave Thomas (no JAOO Panel)

Peguei carona no Fragmental.

SOA: O Fio da Meada

2007-03-19T11:02:00.000-03:00

Jeff Schneider, há tempos, escreve sobre SOA. Dicas valiosas. Percebendo um certo descompasso - carência mesmo - em fevereiro começou uma série chamada "Starter SOA". Tem 3 partes até agora. Não se sabe se continuará. Mas o pouco que foi para o ar é de enorme valia.

Na 1ª parte ele fixa as 3 áreas que devem ser 'atacadas' no início de um programa SOA:

Gerenciamento do Portfólio
Arquitetura Corporativa
Gerenciamento da Informação

No gráfico acima ele mostra o 'ataque' e suas derivações mais específicas, ilustrando em alto nível os principais papéis e responsabilidades que existem em uma equipe formada para implementação de uma SOA.

Na 2ª parte ele sugere a criação de um "SOA Steering Comittee". No desenho abaixo os membros do comitê e respectivas disciplinas:

A sugestão do Schneider tem algumas semelhanças com aquele desenho que apresentei aqui há quase 2 anos:

Fui mais detalhista em alguns pontos, mas pequei por ignorar por completo a Arquitetura da Informação. Na verdade, joguei nas costas do Arquiteto de Serviços essa responsabilidade. Um serviço encapsula dados e lógica. Mas isso não tem nada a ver com a proposta de Schneider. Como bem explicou Todd Biske, "o gerenciamento da informação é a fonte de consistência entre todos os serviços". Sendo assim, no gráfico acima, o Arquiteto da Informação ficaria logo abaixo do Arquiteto SOA. É seu braço direito e fiscal.

O Gerenciamento do Portfólio é uma das áreas críticas, segundo Schneider. No meu ponto de vista, deveria ser uma responsabilidade do próprio Gestor do Programa ("SOA Leader" na nomenclatura utilizada por ele). Auxiliam no gerenciamento do portfólio o Arquiteto de Negócio e o Gestor da Biblioteca de Ativos (GBA), além do representante do PMO (Escritório de Projetos). Entendo que portfólio são os projetos e os ativos existentes. É grande demais para uma cabeça só. Aproveito para insistir que uma boa ferramenta de apoio para tal gerenciamento, sintética e objetiva, é o Mapa Estratégico. Desde que devidamente adaptado para o programa.

Convite

2007-03-15T09:22:00.000-03:00

No próximo dia 14 de abril estarei na FIAP, em Sampa, participando do Seminário "Gestão de Projetos de Software" promovido pela Tempo Real Eventos. Eu sei, é um sabadão. Mas será uma oportunidade legal para trocarmos idéias e atualizarmos fofocas. Opa, e pq não, tomarmos algumas depois do evento!

Farei a palestra de abertura. Na seqüência tem gente muito boa:

Juan Esteban Bernabó vai mostrar como "Criar Equipes Altamente Eficazes";
Adail Retamal tratará de "Ferramentas e Qualidade"; e
José Paulo Papo encerra o evento falando de "Gerenciamento de Riscos".

Maiores detalhes sobre o evento, local e inscrição, você encontra nesta página.

Conto com todos vocês que aparecem aqui no finito de vez em quando.

Help Wanted: Translators

2007-03-13T08:41:00.000-03:00

Uma cambada pra lá de legal, boa parte colegas na UFLA(vras), disparou um trabalho voluntário muito caro* para o solo tupiniquim: a tradução do SWEBOK - Software Engineering Body of Knowledge. O trampo tá carecendo de mão-de-obra. Além dos poucos voluntários, tem gente (como eu) que anda bem enrolada.

Quem quiser participar da empreitada manda um alô para o Saulo Arruda.

.:.

* Caro porque é raro. Quantos textos ultra-BÁSICOS da nossa área nunca foram traduzidos? Nem vou falar de "The Mythical Man-Month", "Peopleware"...

O trabalho, concebido pelo Luciano Borges e guiado pelo Tiago Soldá (que fez um excepcional trabalho de infra e organização), pode merecer reconhecimento legal do IEEE. Ou seja, não será a mesma 'saia-justa' que um dia ocorreu com uma tradução não autorizada do PMBOK.

SOA: As Mudanças Culturais

2007-03-07T11:19:00.000-03:00

No mundo de TI, tudo que é realmente novo gera mudanças culturais. SOA propõe e depende muito de uma série de mudanças culturais. A forma como uma organização percebe e gerencia seus processos de negócio talvez seja uma das mudanças mais visíveis - mais claras. Mas existem outros tipos, relativamente menores, que também são críticos para o sucesso da iniciativa.

Alguns princípios que regem o gerenciamento de projetos, por exemplo, precisam ser revistos. Recentemente aconteceu uma boa discussão no grupo CMM-Brasil que envolveu, entre outras coisas, o balanceamento do 'trio de ferro: Preço x Prazo x Escopo'. Resumindo: quem defende uma abordagem Ágil* diz que, após a negociação e contratação formal, o único item que deveria variar na equação acima é o escopo. Deveríamos eliminar algumas funcionalidades com o intuito de manter intactos o valor e o prazo inicialmente acordados.

De uma maneira geral, e não exclusivamente no caso de um programa SOA, a regra é questionável e polêmica. Agilidade combina com flexibilidade. E regras escritas em pedra não combinam com flexibilidade. Está aí um tipo de princípio que não deveria ser adotado no nível da organização. Alguns projetos podem exigir o total atendimento dos requisitos apresentados. Neste caso, clientes e usuários podem concordar com uma flexibilização dos preços e prazos apresentados. A negociação do(s) ponto(s) de variabilidade do 'trio de ferro' deveria fazer parte do acordo inicial, seja ele um contrato ou um convênio. Ao contrário do que foi dito naquela thread do grupo de discussão, não deixo de ser ágil porque concordei com a entrega de todas as funcionalidades requeridas por um cliente. Mesmo que isso signifique algum atraso em relação aos prazos acordados anteriormente.

Agora, quando se trata especificamente de uma iniciativa SOA, a fixação do escopo como o único fator variável do 'trio de ferro' pode ser um engano ainda mais nocivo. Um engano bastante comum que, segundo Todd Biske, deriva de uma mentalidade 'schedule-driven'. Vou surrupiar seus argumentos:

Muitas organizações com as quais trabalho têm a tendência de ser 'guiadas pelos cronogramas' (schedule driven). Ou seja, o elemento menos flexível do projeto é o cronograma. Assim, a coisa que mais 'sofre' é o escopo. Infelizmente, não se trata do escopo propriamente dito e sim da diferença entre o caminho mais rápido (tático) versus o melhor caminho (estratégico). Se você está tentando implementar uma SOA, saiba que esse tipo de governança de TI tornará sua vida bem difícil. Você está premiando o sucesso do cronograma, não o sucesso da arquitetura.

Todd encerra dizendo que se trata de uma "grande mudança cultural". É sim, particularmente onde impera o imediatismo. SOA deve, de alguma forma, ser vacinada contra esse mal. E isso não significa, de forma alguma, deixar de ser ágil.

finito 3.0

2007-02-28T13:50:00.000-03:00

A versão beta nasceu há quase 3 anos, com a exclusiva finalidade de me apoiar na elaboração de artigos e apresentações. Da beta para a 1.0 pouca coisa mudou. No início do ano passado, com o 'start' definitivo de minha carreira solo, brotou a versão 2.0. Agora, buscando mais e melhores desafios, apresento o finito 3.0!

Blog, site, catálogo de serviços. Os próprios serviços. Tudo novinho em folha. Em Folhas. Espero também que seja uma boa e consistente plataforma para as novidades que pintarão aqui em breve.

E aí, gostou? Não? Envie suas críticas e sugestões. Sempre serão bem vindas.

Quero aproveitar a oportunidade para agradecer as pessoas que me ajudaram na construção desta versão (em ordem alfabética): Denis Leite, Ivo Michalick, Nelson Biagio Jr. e Saulo Arruda. Pelas recomendações no LinkedIn, meu muito obrigado para: Alexandre Calderaro, João Stankevicius, Marcelino Bersch, Ronan Cunali, Simone Lopes e Victor Zamora. Pelo apoio desde sempre: Ariane Garé, Anderson Pontes Pinto, Carlos Teixeira, Luis Felipe Braga e Nelson Ponce. Pelos palpites e validações: Dona Tutti e Guz Vasconcellos. Tks! Hehe.. ficou parecendo listinha de ganhador de Oscar.

Meme #013 - O Ócio Lubrifica

2007-02-21T11:24:00.000-02:00

Slack at all levels is necessary to make the organization work effectively and to grow. It is the lubricant of change. Good companies excel in the creative use of slack. And bad ones can only obsses about removing it.

- Tom DeMarco (em "Slack")

Surrupiei a citação deste excelente artigo do Maurício Linhares. Cheguei até ele via Fragmental.

Contratos ou Convênios?

2007-02-16T10:13:00.000-02:00

A aquisição de projetos de software é o tipo de assunto que dá muito pano pra manga. No excelente grupo CMM-Brasil, o tema (e o carcomido embate 'agile x classic(!*)), gerou uma boa quantidade de mensagens nesta semana. Ontem o JP Rangaswami, do 'Confused of Calcutta', apresentou uma visão interessante:

In a contract, at the slightest sign of trouble, you look for “recourse”. A contract tells you how to punish the other person if something goes wrong. In a covenant, at the slightest sign of trouble, you look for “repair”. A covenant tells you that the two of you will work something out, not sue each other.

Voltarei ao tema, contando algumas experiências pessoais.

.:.

* Classic?!? Não sei se vi em algum lugar. Mas ficou legal a 'tag' para identificar o outro lado da moeda quando o assunto são os processos e modelos para desenvolvimento de sistemas.

Google Testing Blog

2007-02-15T09:50:00.000-02:00

O Google tem experiências muito boas para compartilhar. Em todas as áreas que formam o que chamamos de Engenharia de Software. O Google Testing Blog é um dos vários "Google Dev Blogs" que os googlers disponibilizam.

Eles farão um 'rodízio' de slogans. O atual, adaptado de uma frase do Mario Andretti, é "If it ain't broke, you're not trying hard enough". Legal. Mais legal ainda é a logomarca aí ao lado.

Getting Real

2007-02-10T00:51:00.000-02:00

Graffiti: Vocês usam algum processo de desenvolvimento? Podem falar um pouco sobre ele? Tipo, tem um pouco de XP ou afins?

Marco Gomes: Usamos o Getting Real, a programação é "Orientada à Gambiarras com Ajustes Posteriores" e trabalhamos sempre nas madrugadas.

.:.

O papo aí é um pequeno trecho da entrevista que Marco Gomes e Rapha Vasconcellos, criadores do Boo Box, deram para o Graffiti (meu blog 'menos sério', hehe). Pena que não deu para explorar mais o assunto, o processo "Getting Real". Mas, pelo jeito, oportunidades não faltarão.

Ativos: Ciclo de Vida e Processos

2007-01-25T11:08:00.000-02:00

Seqüência de "Ativos: O Cofre e o Guardião", capítulo da série "Gerenciando Ativos de Software".

Foto de Bryan Furnace.

Antes que possamos falar especificamente sobre processos de desenvolvimento e administração de ativos, é importante entender o seu Ciclo de Vida. Quando nos preocupamos exclusivamente com o reuso, percebemos apenas duas atividades principais [1]: o desenvolvimento de ativos (dos serviços, em uma SOA); e o desenvolvimento dos produtos / aplicações (ou meta-aplicações em uma SOA), que utilizam os ativos como blocos de construção. No entanto, se a intenção é o completo gerenciamento dos ativos de software, o desenvolvimento de ativos e aplicações é só uma parte do trabalho. Porque devemos gerenciar todo o ciclo de vida dos ativos. E este ciclo é composto por 5 momentos bastante distintos [2*]:

Identificação: a necessidade ou o potencial de (re)uso de um determinado ativo é identificado. Requisitos e restrições são levantados e a viabilidade de sua produção é estudada. Em um programa SOA, identificamos serviços.
Produção: momento no qual um ativo é produzido. Como veremos posteriormente, um ativo pode ser produzido no contexto de um projeto ou em uma unidade destacada especificamente para este fim.
Consumo: o ativo é (re)utilizado na construção de aplicações ou meta-aplicações.
Manutenção: etapa de duração indeterminada, existe enquanto o ativo estiver disponível para consumo (no repositório) ou em uso por uma ou mais aplicações.
Aposentadoria: quando um ativo é descartado, na maioria das vezes sendo integralmente substituído.

Para cada momento no ciclo de vida de um ativo de software há um processo específico. A lista abaixo apresenta os processos e suas principais responsabilidades [3]:

Identificação
- Coleta e Análise de Requisitos
- Análise do Negócio
- Avaliação Custo / Benefício
Produção
- Desenvolvimento do Ativo (ou Aquisição e Customização)
- Testes e Qualificação
- Classificação (aplicação etiqueta RAS)
Consumo
- Busca e Avaliação do Ativo
- Integração (desenvolvimento da aplicação)
- Relatório sobre o (re)uso
Manutenção
- Cadastramento do Ativo (catálogo e repositório)
- Suporte ao Ativo
- Administração e Suporte ao Repositório
- Gerenciamento de Mudanças nos Ativos
Aposentadoria
- Análise de (re)uso, redundâncias e oportunidades de melhoria
- Preparação para descarte do Ativo
- Remoção do Ativo

É interessante notar que, apesar de algumas semelhanças, os processos acima não sobrepõem nem podem substituir um processo de desenvolvimento tradicional. As atividades listadas extrapolam as fronteiras de um projeto. E devem compor um Programa de Gerenciamento de Ativos (que pode ser um sub-conjunto de um Programa SOA). O diagrama abaixo relaciona alguns dos processos listados com o RUP [2]:

Clique para ampliar.

Reparem que a produção de ativos pode ser parte de um projeto ou uma responsabilidade de outro grupo (na parte inferior do gráfico). No entanto, essa possibilidade não deveria ser aceita em iniciativas de reuso sistemático nem em programas SOA.

No primeiro caso, por tranferir para um projeto um conjunto de atividades (e respectivos custos) que raramente se justificam. A pulverização das atividades de produção também pode comprometer a qualidade dos ativos. Para a implantação do reuso sistemático, parece ser mais indicado que um grupo seja criado para tratar exclusivamente das atividades de produção.

Em programas SOA, o cenário sinalizado pelo diagrama acima parece ainda menos factível. A divisão entre o desenvolvimento de ativos (serviços) e aplicações é de certa forma arbitrária. O desenvolvimento de cada serviço deve ser visto como um projeto em si, independente de seu porte. E em um projeto para a construção de uma meta-aplicação (puro consumo de ativos / serviços), a inserção da construção de um serviço em seu escopo pode significar aumento da complexidade sem nenhum benefício que o justifique.

Distribuindo Responsabilidades

Como vimos no capítulo anterior, as atividades de administração e suporte ao repositório, cadastramento de ativos e manutenção do catálogo são de responsabilidade do GBA (Gestor da Biblioteca de Ativos). Esta pessoa ou grupo deve ficar subordinada ao comitê que administra os ativos ou o programa SOA. As atividades de Identificação, Manutenção e Aposentadoria de ativos (serviços) seriam uma responsabilidade deste comitê gestor. É lógico que o porte da iniciativa (principalmente o número de ativos), é que determinará o tamanho desta estrutura. As atividades de suporte e melhoria dos ativos podem ser tratadas como pequenos projetos, e delegadas para a equipe de produção.

Como foi dito anteriormente, é indicado que a equipe de produção seja uma entidade autônoma, principalmente em relação àquelas que desempenham atividades de consumo de ativos. Seguindo um padrão que caracteriza os serviços em uma SOA, o ideal é que todas as equipes sejam "levemente acopladas".

Sendo assim, temos um desenho que apresenta três grandes grupos de pessoas:

Gerenciamento de Ativos
Produção de Ativos
Consumo de Ativos

[continua]

.:.

Os próximos 3 capítulos falarão sobre os processos de cada um dos 3 grupos acima. Aumentei consideravelmente o escopo deste trabalho, e por isso o prazo de 11/jan foi sumariamente desconsiderado. Nesta semana mesmo publiquei um breve "desvio" da série, para falar exclusivamente sobre a criação de uma (necessária) base de conhecimentos. Não a considerei uma parte desta série, mas é provável que ela apareça (devidamente ampliada e remodelada) na compilação final. Compilação que eu espero publicar ainda em fevereiro. O desvio que fui obrigado a realizar foi bem maior do que o artigo citado mostra: mergulhei na disciplina "Engenharia de Requisitos" para adaptá-la para programas de reuso e, principalmente, SOA. No próximo capítulo mostro meus achados.

.:.

Referências:

Objects, Components, and Frameworks with UML - The Catalysis Approach
Desmond F. D'Souza e Alan Cameron Wills
Addison-Wesley (1999).
Asset Lifecycle Management for Service-Oriented Architectures
Grant Larsen e Jack Wilber
IBM / The Rational Edge (2005).
* O artigo original fala de 4 workflows. Adaptei a terminologia e inseri o momento "Aposentadoria". Justifico as alterações no próximo capítulo.
Practical Software Reuse
Michel Ezran, Maurizio Morisio e Colin Tully
Springer (2002).

Transformando Etiquetas em uma Base de Conhecimentos

2007-01-23T17:16:00.000-02:00

Extensão do capítulo "Etiquetando Ativos de Software", penúltimo capítulo publicado até agora na série "Gerenciando Ativos de Software".

Neste ponto eu começaria a escrever sobre os processos necessários para a administração de ativos de software e para o reuso. O ponto de partida e um dos fatores mais importantes e críticos tanto para o reuso quanto na implementação de uma SOA é a Engenharia de Requisitos -- ou, colocando em outro padrão, o Desenvolvimento e o Gerenciamento de Requisitos. Para explicar a importância desta disciplina no contexto da série, basta lembrar uma frase que citei em um dos primeiros capítulos: "Oportunidades de reuso são como bugs: quanto antes elas forem encontradas, melhor" [1].

As similaridades e as diferenças entre aplicações são encontradas em dois lugares principais: nos requisitos e na arquitetura. O primeiro delimita o problema. A segunda aponta uma forma de solução. Foi aqui que esbarrei numa questão que acabou 'forçando' este post: afinal, como coletar requisitos com o objetivo de detectar oportunidades de reuso?

A busca pela resposta acabou me levando de volta para uma antiga briga*: sem uma base de conhecimentos bem estruturada, esse levantamento é uma tarefa hercúlea, cara e nada ágil. Se boa parte das ferramentas para administração de requisitos ainda não achou uma boa solução para a rastreabilidade*, o que esperar então da forma como elas tratarão essa "nova" demanda?

Porque não se trata apenas de recuperar os requisitos. Devemos ter condições de analisar todo o histórico de construção - observar todas as derivações (modelos, código etc) e conhecer as decisões tomadas. Conhecer todo o ciclo de vida de um ativo pode ser um fator determinante para a sua reutilização.

As etiquetas RAS, apresentadas anteriormente, suprem uma parte dessas necessidades. Mas tanto as suas informações quanto a sua forma de persistência não atenderiam plenamente a demanda pela busca e comparação de requisitos.

Uma deficiência do padrão, apontada anteriormente, é o fato dele não contemplar o histórico de (re)uso do ativo. Se considerarmos então tudo o que precisamos saber sobre os requisitos, definitivamente o padrão RAS não é suficiente. Sua forma de armazenamento (arquivos XML em um sistema de arquivos tradicional) também não facilita as tarefas de busca. Precisamos de uma base de conhecimentos bem estruturada. E sua persistência em um sistema gerenciador de bancos de dados parece ser a melhor alternativa.

Clique para ampliar.

O padrão RAS é extensível. E ele já recebe informações sobre requisitos na entidade/classe "Artefato". O que eu sugiro no diagrama acima é uma extensão do padrão, de forma que ele possa contemplar informações mais específicas sobre os requisitos e sobre o negócio. Utilizei três fontes para traçar o diagrama conceitual: a base que descrevi no artigo supra-citado*, o "Requirements Knowledge Model" de Suzanne e James Robertson [2], e o meta-modelo básico de conceitos de modelagem de negócios proposto por Hans-Erik Eriksson e Magnus Penker [3].

Todos os requisitos são associados aos casos de uso do negócio que, por sua vez, são vinculados à processos de negócio. A caracterização e descrição dos processos é apoiada por quatro elementos básicos: seus Objetivos, Recursos, Eventos e Regras. Informações básicas sobre o negócio podem facilitar a busca e a comparação de requisitos.

Os requisitos também são associados aos elementos que formam a solução. A vinculação direta é com os casos de uso do produto ou serviço que, segundo o padrão RAS, também são cadastrados como "Artefatos". Desta forma é possível rastrear todas as derivações que ocorreram durante o desenvolvimento de determinada solução.

Na parte inferior do diagrama eu apenas sinalizo a possibilidade de classificar e detalhar melhor os requisitos.

É importante salientar que nós não reusamos UM requisito. Não buscamos isso. O que se reutiliza é um conjunto (cluster) de requisitos. Todos os descritores e entidades sugeridas acima existem para possibilitar a formação um conjunto. Por exemplo: podemos selecionar todos os requisitos de um determinado processo de negócio; todos os requisitos funcionais que referenciem determinado recurso; os requisitos não-funcionais de determinado produto / serviço; e assim por diante.

.:.

Não é minha intenção aprofundar muito nas questões colocadas neste post. Tanto que ele nem está no 'padrão de escrita' da série. Posteriormente, na versão editada desta série e em outros artigos, falarei mais sobre a construção de uma Base de Conhecimentos para organizações que desenvolvem software.

* Obs.: Na realidade, preciso reescrever e corrigir este artigo. É de 2003, e até hoje tá ali no canto, falando de "requerimentos".

.:.

Referências:

Practical Software Reuse
Michel Ezran, Maurizio Moricio e Colin Tully
Springer (2002).
Requirements-Led Project Management
Suzanne Robertson e James Robertson
Addison-Wesley (2005).
Business Modeling with UML - Business Patterns at Work
Hans-Erik Eriksson e Magnus Penker
Wiley (2000).

Gerenciamento de Projetos de Software com ênfase em Planejamento

2007-01-22T10:13:00.000-02:00

Acontecerá em BH, entre 5 e 14 de fevereiro, o curso "Gerenciamento de Projetos de Software com ênfase em Planejamento". O instrutor e 'construtor' de todo o material do curso é Ivo Michalick, PM-Mestre hiperativo e fundador de um dos melhores grupos de discussão da área: o CMM-Brasil.

Posso estar enganado, mas acho que é o primeiro curso a ser realizado aqui no Brasil que usa "The Art of Project Management", do Scott Berkun, como UMA de suas referências. Uma, porque a bibliografia utilizada pelo Ivo é extensa e, principalmente, PLURAL. Vou repetir aqui o que escrevi há pouco para ele: muitos cursos sobre gerenciamento de projetos são muito 'bitolados' em uma única escola: ou PMBoK, ou APM ou etc. A amplitude das referências utilizadas pelo Ivo tornam esse curso muito particular. Vale a pena. E hoje é o último dia para aproveitar um desconto especial de 15%!

Razões para Criar Software

2007-01-17T11:16:00.000-02:00

11.301% of software is written to save money.
13.852% of software is written to make money.
24.718% of software is written to make someone in the company (or some department) look good to their peers or bosses.
50.129% of software is written as a panic reaction to solve a problem that no one understands.

Olha que é só um pequeno trecho de um ácido e hilário post de Kevin Barnes, em seu Code Craft. Vale cada minuto da leitura.

Meme #012 - O Cliente está sempre Conectado

2007-01-15T13:59:00.000-02:00

"I think that right now we’re at a stage where the tools and accepted architectures do not fit the job that programmers have to do. We have three factors that are not going to change in the near future, and they all live on the client: HTML, the browser, and Javascript. Everything else is negotiable. It’s up to programmers to figure out how to deliver the best application they can using any back-end they want, as long as it works with those three front-end technologies. Programmers have done some really cool stuff on top of those three technologies, but things are still pretty awkward."

...

"The big problem, I think, is that the front-end is still very disconnected from the back-end. Because of SOA, people are still thinking very much in terms of sending and receiving messages rather than thinking about how to create a smooth and seamless application that exists both on the client and the server. I don’t know if it’s because of the fact that the Web was very disconnected in the early days, but most programmers still don’t think of the Web browser as a connected client."

...

"However, there is no longer any good reason to keep the client disconnected from the server in terms of software architecture. Broadband penetration is now 75% of active Internet users in the U.S., and much higher in countries that are not as backwards as we are. For some reason, programming techniques have not yet adapted to this fact. And what’s more, everyone is on their way to becoming an always-on node on the Internet network. One third of Blackberry owners are not using their phones for business. The iPhone from Apple (if it gets to keep its name) is a tiny OS X computer with Internet connectivity. In places where Wi-fi hotspots aren’t present, Wi-Max will be soon. In other words, we can no longer get around the fact that the client is once again part of the architecture equation, and our programming practices need to support that fact."

- Jason Kolb (em "Network-Oriented Architecture")

Ativos: O Cofre e o Guardião

2007-01-09T10:48:00.000-02:00

Continuação de "Etiquetando Ativos de Software". Parte da série "Gerenciando Ativos de Software".

Foto de Kk+.

A classificação e organização dos ativos de software sugeridas no capítulo anterior indicam claramente a necessidade de um repositório. Um misto de 'cofre' e estoque que deve armazenar e facilitar a recuperação de todo o patrimônio catalogado. O padrão RAS apresenta uma especificação relativamente simples para a implementação de um repositório, que visa exclusivamente o armazenamento e a recuperação de ativos [1]. O diagrama abaixo apresenta uma visão geral do serviço do repositório RAS:

Basicamente são definidos apenas dois serviços: a busca através de palavras-chave ou pelo caminho lógico do arquivo. Já existem algumas ferramentas* que atendem essa necessidade, todas oferecendo mais funcionalidades do que aquelas previstas na especificação RAS. A lista abaixo apresenta as funções que deveriam existir em todo repositório de ativos de software [2]:

Identificação e Descrição dos Ativos: todos os ativos devem ser apresentados de maneira homogênea, utilizando uma mesma interface.
Cadastramento de Ativos: o repositório deve facilitar a inserção de novos itens.
Navegação no Catálogo de Ativos: os usuários devem ter condições de navegar por todo o repositório, refinando as listas por Tipo de Ativo, Contexto, Histórico de Uso e todos os demais atributos que caracterizam um ativo.
Busca Textual: os usuários devem ter condições de procurar por ativos a partir de trechos ou palavras que constem de seu nome, descrição ou demais atributos.
Recuperação: a recuperação de um determinado ativo deve ser fácil e direta.
Informação Completa: é crucial que a interface mostre todos os dados sobre o ativo. Suas dependências, por exemplo, devem ser nítidas para os usuários.
Histórico: todo o histórico de uso do ativo (informações que não constam na especificação RAS original, conforme alertado no capítulo anterior) também deve ser de fácil acesso.
Contabilidade: todos os números relativos ao uso do ativo (número de acessos, reuso efetivo etc) bem como os números gerais do próprio repositório (total de ativos, número de buscas bem e mal sucedidas etc) devem ser fornecidos.
Controle de Acesso: todas as funcionalidades do repositório devem estar disponíveis para perfis específicos. Enquanto o Gestor da Biblioteca (mais sobre ele abaixo) tem controle total do repositório, os desenvolvedores não deveriam ter condições de alterar diretamente informações sobre os ativos, por exemplo.
Gerenciamento de Versões: ativos podem ter várias versões diferentes. É fundamental que o repositório faça o controle de versões.
Controle de Mudanças: assim como é importante que o repositório forneça suporte automático para a requisição, discussão, aceitação e implementação de mudanças nos ativos.
Notificação de Mudanças: por fim, o repositório deveria 'avisar' todos os usuários quando uma mudança em determinado ativo for solicitada ou implementada.

É desejável que o repositório ofereça dois tipos distintos de interfaces com os usuários finais:

Totalmente integrada ao ambiente de desenvolvimento (IDE), facilitando a convivência dos desenvolvedores (analistas, programadores e testadores) com os ativos que podem ou devem ser utilizados naquele projeto;
Interface acessível via browser, para todas as tarefas de gerenciamento do repositório: manutenção do cadastro de ativos, relatórios e estatísticas etc.

A implantação de processos que levem ao reuso sistemático de ativos de software requer a existência de um repositório gerenciado. Abaixo são apresentados o perfil e as responsabilidades do profissional que deve gerenciar o repositório de ativos de software.

O Gestor da Biblioteca de Ativos (GBA)

Como foi colocado anteriormente nesta série, se o conteúdo do repositório for confuso e mal estruturado (mal padronizado), corre-se o risco de não aproveitar todas as oportunidades abertas pelo investimento. A organização deve delegar para um profissional ou um pequeno grupo a responsabilidade pelo gerenciamento do repositório de ativos.

Em alguns trabalhos [3] são sugeridos dois perfis distintos: o Gestor de Ativos (Asset Manager) e o Bibliotecário (Asset Librarian). Quando o foco da iniciativa é a implantação do reuso sistemático [2], são sugeridos o Gestor de Reuso (Reuse Manager) e o Gestor da Biblioteca de Ativos (Asset Library Manager). Neste ponto será apresentado apenas o GBA. Os próximos capítulos desta série apresentarão os processos de reuso e o gerenciamento do ciclo de vida dos ativos, bem como os demais perfis demandados por eles.

O GBA "gerencia o repositório e sua configuração, e garante que os ativos estejam sempre disponíveis para os desenvolvedores" [2]. Por ser um perfil pouco comum nas organizações de TI, cabe elencar algumas de suas principais características:

É um programador e/ou analista de sistemas;
Tem bons conhecimentos da principal arquitetura tecnológica em uso e, consequentemente, dos Ativos Horizontais que compõem o repositório;
Domina o uso do repositório e de todas as ferramentas (IDE's e afins) que o acessam;
Domina e respeita o "Guia de Criação, Manutenção e Uso de Ativos"**;
Mantém bom relacionamento com todos os desenvolvedores e coordenadores de projetos da organização;
É organizado e disciplinado.

O gerenciamento do repositório não significa sua posse. O GBA apenas garante a disponibilidade e 'limpeza' do repositório. Mas não é ele quem determina o que pode e o que não pode ser realizado ali. As decisões pela inserção e deleção de ativos, por exemplo, fazem mais sentido quando são da alçada do grupo que cuida da Arquitetura Corporativa (AC). Cada equipe de projeto ou profissional pode sugerir adições ao repositório. Mas a palavra final deveria ser de um comitê central (AC).

O GBA também não tem poderes sobre um ativo. Cada ativo cadastrado possui um autor e um dono. Alterações, sugestões de melhorias ou problemas com um determinado ativo são tratadas diretamente com o seu proprietário (ou com um grupo de suporte, como será apresentado nos próximos capítulos). O GBA pode, no máximo, intermediar o processo. Sendo assim, quais seriam então as principais responsabilidades do GBA? Elas estão sumarizadas abaixo:

Gerenciamento do Repositório: garantindo sua disponibilidade e performance. Sendo assim, relaciona-se (nas exceções e dúvidas) com todas as equipes de desenvolvimento;
Publicação do Catálogo de Ativos: atualiza e publica o catálogo com todos os ativos constantes do repositório. Espera-se que uma boa ferramenta realize tal serviço, mas sua manipulação é uma responsabilidade do GBA;
Manutenção do Catálogo: a inserção, atualização e exclusão de ativos é realizada pelo GBA. É uma forma de garantir que todas as diretrizes fixadas no "Guia"** serão respeitadas.

[continua]

.:.

Referências:

RAS - Reusable Asset Specification - Versão 2.2
Object Management Group (OMG) (05/Nov/2005).
Practical Software Reuse
Michel Ezran, Maurizio Moricio e Colin Tully
Springer (2002).
Asset Lifecycle Management for Service-Oriented Architectures
Grant Larsen e Jack Wilber.
IBM/Rational (2005).

.:.

Observações:

* - Ferramentas: A Flashline, recentemente adquirida pela Bea, há tempos oferece um repositório desenhado especificamente para o reuso sistemático de ativos de software. Sourceforge (VA Software) e IBM também possuem produtos que podem ser adaptados para atender os requisitos apresentados neste artigo.

** - Guia de Criação, Manutenção e Uso de Ativos: um documento que seria elaborado pela equipe de Arquitetura Corporativa ou similar. Nos próximos capítulos desta série ele será apresentado em maiores detalhes.

Etiquetando Ativos de Software

2007-01-04T14:20:00.000-02:00

Continuação do artigo "Ativos de Software". Integrante da série "Gerenciando Ativos de Software".

No artigo anterior foi apresentada a "etiqueta" RAS (Reusable Asset Specification) [1], na sequência de uma definição sobre ativos de software e suas principais características. Neste post o padrão RAS será apresentado em maiores detalhes. O modelo abaixo apresenta uma visão geral dos elementos do Core RAS:

Clique para ampliar.

Existem 4 grandes grupos de informações sobre os ativos: Classificação, Solução, Uso e Ativos Relacionados. Abaixo serão apresentados os elementos de cada um dos grupos. Cabe lembrar que o Perfil e os Perfis Relacionados são extensões específicas de um ativo. Serão apresentados aqui apenas os elementos do Core RAS, ou seja, aqueles obrigatórios segundo o padrão.

Classificação

Trecho do padrão que trata da definição, identificação e contextualização de um ativo de software. Ele possui uma série de Descritores que apresentam suas características e qualidades. Enquanto o padrão RAS sugere o uso de uma descrição livre, alguns autores indicam o uso de uma classificação baseada em conjuntos de atributo+valor, como por exemplo: "tipo do ativo: Código", "linguagem: Java" [2]. Uma correta e ampla classificação facilita a busca por ativos em um repositório.

Assim como a apresentação de um ou mais Contextos. Na última versão publicada do padrão são apresentados alguns exemplos de categorias para contextos, como core, negócios, desenvolvimento, documentação etc. Interessante é que todos os exemplos referem-se a Artefatos e em sua maioria estão relacionados com produtos gerados em determinado momento do ciclo de vida de um ativo. São mais relevantes para a classificação de um ativo as informações acerca do ambiente (ambientes de desenvolvimento, testes e produção) e, em caso de ativos verticais, a descrição do(s) problema(s) de negócio que o ativo endereça.

Outra qualificação aparentemente ausente no padrão RAS* é uma indicação direta do Tipo do Ativo. Essa informação relaciona-se diretamente com o tipo de uso que pode ser feito daquele ativo. A lista abaixo apresenta exemplos de tipos de ativos, mostrando seu Tipo seguido do Tipo de Uso [2]:

Executável: Chamada direta.
Biblioteca: Integração.
Padrão (Pattern): Imitação.
Frameworks: Customização.
Pacotes de Software: Integração.
Requisitos: Comparação.

*Obs.: Porém nada impede que esse tipo de classificação seja realizada através dos elementos Descritor e Grupo de Descritores.

Por fim há um grande elemento chamado Descrição que compila todas as informações sobre a classificação de um ativo, além de outras capturadas em outros grupos. Segundo o padrão, trata-se de um simples container para uma descrição apresentada em linguagem natural.

Solução

A solução oferecida por um ativo é representada por um ou mais Artefatos. Um artefato, segundo a especificação RAS, "é um produto que pode ser criado, armazenado e manipulado por produtores / consumidores de ativos e por ferramentas. Ele pode ser um arquivo armazenado no pacote do ativo ou uma entidade lógica que possui pelo menos um artefato que existe na forma de um arquivo" [1].

Na prática, a solução sempre será representada por um conjunto de artefatos com diferentes tipos de relacionamentos entre si. As relações de dependência são formalizadas em um elemento específico (Dependências / artifact-dependency)*. O tipo de dependência (em tempo de compilação ou em runtime, por exemplo) também pode ser especificado.

O padrão RAS fixa dois níveis de Tipos de Artefatos: Primários e Secundários. O primeiro vincula o artefato diretamente a um programa, usando a extensão do arquivo (.jar, .ppt, .htm, .js etc). Os tipos secundários são utilizados apenas para descrição. Como exemplos a especificação cita: Casos de Uso, Modelos etc.

Faz mais sentido que sejam colocadas aqui, no Contexto do Artefato (contexto-artefato / artifact-context), informações sobre o momento no ciclo de vida do ativo aquele artefato foi gerado. Outras informações, como ferramentas utilizadas, detalhes do ambiente (que se diferenciem daqueles fixados para o Ativo como um todo - na seção Classificação), também devem ser cadastradas neste elemento.

Finalmente, na seção Solução, há o Ponto de Variabilidade. Trata-se da indicação do(s) local(is) onde o artefato pode ser alterado. É indicado que se forneça um contexto, bem como uma referência que detalhe os tipos de alterações que podem ou devem ser feitas.

Uso

Nesta seção são fornecidas informações sobre a(s) forma(s) de uso e manipulação dos ativos. Condensa-se aqui, particularmente no elemento Atividade, todas as ações que podem ou devem ser executadas para o efetivo uso de um ativo e de seus artefatos. Uma atividade por ser vinculada a um artefato específico (atividade-artefato / artifact-activity) ou a todo o ativo (atividade-ativo / asset-activity). A atividade pode se referir a um contexto (ref-contexto / context-ref) específico, e pode ou deve indicar o ponto de variabilidade (variability-point-binding) ao qual se aplica.

É interessante como a descrição oficial da especificação RAS faz referências ao uso de ferramentas, particularmente nesta seção. Parece ser reflexo direto do perfil dos principais patrocinadores do padrão. No entanto, graças à extensibilidade da especificação, é relativamente simples 'corrigir' o padrão ou, colocando de outra forma, adequá-lo para as necessidades específicas de uma organização.

Nesta seção Uso, por exemplo, faz falta um Histórico de Uso do Ativo. Conhecer a história de um ativo é fundamental para uma eficaz avaliação do seu potencial e do retorno gerado por ele. O Histórico deveria indicar o "Contexto de Uso e os resultados obtidos (sucesso ou fracasso, facilidade de uso, melhorias necessárias, problemas encontrados no entendimento do ativo, testes, integração e adaptação do ativo, esforço requerido nessas tarefas, ...)" [2].

Ativos Relacionados

A última seção do Core RAS cuida de vincular o ativo com todos os outros ativos que se relacionam direta ou indiretamente com ele. Um ativo de software, como colocado na especificação, "raramente existirá em isolamento". Apesar do padrão indicar que o tipo de relacionamento entre ativos é totalmente aberto, ele indica que para quatro tipos de relacionamentos existem Valores Reservados. São eles [1]:

Aggregation: indica que o ativo 'contém' o ativo relacionado;
Similar: o ativo possui características similares às daquele relacionado;
Dependency: indica que o ativo referencia ou depende dos serviços ou artefatos do ativo relacionado;
Parent: o ativo 'é contido' ou pertence ao ativo relacionado.

Cabe neste ponto alertar para a possibilidade de um risco: gerar um repositório de ativos bastante confuso. Um artefato pode ser tratado como um ativo em determinado contexto, mas pode ser um componente de outro ativo maior em outro momento. Vale lembrar que até um requisito pode ser tratado como um ativo propriamente dito. Tem-se assim a noção do tamanho que um repositório de ativos pode atingir. Parece indicado que a organização defina - particularmente nos momentos iniciais da implantação de processos de gestão e reuso de ativos de software - características mínimas e porte mínimo para que um determinado artefato ou conjunto de artefatos sejam tratados como ativos.

[continua]

.:.

Referências:

RAS - Reusable Asset Specification - Versão 2.2
Object Management Group (OMG) (05/Nov/2005).
Practical Software Reuse
Michel Ezran, Maurizio Moricio e Colin Tully
Springer (2002).

.:.

Observação importante: Para uma visão completa da especificação RAS, recomendo a sua leitura integral. A versão 2.2, publicada em novembro/2005, é um arquivo PDF com 121 páginas.

Não obtive NENHUM retorno na pequena pesquisa que fiz sobre a utilização do padrão RAS aqui no Brasil. Sei que as últimas versões das ferramentas IBM/Rational, por exemplo, usam RAS. Sei também que tais ferramentas possuem uma considerável base instalada por aqui. Mesmo assim, desconfio, RAS é uma feature ignorada. Aliás, como parece ser tudo que se relacione a "reuso de ativos de software".

Aliás, tentei um contato com o RiSE (Reuse in Software Engineering Group), que, apesar do nome, é uma iniciativa tupiniquim vinculada ao CESAR e à UFPE. Resposta rápida: "desculpe a demora. os papers do RiSE voce pode pegar nos sites de ieee, acm, etc.". Admiro o trabalho dos caras, mas queria entender porque é tudo tão fechado e difícil. Aliás, nem responderam meu último email, enviado em 21/dez. Parece ser mais fácil conversar com Scott Berkun, Martin Fowler e Grady Booch do que com algumas figuras daqui. Estranho, não? Mas deixa pra lá...

Seguinte: não queria "afundar" tanto assim, mas acho que na próxima parte desta série vou falar sobre os repositórios. Tentarei encaixar no mesmo artigo o job description do GBA, o nosso Gestor da Biblioteca de Ativos.

SOA: No Topo da Agenda de 2007

2007-01-03T16:04:00.000-02:00

Pesquisa da McKinsey com 72 executivos de TI confirma: SOA está no topo da agenda de 64% deles. Espero que a tendência também apareça nas pesquisas com os CIO's tupiniquins. E em seus orçamentos, é claro.

Interessante do estudo da McKinsey é a justificativa apresentada por 48% dos executivos: eles querem implementar uma SOA para facilitar a integração com seus parceiros de negócios. Das duas, uma:

Seus sistemas internos estão Ok (bem integrados) e não justificariam a adoção de uma SOA; ou
Trata-se de uma estratégia para facilitar a obtenção de investimentos - aliás, uma boa estratégia. SOA não impõe um ponto de partida, e a priorização de processos de negócios mais críticos pode acelerar o ROI e melhorar a percepção dos benefícios. Processos 'públicos' (que ultrapassam as fronteiras da empresa) são sempre críticos. Risco: confundir SOA com um conjunto de web services.

.:.

Joe McKendrick, da ZDNet, também elencou uma série de previsões para SOA em 2007: Melhores ferramentas (no "ano da modelagem") e uma adoção lenta mas consistente estão entre elas. Mas a mais dramática deve preocupar o pessoal daqui também: a falta de profissionais habilitados para trabalhar na implementação e manutenção de uma SOA.

Meme #011 - Fábrica de Software = Oxímoro

2006-12-29T16:19:00.000-02:00

São seis os fatores importantes que determinam a produtividade do trabalhador do conhecimento, a saber:
A produtividade do trabalhador do conhecimento requer que façamos a pergunta: "O que precisa ser feito?"
Ela exige que coloquemos a responsabilidade pela produtividade nos próprios trabalhadores do conhecimento. Eles precisam gerenciar a si mesmos e ter autonomia.
A inovação continuada tem de fazer parte do trabalho, da tarefa e da responsabilidade dos trabalhadores do conhecimento.
O trabalho do conhecimento requer aprendizado contínuo por parte do trabalhador, mas também ensino contínuo.
A produtivivade do trabalhador do conhecimento não é - ao menos principalmente - uma questão de quantidade produzida. A qualidade é, no mínimo, igualmente importante.
Finalmente, a produtividade do trabalhador do conhecimento requer que ele seja visto e tratado como um "ativo", e não como um "custo", e que os trabalhadores do conhecimento queiram trabalhar para a organização.
Cada um desses requisitos - com exceção talvez do último - é quase o oposto daquilo que é necessário para se elevar a produtividade do trabalhador manual.

- Peter F. Drucker (em "Desafios Gerenciais para o Século XXI")

===

Em 26/ago/06 o Graffiti também falou sobre "Fábricas de Software".

Meme #010 - SOA não é Futuro

2006-12-28T10:56:00.000-02:00

A impressão que tive é que com a quantidade de dinheiro que se está investindo em SOA hoje não dá mais pra chamar de futuro, mas de presente. Claro que há um problema muito grande aí: Este foi o mesmo cenário, por exemplo, com EJBs.

Eu espero sinceramente que tenhamos aprendido a lição e que estudemos os conceitos por trás das coisas antes de sair por aí implementando sistemas que não funcionam utilizando ferramentas caríssimas.

- Philip Calçado (em seu blog Fragmental)

===

Acabei de conhecer o trabalho do Philip. Coisa muito boa, escrita d'uma forma muito legal. Tanto que já tá devidamente assinado e referenciado ali embaixo.

E assim retomo os posts "meme" aqui no finito.

Ativos de Software

2006-12-21T10:45:00.000-02:00

Continuação de "Reuso: Prática Sistemática".

Foto de Rebecca (Kairos Photo).

Um estoque de ativos de software, ou de 'blocos de construção', é uma das quatro características-chave do reuso, conforme citado na 2ª parte desta série. Este artigo apresentará uma definição para ativos de software, além de introduzir o padrão RAS (Reusable Asset Specification) para sua classificação. Também serão sugeridas adaptações para que o modelo seja utilizado em uma iniciativa SOA.

Definindo Ativos de Software

Ativos de software, particularmente quando se fala de reuso, não podem ser vistos apenas como códigos, módulos executáveis e licenças de uso. Todos os artefatos gerados durante o ciclo de vida de um software podem ser considerados e gerenciados como ativos. Requisitos, casos de uso, estimativas, modelos e programas para testes, dentre vários outros, podem ou devem ser tratados como ativos de software.

"Ativos são artefatos de qualquer natureza, gerados em qualquer momento do processo de desenvolvimento. 'Ativo' é uma palavra adequada já que os artefatos produzidos capturam conhecimentos que são importantes para a organização e, conseqüentemente, possuem um valor potencial. O reuso é uma maneira poderosa de se aproveitar esse potencial para agregação de valor." [1]

O padrão RAS, tratando especificamente de ativos reutilizáveis, apresenta uma definição ainda mais simples e objetiva: "Ativo reutilizável oferece uma solução para um problema, em determinado contexto." [2]

Existem dois tipos básicos de ativos de software:

Verticais: mais voltados para o negócio, são especialistas em determinado domínio. Por representarem conhecimentos que podem ser o diferencial de uma organização, eles são considerados ativos de maior valor.
Exemplos: Cálculo de seguros; Credit Score; Reposição de estoques; etc.
Horizontais: representam elementos da arquitetura, sendo portanto mais voltados para a tecnologia. Por serem mais fáceis de serem identificados e reutilizados, são considerados ativos de menor valor.
Exemplos: Componentes para interface gráfica com usuários; frameworks para acesso a bases de dados; Serviços de autenticação; etc.

O padrão RAS propõe a utilização de três critérios para uma completa classificação de um ativo. São eles:

Granularidade: determina o número de problemas endereçado por um ativo. Pode ser pequena, quando trata de um único problema. Um algoritmo para cálculo do dígito verificador do CPF ou uma combo box, por exemplo. Ou pode ser grande, apresentando soluções para um ampla gama de problemas. Um serviço de vendas, O framework Hibernate ou a própria especificação Java EE são exemplos de ativos 'grandes'*.
Visibilidade (e/ou Variabilidade**): indica quanto de um ativo pode ser visualizado e manipulado. Apesar de algumas diferenças na nomenclatura utilizada, é consenso que existem 4 níveis distintos de visibilidade / variabilidade de um ativo:
1. Caixa Preta: o ativo não pode ser alterado e seu interior não pode ser visualizado. Normalmente representa código binário - módulos executáveis adquiridos de terceiros.
2. Caixa de Vidro (ou Limpa): detalhes da implementação são expostos (via modelos, documentação ou até mesmo o código-fonte), mas o ativo não pode ser alterado. A transparência visa exclusivamente o apoio na utilização daquele software.
3. Caixa Cinza: interior do ativo é parcialmente exposto e manipulado, normalmente através de parâmetros. São componentes ou serviços desenvolvidos com o objetivo de serem reutilizados.
4. Caixa Branca: o ativo oferece total visibilidade e variabilidade. Além da total disponibilidade do código-fonte, ativos com este nível de visibilidade também apresentam seus requisitos, casos de uso, modelos, e todos os demais artefatos relevantes gerados no processo de desenvolvimento.
Articulação: descreve o grau de completitude de um determinado ativo. Ou seja, o quão pronto um ativo está para a solução de um dado problema. Um conjunto de requisitos, por exemplo, está longe de solucionar efetivamente o problema. Diz-se que seu grau de articulação é baixo. Já um componente em sua forma executável apresenta um alto grau de articulação.

O gráfico abaixo ilustra a combinação dos três critérios apresentados acima na classificação de alguns tipos de ativos de software:

Etiquetas de Patrimônio

Como foi colocado na introdução desta série, todos os ativos físicos de uma organização merecem ferramentas e processos de administração e controle. Uma das partes mais visíveis desse controle são as etiquetas de patrimônio, que possuem códigos que facilitam a localização dos ativos em um sistema. Ativos de software podem merecer o mesmo tipo de gerenciamento. Principalmente em organizações que dependem muito de seus sistemas de informação. Mesmo quando o reuso sistemático não é um objetivo da organização, o gerenciamento de ativos de software deveria ser considerado. Trata-se de um item que pode ser relevante quando a organização estiver implantando processos de governança corporativa, por exemplo. (***Veja as observações no final do texto).

O padrão RAS foi criado exatamente para funcionar como essa 'etiqueta de patrimônio' para ativos de software reutilizáveis. Ele é estruturado em duas categorias: Núcleo (Core RAS) e Perfis. O núcleo representa todos os elementos fundamentais de um ativo. Os perfis são utilizados para descrever características específicas de um ativo. Por exemplo: podemos ter um ativo que gera orçamentos para o seguro de um automóvel; este ativo possui dois perfis distintos: um para sua versão off-line e outro para a versão web service. Uma etiqueta RAS básica, descrevendo apenas o núcleo, é ilustrada abaixo:

A seção Classificação apresenta todas as características básicas do ativo, inclusive o contexto no qual ele se insere. Solução relaciona todos os artefatos que compõem o ativo. A área chamada Uso contém todas as regras para customização, instalação e reutilização do ativo. Por fim, a seção Ativos Relacionados apresenta todos os ativos que possuem algum tipo de relacionamento com o item em questão.
Obs.: Na próxima parte deste artigo será apresentado o modelo completo para 'etiquetagem' de ativos de software.

É grande a similaridade entre uma etiqueta RAS e os contratos que regem o uso dos serviços em uma SOA. Se a primeira for elaborada dentro do padrão, e o segundo obedecer as melhores práticas sugeridas, obtém-se dois documentos (XML) bastante redundantes. Na realidade a etiqueta RAS parece ser um subconjunto de um contrato. Este apresenta um número maior de informações, relevantes principalmente em tempo de execução.
Obs.: Farei uma pequena pesquisa para saber como tal similaridade está sendo tratada.

[continua]

===

Referências:

Practical Software Reuse
Michel Ezran, Maurizio Moricio e Colin Tully
Springer (2002).
RAS - Reusable Asset Specification - Versão 2.2
Object Management Group (OMG) (05/Nov/2005).

===

Observações:

* Confesso que o termo 'granularidade' cria algumas dificuldades. No inglês é trivial o uso das combinações "coarse-grained" e "fine-grained". Mas a tradução literal não pega muito bem. Sugestões?

** 'Variabilidade' eu traduzi literalmente. Mas acho que deve existir uma palavra melhor na língua portuguesa. Mesmo que, como na especificação RAS original, ela continue sendo utilizada em combinação com o termo 'Visibilidade'.

*** Sobre Gerenciamento de Ativos de Software

É importante notar que o Gerenciamento de Ativos de Software tratado nesta série de artigos difere-se substancialmente daquele que pegou carona na onda Governança, ITIL e afins.

Software Asset Management (SAM), conforme descrição obtida na Wikipédia (em 21/dez/06), significa: "um conjunto de práticas de negócio que incluem a gestão de licenças, gestão da configuração, padronização de imagens e concordância com restrições regulatórias ou legais, como leis de copyright, Sarbanes Oxley..."

O gerenciamento falado nesta série de artigos 'desce' o nível, incluindo em seu escopo itens tão pequenos como um requisito ou um componente de tela.

Categoria(s):

Reuso: Prática Sistemática

2006-12-14T17:25:00.000-02:00

Continuação de "Reuso: Conceitos, Justificativas e Desculpas".

O reuso de ativos de software é uma daquelas várias promessas da área de TI que parecem gerar mais decepções do que resultados concretos. Antes da onda SOA, as propostas que colocaram a reusabilidade como uma de suas maiores vantagens foram a Orientação a Objetos (OO) e o Desenvolvimento Baseado em Componentes (CBD - Component-Based Development). Ambas as propostas tinham o reuso como uma conseqüência natural. Ou seja, não se preocuparam em fazer do reuso uma prática sistemática, planejada. Autores como Grady Booch transferiam para os programadores a responsabilidade de reutilizar ativos de software: "durante a implementação, procure agressivamente por partes que possam ser reutilizadas" [1]. Hoje é dito que "oportunidades para o reuso são como os bugs, quanto antes elas forem encontradas melhor" [2].

O reuso não planejado, chamado por Steve McConnell de "reuso oportunista", careceria de "alguma sorte" para a sua realização [3]. Sendo casual, ele dependeria muito da equipe do projeto e do conhecimento que esse time tem sobre os ativos existentes e projetos anteriores da organização. Hoje pode-se afirmar que os benefícios gerados pelo reuso de ativos de software não podem ser plenamente realizados se dependerem exclusivamente da casualidade - o encontro de coincidências entre dois ou mais projetos - e do conhecimento de uma equipe de projeto.

O reuso sistemático ou planejado de ativos de software significa [2]:

Compreensão de como o reuso contribui para a realização dos objetivos do negócio como um todo;
Definição de estratégias técnicas e gerenciais para que se alcance o máximo valor com o reuso;
Integração do reuso em todo o processo de software e também no programa de melhoria do processo;
Garantia de que toda a equipe possui as competências e motivação necessárias;
Estabelecimento do adequado suporte organizacional, técnico e orçamentário; e
Uso de métricas apropriadas para controle da performance do reuso.

Ao contrário do que se imaginava, o reuso depende muito pouco de tecnologia. Pesquisa realizada com 71 organizações de desenvolvimento mediu o impacto de uma série de fatores na adocação do reuso e concluiu que, das 6 dimensões medidas, a tecnologia é a menos relevante. No reuso sistemático, os fatores mais críticos para o sucesso seriam [4]:

Planejamento e Melhoria Contínua do Processo;
Existência de um Processo Formalizado;
Apoio da Alta Gerência;
Similaridade entre Projetos; e
Arquitetura Comum.

Posteriormente esta série de artigos tratará de cada uma das dimensões apresentadas na lista acima. Neste ponto o importante é a constatação de que "a introdução do reuso sistemático é muito mais do que uma mudança tecnológica: ele deve ser compreendido e gerenciado como um grande conjunto de mudanças no processo de software" [2]. As três primeiras dimensões apresentadas acima, do tipo organizacional, aparecem apenas quando o processo de reuso é sistemático e formalizado perante toda a organização.

É importante lembrar que, como foi colocado no primeiro artigo da série, dois dos principais modelos para melhoria dos processos de software, o CMMI e o MPS.br, não contemplam o reuso. Apesar de indicarem que se trata de um nítido sinal de maturidade do processo de uma organização [5]. Algumas propostas sugerem a adaptação dos grupos de reuso da ISO/IEC 15504-5 para as áreas de processo do CMMI [6]. Há ainda a possibilidade do MPS.br incorporar processos de reuso em versão a ser liberada no primeiro semestre de 2007. Organizações interessadas em adotar o reuso sistemático poderiam optar por incorporá-lo ao seu programa de Melhoria de Processos de Software (MPS) ou tratá-lo como uma iniciativa independente.

No entanto, na implementação de uma SOA, o reuso está no núcleo dos trabalhos. O reuso sistemático não é mais uma opção, mas uma condição crítica para o sucesso de uma iniciativa dessa natureza. Pode-se dizer então que a introdução de uma SOA forçará a adoção de práticas sistemáticas de reutilização de ativos de software. Organizações poderão aproveitar a oportunidade e tornar o reuso um componente fixo de seu programa MPS.

Alto Custo

Edward Yourdon sugeriu uma regra que dizia que um "ativo reutilizável exigirá o dobro do esforço requerido por um ativo comum" [7]. Fred Brooks estima que deve ser "o triplo" do número sugerido por Yourdon [8]. Steve McConnell reconhece que o reuso planejado não é uma prática de curto prazo. "Um programa de reuso pode demorar 2 anos para começar a gerar componentes realmente reutilizáveis". Mas cita que os ganhos de produtividade podem fazer com que a organização passe a realizar 35 pontos de função (PF) / pessoa / mês, contra uma média nacional que seria de 5 PF / pessoa / mês [3]*.

Os autores de "Practical Software Reuse" colocam o tema de outra forma: "todos os custos com software são sempre considerados um overhead". "Por isso", eles continuam, "as avaliações do retorno sobre os investimentos (ROI) em iniciativas de melhorias (seja reuso ou um programa MPS) raramente estão disponíveis e raramente são críveis". No entanto, "independente da forma como o contabilizemos, reuso é um investimento. E todo investimento envolve incertezas, riscos e 'chutes'" [2].

Por tudo isso parece que, sem o envolvimento e o apoio da alta gerência, torna-se quase impossível a implantação de práticas sistemáticas de reuso. E, com certeza, está aqui uma das grandes razões para o fato do reuso nunca ter entregue um mínimo das promessas realizadas nas últimas décadas.

[continua]

===

Referências:

Object Solutions
Grady Booch
Addison-Wesley (1996).
Practical Software Reuse
Michel Ezran, Maurizio Moricio e Colin Tully
Springer (2002).
Rapid Development
Steve McConnell
Microsoft Press (1996).
Strategies for Software Reuse:
A Principal Component Analysis of Reuse Practices
(PDF - Requer registro e pagamento)
Marcus A. Rothenberger et al
IEEE Transactions on Software Engineering, Vol. 29, No 9, (Set/2003).
CMMI Performance Results
Exemplo de um caso específico (Boeing).
Carnegie Mellon / Software Engineering Institute (SEI).
Adaptação dos Processos do Grupo de Reuso do ISO/IEC 15504-5 para as Áreas de Processo do CMMI (PDF)
Leandro de Paula Silva
Monografia de graduação apresentada ao Departamento de Ciência da Computação da Universidade Federal de Lavras (2006).
Decline and Fall of the American Programmer
Edward Yourdon
Yourdon Press (1992).
The Mythical Man-Month - Anniversary Edition
Fred Brooks
Addison-Wesley (1995).

===

* Ah, como eu gostaria de conhecer, nem que fosse um pouquinho só, os números tupiniquins...

Categoria(s):

Reuso: Conceitos, Justificativas e Desculpas

2006-12-14T16:32:00.000-02:00

Continuação de "Gerenciando Ativos de Software".

Obs importante: por se tratar de um compilação de idéias que estou realizando em "run time", a seqüência e conteúdo dos artigos desta série podem ser consideravelmente modificados em sua versão final, um PDF que espero publicar até o dia 11/jan/2007. Nem todas as revisões se refletirão no blog. Optei por falar sobre REUSO nesta 2ª parte por se tratar do grande objetivo da série. O capítulo seguinte, que deve ser publicado na próxima semana, falará sobre Ativos de Software de uma maneira mais específica. Inclusive (re)apresentando* a proposta RAS (Reusable Assets Specification) do OMG e fazendo uma relação da especificação com os elementos que compõem uma SOA.

* A primeira vez que publiquei um material sobre RAS foi em 2004. Está no artigo "Gestão Estratégica de Ativos de Software" [PDF]. Desta vez espero ser um tanto mais específico.

Foto da Crystal.

Reuso é a prática sistemática de se desenvolver software a partir de um conjunto de 'blocos de construção', de forma que as similaridades dos requisitos e/ou da arquitetura entre as aplicações possa ser explorada para que sejam alcançados benefícios substanciais na produtividade, qualidade e na performance do negócio.[1]

O texto acima, transcrito diretamente de "Practical Software Reuse" [1], é uma das mais recentes (re)definições do termo Reuso de Software. É forte porque desconsidera aquilo que Steve McConnell chamou de "reuso oportunista" [2]. O reuso oportunista/casual parece ser a única alternativa oferecida na versão original do RUP, por exemplo [3]. A definição acima também é completa, porque encerra em uma única frase aquilo que seus autores consideram as 4 características-chave do reuso:

É uma prática sistemática para o desenvolvimento de software;
Emprega um conjunto de 'blocos de construção' (artefatos reutilizáveis);
Explora similaridades dos requisitos e/ou da arquitetura entre as aplicações; e
Oferece benefícios substanciais para a produtividade, qualidade e performance do negócio.

Antes de uma análise de cada uma das características listadas, é interessante confrontar a definição acima com o Reuso prometido pela proposta SOA. O artigo anterior citou uma pesquisa [4] que diz que as empresas esperam reutilizar apenas 30% dos serviços implementados. É interessante notar que trata-se de um tipo de reuso relativamente diferente daquele apresentado acima.

Assim como em propostas anteriores, notadamente Orientação a Objetos (OO) e Componentização, o reuso em uma SOA pode acontecer em dois momentos muito distintos:

Em Tempo de Construção, realizado diretamente por um analista ou programador; e
Em Tempo de Execução, realizado por outro ativo.

O reuso em tempo de construção é parte central na implementação de uma SOA. Todos os serviços, particularmente aqueles que representam entidades ou processos de negócios, devem encapsular um ativo existente, independente da sua tecnologia. Uma SOA propõe dar sobrevida para todos os sistemas legados de uma organização. Por isso não faria muito sentido falar de níveis de reuso em tempo de construção de uma SOA.

A pesquisa, encomendada pela Bea [4], não fala explicitamente mas leva a entender que se trata do reuso em tempo de execução. De qualquer forma, a meta (30% de reuso) parece bastante modesta. Os 'blocos de construção' em uma SOA são os seus serviços que, conceitualmente, podem ser categorizados da seguinte maneira:

Básicos: representam entidades (clientes, produtos) ou pequenas atividades (validação de crédito, verificação de disponibilidade em estoque);
Intermediários: únicos que mantêm relação direta com a parte tecnológica da arquitetura (fornecendo pontes, conversores etc);
Processos: representam diretamente atividades ou processos de negócios (vendas, baixa de duplicatas etc).

Espera-se que um serviço em uma SOA seja único na função ou conjunto de dados que oferece. Não faz sentido, por exemplo, que existam dois serviços representando a entidade Clientes. Por isso parece estranha a expectativa de que apenas 1/3 dos serviços seja reutilizado por outros em tempo de execução. De qualquer maneira, os dados disponíveis sobre implementações SOA existentes ou em andamento ainda são raros e vagos.

Experiências com a adoção do reuso sistemático anteriores à SOA mostram que é factível a colocação de metas mais ambiciosas. Alguns casos reportam níveis de reuso entre 50% e 95%! [1] Mais relevantes que as taxas de reutilização são os benefícios gerados diretamente por ela: ganhos de produtividade de 58% por ano em um período de 4 anos [2]; redução de 84% nos custos de desenvolvimento [1]; redução de 70% no tempo de desenvolvimento [1]. Um programa SOA não deve alcançar números tão altos, mas eles devem servir, no mínimo, como uma boa referência para os projetos SOA.

===

[ Continua ]

===

Referências:

Practical Software Reuse
Michel Ezran, Maurizio Moricio e Colin Tully
Springer (2002).
Rapid Development
Steve McConnell
Microsoft Press (1996).
The Rational Unified Process - An Introduction (Second Edition)
Philippe Kruchten
Addison-Wesley (2000).
SOA Research - SOA Justification (PDF - Requer registro)
GCR Custom Research
Patrocinada pela Bea Systems.

Categoria(s):

Gerenciando Ativos de Software

2006-12-11T16:30:00.000-02:00

Foto de Aleatoric_Yersinia

A crescente aceitação da proposta de Arquiteturas Orientadas a Serviços (SOA) fez com que voltasse para agendas e debates um velho tabu da área de TI: o Reuso de Ativos de Software. Uma pesquisa recente, tratando especificamente de SOA, mostra que a maioria das empresas espera reutilizar apenas 30% dos serviços criados. Apesar de 84% delas dizerem que a possibilidade de reutilização de ativos é uma das maiores promessas de uma SOA; uma das maiores justificativas para sua adoção. Vamos aproveitar o debate [1] para tratar o tema de uma maneira mais aprofundada. Este post inaugura uma série sobre o assunto. Gestão de Ativos; Reuso Sistemático; Adequação de processos; RAS (Reusable Asset Specification); GBA (Gestor da Biblioteca de Ativos); dentre outros, serão tratados de maneira específica nos próximos artigos*.

Reuso: Um Tabu

O assunto é tão antigo e batido, com sucessivas ressurreições e decepções, que fará com que muitos profissionais da área simplesmente ignorem a discussão e a nova fase de oportunidades aberta pelo conceito SOA. Data de 1968 a primeira tentativa para tornar o reuso sistemático uma prática [2], uma disciplina obrigatória em Engenharia de Software. Muito tempo depois, de maneira menos impositiva, foi a vez da Orientação a Objetos e da Componentização proporem e facilitarem o reuso de ativos de software. A princípio, os resultados sempre foram desprezíveis. Quando havia algum resultado.

A reutilização de experiências e conhecimentos externos - normalmente apresentados como aplicações, frameworks, componentes, design patterns ou até mesmo código fonte - é prática corriqueira na maioria das organizações que desenvolvem sistemas atualmente. O grande problema, o tabu em torno do reuso de software, é o não aproveitamento dos ativos criados internamente. Qualquer tipo de ativo.

O reuso do capital intelectual - do conhecimento e da capacidade de aprendizado e inovação - é um desafio para todas as áreas de praticamente todo tipo de empresa. Não se trata de uma carência específica da área de TI, apesar de sua natural orientação a projetos e sua intimidade com tecnologias indicarem que seria teoricamente mais simples a adoção de métodos e ferramentas para uma excelente gestão de conhecimentos. Trata-se de uma área que tem muito a evoluir. Erros e falhas recorrentes indicam que o conhecimento não está fluindo de forma adequada. "Os que não conseguem lembrar-se do passado estão condenados a repeti-lo", dizia George Santayana.

No entanto, de todos os ativos que formam o grande inventário da área de TI, aquele que parece mais esquecido ou, colocando de outra forma, relegado a um segundo plano, são os ativos de software. Seus co-irmãos palpáveis, notadamente o hardware e todas as instalações físicas, herdaram métodos e ferramental de controle de todos os outros ativos tangíveis de uma organização. Eles aparecem no controle patrimonial (nos sistemas de Ativo Fixo e Contabilidade) da empresa. Cadeiras, servidores e caminhões merecem uma "etiqueta" de patrimônio. Você usa, e reusa, aquilo que você sabe que possui. Quando conhece sua localização, utilidade, modos de uso, restrições, idade etc.

Autores como Robert Kaplan e David Norton, criadores do Balanced Scorecard, classificam os ativos de software como intangíveis [3]. Talvez sejam exatamente a percebida intangibilidade e a infinita maleabilidade do software que façam com que ele seja um ativo muito mal tratado e pouco controlado. Outro motivo, sugerido por Paul Strassmann [4], seria a falsa idéia de que o ciclo de vida do software obedece aquele ditado pelo hardware (com uma total depreciação em um prazo de 4 anos). É sabido que algumas empresas, particularmente no ramo financeiro, possuem código com mais de duas décadas de vida.

"Sem o legado, cada geração começaria na idade da pedra."
- Paul Strassmann

Visando à valorização dos ativos de software, Strassmann sugere que as organizações [4]:

Adotem ferramentas que forcem a construção de software a partir de um repositório de peças padrão reutilizáveis;
Façam da acumulação e preservação dos ativos de software úteis um de seus principais objetivos;
Ofereçam incentivos para que o staff de sistemas inclua a acumulação de ativos de software como um de seus objetivos-chave; e
Aumentem a longevidade dos ativos de informação ao invés de aceitar a suposição de que eles não valerão nada após o período de breakeven.

Viabilidade

A era industrial se consolidou através do reuso de peças padrão. A economia de escala é indissociável do reuso. As linhas de montagem ganharam a forma que conhecemos hoje após a adoção de conceitos de reuso. O mercado de TI lançou suas "fábricas de software" mas parece ter se concentrado exclusivamente na parte (des)humana da metáfora.

Apesar do reuso sistemático ser considerado um claro indicador de maturidade [5], não há em propostas como o CMMI ou MPS.br [6] uma área ou processo específico para incentivá-lo e controlá-lo. No RUP, amplamente divulgado e relativamente aceito, o reuso de ativos é citado como "facilitado" pelo processo [7]. No entanto, não há uma única disciplina que tente fazer do reuso uma prática sistemática, intencional.

“Os ativos intelectuais, ao contrário dos ativos físicos, aumentam de valor com o uso.”
– James Brian Quinn

O mesmo se aplica para ativos de software (que são um tipo de ativo intelectual): quanto maior seu uso (e reuso), maior seu valor. Por isso causa estranheza, particularmente naqueles "não-letrados" na área, nossa incapacidade ou resistência em fazer do reuso uma prática central, obrigatória. Assim como parece estranha e extremamente pessimista a meta aferida na pesquisa citada no início deste artigo: a reutilização de 30% dos serviços em uma SOA. Casos documentados [5], anteriores à onda SOA, reportam ganhos de até 72% em organizações que adotaram o reuso de ativos de software como uma prática sistemática. Se sua viabilidade é provada em empresas que não têm no desenvolvimento de software uma atividade fim, o que dizer então daquelas que vivem de produzir e comercializar software?

===

* Como em alguns casos anteriores, este artigo é parte de um estudo/trabalho em desenvolvimento. Ao término da série será publicada uma compilação, em formato PDF, com as devidas revisões e considerando eventuais críticas e/ou sugestões recebidas. Sinta-se à vontade para participar.

===

Referências:

Outside the Box (blog de Todd Biske): Use or Reuse?
Software Reuse: Principles, Patterns, Prospects
Mária Smolárová e Pavol Návrat
Slovak University of Technology
Mapas Estratégicos
Robert S. Kaplan e David P. Norton
Editora Campus / Elsevier (2004).
The Squandered Computer
Paul A. Strassmann
The Information Economics Press (1997).
Practical Software Reuse
Michel Ezran, Maurizio Moricio e Colin Tully
Springer (2002).
Hoje (11/Dez/2006) fiz uma consulta ao grupo de discussão CMM-Br. Tudo indica que o MPS.br receberá um processo específico para tratar de Reuso a partir de Abril/2007.
Agradeço os colegas Rafael Prikladnicki e Marcio Pecegueiro do Amaral pelas informações.
The Rational Unified Process - An Introduction (Second Edition)
Philippe Kruchten
Addison-Wesley (2000).

Categoria(s):