O problema

Não importa se seu background é Agil, Iterativo, Waterfall ou Tradicional. Uma coisa é certa e todos concordamos: Requisitos excelentes combinados a uma arquitetura perfeitamente executada é uma ótima fórmula para o sucesso. Inicialmente, a fórmula parece ser simples. E é! O problema está em sua execução. Como saber se estamos exagerando nos requisitos e no design? Em outras palavras: quão profundos (ou superficiais) os requisitos devem ser para serem o bastante para um encaixe perfeito entre negócio e tecnologia?

A quantidade certa de cada ingrediente nesta fórmula tem assombrado a comunidade de desenvolvimento de software desde os tempos do COBOL até os dias de Internet/Cloud/.Net/Java/Ruby/Python/PHP de hoje. Esse mistério precisa ser desvendado!

Uma solução

Uma solução para este dilema pode ser encontrado em metodologias ágeis. Se fizer esta pergunta para um “agilista” a resposta será, na maioria dos casos: evite BDUF (Big Design Up Front). Faz sentido. Uma das características de requisitos é que eles tem a tendência de mudar. Portanto, se você demorar demais definido seus requisitos e arquitetura, tão logo você esteja pronto para iniciar a codificação, adivinhe o que acontece? Os danandos dos requisitos decidem mudar!

Bem… então temos um bom começo! Evitar BDUF! Mas esta é uma abordagem restritiva, não prescritiva. É ótimo saber o que NÃO fazer. Mas o que DEVEMOS fazer? Bem… mais uma vez os “agilistas” dirão: TDD é o caminho, irmão: vá e comece pelos testes. Novamente, uma grade diretiva, dessa vez bem prescritiva… mas completa? Sinto-me na obrigação de responder: não. Infelizmente, saber que os testes devem ser escritos antes da implementação em si é parte do “caminho para a perfeição”. TDD é fantástico: concordo com todas as minhas forças. Basicamente força o desenvolvedor a escrever código utilizando componentes desacoplados. Se a arquitetura seguir boas práticas comprovadas, design patterns e bom e velho bom senso, melhor ainda. Porém, uma última pergunta perdura: O QUE deve-se testar?

Vejo algumas mãos levantadas na audiência? Ah, sim. O senhor, por favor pode falar:

- Bem, Daniel, é claro! A resposta está nos requisitos. O desenvolvedor deve ler os requisitos, entender a necessidade de negócio e desenhar os testes de acordo com os requisitos.

Muto bem! Excelente sugestão. Mas resta um porém na seguinte combinação de palavras: “entender a necessidade de negócio”. Desenvolvedores são, geralmente, um grupo de indivíduos cartesianos. Vivemos em um mundo de zeros e uns, “Trues” e “Falses”, “ifs” e “elses”. Requisitos de negócio precisam identificar claramente a necessidade do cliente, mas se não forem escritos muito cuidadosamente, a ambiguidade se prolifera e o resultado vai acabar parecendo com o antigo, mas ainda muito verdadeiro desenho do “balanço na árvore”.

Ah, e mais um detalhe: e a rastreabilidade? Qual frase dos paragráfos da especificação clássica de requisitos é rastreável ao código que precisa ser revisado sempre que algo muda? Difícil, não é?

A solução

Mutio bem: diversas abordagens para definir requistos não ambíguos, verificáveis, atingíveis e específicos tem sido o objeto de muitos artigos, metodologias e frameworks. De agora em diante, vou focar em uma metodologia/framework que tem funcionado impressionantemente bem na minha experiência: Behavior Driven Development (ou BDD). O BDD tenta diminuir a distância entre os analistas de requisitos e desenvolvedores especificando uma “linguagem” bem definida. Esta “linguagem” é, ao mesmo tempo, natural e específica. É claramente entendível por stakeholders técnicos e de negócio e descrevem o comportamenteo de um sistema. Por exemplo:

Funcionalidade: Pedidos
  De modo a comprar um item
  Como um cliente
  Eu quer ser capaz de fazer pedidos
	
