Este artigo evidencia aspectos importantes do processo de codificação, traçando um paralelo entre eficácia e eficiência no trabalho do desenvolvedor. Também destaca como a adoção das práticas ágeis proporciona uma melhoria na qualidade do código fonte em projetos de software.
Influência do Mercado no processo de desenvolvimento.
Motivos da baixa qualidade no processo de codificação
O mercado é regido por constantes mudanças que impactam no dia a dia das empresas. Sabe-se que tais mudanças se revertem em alterações, às vezes diárias, nos softwares e consequentemente afetam o ritmo de trabalho do time de desenvolvimento. Diante disso, é necessário, que os desenvolvedores possam corresponder proporcionalmente a essa demanda, fazendo com que as organizações se mantenham, ou se tornem, mais competitivas perante o mercado. É comum que uma pressão recaia sobre o time, uma vez que todo o processo está associado à utilização de sistemas.
Neste cenário, a eficácia passa a ser um caminho natural para responder à demanda do mercado. A eficácia é o menor caminho para alcançar um objetivo. Neste contexto, o objetivo pode ser a correção de um erro que impede o andamento de um determinado processo ou a entrega de uma nova funcionalidade que irá gerar algum diferencial para a empresa.
Porém, nem sempre eficácia e qualidade andam juntas. A grande incidência de código mal escrito é resultado da eficácia buscada pelo time. Geralmente, isso ocorre quando uma demanda classificada como urgente é solicitada pelos gestores. O código de baixa qualidade geralmente tem características como inflexibilidade, fragilidade, alto nível de dependência e baixo grau de entendimento.
Há outros fatores que podem contribuir para a produção de código de baixa qualidade. Considere uma provável necessidade de autoafirmação de um desenvolvedor que deseja mostrar que pode atender com rapidez o que lhe é solicitado. Em situações como essa, é evidente a influência de fatores psicológicos, como, por exemplo, o ambiente de competitividade no time de desenvolvimento.
Consequências da má qualidade de código
Priorizar somente a eficácia no processo de codificação é prejudicial e insuficiente, se tornando uma prática válida apenas para gestores que buscam soluções imediatistas. Conforme mencionado anteriormente, a eficácia resulta em um aumento na incidência de código mal escrito, o que é bastante prejudicial a todos os envolvidos. Para exemplificar este prejuízo, podemos destacar:
Improdutividade resultante da manutenção de códigos de complexos;
Compromete psicologicamente a equipe, devido à sensação de não corresponder às expectativas dos envolvidos;
Proliferação de código de má qualidade;
Expõe a reputação profissional do desenvolvedor, pois deixará uma má evidência do seu trabalho;
Aumento do custo do projeto.
Devido a pouca evolução do projeto, é comum que os gestores exerçam uma cobrança mais efetiva visando alcançar os resultados, o que resulta em maior pressão ao time de desenvolvimento. Além disso, os gestores passam a adotar as seguintes práticas:
Contratação de novos desenvolvedores objetivando maior produtividade da equipe;
Maior fiscalização sobre as atividades de cada desenvolvedor;
Propostas de hora extra, buscando reduzir o prazo de entrega;
Desligamento de membros do time.
Tais ações geralmente não implicam na melhoria da produtividade. Pelo contrário, resultam na insegurança, desmotivação, inchaço da equipe e ainda menor evolução no andamento do projeto.
Utilização das práticas ágeis neste contexto
Adotando o SCRUM como framework, o desenvolvimento de um grupo de funcionalidades (Sprint Backlog) sempre estará associado a um tempo predefinido. Isto garante que a equipe possa realizar o seu trabalho com boa qualidade, em um período que pode variar de duas a quatro semanas.
Neste modelo, há um espaço de tempo definido para a entrega de uma funcionalidade, sendo que a complexidade do trabalho é diretamente proporcional a esse tempo. O conceito de Time Box faz com que o tempo, que antes era um fator crítico, passe a ser aliado do desenvolvedor ao realizar o seu trabalho. O fator tempo passou a ser controlável uma vez que o time pode mensurar a relação entre trabalho desenvolvido e o tempo gasto ou tempo restante.
A adoção das Time Boxes favorece a produção de código de qualidade, obedecendo a boas práticas e convenções específicas do projeto ou da empresa. Quando adotamos o SCRUM, favorecemos ao desenvolvimento de um ritmo de trabalho uniforme, ao aumento da produtividade além de contribuirmos para uma melhora considerável no ambiente de trabalho.
Além do uso de Time Boxes, outro pilar do SCRUM que favorece a qualidade de código é a inspeção. O fato de haver inspeção constante faz com que ocorra diminuição de inadequações no código já que o mesmo será previamente detectado e corrigido. Nesse contexto, devemos salientar que a interdisciplinaridade e autogerenciamento do time de desenvolvimento permitirá que todos possam inspecionar o código, contribuindo para o aprendizado constante e para a prevenção de erros do release.
A programação pareada proposta pelo XP Extreme Programming, permite a refatoração de código quase que de maneira automática. A análise do código de um segundo desenvolvedor é importante e permite que a utilização de determinados métodos ou variáveis seja questionada, repensada e otimizada.
Como atender as constantes demandas do mercado
Entregar releases de forma contínua significa manter o projeto em conformidade com as características do mercado que está em constante mudança. Definir as features que irão compor o próximo Sprint Backlog e saber alinhá-las aos interesses da gerência ou de outros stakeholders é um artifício que permite atendê-los de maneira convincente. O dimensionamento do tempo para desenvolvimento e entrega de releases deve estar associado aos anseios do mercado. Isso está intimamente relacionado à criação de um elo confortável entre a forma de trabalho do time e as expectativas da gerência. Ter um código legível e fácil de manter é um dos requisitos necessários para que o time possa entregar software de forma contínua e em curtos espaços de tempo, estabelecendo um ciclo harmônico entre a empresa e o mercado.
Este artigo inspira-se em conversas que tive ao longo de conferências com alguns potenciais clientes que, expressando sua preocupação com os perigos do desenvolvimento baseado em modelos, me fizeram pensar a respeito.
Na minha opinião, já foram publicados vários artigos sobre os perigos do desenvolvimento baseado em modelos. Muitos deles sustentam argumentos válidos; outros, no entanto, têm um caráter mais histórico e uma natureza repetitiva, e não consideram os recentes avanços nesse tema.
É difícil encontrar artigos que façam referência a “Oito razões pelas quais escrever código manualmente é extremamente perigoso”. Certamente, existem mais de oito razões a serem enumeradas, e até me senti tentado a escrever algumas delas. O desenvolvimento em modelos gera muitos perigos, muitos dos quais originados da não compreensão de seu real valor. Assim, admito que muitos dos riscos mencionados em diversos artigos são reais. Contudo, queria enumerar também algumas das vantagens trazidas pelo desenvolvimento baseado em modelo, conhecido pelo nome “Model-driven Development” (MDD).
1. O MDD é portador de muita flexibilidade Não há dúvidas de que o MDD implica grande flexibilidade para empresas e negócios. A flexibilidade é entendida aqui como a capacidade de dar respostas às mudanças e à adaptabilidade, tanto no que diz respeito à parte técnica como na comercial. Quando, a partir de uma linguagem selecionada, se escreve uma solução à mão, tem-se um tipo de flexibilidade (que se relaciona com o poder dentro da linguagem escolhida…?) em curto prazo, mas, a longo prazo, se está introduzindo uma grande dose de rigidez. Por isso, é fundamental levar em conta, antes de definir que passos seguir, o tempo pretendido de duração do investimento que é o objeto do desenvolvimento.
Quando a escolha é Silverlight, Flash, Visual Basic, Fox, tanto no passado como no presente, é preciso criar aplicativos HTML5 ou iOS. Nesse caso, temos que grau de flexibilidade? E quantos conceitos podem ser reutilizados a partir do código existente, sempre que isso for possível?
Quando o código é criado à mão, tudo o que se obtém é um código que poderá ser reutilizado ou – talvez e mais provavelmente – não. No desenvolvimento baseado em modelos, existe um modelo e a possibilidade de reutilizar conceitos. Quem cria um aplicativo Android a partir do modelo FoxPro Win é quem a longo prazo dispõe de maior flexibilidade. Desse modo, a resposta para a pergunta ”O desenvolvimento baseado em modelos é flexível?” é: depende. Para empresários e companhias que planejam suas atividades a longo prazo, a resposta é: sim, o desenvolvimento baseado em modelos permite uma excelente flexibilidade.
2. Modelos modernos com grandes possibilidades de expansão Atualmente, existem modelos com grande capacidade para estender em distintos níveis e cujos designs são pensados para sua interação com o código escrito à mão em todos os níveis. É comum que grande parte desse código, a médio prazo (se for realmente muito comum), se incorpore ao modelo em algum momento. Não existem modelos perfeitos, embora muitos deles sejam úteis e tenham grande capacidade para se estenderem. O interessante é encontrar uma maneira que conte com a vantagem de produtividade dos MDD, além da possibilidade de extensão, quando o modelo não for suficiente.
3. Os programadores podem concentrar-se mais no “que” do que no “como” É formidável permitir que quem não tem nenhuma ideia sobre Objective C possa criar aplicativos de negócios para iPhone e iPad que cumpram os alinhamentos da Apple e se baseiem em um modelo que também pode ser usado para gerar aplicativos em Android, BlackBerry ou Windows 8, quando for preciso. E tudo isso com um mínimo esforço. Realmente fantástico.
4. Existem plataformas MDD que suportam controle de versões e integração contínua Contrariamente ao que as típicas queixas estabelecem sobre o desenvolvimento baseado em modelos, na realidade, ele pode suportar o controle de versões, a colaboração e outros aspectos. Um exemplo disso é o fato de que estamos trabalhando há muitos anos para obter a atual situação, e é realmente interessante contar com a versão completa de um sistema de controle integrado com ferramentas de integração contínua.
5. Existem ferramentas muito ligadas ao MDD Quase todas as indústrias recorrem ao software para aumentar sua produtividade e melhorar a eficácia de todos os seus níveis operativos. Trata-se de um enfoque óbvio. Entretanto, a indústria do software é a única que se recusa a criar um programa por meio da aplicação de um sistema para cumprir os mesmos objetivos (aumentar a produtividade e melhorar sua eficácia e eficiência). Por sorte, existem muitas empresas que estão bem próximas de uma mudança de paradigma. A única maneira de alcançar essa transformação é por meio da criação de mais ferramentas fascinantes que criem software mediante a utilização de software.
6. A equipe que trata das necessidades deve concentrar-se apenas em aspectos comerciais A equipe responsável por considerar as necessidades pode concentrar seu trabalho no aspecto comercial, sem ter que se envolver com a parte técnica. É comum que a satisfação de certas necessidades seja impossível por causa das limitações do modelo. Porém, isso também acontece com as soluções de código escrito à mão. É muito difícil conseguir que em um formulário exista a possibilidade de um scroll dentro de outro scroll em uma solução Android, mas a causa de tal impossibilidade não deriva do desenvolvimento baseado em modelos. Meu argumento baseia-se no fato de que, como disse antes, uma das maiores vantagens dos modelos atuais é sua interoperabilidade com o código escrito à mão. E, no pior dos casos, será preciso escrever algo à mão. Mas isso não invalida a maior parte das vezes, em que as equipes devem concentrar-se sobre o aspecto comercial da equação em vez de preocupar-se em como programar uma solução em particular.
7. Deve-se vender a solução no paradigma MDD O desenvolvimento baseado em modelos constitui uma maneira diferente de criar soluções, e não é necessário dar explicações ao usuário final, já que ele se encarregará de obter os benefícios. Pode-se apresentar a solução como algo extremamente flexível a longo prazo, em que se salva uma grande quantidade de informação do negócio (representada através dos modelos) que será utilizada no futuro.
8. Já não é preciso se preocupar com a evolução tecnológica Quando se trabalha na gestão de uma empresa, querer aplicar a melhor tecnologia disponível a cada momento é lógico. Mas quando isso implica ter que considerar os detalhes de cada nova tecnologia, estará tirando o foco do aspecto central do negócio. Recorrer ao desenvolvimento baseado em modelos permite concentrar-se apenas no modelo do negócio sem ter que se preocupar com as contínuas mudanças de tendências da tecnologia subjacente.
Esta foi minha aproximação inicial ao tema, mas a lista de razões pode ser aprimorada.*Johan den Haan descreve aqui outras razões para justificar o uso de “Model-Driven Development”.
Vivemos a passagem da topologia da dependência do líder-alfa para a da inteligência coletiva dos formigueiros.
Quanto mais converso com meus alunos, mais vejo o tamanho do desafio que temos pela frente.
Temos que compreender uma mudança topológica do mundo, conseguir digeri-la e adotar práticas para poder lidar com ela.
Ufa, não é pouca coisa.
Nunca na história (desta humanidade como dizia o Lula) tivemos a
chance de perceber a mudança dessa natureza (topológica cognitiva) e ter
de lidar tão rápido com ela, pois cada vez as mudanças nas topologias
estão ficando mais rápidas (se podemos dizer que séculos são rápidos, no
caso da última).
Digamos que vivemos hoje a passagem na placa-mãe da sociedade de uma topologia para outra.
Uma topologia cognitiva define basicamente como nos organizamos como
espécie em todos os sentidos: decidimos, produzimos, conhecemos,
aprendemos.
Vivemos a passagem da topologia da dependência do líder-alfa para a da inteligência coletiva dos formigueiros.
Em termos de topologia já tivemos três, conforme sugeriu Pierre Lévy: oral, escrita e digital.
Podemos dizer, assim, que estamos nos primórdios da topologia
cognitiva 3.0, mais dinâmica e compatível a um mundo de 7 bilhões de
pessoas, que vive em megalópoles.
Muitos dirão que há tempo para se preparar, mas há dois problemas aí:
projetos que estão sendo feitos de redes sociais corporativas estão
fora de foco e vão ser dinheiro jogado fora ( e os projetos estão aí em
desenvolvimento);
e a coisa agora está sendo muito mais rápida do que as anteriores,
por causa da densidade e capacidade de inovação dos polos principais,
todo cuidado é pouco, vide indústria da música.
Vejamos:
Detalhemos.
Note que há por baixo da sociedade uma topologia que define a forma de trocarmos informações.
Podemos apontar, conforme nos sugeriu Pierre Lévy, essas três etapas, que passam pela oralidade, escrita e agora a digital.
Cada uma necessária pelo crescimento da população, que força uma sofisticação topológica, que forma a placa-mãe da sociedade.
Podemos notar que as topologias têm fases, primeiro são beta-testadas em grupos menores e depois se massificam.
Se relacionam com o ambiente presencial: quanto menores os
conglomerados, mais podemos horizontalizar; quando aumentam, é
necessário verticalizar. Na nossa topologia, estamos tentando
horizontalizar a explosão demográfica, por isso estamos adotando o
modelo das formigas.
O modelo topológico da espécie humana adotado té aqui é mais próximo das matilhas, com uma maior dependência do líder-alfa.
A sofisticação da topologia, com novas tecnologias cognitiva,
significa necessariamente o aumento de troca entre os indivíduos para
manter a espécie funcional.
As topologias cognitivas atingem toda a sociedade e é
sobre ela que a gestão vai ser modelada. Assim, não é a gestão que
define a topologia cognitiva, mas o contrário.
Veja o modelo abaixo, que segue um pouco as topologias passadas.
Note que na rede centralizada, todos dependem muito mais do centro, do líder-alfa, com pouca interação entre as pontas.
No segundo modelo, divide-se um pouco o papel das pontas, mas ainda
há uma forte centralização, que vai entrando cada vez mais em crise,
conforme o tamanho da espécie vai aumentando, pois perde-se tempo ao se
depender de um ponto específico.
E, por fim, na distribuída, que é o modelo mais próximo da topologia 3.0, apenas administrada, através de rastros digitais.
A passagem de um modelo de 2 para 3 é hoje
impossível, pois precisamos do líder alfa para definir critérios de
decisão e organizar o fluxo.
O que a topologia cognitiva 3.0 permite, através da rede digital, é a
criação de trocas, a partir de rastros digitais, similar ao das
formigas, que vai retirando a necessidade da supervisão do líder-alfa,
cada vez mais trocamos com os pares palavras e rastros, o que vai nos
permitindo consolidar um novo modelo de gestão mais eficiente do que o
anterior.
Vide os modelos de gestão do Taxibeat, Mercado Livre, Estante
Virtual, todos baseados no Karma Digital, rastros, nos quais quem compra
ajuda a mostrar onde e quando comprou e alguns classificam a qualidade
do atendimento, ajudando aos que vem depois a tomar decisões melhores e
mais seguras.
Essa é a grande mudança, pois conseguimos administrar muito mais
gente, com um modelo de gestão muito mais barato, pois formiga humana
ajuda formiga humana.
Assim, a topologia define a gestão e não o contrário.
Nosso problema é que a atual topologia está nas camadas mais
profundas do nosso cérebro e precisamos criar métodos para conseguir
vê-las e poder modificá-las. Isso é a parte mais difícil.
Toda a estrutura social, incluindo a escola, prepara e
está moldada para o modelo ineficaz da matilha, sendo hoje o
formigueiro a aberração, causando forte estranhamento.
Olá, pessoal! Dando continuidade a série de artigos sobre APEX,
hoje vamos ver como criar uma lista de valores encadeadas no APEX,
denominado “Select List” no APEX e popularmente conhecidas como LOV.
As LOVs encadeadas são aquelas que dependem da seleção de um registro
em uma outra LOV para exibição de seus registros vinculados à LOV
alterada. Por exemplo, em um cadastro de funcionários, temos o
departamento e o sub-departamento ao qual o funcionário pertence. Os
sub-departamentos existentes são listados com base em um departamento
previamente selecionado.
Para esse artigo, utilizarei a aplicação de demonstração que criamos no artigo anterior. Inicialmente, vou explicar um pouco mais sobre as listas de vlores no APEX.
Para criação de uma lista de valores em uma página, devemos incluir/alterar um item de página, para o tipo “Select List”:
Existem propriedades expecíficas para cada tipo de item. No caso de
um item “Select List”, é habilitado a seção “List of Values”:
Nesta seção, podemos ver as seguintes propriedades:
Named LOV: Podemos selecionar uma LOV previamente criada e compartilhada para todas as páginas da aplicação;
Display Extra Values: Define se a LOV permite a exibição de valores
extras, que não existem na lista de valores. Por exemplo, é feito uma
LOV sobre o campo TIPO_FUNCIONARIO da tabela FUNCIONARIO. Os
tipos de funcionários previstos são CLT e PJ, mas por algum motivo não
identificado existe um registro que contém o valor CLT-Flex nessa
coluna. Com a opção Display Extra Values ativada, a LOV irá exibir
CLT-Flex, caso contrário a LOV será exibida somente com CLT e PJ;
Null Display Value: Define quais são os valores para o conteúdo
nulo. Por exemplo, quando é criado um novo registro na tabela
FUNCIONARIO, o campo TIPO_FUNCIONARIO é nulo. Podemos fazer um tratamento para essas condições, exibindo a opção “Selecione”;
Cascading LOV Parent Item(s): Define que a LOV sera atualizada em
tempo de execução quando o item informado for alterado. Por exemplo,
quando essa for uma LOV encadeada, quando selecionado um registro da LOV
de departamento, a LOV sub-departamento deverá ser atualizada;
List of Values Definition: Deve ser informado uma query ou a definição estática dos elementos que serão exibidos na LOV.
Por exemplo:
Query: ”SELECT DESC_DEPARTAMENTO, ID_DEPARTAMENTO FROM
TB_DEPARTAMENTO”, onde o primeiro campo será o valor de exibição da LOV e
o segundo o valor de retorno.
Estática:”STATIC:Funcionário;CLT,Terceiro;PJ”, onde o STATIC define
que é uma LOV de conteúdo fixo, seguido por valor de exibição da LOV e
valor de retorno.
Para visualizar mais exemplos de como criar a LOV, clique em “List Of Values Examples”:
Agora que sabem quais são as principais propriedades de uma LOV,
vamos criar uma LOV encadeada. Para isso, vamos criar as tabelas TB_DEPARTAMENTO e TB_SUBDEPARTAMENTO, com o relacionamento 1:N da tabela TB_DEPARTAMENTO para a tabela TB_SUBDEPARTAMENTO:
Também será necessário incluir as colunas ID_DEPTO e ID_SUBDEPTO na tabela TB_FUNCIONARIO para podermos referenciar a qual departamento e sub-departamento um funcionário pertence.
Após criar as tabelas e as colunas, vamos criar os campos na página
de cadastro de funcionários. Clique com o botão direito sobre o nome da
região onde deseja colocar a LOV e selecione a opção “Create Page Item”:
Selecione o tipo “Select List”:
O campo departamento será chamado P2_DEPARTAMENTO, pois ele
está sendo criado na página 2. Vamos defini-lo como preenchimento
obrigatório, assim sempre será requirido que o campo contenha valor.
Na seção “List Of Values”, vamos colocar a query que lista os departamentos do funcionário:
Neste
momento também vamos colocar o texto “Selecione”, que torna mais
agradável para quando o usuário estiver criando um novo funcionário e o
campo estiver nulo.
Na seção SOURCE, devemos informar ao APEX sobre qual campo da tabela TB_FUNCIONARIO esse item é referente. Isso permitirá que o APEX automaticamente insira, atualize e leia as informações desse novo campo:
Deve-se mudar a propriedade “SOURCE TYPE” para “Database Column” e informar o nome da coluna referente ao id do departamento na tabela, no caso ID_DEPTO. Deve-se criar o Item P2_SUBDEPARTAMENTO da mesma forma que o item acima.
Na seção “List of Values”, informe a query conforme abaixo:
Na query, o campo ID_DEPTO, da tabela TB_SUBDEPARTAMENTO, está sendo filtrado pelo conteúdo do campo P2_DEPARTAMENTO. Veja que na propriedade “Cascading LOV Parent Item(s)”, foi informado o campo P2_DEPARTAMENTO à
LOV dos departamentos, ou seja, quando for escolhido um departamento a
LOV de sub-departamentos sofrerá uma atualização e será filtrado os
sub-departamentos do departamento escolhido anteriormente. Isso irá
demonstrar o efeito de encadeamento.
Por questões meramente estéticas, vamos deixar a largura da LOV
sempre fixa. Para isso vamos colocar o texto style=”width:120px” na
propriedade HTML Form Element Attributes da seção Element.
Agora, vejamos o resultado:
Pessoal, nesse artigo vimos como criar uma LOV encadeada – é muito
comum sua utilização e outras tecnologias. E hoje vimos como é simples
sua criação no APEX. Para acessar aplicação demo utilize o link http://apex.oracle.com/pls/apex/f?p=30361.
A convergência de quatro grandes ondas tecnológicas, que são
Cloud Computing, Big Data, Mobilidade e Social Business provocam
disrupções e, portanto, tanto oportunidades como riscos aos negócios e
às áreas de TI atuais.
Adotar e gerenciar de forma eficiente e eficaz essas quatro ondas vai
causar impacto significativo nos gestores e profissionais de TI. Dois
aspectos se destacam: governança e gerenciamento desse novo ambiente, e a
essencial necessidade de repensar a arquitetura de sistemas que irão
compor os novos sistemas que englobarão essas ondas tecnológicas. Neste
artigo, vamos debater a questão da arquitetura desses novos sistemas.
Os sistemas atuais, desenvolvidos pelo paradigma cliente-servidor,
não foram feitos para integrarem de forma consistente recursos como
social business, mobilidade e Big Data, e nem foram concebidos para
operarem em ambiente de nuvem. Compreensível. Tudo é muito novo. Afinal,
a onda da mobilidade começou a se formar com o sucesso do iPhone
(lançado em 2007) e dos tablets (marcado pelo anúncio do iPad em 2009).
Social business foi encarado como igual a Facebook e visto apenas como
mais um meio de o marketing se relacionar com seus clientes, sem maiores
preocupações com os sistemas legados da corporação. Big Data foi
inicialmente visto como um novo nome para Data Warehouse e, portanto,
“já fazemos isso”, e cloud surgiu com grande desconfiança. Aliás, a
mesma de vinte anos atrás começava-se a falar em client-server!
O cenário tecnológico atual é muito diferente do de anos atrás. O
ambiente central era o ERP, e tudo girava em torno dele. Hoje, o ERP
continua como base de processamento de dados transacionais, mas atende a
apenas de 30% a 40% das necessidades de informações de uma empresa. Os
novos sistemas devem atuar de forma integrada com as ondas tecnológicas.
Ou seja, uma interação via mídias sociais, oriunda de um tablet, gera
uma transação de venda e baixa do estoque, passando por uma análise,
provavelmente em tempo real, do perfil do cliente, para propor uma ação
promocional de cross-selling.
Esse contexto nos leva a uma arquitetura baseada em serviços (e tem
gente que disse que SOA morreu… O termo SOA pode ter até desaparecido,
mas aplicações orientadas a serviço são uma demanda real e bem
presente), pois os princípios básicos desse modelo (encapsulamento,
separação de funções, baixo nível de acoplamento etc.) permitem
desenvolver as aplicações com esse nível de integração com tantas e
diversas tecnologias.
Bem, começam agora as dificuldades. Primeiro, capacitação. Depois de
um período de esplendor, no qual SOA era a sigla da moda, o termo caiu
em desuso e infelizmente hoje nem todos os desenvolvedores estão
capacitados a desenvolver aplicações que sejam realmente SOA. Além
disso, nos últimos anos, a concentração da capacitação foi no modelo
cliente-servidor, acoplado ao paradigma teclado-mouse, Portanto, não é
fácil conseguir desenvolvedores com skill para desenvolver novos
aplicativos, touch-screen, integrados com plataformas de social business
e atuando com tecnologias de Big Data em tempo real, em um ambiente de
nuvem. A própria academia não está preparando adequadamente esses
profissionais. Recentemente, estive em uma universidade de peso, e os
temas Big Data, Cloud Computing, Mobilidade e Social Business eram
palestras de uma hora cada, em um currículo de quatro anos. Ou seja,
estavam formando profissionais para um mundo que já é passado…
Vamos debater um pouco mais essa arquitetura. O conceito básico dos
novos sistemas provavelmente será “everything is a service”, e a
aplicação central será um framework com APIs que permitirão aos usuários
e outras empresas desenvolverem novas funcionalidades. Um exemplo
simples: por que a tela do Internet banking tem que ser a mesma para
todos os usuários? Se os acessos aos recursos básicos forem efetuados
vias APIs seguras, o banco ficará responsável apenas pelos sistemas core
( e eventualmente uma home page padrão, como default), deixando as
interfaces serem desenvolvidas por outras empresas e pelos próprios
usuários. As características dessa arquitetura são essencialmente SOA:
alta modularidade, serviços distribuídos (os serviços podem estar em
nuvens de diversos provedores), baixo nível de acoplamento e fácil
substituição de serviços (modelo adotado pelas empresas típicas da Web,
sempre em beta mode, ou seja, evoluindo constantemente os serviços, sem
impactar o que opera ao seu redor).
Uma sugestão é usar como benchmarks para os novos sistemas, não os
modelos de aplicações que as demais empresas do setor usam, mas olhar as
empresas da Internet e avaliar como elas resolvem o desafio de estarem
atendendo a imensos volumes de dados, implementando constantemente novas
funcionalidades e usando APIs para fomentarem um ecossistema de novas
aplicações criadas por outras empresas e pelos seus usuários. Um bom
exemplo é a Amazon.com. É uma aplicação tipicamente SOA, com APIs
abertas para novas funcionalidades. Para ter uma ideia da arquitetura da
Amazon.com recomendo acessar este texto,
principalmente a sessão Lessons Learned. Claro que o modelo de
aplicações da Amazon não é válido para todas as empresas, mas serve de
referência de “best practice” para uma aplicação SOA de alta
escalabilidade, principalmente para empresas com volume significativo de
clientes, como bancos, grandes varejistas, telcos e cartões de crédito.
Enfim, estamos diante de grandes mudanças que vão afetar as áreas e
os profissionais de TI. A arquitetura de sistemas e os arquitetos de
software passam a ter um papel da maior importância, mas devem estar
preparados para essas mudanças! Talvez a melhor frase final seja “SOA is
Dead, Long Live to services”.
Mais um artigo da série Agile! Veremos como escrever boas user
stories. Este é um ponto importante, pois uma boa user story deve ser
entendida tanto pelo team técnico quanto pelo cliente/PO.
Lets…
Sabemos que escrever as user stories é “trabalho” do PO, mas na
teoria, porque na prática quem vai escrever ou é o Scrum Master ou o
time. Nem sempre a realidade do mercado consegue seguir o que temos na
literatura. Mas o objetivo deste artigo não é esse e sim tentar
responder: “as user stories do seu projeto são boas?”. Ou seja, para seu
cliente, ela é valiosa? Ele olha para ela e sabe de fato o que
significa que será feito?
Estou lendo o livro The Samurai Agile,
de Jonathan Rasmusson (em breve vou publicar um review sobre ele); em
um dos seus capítulos ele aborda sobre o assunto e vi que já cometi
alguns erros quando precisei escrever user stories há um tempo, em um
projeto pessoal. Um dos problemas foi não ter percebido o quanto alguns
pontos na user story estavam técnicos. O autor faz uma pergunta
interessante: “Se seu cliente estivesse com fome e ele tivesse que
escolher apenas entre as duas opções abaixo, o que seria mais claro para
ele?”
1. História: Ernie’s Tech Diner
C++ 3 days
Connection pooling 2 days
Model-View_presenter pattern 5 days
2. História: Sam’s Business Pancake House
Create user account 3 days
Notify subscribers of new listings 2 days
Cancel subscription 1 day
Com certeza a história dois faz mais sentido para o negócio do
cliente. Os termos são simples e fáceis de serem entendidos. E o mais
comum: quando somos muito técnicos e escrevemos como na primeira
história, o SM deve ficar atento com isso caso todo o time esteja
participando da escrita das US. E em outro exemplo o autor trouxe que
podemos ser técnicos e o cliente entender. A história abaixo não perde
seu valor:
Add database connection pooling: é dificil para o cliente entender
Mas…
Reduce page load time from 10 secs to 2 secs.
Parece que faz mais sentido para o cliente e você já sabe o que
acontece nos bastidores para atingir o objetivo da user story (US).
Enfim, qualquer US deve ser do tipo INVEST, ou seja, independente, negociável, valiosa, estimável, small (pequena) e testável.
Independente: sua história não pode depender de outras histórias, caso isso aconteça é preciso quebrá-la.
Negociável: é que ela pode ser alterada e adaptada e não fechada.
Testável: que seja possível criar testes que valide aquela história. Algo como:
Login with expired:
Testable:
– redireciona logins expirados
– mostra mensagens de erros apropriadas
Small & Estimatable: não tem que ser grande e sim pequena para que possa ser estimável, quanto maior, mais difícil é estimar.
Recentemente fui procurado por um colega desenvolvedor para
ajudá-lo a resolver um problema que, segundo ele, estava lhe tirando o
sono.
O problema parecia muito simples à primeira vista: era necessário
escrever uma declaração SQL para atualizar um campo Matched caso um ID
de usuário aparecesse em duas tabelas que eram alimentadas com dados de
sistemas diferentes.
A coisa parecia elementar, até que meu colega observou um detalhe: as
tais tabelas possuíam chaves primárias compostas. Isto é, a chave
primária era definida por uma combinação de colunas ao invés de um única
coluna, como acontece no caso das chaves primárias simples. E este
detalhe faz muita diferença na implementação da solução.
Alguns SGBDs, como o SQL SERVER, suportam o uso de junções de tabelas
dentro de declarações UPDATE, o que facilita em alguns casos especiais.
Mas a maioria dos SGBDs que eu conheço não aceita esta sintaxe.
Vejamos alguns exemplos de sintaxe.
Digamos que o problema descrito acima envolvesse apenas chaves
simples (a coluna UserID). Se eu usasse o SQL SERVER, poderia escrever
assim:
--sintaxe SQL SERVER
UPDATE MyTable
SET Matched = 1
FROM MytTable M INNER JOIN OtherTable O ON M.UserID = O.UserID
Uma maneira mais usual de se escrever isso e que seria aceita DB2,
ORACLE, POSTGRES e vários outros, seria usando o operador IN na cláusula
WHERE.
-- sintaxe genérica (DB2, ORACLE, SQL SERVER, POSTGRES...)
UPDATE MyTable
SET Matched = 1
WHERE UserID IN (SELECT UserID FROM OtherTable)
O problema é que esta solução só funciona quando temos uma única
coluna na cláusula WHERE. Ou seja, isso não resolveria o problema de uma
tabela com chave primária composta. E como nosso SGBD não suportava uso
de JOIN na declaração de UPDATE, tive que encontrar outra estratégia.
Na solução que eu propus para o problema inclui a cláusula WHERE, mas
usa outro operador: EXISTS. Este operador é pouco usado e muitas vezes
esquecido. Mas cai como uma luva na solução deste problema.
O EXISTS testa se uma subconsulta retorna algum registro. Se retornar
1 ou mais registros, o resultado é VERDADEIRO. Se for vazia, o
resultado é FALSO.
No caso em questão, as tabelas envolvidas (MyTable e OtherTable)
possuem chaves primárias compostas por dois campos : UserID e Account. A
ideia é combinar as chaves das duas tabelas dentro da subconsulta.
Com estas informações, não foi difícil montar uma nova declaração UPDATE, como mostro a seguir:
UPDATE MyTable M
SET M.Matched = 1
WHERE EXISTS (
SELECT 1
FROM OtherTable O
WHERE O.UserID= M.UserID
AND O.Account = M.Account
)
Um detalhe: com a consulta acima faz um teste baseado na chave
primária das tabelas, é de se esperar que o UPDATE rode com uma boa
performance.
Esta solução acabou sendo implementada e a aplicação que a usa vai muito bem, obrigado.
Olá, pessoal. Como DBA há algum tempo, acabo fazendo várias
consultorias em diferentes clientes que têm problemas com seus bancos de
dados. Entre os cenários de bases de dados que eu encontrei,
provavelmente o aspecto que mais afeta o meu trabalho é lidar com
modelos de banco de dados grandes e complexos, que foram criados para
satisfazer os requisitos de armazenamento dos dados.
A origem destes modelos não é incomum nos dias de hoje: com novos
requisitos sendo agregados aos sistemas existentes, os desenvolvedores e
outros profissionais têm que modificar os objetos do banco de dados,
criar novas tabelas, relacionamentos, colunas, tipos de dados e assim
por diante. Além disso, é fato que se a empresa cresce, os dados
armazenados também tendem a crescer muito, o que aumenta a complexidade
para executar tarefas de manutenção no modelo, nos dados, nos objetos, e
no banco de dados em geral. Deste modo, a fim de ser preparado para
lidar com modelos de banco de dados grandes e complexos, apresento
algumas dicas que preparam o terreno e ajudaram a resolver os problemas
do banco de dados do cliente que me contratou para a consultoria.
O objetivo principal deste artigo é apresentar algumas dicas para
ajudar os profissionais que precisam trabalhar com modelos de bancos de
dados complexos, grandes e de difícil compreensão, que qualquer um pode
encontrar no trabalho do dia a dia. Normalmente, esses modelos de banco
de dados armazenam milhares de gigabytes em muitos objetos relacionados,
que podem ser usados por centenas de usuários simultâneos. Então, ter
algum tipo de lista TODO para lidar com este tipo de bases de dados
especiais pode ser boma não apenas para resolver problemas imediatos,
mas também para organizar o trabalho para futuras necessidades e tarefas
de manutenção. Apenas para pontuar, recomendo para aqueles que possuem
pouca experiência com modelagem de banco de dados escutar o episódio do DatabaseCast que fala sobre modelagem de dados.
Sem mais delongas, estas são as minhas dicas para aqueles que têm de
compreender e manipular rapidamente um modelo de banco de dados grande
sem ser seu criador.
1. Identificar as maiores, mais cheias mais usadas tabelas no modelo
Todo modelo de banco de dados grande tem pelo menos uma tabela
principal que contém uma elevada porcentagem do tamanho do banco de
dados. Este é um fato observado através de muitos anos de experiência.
Também é comum encontrar nesta tabela uma grande quantidade de colunas
com tipos de dados diferentes. Na maioria dos casos, essas tabelas
grandes são as mais acessadas e utilizadas pelas aplicações e, por isso,
é muito útil e recomendado conhecer e reconhecer estes objetos
rapidamente, uma vez que você provavelmente vai acabar trabalhando com
eles mais cedo ou mais tarde. Possuir uma maneira de diferenciar essas
tabelas dos outros objetos em um diagrama é um plus que pode economizar
tempo quando for necessária uma olhada rápida no modelo.
2. Use uma ferramenta de controle de versão ou de gestão de configuração
Hoje existem muitas ferramentas que oferecem recursos para acompanhar as
mudanças ao longo do tempo no modelo de banco de dados, como já citado em outro artigo.
Novas colunas, relacionamentos, mudanças de tipos de dados e outras
modificações menores como estas são comuns em modelos de banco de dados
grandes, que tendem a evoluir constantemente para se adaptar a novos
requisitos de negócios e pedidos de mudança na aplicação. O uso de
ferramentas de controle de versão pode requerer a geração de um script
contendo a definição da base de dados dos objetos ou tarefa similar.
Como alternativa, já existem recursos para integrar as ferramentas com
IDEs existentes, tais como o Microsoft Visual Studio.NET com o Team
Foundation Server. Sendo assim, o argumento de que os DBAs não precisam
utilizar alguma ferramenta de controle de versão porque eles não fazem
nenhum programa não é mais aceitável hoje em dia.
3. Saiba como imprimir o modelo de banco de dados completo ou parcial
Ah, o modelo de banco de dados impresso! Milhares de escritórios e
paredes dos departamentos de TI ao redor do mundo são decorados com
essas relíquias que se tornam onipresentes quando o modelo de dados se
torna grande. Como eu aprendi com as muitas equipes que eu trabalhei, há
sempre alguém que pede uma versão impressa de algum objeto ou até mesmo
o modelo de banco de dados inteiro. Portanto, é importante sempre ter
uma maneira simples, rápida e fácil de imprimir uma tabela, ou um
conjunto de tabelas e seus relacionamentos. Opções para gerar arquivos
PDF, imprimir o modelo de banco de dados em páginas separadas (seguido
pela tediosa tarefa de grudar as folhas na ordem) e o uso de cores
diferentes de papel para identificar versões e outros metadados do
modelo estão entre as práticas que vem a calhar para um DBA que trabalha
com uma equipe de desenvolvedores.
4. Identifique os objetos complementares mais utilizados (stored procedures, triggers, funções, índices)
Uma vez que o banco de dados não é composto apenas por tabelas e seus
relacionamentos, é muito pragmático conhecer os outros objetos que
acessam, controlam e manipulam as principais tabelas mencionadas no
primeiro item deste artigo. Eu descobri que os modelos de dados grandes
geralmente empregam muitas stored procedures, views, funções, triggers e
outros objetos que são tão importantes quanto as tabelas que armazenam
os dados. Conhecer a lógica por trás das principais linhas de código que
compõem esses objetos pode economizar tempo durante a depuração,
diminuir o esforço necessário para o processo de tunning e colocar o DBA
em uma posição muito confortável quando há a necessidade de modificar
os dados.
5. Tenha como visualizar o banco de dados em camadas separadas: com e
sem relacionamentos, com e sem índices, com e sem constraints, etc
O mercado é inundado com ferramentas CASE de modelagem que podem
ajudar os profissionais a lidar com grandes modelos de banco de dados
lógicos e físicos. No entanto, se estes modelos puderem ser criados de
forma interativa e incremental da mesma forma como uma imagem é criada a
partir de camadas, o DBA pode ter um meio poderoso para visualizar
detalhes específicos sem toda a complexidade de um modelo grande. Por
exemplo, imagine um modelo de banco de dados de um ERP (Enterprise
Resource Planning) que contém tabelas originais e algumas tabelas
criadas para a integração com um sistema de intranet existente ou mesmo
customizações adicionais ao ERP. Seria muito importante se o DBA pudesse
simplesmente esconder as tabelas do modelo que vieram a partir da
integração com a intranet e, assim, visualizar as informações
necessárias para uma tarefa específica que exige apenas as tabelas de
ERP e vice-versa. Este tipo de disposição em camadas do modelo é uma
maneira muito inteligente para separar e isolar as partes do modelo que
são específicas para uma tarefa, de modo a evitar a propagação da
complexidade do modelo.
6. Use retângulos coloridos para agrupar tabelas de um mesmo subsistema
Outra abordagem que pode ser utilizada para separar e isolar partes
do modelo sem modificá-lo é o uso de desenhos coloridos. Por exemplo,
retângulos coloridos são praticamente um padrão de modelagem utilizado
quando existe a necessidade de separar os subsistemas de um modelo. Esta
técnica é fácil, simples e não apenas agrupa tabelas e relacionamentos,
mas também melhora a legibilidade e a documentação do modelo. É claro,
comentários sobre os elementos do modelo são muito úteis quando eles
descrevem em poucas palavras informações que podem levar horas de estudo
e análise para serem obtidas.
7. Obtenha a ordem correta para inserir, atualizar e remover os
dados em tabelas específicas, respeitando os relacionamentos entre elas
Este item é um pouco complicado, pois geralmente a ordem correta para
inserir, atualizar e remover os dados em tabelas do modelo é programada
na aplicação ou no interior de um objeto no banco de dados como, por
exemplo, uma stored procedure. A parte complicada é que as modificações
são influenciadas e moldadas por regras de negócios e, às vezes, é quase
impossível separá-los. No entanto, se o DBA pode realizar essa
separação e criar um script que inseria, atualize ou remova corretamente
os dados nas tabelas da mesma forma como eles são feitos através da
aplicação, o profissional aumenta seu arsenal de scripts e pode
economizar várias horas durante um chamado ou situação emergencial. Por
favor, não me interpretem mal: eu não estou sugerindo que o DBA ou
qualquer outro profissional deva modificar diretamente os dados da
tabela sem passar pela aplicação (o famoso forçar o dados na mão ou por
debaixo do pano) a fim de resolver rapidamente um problema. O que estou
sugerindo é que o conhecimento de como as tabelas interagem entre si
para uma operação ou tarefa específica pode ser muito útil e deve estar
no conjunto de ferramentas do DBA.
8. Sempre tenha uma forma rápida de procurar pelo nome dos atributos
Modelos complexos podem conter centenas ou mesmo milhares de objetos
de banco de dados. É prudente ter uma maneira simples de pesquisar e
obter informações de metadados a partir dele. Quase sempre é preciso
saber exatamente qual tabela ou view interna do banco de dados contém a
informação quando o DBA está à procura de algo. Boas ferramentas CASE de
modelagem também fornecem opções e recursos adicionais para pesquisas
básicas e avançadas nos elementos de modelagem mesmo se o estágio de
criação do diagrama estiver no início.
9. Tenha um script que gere todos os objetos banco de dados com uma fração de seu dados (10% é ok)
Este ponto é mais uma dica pessoal do que uma ferramenta obrigatória.
Em várias ocasiões eu precisei criar um ambiente novo de banco de dados
para teste/produção/ homologação (ou para qualquer combinação destes) a
partir de um modelo de banco de dados existente. Estas situações exigem
que os todos os objetos devam ser criados em um servidor diferente (às
vezes virtualizado) com toda a complexidade do modelo, porém com apenas
uma fração de seus dados. A marca de mais ou menos 10% parece ser uma
taxa de dados aceitável para começar, porque pode haver ocorrências de
determinadas entidades (produtos, clientes, funcionários, configurações
de aplicativos, etc) no banco de dados necessárias para que a aplicação
funcione. O script necessário para criar todos os objetos é trivial e
pode ser gerado automaticamente por uma ferramenta fornecida pela base
de dados, mas a geração da ordem correta para inserir os dados pode ser
uma tarefa complexa, como discutido no item 7.
10. Mantenha uma lista atualizada das permissões nos objetos mais
comuns para saber rapidamente o que um usuário específico pode e não
pode fazer com os objetos
Talvez a tarefa administrativa mais comum de um DBA envolva o
gerenciamento de permissões. Os comandos DCL (Data Control Language) e
as interfaces gráficas de usuário das ferramentas administrativas de
banco de dados fornecem uma maneira adequada e simplificada para
concessão, revogação e negação das permissões de um objeto para os
usuários. Assim, o DBA que trabalha com um modelo complexo tem que estar
ciente das permissões atribuídas para os objetos e os usuários. A
separação de permissões em grupos pode ser muito útil, mas saber como
indicar rapidamente qual grupo possui um conjunto específico de
permissões para as tabelas de um subsistema do modelo é uma habilidade
imprescindível que qualquer DBA deve possuir. Contar com uma
documentação resumida e agrupada descrevendo as permissões do usuário
para as principais tabelas e objetos pode ter um grande impacto na
realização de tarefas administrativas diárias, especialmente se o banco
de dados trata a segurança de acesso de forma diferenciada.
11. Saiba como prever e estimar o tamanho de objetos específicos para prever o crescimento ou encolhimento do banco de dados
Previsões baseadas em dados reais e modelos estatísticos, criados a
partir de uma distribuição de dados, podem ser muito úteis quando há
necessidade de criar um relatório sugerindo a alocação e/ou realocação
de recursos de banco de dados que afetam os custos de hardware e largura
de banda. Na minha experiência com consultoria achei mais profissionais
atuando por “achismo” do que eu gostaria de admitir quando há
necessidade de justificar alocação/realocação de recursos de banco de
dados. Aqui a dica é simples: sempre monte suas sugestões com base em
estatísticas, métricas, medidas, necessidades e demandas reais para
tornar o seu argumento sólido ao invés de criá-lo na suposição e valores
pobres, previstos sem uma base estatística concreta.
12. Mostre no modelo quais objetos possuem opções de
particionamento, se eles são compactados e a quais os grupos de arquivos
eles pertencem
Os bancos de dados relacionais atuais possuem muitas opções para
particionamento, compressão e de separação interna dos dados armazenados
dentro das tabelas. Ao fazer tarefas de manutençã,o é importante saber
quais tabelas são compactadas, possuem particionamento ativado, como
este particionamento é implementado e onde os dados são armazenados
fisicamente (ou seja, os grupos de arquivos e os arquivos de dados). No
entanto, o modelo de dados e o diagrama de ER não tem uma notação
específica para representar este tipo de informação, pois isso é
responsabilidade do DBA descobrir como descrever e documentar essas
opções e configurações. Comentários, cores diferentes, figuras
geométricas ou até mesmo uma pequena tabela indicando como o
particionamento separa os dados são sugestões que podem tornar o modelo
mais rico e aumentar a percepção da DBA sobre opções e configurações
apenas dando uma rápida olhada no diagrama.
13. Em modelos OLAP centralize a tabela de fatos e tenha à mão uma
maneira de visualizar as hierarquias principais, os níveis, membros e
grãos de cada tabela de dimensão
Modelos de dados OLAP, implementados no estilo estrela, floco de neve
(snowflake) ou uma mistura desses dois estilos, tendem a ser mais
simples que os complexos modelos de dados OLTP. Uma das razões para isso
é porque há mais planejamento envolvido durante a elaboração das
relações e as entidades do que o planejamento de modelos OLTP. Além
disso, as definições das dimensões, níveis, hierarquias e grãos cria uma
estrutura lógica de dados que é facilmente visualizada após uma
inspeção dos detalhes da tabela. No entanto, a documentação pobre das
características de dimensões e as suas relações com os dados da tabela
faz com que o modelo seja mais difícil de compreender. Uma ideia para
simplificar a compreensão de um modelo de dados OLAP é centralizar a
tabela fato no diagrama de tal maneira que ela se destaque das outros e
possa ser claramente identificada à primeira vista. Decorar o modelo com
abundância de informações agrupadas sobre a estrutura e metadados das
dimensões também é uma boa prática que pode economizar tempo quando é
preciso imaginar como os dados vão ser mostrados quando o usuário
estiver navegando em um cubo de dados.
Depois de explicar essas dicas, é fácil perceber a maioria delas se concentra na documentação do modelo de banco de dados e seus objetos.
Obviamente, os principais esforços no desenvolvimento de sistemas estão
relacionados à implementação de novos requisitos e alteração de
recursos existentes. No entanto, a comunidade de TI e especialmente os
DBAs, devem insistir na tarefa de documentação não apenas no código
fonte ou no software a ser entregue, mas também em artefatos que são
importantes para todo o ciclo de desenvolvimento.
Ao seguir as dicas apresentadas neste artigo, os leitores podem se
preparar melhor para lidar, entender e trabalhar com modelos de dados
grandes e complexos. Este cenário não é incomum conforme a aplicação vai
recebendo mais dados. Contar com algumas dicas e melhores práticas
pode ajudar o profissional quando é preciso lidar com dados em um banco
de dados complexo e um modelo extenso. Os leitores que apreciaram as
dicas deste artigo podem encontrar mais conteúdo como este no meu livro
chamado Conversando sobre Banco de dados, já a venda.
Neste artigo vou trazer o que ganhamos ao escrever User Stories
ao invés de ter que gastar mais tempo escrevendo documentações de
requisitos. Não estou dizendo que não devemos documentar, pelo
contrário. Porém, a ideia é saber o que e como documentar.
O User Stories promove os seguintes pontos:
Aprendizado;
Precisão;
Encoraja a comunicação face-to-face com o cliente;
Possibilita feedback em tempo real;
Evita a falsa sensação de que temos tudo documentado de forma correta e só falta implementar;
Permite uma colaboração e inovação com o time.
Já os documentos de requisitos:
São grandes e cansativos;
Encoraja o trabalho por imaginação com falsos ‘achismos’;
É difícil de planejar;
Feedback em tempo real é inexistente;
Desencoraja abertura de colaboração e invocação com o time.
Isso quer dizer que não vou documentar? Não. Em um projeto Agile há
documentação sim, porém ela não é o meio primário de obter as coisas e
nossa última fonte de obter o entendimento, conversar com o cliente, é
mais importante. A diferença é que aqui evitamos o desperdício do tempo
documentando, pois ao terminar toda documentação, o que foi escrito no
início talvez não tenha mais valor para o cliente.
Vou ficando por aqui. Espero que tenham curtido o artigo e possam colocá-lo em prática na realidade de vocês.
Este é o terceiro e último artigo da série que aborda
perspectivas futuras para empresas de software. Com a revolução digital,
estamos diante da possibilidade de analisar um volume inédito de dados
digitais, o fenômeno chamado Big Data, que para as empresas
provavelmente terá um impacto tão grande em seus processos de negócio e
decisão quanto a popularização da Internet.
As informações vêm de todos os cantos. Vêm dos mais de 600 milhões de
sites, vêm dos 100 mil tuítes por minuto, dos compartilhamentos de mais
de um bilhão de usuários do Facebook, que geram pelo menos 2,7 bilhões
de comentários diariamente, dos sensores e cameras espalhadas pelas
cidades monitorando o trânsito e a segurança pública, do um bilhão de
smartphones… É um número crescente. Estima-se que dos 1,8 zetabytes que
serão gerados em 2012, pularemos para 7,9 zetabytes em 2015. Em resumo,
estamos diante de uma verdadeira avalanche de informações.
A imensa maioria destes dados não é tratada e analisada. Mas já vemos
alguns casos bem interessantes. A maior varejista do mundo, o Walmart,
analisa diariamente 300 milhões de comentários feitos por clientes no
Twitter e Facebook. E com a computação em nuvem não é necessário dispor
de um imenso parque computacional dentro de casa. Pode-se fazer esta
análise em nuvens públicas e pagar-se apenas pelo consumo de recursos da
análise. Isto permite criar o paradigma de Big Data sem Big Servers.
Dados são os recursos naturais da sociedade da informação, como o
petróleo para a sociedade industrial. Mas só têm valor se tratados,
analisados e usados para tomada de decisões. Surge a oportunidade dos
ISVs incorporarem à seus produtos os recursos para estas análises, as
funcionalidades de Business Analytics ou BA, e com isso criarem
oportunidade para obterem diferenciações competitivas. Duas pesquisas
reforçam esta afirmativa. Uma do Gartner, que coloca BA como uma das
cinco prioridades dos CIOs nos últimos cinco anos e outra, da IBM, em um
recente CIO Study que mostrou que 83% dos CIOs olham BA como altamente
prioritário.
Gerenciar um negócio apenas na base de planilhas é manter a empresa
sob um gerenciamento primitivo. Uma gestão por Excel não atende à
complexidade e velocidade que as decisões em um mundo cada vez mais
complexo exigem. Os usuários estão móveis, com poderosos computadores de
bolso, como smartphones e tablets, as informações estão sendo
processadas em nuvem e todo este aparato pode ser desperdiçado se não
houver tecnologias que permitam levar informações analisadas para a
ponta.
Como os ISVs devem se posicionar diante deste desafio e oportunidade?
Acoplando soluções de BA em seus produtos, o que melhora sensivelmente
a experiência dos seus usuários e agrega valor. Um ERP, por exemplo,
não trata mais que 30% a 40% dos dados que são necessários à tomada de
decisões empresariais e muito menos consegue atuar de forma preditiva. O
resultado é que com BA os ISVs conseguem ascender na cadeia de valor
dos seus clientes, tornando-se mais importantes para eles.
Mas para adotar BA, algumas decisões estatégicas devem ser tomadas.
Uma é desenvolver por si um sistema de BA. Não me parece uma boa ideia,
pois a curva evolutiva desta tecnologia aponta para evoluções
significativas nos próximos anos como maior ênfase em análises
preditivas e interfaces via linguagem natural. Isto demanda um
investimento muito elevado em P&D e dificilmente uma empresa de
software de médio porte conseguirá se manter competitiva diante dos
grandes atores envolvidos nesta indústria. Outra hipótese, e acredito a
mais sensata, é acoplar seu produto a uma tecnologia de mercado, como o
Cognos e o SPSS da IBM. Aliás, recomendo acessar www.ibm.com/bao e navegar pelas diversas soluções da IBM chamadas de Smarter Analytics.
Além disso, as diversas alternativas existentes hoje permitem,
inclusive, oferecer este serviço de análise de dados via SaaS e não como
software instalado no cliente. Um boa oportunidade de um novo negócio a
ser explorado. Na prática, soluções deste tipo permitem a empresas de
software de porte médio, que podemos chamar de tier 2, oferecerem
funcionalidades tier 1, com proposição de valor (leia-se preços) ainda
de tier 2.
Para os ISVs focados em segmentos verticalizados, as funcionalidades
de BA podem ser um grande diferenciador. Por exemplo, na area de saúde,
agregando valor ao seu produto para facilitar a deteção de fraudes, que
dificilmente são obtidas analisando-se apenas os relatórios e planilhas
derivadas do ERP. Para varejo, criar condições de melhorar o mix de
vendas. Um exemplo interessante de quão séria é essa tendência do
mercado, a Walmart adquiriu uma startup chamada Kosmix
em 2011. A proposta desta tecnologia é detectar pela localização dos
celulares dos clientes o número de pessoas em cada loja e com essa
informação os estoques das unidades que estão com vendas mais baixas são
enviados para as que estão vendendo mais. Sugiro inclusive acessar o Walmart Labs
para termos uma ideia do que grandes varejistas estão investindo em
tecnologias que agregam business analytics e o fator social ao
e-commerce.
Outro exemplo é a empresa brasileira IDXP,
ganhadora do programa de empreendedorismo Smart Camp da IBM, em 2012,
com uma solução voltada a análise em tempo real do comportamento do
cliente na loja.
É indiscutível que BA é um passo importante para os ISVs, ao mesmo
tempo que mobilidade, social media e cloud computing. Mas, a decisão não
é entrar ou não neste novo mundo, mas como e em qual velocidade entrar.
Afinal, esse passo exige investimentos, mudanças culturais, novas
expertises e também novos direcionamentos estratégicos. É um desafio e
tanto, mas essencial para a sobrevivência das empresas de software.
25
0
