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!

Introdução

Faz realmente muito tempo que não escrevo um artigo sobre desenvolvimento de sistemas mais técnico. Quem me conhece, sabe do meu passado bem próximo de linguagens como Pascal, Delphi, Java e C#. Já escrevi muitos artigos quando trabalhava na Borland, e alguns deles sobre WebServices. WebServices, lembram? Aquela tecnologia super moderna que permite a publicação e consumo de serviços e metadados (WSDL) via Web trafegando pacotes em XML? Pois é… super moderno não?

Na verdade, não. Apesar de se ainda suportar WebServices SOAP por aí, a tendência da Web 2.0 é a de se manter as coisas o mais simples e fáceis possíveis (KISS, entende?). Além disso, com o advento do AJAX e do browser como a plataforma cliente preferida da Web 2.0, o consumo de XMLs passou a ser uma coisa um pouco, por assim dizer, pesada para ser feita em AJAX, que normalmente faz uso de JavaScript.

Este conjunto de novos requisitos tecnológicos fez surgir dois novos “animais” magrinhos para a implementação de serviços via web, que estão rapidamente suplantando os WebServices SOAP convencionais (e gordinhos):

• WebServices RESTful (versus SOAP-based)
• JSON (versus XML)

Este é o primeiro de dois artigos que exploram as capacidades do WCF para comunicação com RESTFul WebServices e JSON.

WebServices RESTful

O protocolo SOAP é extremamente rico e cheio de funcionalidades. Via SOAP você consegue descrever objetos e mensagens de forma fortemente tipada, utilizando XML. Contudo, a infraestrutura para suporte a WebServices SOAP é bem pesada e, como já citei, pouco aderente a clientes “leves” como JavaScript rodando em um browser.

Com o objetivo de tornar a invocação de métodos remotos e de troca de dados um processo mais leve, surgiu o conceito de WebServices RESTful. Estes WebServices não seguem um protocolo complexo como o SOAP, mas devem seguir as características REST definidas por Roy T. Fielding. Basicamente, WebServices RESTFul são stateless e acessados a partir de operações HTTP padrão (GET, POST, PUT, DELETE) e retornam qualquer conteúdo (normalmente XML, JSON ou outro mime type).

Outra característica interessante desse tipo de WebServices é a de que a infraestrutura existente de servidores web pode ser utilizada, sem a necessidade de se incluir application servers, gateways, proxies, etc. (contudo, não há proibição de usá-los). O melhor é que servidores web existentes (Apache, IIS, etc.) suportam caching, autenticação, criptografia, etc.  sem grande necessidade de programação ou configuração, o que aumenta a performance e diminui a necessidade de recursos dos serviços.

JSON

Como uma alternativa ao XML, Douglas Crockford criou o JSON, que se tornou um RFC oficial (RFC 4627). A sua sintaxe é bem mais leve que o XML e é facilmente “parseavel” por qualquer linguagem de desenvolvimento. Baseia-se em um subset do JavaScript. Segue um exemplo de um bloco JSON:

  1: {"menu": {
  2:   "id": "file",
  3:   "value": "File",
  4:   "popup": {
  5:     "menuitem": [
  6:       {"value": "New", "onclick": "CreateNewDoc()"},
  7:       {"value": "Open", "onclick": "OpenDoc()"},
  8:       {"value": "Close", "onclick": "CloseDoc()"}
  9:     ]
 10:   }
 11: }}

WCF – Acessando a API do Twitter

Como exemplo de uso de WebServices RESTful com JSON, vou utilizar a api do Twitter, mais especificamente a chamada “statuses/public_timeline”.

Para começar, em seu Visual Studio 2008 ou Visual C# 2008 Express, crie um projeto Console.

Adicione referências aos assemblies abaixo:

• System.ServiceModel.dll
  
• System.ServiceModel.Web.dll

Ótimo! Estamos prontos para definir o contrato de dados

Definido o contrato de dados

Vamos utilizar o atributo DataContract para definir nosso “contrato de dados” com o serviço “statuses/public_timeline” em uma nova classe assim:

  1: using System;
  2: using System.Collections.Generic;
  3: using System.Linq;
  4: using System.Text;
  5: using System.ServiceModel;
  6: using System.Runtime.Serialization;
  7: 
  8: namespace TwitterClientPlayground
  9: {
 10:     [DataContract]
 11:     public class Status
 12:     {
 13:         [DataMember(Name = "text")]
 14:         public string text {get; set;}
 15: 
 16:         [DataContract]
 17:         public class User
 18:         {
 19:             [DataMember(Name = "screen_name")]
 20:             public string screenName {get; set;}
 21:         }
 22:         [DataMember (Name="user")]
 23:         public User user { get; set; }
 24: 
 25: 
 26:     }
 27: }

