Segundo [BECK, 2004], a XP se distingue das outras metodologias por:

• Seu feedback antecipado;
• O planejamento incremental, que gera rapidamente um plano geral que evolui com o decorrer do projeto;
• Sua habilidade de implementar as funcionalidades de forma flexível considerando as necessidades mutáveis do negócio;
• Sua confiança nos testes automatizados;
• Sua confiança em comunicação oral;
• Sua confiança em um processo de projeto evolutivo que dura tanto quanto o sistema;

Risco: O Problema Básico

A principal motivação da Programação eXtrema parte do princípio que o desenvolvimento de software tem falhas na entrega e falhas nos produtos entregues caracterizando o problema básico – o risco, portanto, produz-se software de baixa qualidade. Segundo [BECK, 2004], existem vários riscos associados ao desenvolvimento do software, como: (i) cronograma irreal; (ii) cancelamento do projeto por vários atrasos no cronograma; (iii) o sistema é descontinuado pelo alto custo de se fazer modificações ou a taxa de erros cresce tanto que o sistema deve ser substituído; (iv) o negócio é mal compreendido e o software desenvolvido não resolve o problema original; (v) as regras de negócio mudam antes que o software seja finalizado; (vi) funcionalidades inúteis. A missão da XP é aceitar o risco como problema a ser resolvido, onde o objetivo é encontrar a solução. Nesse sentido, a necessidade é criar um modelo de desenvolvimento de software que trate desses riscos.

Além de mitigar ao máximo os riscos, a metodologia XP advoga que quatro variáveis têm de ser controladas no projeto – custo, tempo, qualidade e escopo. Dessa forma, o modelo desenvolvimento de software é dirigido sob a perspectiva de controlar as referidas variáveis. Em um projeto, as referidas variáveis são restrições inerentes ao produto final. Eventualmente se o custo e/ou o tempo forem escassos, é muito provável que a qualidade do produto entregue possa estar muito inferior àquela esperada no escopo do projeto.  A XP cria valores, princípios de atividades básicas e práticas para tentar conduzir bem os problemas correlacionados à efetivação dos riscos do projeto. Esses valores podem ser caracterizados em:

1. Comunicação: deve ser extremamente aberta e franca. A XP dá uma ênfase especial à comunicação e é essencial para tudo o que acontece no contexto de um projeto. Segundo [BECK, 2004], “Os problemas nos projetos podem ser invariavelmente rastreados a alguém não ter conversado com alguém mais sobre alguma coisa importante”.
2. Simplicidade: é representada na XP pela busca pela “coisa mais simples que possa funcionar” [BECK, 2004]. O propósito é construir algo simples e direto que solucione problemas de hoje e ter certeza de que isso seja suficientemente flexível para ser refinado e expandido de modo a solucionar os problemas de amanhã, mas fundamentalmente não se preocupa hoje com os problemas de amanhã.
3. Feedback: seu objetivo é criar ciclos de realimentação que atuam em intervalos de tempos pequenos como dias e minutos, em relação aos testes de unidade, e, grandes semanas (dias, semanas) em associação a teste de aceitação de usuário, e,  planejamento e cronograma de projeto.
4. Coragem: é o valor que permite aos participantes da XP se aventurarem em projetos de alto risco e alta recompensa nas tarefas de desenvolvimento. Isso muitas vezes se manifesta na forma de desenvolvedores que constroem protótipos descartáveis durante a codificação.

Princípios Fundamentais da XP

De acordo com [BECK, 2004] os princípios fundamentais da XP são:

1. Feedback rápido: o princípio é obter o feedback, interpretá-lo e aplicar o que é aprendido no sistema o mais rápido possível, realimentando o que foi aprendido em dias ou semanas, em vez de meses ou de anos.
2. Simplicidade presumida: este princípio dita que a equipe deve pressupor que todo problema tem uma solução razoavelmente simples. Como conseqüência, o tempo poupado na maioria dos problemas para os quais isso é válido pode ser usado para abordar problemas que realmente necessitem de soluções complexas.
3. Mudanças incrementais: parte do princípio que grandes modificações feitas de uma só vez têm grandes chances de não dar certo. Assim, qualquer problema é resolvido por meio de uma série de mudanças menores.
4. Aceitação das mudanças: este princípio se apóia na premissa da XP que de desenvolver software no contexto de requerimentos vagos ou que mudam rapidamente. As idéias é que os membros da equipe devem simplesmente aceitar as mudanças como algo natural, diário, em vez de algo que ocorre eventualmente.
5. Alta qualidade: ninguém gosta de fazer um trabalho de baixa qualidade. Todos gostam de fazer um bom trabalho. A XP defende que se você não vai fazer algo bem, então não faça independentemente das restrições de cronograma e orçamento.

Atividades Básicas do Desenvolvimento

[BECK, 2004] define quatro atividades básicas associadas ao desenvolvimento de software utilizando XP, sendo elas:

1. Codificar: as práticas da XP utilizam o código como um mecanismo para atingir objetivos secundários incluindo o aprendizado rápido e uma melhor comunicação. Algumas das práticas citadas no tópico a seguir estão ligadas à codificação: refatoração, programação em pares e integração continua.
2. Testar: está fortemente relacionada à codificação. Os desenvolvedores devem escrever códigos de teste de unidade antes escrever o código e verificar se o código passa por todos esses testes antes de se tornar um sistema. O cliente também é envolvido nos testes funcionais, onde os mesmos devem confirmar se o sistema satisfaz as regras de negócio.
3. Escutar: refere-se à necessidade de estruturar a comunicação de modo que as conversas, sempre que possível, envolvam os problemas de hoje, não os de amanha, em um nível de detalhe apropriado.
4. Projetar: está associado a necessidade de criar uma estrutura que organiza a lógica dentro do sistema de modo a torná-lo robusto e possível de manter. Nesse contexto, a prática utilizada é projetar simples.