Cenário: Adicionar um item ao carrinho de compras
  Dado que eu tenha selecionado um item
  E eu tenha informado a sua quantidade
  Quando eu pressionar o botão "adicionar ao carrinho"	
  Então o item deve ser adicionado ao carrinho
  E o valor total do carrinho deve ser incrementado da quantidade do item multiplicada pelo seu valor

O texto certamente parece ser não ambíguo, verificável, atingível e específico, não é?

E se cada uma destas linhas do cenário se transformasse em um passo específico em um test case N/J/x/Unit, a partir do qual arquitetura e código pudessem ser derivados, a-lá TDD? Não seria fantástico? Este e exatamente o objetivo do BDD.

Próximos passos

Acho que isto já é o bastante para justificar um par de artigos no futuro (próximo) que irá clarificar e exemplificar ainda mais o BDD. Como meu background é em .Net, vou fornecer exemplos em C# usando uma implementação muito bacana de BDD específica de .Net baseada no Cucumber: o Specflow, um projeto open source patrocinado pela TechTalk.

 

The problem

It doesn’t matter if your background is Agile, Iterative, Waterfall or Traditional. One thing is certain and we all agree: Excellent requirements combined with perfectly executed architecture is a great formula for success. At a first glance, the formula is simple… and it is! The problem is in the execution. How do we know we are being too heavy handed on requirements and design? In order words: how deep (or shallow) must the requirements be in order to be enough and how much design is needed for a perfect fit between business and technology?

The right amount of each ingredient of this formula has been haunting the development community since COBOL times and is still relevant in our Internet/Cloud/.Net/Java/Ruby/Python/PHP days… the mystery must be solved!

A solution

One solution to this dilemma can be found in agile methodologies. If you ask an agile methodologist the ingredient question, the answer will be, in most cases: avoid BDUF (Big Design Up Front). And it makes sense. One of the characteristics of requirements is that they tend to change. So if you take too much time in defining your requirements and architecture, as soon as you are ready to start implementing… guess what? Those pesky requirements decided to change!

So that’s a good start! Avoid BDUF! But that’s not a prescriptive approach, it’s restrictive. It’s great to know what we should NOT do. But what SHOULD we do? Well… again, agilists will say: TDD is the way, my brother … go forth and test first! Again… another great directive… and that’s very prescriptive… but is it complete? Hmmm… I’ll have to answer: no. Unfortunately, knowing that tests should be written before the actual implementation is part of the “path to perfection”. TDD is fantastic, I agree wholeheartedly. It practically forces the developer to write code using decoupled components. If the architecture follows industry-proven best practices, design patterns and good old common sense, it’s even better.  But one last question remains: WHAT should we test?

Do I see some hands raised in the audience? Oh, you, sir, please go ahead:

- Well, Daniel, of course. The answer is in the requirements. The developer should look up the requirements, understand the business need and design the tests accordingly.

Very well! That’s an excellent suggestion. But there’s a catch. It lies in the following word combination: “understand the business need”. Developers are, generally, a homogeneously Cartesian group of individuals. We live in a world of “0s” and “1s”, “Trues” and “Falses”, “ifs” and “elses”. Business level requirements may clearly identify a client need, but if they are not very carefully worded, ambiguity proliferates and the result may be like the age old, but too true “tire swing” cartoon.

Oh… and another catch: what about traceability? Which sentence of a classic requirement specification (set of) paragraphs traces to the code that needs to be reviewed whenever something changes? Tough, eh?

The solution

Well, several approaches to define unambiguous, verifiable, attainable and specific requirements have been subject of numerous papers, methodologies and frameworks. From now on, I’ll focus on a framework/methodology that has been working amazingly well in my experience: Behavior Driven Development (or BDD). BDD tries to bridge the gap between requirements analysts and developers by specifying a well defined “language”. This “language” is, at the same time, natural and specific. It is clearly understood by both business and technical-type stakeholders and describes system behavior. Here’s an example:

Feature: Order Placement	
  In order to purchase an item	
  As a customer	
  I want to be able to place orders
	
Scenario: Add item to cart
  Given I have selected an item	
  And I have provided its quantity	
  When I press the "add to cart" button	
  Then the item should be added to the cart
  And the cart's total amount should be incremented by the selected item quantity multiplied by its price