Você pode ver acima que a classe é uma classe C# como qualquer outra, com anotações em seus membros. A anotação “DataContract” define que a classe deve ser utilizada como contrato de dados pelo WCF. “DataMember” define membros do contrato de dados.

Uma questão interessante é que quando estamos utilizando uma “nested class”, esta também precisa ser marcada com “DataContract” (ver a classe “User” acima).

Definindo o contrato de serviço

O contrato de serviços é equivalente a um “stub” SOAP criado pelo “Add Web Reference” do IDE. Segue o nosso exemplo abaixo:

  1: using System;
  2: using System.Collections.Generic;
  3: using System.Linq;
  4: using System.Text;
  5: using System.ServiceModel;
  6: using System.ServiceModel.Web;
  7: 
  8: namespace TwitterClientPlayground
  9: {
 10:     [ServiceContract]
 11:     public interface ITwitterClient
 12:     {
 13:         [OperationContract]
 14:         [WebGet(
 15:             ResponseFormat = WebMessageFormat.Json,
 16:             UriTemplate="statuses/public_timeline.json"
 17:             )]
 18:         List<Status> Statuses_PublicTimeLine();
 19:     }
 20: }

O atributo “ServiceContract” define uma interface que irá ser utilizada pelo WCF como contrato de serviços entre o cliente e o servidor. “OperationContract” define uma operação e “WebGet” indica que a operação (método) será equivalente a uma chamada HTTP GET e permite que configuremos detalhes como o formato da resposta em ResponseFormat(no caso, JSON) e o fragmento da URI para acesso ao serviço em UriTemplate. A UriTemplate suporta parâmetros (entre chaves {}), que devem ter o mesmo nome do parâmetro do método sendo anotado, quando a operação do serviço assim o requerer. No caso, “statuses/public_timeline” não aceita parâmetros.

Conclusão

Por enquanto, neste artigo, procurei explicar os conceitos de WebServices RESTful e JSON, bem como a definição de contratos WCF para o consumo deste tipo de WebServices. No próximo artigo, iremos finalmente utilizar os contratos aqui definidos para efetuarmos chamadas ao WebService do Twitter.

Até lá!

No meu artigo anterior sobe SCRUM, comentei sobre um assunto polêmico: o uso de ferramentas para gerenciar projetos ágeis. Agora… mais pano para a manga: outsourcing e metodologias ágeis, vamos lá: Se você for ler o Manifesto Ágil e seus princípios, você acabará esbarrando na seguinte afirmação:

The most efficient and effective method of
conveying information to and within a development
team is face-to-face conversation.

Hmmm… quer dizer então que processos e metodologias ágeis só fazem sentido quando a equipe de desenvolvimento e os donos do produto estão localizadas em um mesmo andar ou prédio? O termo chave aqui é o “face-to-face”. (muitos se referem este tipos de time como “tight matrix” ou “collocated”).

Quando estamos fisicamente presentes em um mesmo ambiente, temos a possibilidade de nos comunicar não verbalmente. Quando o componente não verbal está ausente, perdemos grande parte do conteúdo da mensagem¹. Portanto, realmente, o valor do “face to face” é indiscutível. Além disso, manter o trabalho em equipe quando o time precisa se comunicar virtualmente é bem mais trabalhoso, pois a socialização, o “cafezinho” para relaxar em conjunto, por exemplo, não existe.

Contudo, vivemos momentos conturbados. Muitas decisões são tomadas sob um aspecto inerentemente financeiro. Tudo o que é financeiro é mensurável e é aí que a defesa do “face to face” fica complicada. Como combater o ROI do outsourcing?

A favor do outsourcing, vivemos em um mundo extremamente conectado, um mundo de Instant Messengers, twitter, blogs, VOIP, web cams… A associação disso tudo a ferramentas colaborativas de gerência de projetos permite que nos aproximemos bastante da experiência face a face.

Outra possibilidade, que permite às empresas usufruir das vantagens financeiras do Outsourcing e favorece o trabalho em equipe, é a do Outsourcing in-house, que permite a interação direta com a equipe outsourced, pois esta trabalha em um ambiente fisicamente próximo a do cliente.

Para concluir: O outsourcing de desenvolvimento de software é um fato e está muito presente nos dias de hoje, mas, como vimos nesta discussão, não há necessidade de se descartar as metodologias ágeis. De fato, as vantagens da agilidade continuam relevantes.

---

¹ Christopher K. Hsee, Elaine Hatfield & Claude Chemtob (1992): Assessments of the emotional states of others: Conscious judgments versus emotional contagion. Journal of social and clinical psychology 14 (2): 119-128. e
Mehrabian, Albert & Susan R. Ferris (1967): Inference of attitudes from nonverbal communication in two channels. Journal of consulting psychology 31 (3): 248-252.

Essa é uma discussão que, tenho certeza, dá muito pano pra manga.