Práticas do XP

[BECK, 2004] lista algumas práticas que devem ser seguidas pela equipe de desenvolvimento para que os valores, princípios e atividades básicas da metodologia sejam alcançados, são elas:

1. O jogo do planejamento: determinar o escopo da próxima versão de forma que os requisitos mais importantes sejam contemplados e a entrega possa ser um praza não muito longo. Quando o planejado fugir do realizado, então o plano deve ser reajustado.
2. Entregas freqüentes: dividir o desenvolvimento em pequenos módulos de acordo com as funcionalidades de forma que possa ser rapidamente colocado em produção.
3. Metáfora: conduzir o desenvolvimento por meio de histórias simples, compartilhada por todos os envolvidos, sobre como o sistema deverá funcionar.
4. Projeto Simples: o sistema deve ser pensado e projetado de maneira simplista. Complexidades desnecessárias são removidas assim que descobertas.
5. Testes: os programadores escrevem os testes de unidade durante todo o desenvolvimento, o qual deve ser executado sem falha para o desenvolvimento continue.
6. Refatoração: os programadores se preocupam sempre em deixar o código estruturado removendo códigos redundantes, simplificando e aumentando a flexibilidade.
7. Programação em pares: todo o desenvolvimento é realizado por programadores trabalhando em pares.
8. Propriedade coletiva: todos podem alterar o código em qualquer trecho e em qualquer momento.
9. Integração contínua: integre e atualize as versões do sistema várias vezes por dia, cada vez que uma tarefa fora terminada.
10. Semana de 40 horas: como regra, trabalhe no máximo quarenta horas por semana, evitando fazer hora extra por duas semanas consecutivas.
11. Cliente presente: mantenha o cliente o mais próximo possível para responder a questões.
12. Padrões de codificação: os programadores escrevem código respeitando as regras que enfatizam comunicação através do código.

Referência:  BECK, Kent (2004). Programação eXtrema explicada: escolha as mudanças, Bookman, 2004.

O nome “Pensamento Lean” nasceu nos anos 90 com o lançamento do best seller The Machine That Changed the World : The Story of Lean Production.  Os princípios de demanda puxada, just-in-time, qualidade total, melhoria contínua e flexibilidade aplicados na indústria japonesa, mais precisamente na Toyota e conhecidos como Toyota Way inspiraram também a indústria de software e fez surgir a abordagem do Lean Software Development

O Lean Software Development provê uma série de princípios sobre a aplicação de um conjunto de técnicas oriundas da indústria e aplicadas em desenvolvimento de software. Esses princípios foram amplamente adotados na manufatura japonesa aonde vieram a ser conhecidos como “Lean Production“.

Nesse contexto, Mary e Tom Poppendieck identificaram sete princípios fundamentais denominados “Lean Principles” e mostraram como eles podem ser aplicados em abordagens de desenvolvimento de software ágil.  Ao longo dos princípios, eles introduziram também e vinte e dois “thinking tools” para traduzir cada princípio em práticas ágeis, em particular eles apresentaram um toolkit para gerentes, lideres técnicos e gerentes de tecnologia que esperam adicionar valor ao invés de criarem barreiras para suas equipes de projetos, como os a seguir:

• Melhoria contínua em direção à excelência: desenvolvimento de software é como um exercício de descoberta.
• Gerenciando incertezas: “decidir o mais tardio possível” para adicionar mudanças dentro do sistema.
• Reduzindo o fluxo de valor: desenvolvimento rápido, feedback, e melhorias contínua.
• Dê autonomia ao time e ao indivíduo sem coordenação e comando-controle.
• Software com qualidade: promovendo coerência, usabilidade, alta coesão, manutenabilidade e adaptabilidade.

Princípio 1: Elimine o Desperdício

Elimine qualquer coisa que não agregue valor ao produto e que não são percebidos pelo cliente. No pensamento Lean, o conceito de desperdício é um grande obstáculo. Se um programador implementa mais funcionalidades do que o necessário de imediato, isso é um desperdício.  Se a equipe produz documentação de análise apenas para estar em concordância com o processo, isso é um desperdício. Se o time entrega funcionalidades incompletas, isso é um desperdício. O ideal é perceber o que os clientes precisam para então desenvolver e entregar exatamente o que eles querem o mais rápido possível. Qualquer outra coisa que fica e que não satisfaça as necessidades do cliente é um desperdício.

Princípio 2: Amplifique o Aprendizado

Desenvolvimento é um exercício de descoberta, enquanto produção é um exercício de redução de variações, e por essa razão, aprender a abordagem de desenvolvimento resultam em práticas que são bastante diferentes do que aprender abordagens de práticas de produção.

Desenvolvimento é como fazer uma nova receita, enquanto produção é como fazer um prato. Receitas são formuladas a partir da experiência de chefes de cozinha. Desenvolver uma receita é um processo de descoberta, onde o chefe utilizando de toda sua experiência e dos ingredientes a sua disposição faz iterações, experimentações, até encontrar a melhor combinação de ingrediente para o melhor sabor. Não se espera que os chefes obtenham uma receita perfeita na primeira tentativa; espera-se produzir diversas variações como parte do processo de aprendizagem. Desenvolvimento de software é concebido de forma melhor com um processo de aprendizado similar ao de criar uma nova receita. A melhor abordagem para melhorar o ambiente de desenvolvimento de software é pelo conhecimento amplificado, em um espiral de criação do conhecimento.