It surely looks unambiguous, verifiable, attainable and specific enough, doesn’t it?

What if each one of those scenario lines became a specific step in a test case, from which architecture and code would be derived, a-la TDD? Wouldn’t it be fantastic? That’s exactly what BDD is about.

Next steps

I think this is just enough information to justify a couple of (near) future entries that will further clarify and exemplify BDD. Those entries will be a bit biased, though. Since my background is basically .Net, I will provide examples in C# using a beautifully implemented .Net-specific Cucumber-based BDD implementation: Specflow, an open source project sponsored by TechTalk.

See you in a bit!

Esse é um assunto bem quente. Não porque seja uma grande novidade ou algo assim, mas principalmente por ser polêmico.

A onda Outsourcing é parecida com o do downsizing, da reengenharia e de muitas “reestruturações” de empresas: ir a extremos para “cortar custos”. Empresas mais maduras já entendem que muitas vezes o custo total (do retrabalho, falha nas entregas, etc.) é muito maior quando a decisão de fazer outsourcing é tomada sem critério.

Dito isto, não acredito que exista uma resposta simples para a pergunta do título deste artigo. Contudo, acredito, sim, que uma regra simples deve ser utilizada no processo de tomada de decisão.

O serviço sendo considerado para ser outsourced é “core” ou estratégico para o negócio da minha companhia?

[   ] Sim – A princípio, outsourcing não deve ser considerado.

[   ] Não – Outsourcing é provavelmente uma boa opção.

A regra é simples, mas responder a pergunta do que é “core” ou estratégico muitas vezes nos faz enveredar por um caminho bem mais tortuoso do que incialmente imaginamos.

Especialmente porque o CIO ou gestor de TI de uma companhia vai precisar discutir esse assunto com outros stakeholders (por exemplo, diretores de outra áreas). A decisão ideal é o resultado de uma visão compartilhada dos participantes da discussão. Não vou me enveredar agora em questões relacionadas a planejamento estratégico, tais como Análise SWOT, Missão e Visão, Balanced Scorecard, etc. Sugiro, somente, que algum método estruturado para se chegar a uma conclusão compartilhada seja utilizado. Do contrário a discussão pode ser demorada e dolorosa.

Uma vez que os objetivos estratégicos de mercado, financeiros, processuais, etc. da companhia estão esclarecidos, temos uma veredito sobre outsourcing, correto? A princípio, sim.

Contudo, se mesmo assim por questões, por exemplo, de custo, a decisão for a de se efetuar o outsourcing do serviço em questão, aqui vão algumas considerações:

Conceito	Básico	Desejável
Seleção de fornecedores	Analise cuidadosamente os fornecedores sob todos os aspectos. O custo é importante, mas a capacidade de entrega é primariamente o que deve ser analisado. Uma vez que o serviço é estratégico ou “core”, um processo formal e detalhado de análise de potenciais fornecedores deve ser utilizado, tal como RFIs e RFPs	Se possível e se o tempo estiver a seu favor, uma prova de conceito é extremamente desejável. Normalmente os fornecedores que “confiam no seu taco” não se opõem a POCs. Outra modalidade de avaliação detalhada é o “try and buy”. Contudo cuidado: muitas vezes o “try” faz com que você, essencialmente, tenha se tornado dependente do fornecedor e não tenha muita escolha senão partir para o “buy”.
Visibilidade	Utilize como um dos critério primordiais no processo de definição do fornecedor a visibilidade que este o dará durante a execução do serviço. Como em sua maioria das vezes o serviço será executado fora da empresa cliente, a possibilidade de se visualizar o estágio, estado e passos intermediários do serviço é essencial para que você não receba “presentes de grego” nas entregas do fornecedor.	Se possível e cabível, faça uso do “in house outsourcing”: use serviços outsourced dentro da estrutura da sua própria empresa para poder acompanhar o andamento do serviço ou projeto de perto.
Qualidade	Questões de controle e garantia de qualidade tornam-se ainda mais delicadas… portanto tente associar remuneração a entregas com “aceite formal”	Implemente cláusulas contratuais que penalizem monetariamente o fornecedor no caso de erro ou quebra de SLA (o que faz mais sentido em serviços de operação de sistemas financeiros tais como folha de pagamento, contabilidade etc.)
Gerente local	O papel do gestor ou gerente do projeto/serviço também deve ser desempenhado por alguém com as competências adequadas da empresa cliente, e não somente por um representante do fornecedor. Desta forma temos um “pai para a criança” e “blindamos”  ainda mais a qualidade das entregas.	Apesar da gestão ser compartilhada entre cliente/fornecedor, a responsabilidade final é a do cliente. Para o fornecedor, um resultado negativo pode significar a perda de um cliente. Para o cliente, a perda de uma oportunidade que pode ser, no limite, “time sensitive” e com impacto relevante em seu negócio.