Os puristas vão dizer: ferramentas para gerenciar o processo ou projeto não importam. São um overhead que afeta a agilidade. O que importa é seguir o processo. E em processos ágeis somente precisamos de:

1. Blocos de Post-it®;
2. Um whiteboard (quadro branco/lousa);
3. Marcadores
4. Uma sala dedicada para os Scrum Meetings, Sprint Planning Sessions e Retrospectives e Reviews
5. Um wiki (no máximo)

Outros dirão: ferramentas importam sim. Não podemos nos dar ao luxo de termos uma sala dedicada com um enorme whiteboard lotado de post-its e anotações diversas. Salas de reunião são compartilhadas e não podemos perder os dados dos backlogs do sprint e do produto. Além disso, poder navegar em uma ferramenta para acessar resultados de sprints anteriores ajuda muito no planejamento de sprints futuros com lições aprendidas, estimativas de tamanho dos stories, etc.

Bem. confesso que a minha escolha natural está no grupo dos Outros. Acredito em manter a “memória corporativa” para melhorarmos iterativamente as nossas entregas de projeto. Meu background em processos e desenvolvimento de software me faz acreditar que ferramentas corretamente implementadas aumentam a produtividade de equipes. (a boa e velha tríade “People, Processes and Technology”)

E – aqui entre nós – tenho certeza que na próxima reunião na mesma sala, o quadro branco será apagado pela outra equipe.  Mesmo que alguém coloque um recado de “não apagar” gigante.

Que ferramenta eu gosto de usar? Neste momento estou usando o Banana Scrum, uma ferramenta gratuita da CodeSprinters disponibilizada em um ambiente on-line, modelo SaaS (Software as a Service), e sinto-me bastante satisfeito. Outras opções:

• ThoughtWorks Mingle (estou estudando agora… bem poderosa)
• Borland TeamFocus (da minha antiga companhia…)
• TargetProcess  (próxima na fila de estudos…)
• Scrum Poker (ferramenta de planning poker online…)

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!

Existem muitas abordagens ágeis disponíveis no ecossistema de processos e metodologias de projetos de software. Entretanto, dentre todas, sinto-me mais confortável – no momento – com o SCRUM.

Uma das maiores vantagens do SCRUM é a sua capacidade de ser genérico o bastante sem perder a praticidade e aplicabilidade no dia-a-dia. Uma vez que tenhamos começado a estudar o processo, gasta-se pouco mais que um par de dias para se começar a aplicar seus conceitos, que são bastante diretos.

Seus princípios são tão universais que é possível se utilizar o SCRUM combinado com outros processos (ex.: FDD ou XP) ou ainda para projetos em áreas que nada tenham a ver com desenvolvimento de sistemas, tais como material de treinamento, marketing, etc. Alguns dos princípios:

• Sprint: Iteração de 2-4 semanas de um projeto SCRUM. O tamanho do sprint escolhido deve ser mantido durante todo o projeto. O escopo de um sprint iniciado não pode ser.
• Papéis:
  • Scrum Master: Facilitador do processo e projeto (o equivalente a um Project Manager)
  • Product Owner: Representante do cliente do projeto
  • Equipe: Responsáveis pela implementação, testes e documentação do projeto
• Cerimônia:
  • Planning Session: Sessão de priorização e detalhmento do escopo de um sprint.
  • Daily Scrum: também conhecido com “stand up meeting”. Reunião diária, de 15 minutos de acompanhamento do projeto. Perguntas:
    • O que você fez ontem?
    • O que você fará hoje?
    • Algum obstáculo?
  • Sprint Review: Tipicamente uma demonstração dos resultados obtidos em um sprint. Todos podem participar (mesmo quem não participa do projeto)
  • Sprint Retrospective: Sessão rápida (15-30 minutos) para compartilhamento de “lições aprendidas”
• Artefatos:
  • Product backlog: conjunto de requisitos ou funcionalidades (stories) de todo o trabalho desejado para o projeto. Cresce livremente, mas é priorizado pelo Product Owner.
  • Sprint backlog: stories do product backlog selecionadas e detalhadas no Planning Session  que devem ser entregues durante um sprint.
  • Burndown chart: Gráfico que torna visível o andamento de um sprint. Permite entender a “velocidade” de desenvolvimento de um sprint.

Visão geral do processo:

Artigos e cursos introdutórios podem ser encontrados aqui:

• Mountain Goat Software / Scrum Presentation (inclusive em português);
• ScrumAlliance.org: Página “Resources”;
• Control Chaos: Página “Resources”;

Treinamentos oficiais no Brasil podem ser procurados na AdaptWorks, empresa onde trabalham meus bons amigos Alexandre Magno e Edmilson Miyasaki.

Para acessar o calendário de cursos oficiais: http://www.scrumalliance.org/training