Princípio 3: Decida o Mais Tarde Possível

Práticas de desenvolvimento que assegurem a tomada de decisão tardia são mais eficazes em domínios que envolvem incertezas. Decidir o mais tarde possível significa manter suas opções aberta o maior tempo possível. O principal conceito deste princípio é diminuir as incertezas retardando as decisões até que possam serem feitas com base em acontecimentos mais firmes, previsíveis e conhecidos. Decisões tardias tendem a ser mais acertadas porque as melhores decisões são feitas baseadas em fatos, e não em suposições ou especulações. A principal estratégia de atrasar as decisões em um desenvolvimento de um sistema complexo é construí-lo com a capacidade de suportar mudanças.

Princípio 4: Entregue o Mais Rápido Possível

Sem entregas rápidas é impossível haver decisões tardias durante o desenvolvimento. Sem entregas rápidas não haverá feedbacks confiáveis no curto prazo.  No desenvolvimento o ciclo de descoberta é fundamental para a aprendizagem: estórias, implementação, feedback e melhorias. Quanto menor esse ciclo, mais pode ser aprendido.

Uma vez que os clientes decidam o que querem, seu objetivo deve ser para criar esse valor tão rapidamente quanto possível. Entregas rápidas garantem que o cliente vai ter o que ele precisa hoje, e não o que ele precisa amanhã.

Em uma organização madura em desenvolvimento de software, tudo isso acontece em um fluxo rápido em resposta a uma necessidade dos clientes.

Princípio 5: Dê autonomia à Equipe

“Construir projetos ao redor de indivíduos motivados. Dando a eles o ambiente e suporte necessário, e confiar que farão seu trabalho.” Esse já é um dos doze princípios por atrás do manifesto ágil. A equipe de trabalho deve ter autonomia para adequar seus próprios processos de engenharia, assumir os seus próprios compromissos e reunir as informações necessárias para alcançar seus objetivos e cumprir as suas metas. Equipes autônomas são multidisciplinares, possuem indivíduos multidisciplinares, trabalham bem com a interdisciplinaridade  e promovem a auto-organização. A esse  tipo de equipe mais um princípio ágil é adicionado: “em intervalos regulares, o time reflete em como ficar mais efetivo, então, se ajustam e otimizam seu comportamento de acordo.”

Nesse ambiente, a equipe de desenvolvimento está em melhor posição para saber responder a problemas difíceis e a pedidos urgentes. A melhor maneira de ter certeza de estar fazendo as coisas corretas é trabalhar diretamente com o cliente para entender suas necessidades, colaborar com os colegas para descobrir como satisfazer essas necessidades, e, frequentemente apresentar os resultados aos interessados para ter certeza de que estamos no caminho certo.

Princípio 6: Construa com Integridade

Qualidade é inegociável. Entregue qualidade intrínseca e explícita aos seus clientes, se eles perceberem isso, significa que foi uma entrega de qualidade. Mary e tom Poppendieck em seu livro identificaram duas dimensões de integridade: integridade percebida e integridade conceitual. A integridade percebida significa que a totalidade do produto alcança um equilíbrio entre as funções, usabilidade, confiabilidade, economia e isso encanta o cliente. A integridade conceitual significa que os conceitos centrais do sistema de trabalho em conjunto são facilitados e coesos. Essa última é fator crítico de sucesso para a integridade percebida.

Um produto possui integridade percebida quando o cliente o experimenta e diz: Isso! Era exatamente isso que eu queria! Esse exemplo acontece com frequencia em aplicações do google. Eu particularmente senti isso quando experimentei o novo recurso de caixa prioritária do gmail.

Um produto de software deve estar sempre adicionando integridade. Isso prolonga o seu ciclo de vida operacional. Software com integridade possui boas arquiteturas, possuem um alto nível de usabilidade e facilidade de uso, são fáceis de dar manutenção, de adaptar e de estender.

Princípio 7: Visualize o Todo

Integridade em sistemas complexos exigem um conhecimento holístico e profundo em diversas áreas. Um dos problemas mais intratáveis com o desenvolvimento do produto é que especialistas em qualquer área (por exemplo, banco de dados ou design) têm uma tendência natural em maximizar o desempenho da parte do produto que representa a sua própria especialidade, ao invés de focar no desempenho do sistema como um todo. Muitas vezes, a integridade do produto como um todo pode ser prejudicado se as pessoas atenderem aos seus próprios interesses especializados em primeiro lugar.

Em desenvolvimento de software não existe mágica, não existe bala de prata, não existe nenhuma conformidade processual que garanta um produto conforme.  Existe, no entanto, um ambiente de descoberta, aprendizado e melhoria constante. Um ambiente formado por pessoas, que praticam socialização, externalização, combinação e internalização em um espiral contínuo de criação de conhecimento, em nível individual, do grupo, e organizacional.  Desenvolvimento de Software pode ser encarado como um jogo cooperativo infinito onde, além de suas atividades de engenharia, também deve ser encarado como uma atividade de ciências humanas, acima das questões técnicas e puramente lógicas. Existem pessoas envolvidas no processo; as que criam e as que usam o software.  A interação entre elas é um dos principais fatores críticos de sucesso para alcançar a conformidade com o produto.