Não há regra geral, mas existem alguns serviços de TI que são comumente considerados como commodities e, portanto, são candidatos a serem outsourced:

• Data centers;
• Colocation/hosting;
• Suporte a infra-estrutura de rede e servidores;
• Backups/restores;
• Email, Calendário, Contatos;
• etc.

Serviços que ficam geralmente em uma “área cinza” que dependem de uma análise mais detalhada como a citada neste artigo:

• Desenvolvimento de Software;
• Administração dos servidores ;
• Business Intelligence (desenvolvimento);
• Software-as-a-service (CRM, Folha de Pagamento, Recrutamento/RH, etc.)

Alguns serviços que pessoalmente não recomendo serem outsourced:

• Gerência de Projetos;
• Gerência de Requisitos;
• Planejamento Estratégico de TI (apoio consultivo, OK);
• Gerência de operações de TI;
• Gerência SOX TI;
• etc.

Mesmo a lista acima pode variar bastante, dependendo de cada caso. Portanto, analise bem e pense: por que fazer Outsourcing quando se pode fazer “Rightsourcing”?

Cheers!

Muito bem, com a (auto) justificativa de se iniciar um blog já resolvida, posso começar a escrever algo sério aqui.

Se você está iniciando seu próprio negócio e está preocupado com custos, começar a sua infra-estrutura de TI com um empurrãozinho de serviços Web 2.0 da Google não atrapalha nada. Como é que disse Sir Isaac Newton?

Se eu vi mais longe, foi por estar de pé sobre ombros de gigantes.

Não sei quanto a você, mas a Google é gigante o bastante para mim.

Muitos serviços e produtos que há muito tempo eram muito bem pagos, podem ser agora desfrutados gratuitamente ou a um preço bem camarada usando-se o Google Apps.

Por exemplo:

• Hosting do web site de sua empresa – Google Sites;
• Servidor de e-mail – Google Apps Email;
• Servidor de calendário – Google Apps Calendar;
• Servidor de diretório corporativo – Google Apps Contacts;
• Servidor de chat corporativo – Google Apps Chat;
• Pacote de Edição de Textos, Planilhas e Apresentação – Google Apps Docs;

Todos os serviços acima, entre outros, são disponibilizados em duas versões: Permier Edition (US$ 50/ano/usuário) e Standard Edition (gratuito). A lista completa e comparação das funcionalidades pode ser vista aqui.

Uma das desvantagens deste tipo de serviço é que seus dados ficam em um servidor fora do seu controle. Mas isso também é uma vantagem, pois não ter que se preocupar com o hosting ou colocation, administração e backup de servidores significa mais economia ainda, o que é essencial no caso de startups com restrições de custo.

O que resta? O controle sobre os dados. Para isso, o Google oferece ferramentas e tecnologias de sincronização de e-mail (via IMAP/POP3/SMTP), tarefas, contatos e calendários com o Outlook (via Google Calendar Sync) e celulares (Google Mobile Sync).

O Google Apps oferece, assim, um conjunto de funcionalidades básicas de colaboração tradicional equivalentes às funcionalidades igualmente básicas de softwares caros e complexos de se instalar e administrar tais como Lotus Notes, Microsoft Exchange.

Para começar, clique aqui.

Se precisa de ajuda, é só comentar neste artigo!