Um dos princípios do manifesto ágil já afirma que “Nossa maior prioridade é satisfazer o cliente, através da entrega adiantada e contínua de software de valor.” e um dos valores do manifesto completa que “Indivíduos e interação entre eles mais que processos e ferramentas“. Em desenvolvimento de software os esforços devem ser desprendidos para alcançar a conformidade com o produto e nem tanto para alcançar a conformidade com o processo. O processo é o meio para alcançar o produto e não o fim. Elimine qualquer coisa que não agregue valor ao produto e que não são percebidos pelo cliente. Elimine o desperdício, simplifique e aceite mais um princípio ágil: “simplicidade: a arte de maximizar a quantidade de trabalho que não precisou ser feito.” Segundo o pensamento Lean, existem alguns desperdícios clássicos em desenvolvimento de software, a seguir:

• Trabalho parcialmente feito  (o “inventário” de um processo de desenvolvimento)
• Processos extras (fáceis de encontrar no desenvolvimento centrado em documentação)
• Funcionalidades extras (desenvolvem-se apenas o que os clientes querem agora)
• Troca de tarefas (todos devem fazer uma coisa de cada vez)
• Espera (para instruções, para mais informações, típico em ambiente comando-controle)
• Handoffs (toneladas de conhecimento tácito se perde)
• Defeitos (pelo menos defeitos que não são rapidamente capturados por um teste)

Manter a conformidade com processo de desenvolvimento formais, tradicionais, prescritivos e centrados em documentação implica em um problema que está muito além de afirmações de serem burocráticos, waterfall, rígidos, etc.  O principal problema é o auto custo de se manter esse tipo de processo. Processo formal é caro, manter a conformidade com o processo é caro, manter conformidade na documentação é caro, manter uma equipe de Quality Assurance é caro e fazer alterações de requisitos no meio do projeto é mais caro ainda.  Processo de desenvolvimento de software baseado em modelos de maturidade como CMMI e MPS-BR só podem ser considerados maduros se houver uma equipe de Quality Assurance atuante, autônoma e não condicionada. Sem Quality Assurance nesse tipo de abordagem grande parte dos esforços no desenvolvimento de um produto em conformidade com o processo é puro desperdício. O que se espera desse tipo de processo, como em qualquer processo, é um ciclo de melhoria contínua a fim eliminar paulatinamente qualquer fonte de desperdício, e por mais incrível que pareça, as referidas fontes de desperdício acabam sendo em atividades redundantes e, sobretudo, em atividades da própria equipe de Quality Assurance. Quando uma equipe formal chega nesse nível significa que ela está madura. Quanto mais madura a equipe, menos atividades de inspeção e verificação são necessárias para garantir a conformidade com o processo e mais esforços podem ser realocado para garantir a conformidade do produto.

Em métodos ágeis, a conformidade com o produto é uma premissa, talvez seja por isso que são chamados de ágeis, e podem ser  observados no próprio manifesto ágil e em seus doze princípios.  As referidas premissas também podem ser observadas nos princípios do pensamento Lean, nos valores e práticas do eXtreme Programming, no jogo cooperativo do Crystal e nas cerimônias do Scrum.

Independente da abordagem, o que importa é “satisfazer o cliente, através da entrega adiantada e contínua de software de valor“. No entanto, no caminho para alcançar esse objetivo, as empresas que desenvolvem software tem que lidar com clientes que lidam diariamente com o caos, e freqüentes mudanças operacionais. Esse ambiente em constante mutação gera novas oportunidades e novas demandas dos clientes. O processo tem que ser flexível, melhorado continuamente  para atender as essas “oportunidades”, focando sempre na satisfação do cliente e embarcando conhecimento em conformidade com o  produto.

Panorama Geral do Curso:

Teremos bastante desenvolvimento no curso. Trabalharemos com Java, Ruby on Rail e Adobe Flex. O objetivo é que, no final, o aluno saia apto a integrar, liderar e implantar processos ágeis em equipes de desenvolvimento de softwares. Nas disciplinas de programação tentaremos introduzir Coding Dojo. Uma forma de interação muito maior, guiado por TDD. Um Coding Dojo é um encontro onde um grupo de programadores se reúne para trabalhar em conjunto em um desafio de programação. Eles estão lá para se divertir, e, através de uma metodologia pragmática, melhorar suas habilidades de programação e de trabalho em grupo. Nesse primeiro semestre tentaremos introduzir o Dojo nas disciplinas de Programação Orientada a Objetos e Padrões de Projeto.

O coding dojo surgiu da motivação que os programadores não treinam. Tipicamente eles estão preocupados apenas em resolver problemas de produção em projetos reais. O objetivo de coding dojo é criar um ambiente de treinamento, um ambiente de contínuo aprendizado e compartilhamento de experiências, independente do nível de habilidade dos participantes com o intuito de aplicar o aprendizado obtido nas reuniões para aplicar em situações reais de desenvolvimento.
A primeira disciplina “Métodos ágeis de desenvolvimento de software”, gosto de dizer que é uma disciplina de evangelização. Nela o aluno irá compreender os princípios e valores de equipes ágeis que pregam: auto-gerenciamento, multidiciplinaridade, TDD, programação em par, software funcionando, interação entre indivíduos, colaboração com cliente, resposta rápida a mudanças etc. Ou seja, essa será uma disciplinas para “quebrar” conceitos.

No decorrer do curo, o aluno irá ter contato com várias outras disciplinas que entrarão com mais cuidado em itens abordados na referida “evangelização”.
A última disciplina: “Laboratório de Engenharia de Software Ágil”, na verdade não será a última, ela ocorrerá em paralelo durante todo o segundo semestre do curso. Será nessa disciplina que o aluno terá a oportunidade de montar uma equipes agil, gerenciada com Scrum, aplicando técnicas de XP para construir um software (do início ao fim) utilizando as técnicas, processos e ferramentas estudadas durante o curso. No final, o aluno terá tido a sua primeira experiência em construir um software do zero seguindo metodologias ágeis.

Veja grade completa do curso aqui ou a grade oficial no site da UNA

Segue uma lista de excelentes livros sobre métodos ágeis.

• User Stories Applied – For Agile Software Development – Mike Cohn

• Refatoração – Aperfeiçoando o Projeto de Código Existente – Martin Fowler

• Modelagem Ágil – Scott W. Ambler

• A arte de Desenvolvimento Ágil – James Shore & Shane Warden

• Código Limpo – Habilidade Práticas do Agile Software – Robert C. Martin

• Domain-Driven Design – Eric Evans

• O Mítico Homem-Mês – Frederick P. Books jr.

• Programação extrema (xp) explicada – Kent Beck

• Padrões de projeto – soluções reutilizáveis de software orientado a objetos – Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides

• TDD – Desenvolvimento Guiado por Testes – Kent Beck

• Padrões de Arquitetura de Aplicações Corporativas – Martin Fowler

• O Programador Pragmático – de aprendiz a mestre – Adrew Hunt & David Thomas

• Agile Estimating And Planning – Mike Cohn

• Lean Software Development -  An Agile Toolkit – Mary Poppendieck & Tom Poppendieck

• Continuous Integration: Improving Software Quality and Reducing Risk – Paul M. Duvall & Steve Matyas & Andrew Glover

• Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation -  Jez Humble & David Farley

• Test Driven Development A Practical Guide

• Practical Guide to Feature Driven Development, Stephen R. Palmer; John M. Felsing

• Crystal Clear, Cockburn

• Coaching Agile Teams, Adkins

• Agile Game Developent with Scrum, Keith

No link abaixo segue uma lista mais completa de livros sobre métodos ágeis de desenvolvimento: List of 100 best books for agile software development http://bit.ly/cg4K1R

O Conhecimento tácito é aquele que reside essencialmente na cabeça das pessoas. É baseado em experiências pessoais e em um contexto específico.

O Conhecimento explícito é transmissível em linguagem formal como documentos, modelos, diagramas, etc.

No capítulo 4  – “Criação do Conhecimento como Processo Sintetizador”, os autores afirmam que o conhecimento não é criado espontaneamente, mas através de interação entre indivíduos, a organização e o ambiente. A criação do conhecimento inicia com o processo de socialização no qual o novo conhecimento tácito é convertido através das experiências compartilhadas na interação social do dia a dia. Eles defendem ainda que o papel da organização no processo de criação do conhecimento organizacional é promover o contexto apropriado para facilitar as atividades de grupo.

Segundo os autores, o conhecimento necessita de um contexto físico para que seja criado. O conhecimento não pode ser criado no vácuo, e necessita de um lugar onde a informação recebe significado através de interpretação para transformar-se em conhecimento. No livro, os autores introduziram o conceito de “ba” (que significa grosseiramente “lugar”) para definir o local no qual o conhecimento é criado, partilhado e utilizado.

Embora seja fácil considerar o ba como um espaço físico como uma sala de reuniões, ele deve ser entendido como interações que ocorrem em um tempo e local específicos. O ba pode emergir em indivíduos, grupos de trabalho, equipes de projeto, círculos informais, encontros temporários e em espaços virtuais como grupos de email e redes sociais.  O ba é um local existencial onde os participantes partilham seu contexto e criam novos significados através de interações. Os participantes do ba trazem seus próprios contextos e, por meio das interações com os outros e o ambiente, mudam o contexto do ba, dos participantes e do ambiente. Na criação do conhecimento, a geração e a regeneralização do ba é a chave, pois o ba proporciona energia, qualidade e local para desempenhar as conversões individuais e percorrer a espiral do conhecimento. O ba é onde a informação é interpretada para tornar-se conhecimento.

O paradigma de Nonaka sobre a criação do conhecimento destaca tanto o processo de criação do conhecimento quanto as condições sob as quais o conhecimento é criado. Essencial para esse paradigma é a interação entre o conhecimento tácito e explícito.  A criação do conhecimento é uma espiral, descrita pelo modelo SECI.

Modelo SECI - Adaptação dos texto de Nonaka e Takeuchi

Esse modelo descreve como o conhecimento tácito é criado através da socialização, convertido de tácito para explícito através da externalização,  recombinado com outras formas de conhecimento explícito através da combinação e convertido, novamente, em conhecimento tácito através da internalização.

Quando li esse capítulo do livre logo remeti o conceito do ba ao conceito de coding dojo.  Segundo o http://codingdojo.org/ “um Coding Dojo é um encontro onde um grupo de programadores se reúne para trabalhar em conjunto em um desafio de programação. Eles estão lá para se divertir, e, através de uma metodologia pragmática, melhorar suas habilidades de programação e de trabalho em grupo.”

O coding dojo surgiu da motivação que os programadores não treinam. Tipicamente eles estão preocupados apenas em resolver problemas de produção em projetos reais. O objetivo de coding dojo é criar um ambiente de treinamento, um ambiente de contínuo aprendizado e compartilhamento de experiências, independente do nível de habilidade dos participantes com o intuito de aplicar o aprendizado obtido nas reuniões para aplicar em situações reais de desenvolvimento.

A prática de coding dojo se assemelha ao conceito do ba.  Seguindo a interpretação de Nonaka e Takeuchi sobre um ambiente de criação de conhecimento, aliado ao conceito de coding dojo,  foi possível criar uma tabela de inter-relação entre o Modelo SECI de criação do conhecimento sob o âmbito da dimensão epistemológica (vide Nonaka e Takeuchi).

Com esse tipo de prática, cada vez mais empresas de desenvolvimento de software estão incorporando reuniões de dojo com o propósito de treinar a equipe, criar novo conhecimento, difundi-lo na organização como um todo e, eventualmente, incorporá-lo a produtos, serviços e sistemas.  Dessa forma, o conhecimento individual na dimensão epistemológica é convertido, por meio de um espiral do conhecimento,  em conhecimento organizacional em uma dimensão ontológica. Essa conversão se dá por interações continuas (coding dojo), em um tempo e local adequado (ba) do indivíduo ao grupo, do grupo à organização, da organização à inter-organização.  Nesse ambiente, a função da empresa no processo de criação do conhecimento é fornecer o contexto apropriado para facilitação das atividades em grupo para criação e acúmulo de conhecimento em nível individual.

Atualmente, muitas empresas estão percebendo o ambiente de socialização produzido por esse tipo de reunião, e estão abrindo as reuniões para a comunidade.  Outras abordagem, são grupos de desenvolvedores que se reúnem espontaneamente, com objetivo de compartilhar conhecimento, treinamento e principalmente diversão.  Esse exemplo ilustra o papel central que as equipes auto-organizadas desempenham no processo de criação do conhecimento.

Este vídeo explica o que é um coding dojo e como organizá-lo.(Em inglês)

Sabe-se que o aprendizado consiste em dois tipos de atividades. O primeiro é obtido através do know-how. O segundo tipo é obtido por meio de novas experiências como exemplos, paradigmas, modelos mentais ou perspectivas. Em ambos, existe um tripé necessário para a conversão de conhecimento em conhecimento tácito e intrínseco do indivíduo. O referido tripé é formado pelas seguintes ações: ver, sentir e fazer.

A tabela a seguir relaciona as ações do tripé ao coding dojo.

Este outro vídeo explica o que é um coding dojo e mostra as suas regras e variações.(Em Português)

De fato, o aprendizado mais poderoso vem da experiência direta, de interação entre indivíduos, de ver, sentir e fazer. Aprendizado continuo em diversas áreas de conhecimento gera no indivíduo um conhecimento horizontal e holístico, que, com um pouco de pragmatismo,  propiciam a criações de novas opiniões, novos pontos de vista e de novas idéias originais e inovadoras.  Idéias originais emanam de indivíduos autônomos, difunde-se dentro da equipe, transformando-se então em idéias da organizacionais. E porque não em um novo start-up?

Atá a próxima viagem….

Edgard

Em uma aula rotineira, próxima do fim do semestre um aluno me indagou e começamos o seguinte diálogo:

Aluno: Professor, como será a prova final?
Eu: Não vou dar prova final!
Aluno: Como assim??
Eu: É isso mesmo, não vou dar prova final. Prova não prova nada. Vamos fazer algo diferente…
Aluno: O que vamos fazer então? (com um ar de preocupado!)
Eu: Vamos fazer um coding dojo.
Aluno: ????

Eu pessoalmente já estava ficando desentusiasmado com aplicação de provas tradicionais; abertas, fechadas, verdadeiro o falso, etc. Honestamente, eu como aluno nunca gostei de fazer provas e como professor detesto mais ainda ter que aplicar.

Nesse semestre tive a oportunidade de fazer diferente. Nesse ano, acompanhando a comunidade em blog e twitter, acabei conhecendo um conceito chamado Coding Dojo.  Segundo o http://codingdojo.org/: “Um Coding Dojo é um encontro onde um grupo de programadores se reúne para trabalhar em conjunto em um desafio de programação. Eles estão lá para se divertir, e, através de uma metodologia pragmática, melhorar suas habilidades de programação e de trabalho em grupo.”

Expliquei para meus alunos o que era Dojo, indiquei alguns links onde eles poderiam ler mais sobre o assunto, entender os formatos, etc. Passei uma lista de assuntos que os alunos poderiam escolher como tema para fazer em formato de Dojo, entre eles: frameworks e ferramentas de teste unitário, teste de carga, teste de aceitação, teste funcional, teste de performance, teste de BD, refactory, deploy continuo, bug tracker, controle de versão, ou qualquer outra que julgássemos relevante e que agregasse valor para a turma.

Em seguida esse mesmo aluno me indagou novamente:

Aluno: Professor. Então nós vamos ter que fazer uma apresentação para turma?
Eu: Vocês não vão apresentar nada. Vocês vão se reunir em dupla, vão escolher um tema dentre os vários que eu passei, vão pesquisar e estudar sozinhos e vão ensinar para os colegas da turma o que vocês aprenderam. E no final vocês terão que enviar um tutorial para o resto da turma, caso alguém queira repetir o que você ensinou.
Aluno: Professor, e como você vai avaliar isso.
Eu: Eu não vou avaliar nada. Quem dará os pontos do seu dojo serão seus próprios colegas. Se seu Dojo for bom, agregar valor e conhecimento aos seus colegas, certamente eles te darão uma boa nota.
Aluno: ???

Abaixo segue a foto de um dos dias do Dojo (infelizmente nesse dia estávamos sem datashow).

Resultado:

1. Alunos satisfeitos e empolgados com a idéia.
2. Alunos naturalmente comprometidos. (mais do que o normal…)
3. Boas notas devido ao comprometimento dos alunos.
4. Compartilhamento de conhecimento:  Eu particularmente vi várias ferramentas que não conhecia.
5. Agregação de valor.
6. Os alunos puderam ter contato várias ferramentas e framework que, em uma prova convencional, eles nunca veriam.
7. Vários outros professores começaram a me parar para perguntar o que era aquele tal de “dojo” que os alunos tanto comentavam.

Enfim, foi uma boa experiência que quero continuar nos próximos semestres

Público Alvo

Desenvolvedores Web e Desktop que estejam interessando em desenvolver aplicações RIA utilizando Adobe Flex integrado com Java EE.

Ementa

Este workshow  tem o objetivo de capacitar o aluno ao desenvolvimento de aplicações ricas para a Web RIA (Rich Internet Application) utilizando Adobe® Flex™ e Java EE

O curso apresenta uma visão integrada de Adobe Flex contemplando aspectos relacionados desde manipulação de dados e componentes em Flex até a sua integração com um back-end Java.

No fim do curso, o aluno com bom aproveitamento será capaz de desenvolver aplicações RIA, explorando frameworks MVC mais utilizados no mercado e explorando vários meios de comunicação.

• Introdução
• Containers de Layout
• Componentes de Navegação
• Trabalhando com Eventos(Disparar e capturar)
• Usando Janelas Popup
• Trabalhando com módulos
• Introdução ao BlazeDS
• Comunicando Adobe Flex com back-end Java EE
• Comunicação em Real-Time (Messages)
• Frameworks MVC para Flex

Pré-requisito

Conhecimento em programação orientada a objetos e em desenvolvimento de aplicações Web ou desktop.

Detalhes:

Data: De 19 a 23 de julho de 2010 – 19:00h às 22:00h
Local: Núcleo de Educação Continuada da Challenge IT
Endereço: Rua Gonçalves Dias, 1181 / 1005 -  Savassi

Instrutor

Edgard Davidson Costa Cardoso

Profissional especialista em engenharia de software e desenvolvimento de sistemas, professor universitário, coordenador do curso de Pós Graduação em Engenharia de Software Centrada em Métodos Ágeis ofertado pela UNA, mestrando em Engenharia Elétrica com ênfase em Engenharia de Software, Especialista em Engenharia de Software, Graduado em Sistemas de Informação. Sou sócio da MÉRITA – ENGENHARIA DE SERVIÇOS E SISTEMAS e atualmente estou utilizando Java como back-end  e Adobe Flex como front-end em projetos e em Mentoring.

Habilidades Após o Workshop

Compreender a tecnologia de RIA (Rich Internet Application) da Adobe.
Desenvolver aplicações RIA utilizando Adobe Flex
Integrar front end (Flex) com back end (Java EE)
Compreender a utilização o Blaze DS
Compreender a utilização de frameworks MVC no Flex
Compreender a integração de Flex com outras tecnologias além do Java

Agenda

• Introdução
  • O que é RIA – Rich Internet Applications
  • Aonde procurar ajuda
  • O que é o MXML
  • MXML e o ActionScript
  • Diferença entre Flex e AIR.
  • Hello World em Flex
  • Data Binding
  • Entendo o que significa assincronismo.
• Containers de Layout
  • Tipos de Containeres
  • Application, Box, Panel, TitleWindow, Form,  ControlBar
  • Layout absoluto e relativo
• Componentes de Navegação
  • ViewStack
  • Accordion
  • TabNavigator
  • States
• Trabalhando com Eventos(Disparar e capturar)
  • Ouvindo eventos em MXML
  • Evento de Objetc
  • Disparar e capturar eventos.
  • Eventos Customizados
• Usando Janelas Popup
  • Criando um janela popup personalizada
  • Removendo uma janela popup
  • Manipulando evento de uma janela popup
• Trabalhando com módulos
  • Criando um componente Module
  • Carregando um módulo com ModuleLoader
  • Manipulando eventos de um componente módulo
  • Passando dado para um módulo
• Introdução ao BlazeDS
  • Download e configuação
  • Entendendo os arquivos de configuração
• Comunicando Adobe Flex com back-end Java EE
  • HTTPServices
  • WebServices
  • Remote Object – RPC ( Remote Procedure Calls )
• Comunicação em Real-Time (Messages)
  • Data Push
  • Construindo um exemplo
• Frameworks MVC para Flex
  • Cairngorm
  • Swiz
  • Mate

Investimento

R$ 595,00 ou 3 X de R$ 198,33

Descontos:

• 05% para pagamento à vista
• 10% para associados de entidades convêniadas
• 15% para estudantes de escolas convêniadas

* Descontos não cumulativos

Inscreva-se

Objetivo do Curso

O curso de pós-graduação lato sensu em Engenharia de Software Centrada em Métodos Ágeis tem como objetivo principal especializar profissionais para o desenvolvimento de softwares de qualidade. Este curso busca capacitar os participantes para uma visão abrangente e atualizada de engenharia de software e, em especial, capacitá-los em métodos ágeis focalizando nas tecnologias correntes para o desenvolvimento de software. O curso contempla tópicos como métodos ágeis, programação orientada a objetos, padrões de projeto, engenharia de requisitos ágeis , usabilidade, arquitetura e teste de software bem com o desenvolvimento aplicações WEB e RIA (Rich Internet Application). Durante o curso, os alunos exercitarão práticas ágeis integradas às outras disciplinas, proporcionando a transversalidade de conhecimento entre os conteúdos. No final, o aluno estará capacitado a implantar, integrar, liderar equipes ágeis de desenvolvimento de software aplicando técnicas e tecnologias atuais de mercado.

Público Alvo

Profissionais de nível superior das áreas de Sistemas de Informação, Ciência da Computação, Análise e Desenvolvimento de Sistemas e Engenharia que atuam no mercado e que desejam se especializar no desenvolvimento de software com qualidade, flexibilidade e visando o máximo retorno sobre o investimento nos projetos de software, ampliando seus conhecimentos nas metodologias, tecnologias e processos que suportam o desenvolvimento ágil de software.

Resultados Esperados

O resultado esperado do curso é que no final o aluno esteja capacitado a:

• Identificar quais são as vantagens e desvantagem de se adotar uma abordagem formal ou ágil para desenvolvimento de software.
• Implantar processos ágeis em equipes de desenvolvimento de softwares, aplicando práticas ágeis no dia a dia do desenvolvimento e possibilitando que o conceito de auto-gerenciamento funcione.
• Liderar equipes que utilizam métodos ágeis de desenvolvimento.
• Gerenciar projetos com práticas ágeis como o Scrum.
• Desenvolver projetos de software em um em equipes ágeis com tecnologias Web e de Rich Internet Application (RIA)
• Ser um profissional crítico, formador de opinião, que entenda de tecnologia, e que estejam capacitados a integrar equipes ágeis contribuindo para a melhoria da qualidade de software nacional.
• Agregar valor no produto de software por meio da Integração disciplinas de engenharia de requisitos, usabilidade, padrões de projeto, arquitetura e teste de software

Diferenciais do Curso

Entre os principais diferenciais do curso de Engenharia de Software Centrada em Métodos Ágeis da UNA está no seu corpo docente, composto por professores com ampla vivência no mercado de trabalho, sua grade curricular composta de disciplinas teóricas e práticas, com conteúdo em acordo com as exigências do mercado, sintonizado com o pensamento ágil, e, sobretudo, que é o único curso pós graduação lato senso em Engenharia de Software de Belo Horizonte totalmente focado na filosofia ágil.

Estrutura Curricular

Disciplinas do primeiro semestre do curso

Disciplinas do segundo semestre do curso

Blog do Curso:

http://engenhariadesoftwareagil.com

Carga horária

360 horas/aulas

Dias e horários

• Sextas-feiras, das 19h25 às 22h55, no Campus Guajajaras
• Sábados, das 08h30 às 12h00 e das 13h00 às 16h30, no Campus Barro Preto

Investimento

• Valor Integral = R$ 6.850,00 ou 18 X R$ 464,98
• Valor com Desconto = R$ 5.137,50 ou 18 X R$ 348,74*

* O valor do respectivo curso está com 25% de desconto e será praticado apenas para matrículas efetivadas adiantadamente.

Localização

Una
Campus Barro Preto
Rua Goitacazes, 1159, bairro Barro Preto – Belo Horizonte – MG

Matricula

Em dezembro de 2010 e janeiro de 2011. Aguarde a próxima turma.

Início do Curso

Próxima turma: Fevereiro de 2011

Coordenação

Tire suas dúvidas com o coordenador.

Professor: Edgard Davidson Costa Cardoso
E-mail: edgard.cardoso@prof.una.br
twtter: www.twitter.com/edgarddavidson
skype: edgarddavidson

JUnitPerf

Veja a documentação completa em no site oficial do  JUnitPerf.

Para saber mais sobre teste unitário com JUnit, veja o meu post anterior e assista os vídeos de Teste Unitário com JUnit..

JUnitPerf oferece classes que permitem construir objetos que recebem testes existentes do JUnit e acrescentam neles avaliação de desempenho. Ele não  altera testes existentes. Pode-se ainda rodar os testes sem o JUnitPerf.

Roteiro para execução do JUnitPerf:

1. Primeiro é preciso estimar os valores ideais para execução dos testes.
2. Escreva testes JUnit para o seu código.
3. Execute um profiler para descobrir os gargalos. Utilize os dados obtidos como parâmetros para estabelecer os valores máximos aceitáveis para cada método.
4. Escreva testes do JUnit (se não existirem) para os trechos críticos quanto à desempenho.
5. Escreva um TimedTest do JUnitPerf para cada teste novo e execute-o. O teste deve falhar. Se passar, não há problema de desempenho com o código.
6. Trabalhe no código até que os testes passem.

TimedTest

Recuperar o tempo transcorrido após a execução do teste JUnit. Se o tempo for maior que o permitido então uma exceção AssertionFailedError é provocada (o que faz o teste falhar)

Exemplo: TimedTest simples que espera que o método execute em menos de 2 segundos (2000 milissegundos)

public static Test suite() {
     TestSuite suite = new TestSuite();
     Test testCase = OperacoesTest.suite();
     Test testCase = new  OperacoesTest("testSoma");
     Test timedTest = new TimedTest(testCase, 2000);
     suite.addTest(timedTest);
     return suite;
}

LoadTest

Permite simular carga, por exemplo, vários usuários acessando a aplicação ao mesmo tempo. Essencial para descobrir problemas que podem surgir em ambientes multiusuário (por exemplo: problemas de concorrência e integridade de dados usados por vários usuários)

Exemplo: LoadTest simples (executa uma vez por usuário) com 100 usuários simultâneos

public static Test suite() {
     TestSuite suite = new TestSuite();
     Test test = new ExampleTestCase("testMethod");
     Test loadTest = new LoadTest(test, 100);
     suite.addTest(loadTest);
     return suite;
}

A seguir, assista o vídeo:

Automatização de Testes de Desempenho com JUnitPerf from Edgard Davidson on Vimeo.

O código fonte completo poder ser baixado aqui.