Especialistas apontam os principais erros cometidos pelas empresas em implantações de sistemas de gestão.

Por Rodrigo Caetano, da Computerworld
19 de agosto de 2009 – 07h00

Grandes projetos, grandes problemas. Não importa a metodologia utilizada, a ferramenta escolhida e o tamanho da equipe. É comum, até demais, que implementações de sistemas de gestão (ERP) fracassem. Prazos são estourados, orçamentos vão muito além do limite e os resultados não correspondem às expectativas das áreas de negócios.

Mesmo projetos bem sucedidos enfrentam problemas no seu decorrer. Sejam eles motivados pela cultura da empresa, por mau planejamento ou briga de egos, os percalços acabam custando caro para as companhias. Afinal, no mundo dos negócios, tempo é dinheiro e sistema que não funciona é igual a processos que não funcionam.

Segundo a consultoria Gartner, a segunda maior prioridade dos executivos de tecnologias para este ano é implementar ou atualizar o sistema de gestão. A vice-presidente de pesquisas da empresa, Ione Coco, afirma que o cenário não deve mudar, pelo menos, até 2012. O que leva a uma reflexão: apesar de tão importantes, por que os projetos de ERP fracassam?

Apontar uma razão principal é difícil, mas, segundo especialistas, existem alguns fatores comuns encontrados nas empresas que, fatalmente, levam ao mau resultado. O primeiro não tem nada a ver com questões técnicas, mas sim com a cultura das organizações. Segundo Ione, as empresas, e principalmente os departamentos de TI, precisam saber o que esperar de um projeto. Estimativas altas demais, ou mesmo com foco errado, comprometem todo o trabalho, não importa se foi bem feito.

Para o sócio da consultoria Mondo Strategies, especializada em gestão integrada de software, Ernani Ferrari, o problema das estimativas ainda vai além do resultado. As empresas têm dificuldades para prever a quantidade de tempo e recursos necessários para a conclusão do projeto. Como conseqüência, tendem a acelerar uma das pontas do processo, pulando etapas e cortando custos, prejudicando as demais.

Em apresentação feita durante evento promovido pela Associação de Usuários SAP do Brasil (Asug), entidade que reúne clientes da fornecedora alemã de sistemas de gestão, o diretor do capítulo São Paulo do Project Management Institute (PMI), Paulo Moraes, apontou alguns pontos que fazem a diferença na hora de iniciar um projeto. O PMI é uma associação sem fins lucrativos que desenvolve estudos sobre o gerenciamento de projetos. Área onde, geralmente, começam os problemas.

Confira as dicas do executivo:

- Falta de uma camada de gerenciamento de projetos: no mínimo, a empresas precisa conhecer as melhores práticas de gerenciamento descritas no PMBOK, principal publicação feita pelo PMI. Mas, qualquer metodologia serve, desde que esteja presente.

- Falha no planejamento do projeto: essa talvez seja a fase mais crítica de um projeto. Segundo Moraes, as empresas não pode ter preguiça de escrever, fazer diagramas, relatórios, etc.

- Processos críticos de negócios mal definidos: quase uma conseqüência do mau planejamento. Fatalmente, caso isso aconteça, a empresa terá de fazer mudanças no sistema depois de estar pronto.

- Falha em detalhar os processos nas pontas: caso a empresa não conheça exatamente a rotina das pessoas que vão, de fato, utilizar o sistema, fatalmente fará algo inútil ou complicado demais.

- Falta de envolvimento do pessoal das pontas: Moraes conta uma história curiosa. Determinada empresa, após implementar um novo ERP, começou a ter problemas com a qualidade dos dados. Após meses de investigação, descobriu que os operadores de empilhadeira, responsáveis pela coleta dos dados nos armazéns da companhia, não conseguiam digitar corretamente nos computadores de mão por usarem luvas. Este pequeno detalhe acabava comprometendo todo o processo.

- Falha em preparar o sistema para agüentar os picos de utilização: nenhum sistema é utilizado com a mesma freqüência o tempo inteiro. É preciso saber o quanto ele agüenta e quanto terá de agüentar, quando for exigido em carga máxima.

- Evangelizar os patrocinadores do projeto: tudo tem de estar escrito. “Se não está explicitamente indicado, está implicitamente excluído”, afirma Moraes. Todos os envolvidos no projeto precisam ter consciência do que está no papel e saber que é isso que será realizado, nada menos, nada mais.

- Iniciar a implantação antes de definir o escopo: nada acontece antes que o cronograma e os recursos estejam bem definidos e formalmente aprovados.

- Estouro do escopo: estratégias e cenários econômicos mudam, mas não é possível modificar o projeto a cada novidade de mercado. Por isso é fundamental ter um sistema bem definido de gerenciamento de mudanças.

- Grandes modificações de software padrão: um sistema SAP, segundo Moraes, faz muita coisa. Antes de modificar o software, certifique-se, realmente, que isso é necessário.

- Falhas de testes: de 20% a 40% do tempo total de projeto deve estar reservado para os testes. E eles só são válidos se forem devidamente documentados.

- Falta de treinamento: é um erro reduzir o custo do projeto cortando o treinamento. É necessário ter um plano de treinamento, que serve, também, para avaliar o conhecimento dos usuários.

- Falhas ao carregar os dados no sistema: um sistema ERP gera mudanças culturais na empresa. Muitas vezes, os funcionários estão acostumados a usar diversos sistemas legados, cada um referente a uma determinada época. Por isso é preciso definir o alcance do novo sistema. Falta de dados também é um problema. Se um usuário diz que precisa trabalhar com determinada informação, não significa, necessariamente, que ela exista.

- Falha no “cut over”: a data de inauguração do novo sistema, e desligamento de antigo, deve estar definida e o processo planejado. É impossível fazer isso sem causar impacto. Este plano tem de ser discutido já na fase de planejamento do projeto.

- Falhas após o “go live”: depois de estar tudo funcionando, não é difícil se deparar com um time de suporte mal dimensionado. Outros problemas são a falta de documentação e falhas no entendimento das responsabilidades dos envolvidos.

- Deixar os testes para depois do “go live”: testes devem ser feitos durante a fase de testes. Testar quando o usuário está precisando da ferramenta dará dor de cabeça, com absoluta certeza.

Fonte: Computerworld

Por José Papo para o José Papo Weblog
em 18/08/2009

Morte do Agile? Será que o José Papo enlouqueceu, alguns devem se perguntar? Não enlouqueci não! Na realidade, o que pretendo argumentar aqui é minha opinião (reforçada por outros papas do desenvolvimento de software, como o Ivar Jacobson) de que hoje já deveríamos considerar a distinção entre Agile e “Engenharia de Software Tradicional” como algo do passado. Na realidade, o que argumento é que os princípios e práticas pregados pelos agilistas são a Engenharia de Software da atualidade e do futuro próximo.

Ainda em muitos lugares Agile é visto como uma novidade, mas a realidade é que se você deseja realizar projetos de qualidade e com alta produtividade só conseguirá realmente utilizando as práticas adotadas pelos agilistas.

Assim como o Jacobson, já começo a ver as guerras metodológicas como coisas do passado, brigas de egos entre metodologistas… he, he! Em vez de ficarmos falando de uma metodologia ou processo versus outro devemos focar nos melhores princípios e práticas que nos trarão vantagem competitiva no desenvolvimento de produtos de software com qualidade.

Os princípios já estão claros quais são para as novas organizações de desenvolvimento de software: Os princípios do Manifesto Ágil.

Já as práticas podem mudar e devemos usar aquelas mais interessantes para cada projeto. Se o projeto é complexo e tem um modelo de entidades com um negócio muito rico porque não usar a prática de desenvolver um modelo de domínio, como descrito no FDD? Se temos uma equipe que ainda não se conhece bem porque não usar pair programming do XP?

Outras práticas deveriam ser obrigatórias, pois garantem a qualidade do produto. Desenvolver um novo sistema sem testes unitários automatizados é assinar uma sentença de morte para o projeto antes mesmo dele terminar.

Uma outra notícia interessante que mostra ainda mais essa guinada das empresas para o uso do Agile como o padrão da Engenharia de Software de nossos tempos: Na versão 7.5 do Rational Unified Process é possível encontrar uma série de práticas, obrigatórias ou opcionais. O fundamento do RUP se chama “Agile Core”. Este contém as práticas de desenvolvimento iterativo, planejamento de projetos em dois níveis, Time completo, Test-Driven Development e Integração Contínua.

Essa nova versão reforça ainda mais duas mensagens:

- A primeira é que o RUP está ainda mais Ágil e de forma ainda mais clara.
- E a segunda é que se você ainda usa os artefatos do RUP, mas faz tudo em cascata, sem testes unitários automatizados e sem integração contínua tenho que reforçar a má notícia: você não está usando o RUP!!! Portanto, não culpe o processo ou metodologia pelo fracasso do projeto caso não esteja seguindo seus princípios e práticas fundamentais.

Fonte: José Papo Weblog

O Blog “Ravings of a Developer TS” disponibilizou uma série de links de materiais gratuitos, referentes a tecnologias Microsoft para desenvolvedores.

Vale a pena conferir em: http://blogs.msdn.com/angelab/archive/2009/07/29/hey-microsoft-coders-free-stuff-training-books-magazines-to-sharpen-your-skills.aspx

Fonte: Twitter Andre Dias

Postado por Vikas Hazrati, traduzido por Marcelo Andrade em 14 Ago 2009 09:01 AM

O Manifesto Ágil recomenda ter-se “Software funcionando mais que documentação abrangente". Isto tem levado muitas equipes a acreditar que não existe necessidade de documentação em projetos ágeis. Os críticos apontam a limitada documentação como uma das fraquezas das metodologias ágeis. Ron Jeffries destacou que as metodologias ágeis não recomendam que não haja nenhuma (nem pouca) documentação, mas sim que enfatizam fortemente que haja a documentação certa. Ele menciona,

Um dos argumentos contrários à XP sequer é verdadeiro. As pessoas acham que dissemos que documentação é uma má ideia. O XP é focado no diálogo direto como meio para máxima efetividade. Nossas recomendações sobre documentação seguem este simples fato.

Com outras palavras, Eelco Gravendeel acrescenta que há apenas dois tipos de documentação em metodologias ágeis,

• Documentos necessários para que todos os integrantes da equipe trabalhem no projeto – Em um mundo ideal, os membros da equipe estão colocalizados e todo o conhecimento deveria ser compartilhado e transferido por comunicação direta. Entretanto, se a equipe estiver distribuída e o conhecimento precisar ser transferido, então escrever documentos e suplementá-los com conferências de áudio/vídeo pode ser útil. Um conjunto mínimo de documentos também é necessário para que as equipes possam falar uma linguagem ubíqua e estejam num mesmo patamar de entendimento.

Eelco sugere que muitos documentos, que são criados para apoiar a criação do produto, demandam uma atenção bem próxima, uma vez que tais documentos perdem-se tão logo o projeto esteja concluído. Segundo ele,

Tão logo você aceite que os documentos que são escrito apenas para apoiar o processo de criação do produto devem ser perdidos assim que o projeto esteja terminado e o produto entregue, há a esperança de que você também possa resistir à vontade de deixar qualquer documento totalmente pronto e 100% correto! Isto é exatamente a razão que faz da escrita de documentos uma tarefa que consome tanto tempo (e portanto, uma tarefa tão custosa!). Uma vez que você aceite que você só precisa de fato escrever apenas o suficiente para transmitir sua mensagem ou para evitar de esquecer coisas importantes, você vai compreender que papel & caneta, fotos de desenhos em quadros brancos, rabiscos no verso de diagramas, cartões de histórias, etc., são o bastante para estes propósitos!

• Documentação a ser entregue junto com o produto final. - Estes são os documentos que fazem parte do produto entregue e que são acordados em conjunto com o cliente. Exemplos típicos incluem

1. Manuais de usuário
2. Manuais de desenvolvedor
3. Guias de manutenção (para como operacionalizar o software)
4. Documentação técnica (para manter o código-base) etc.

Mesmo no caso destes documentos, Eelco sugere,

Quando você acordar sobre as documentações que serão entregues junto com o produto, você ainda pode ser criativo quanto ao formato da documentação. Você pode escrever extensos manuais de usuário, ou você pode usar técnicas modernas como manuais em vídeo gravados com screencast. Esta segunda opção costuma ser mais barata (estatisticamente, cerca de 10 vezes mais barata!) e com muito mais possibilidade de ser utilizada de fato.

Assim, tem-se que há dois tipos de documentos, um que auxilia à equipe e outros que precisam ser entregues junto com o produto final. Se uma equipe ágil estiver preparando documentos que não se encaixem numa dessas categorias, então tais documentos vão demandar um cuidado especial. Em muitos casos, a equipe deveria ser capaz de evitar ter de criar tais documentos.

Fonte: InfoQ

Em 2008 correu o evento de lançamento do InfoQ Brasil. Esse painel aborda assuntos como: Projetos Ágeis não falham? Quais são os critérios para definir o sucesso de um projeto? Por que escolher agile? Confira!

http://www.infoq.com/br/presentations/painel-agile

Postado por Deborah Hartmann Preuss, traduzido por Marcelo Andrade em 12 Ago 2009 09:32 AM

Um pequeno estudo em 2008, mostrando que equipes ágeis eram mais eficazes que as equipes tradicionais, apontou que: "Por ser baseada em numerosos colaboradores pessoais, a produtividade é quase sempre a medida mais difícil de ser melhorada nas organizações." Tathagat Varma, gerente geral de uma grande empresa de soluções em gestão de desempenho em TI, questionou-se se a melhoria da produtividade num ambiente ágil poderia estar relacionada a aprimoramentos no trabalho em equipe. Então ele fez uma análise dos valores e práticas ágeis, mapeando-as para os Cinco Desafios de uma Equipe – Uma Fábula sobre Liderança, de Patrick Lencioni. Este artigo pode ser útil para discussão dos benefícios da agilidade com gerentes que tenham achado o livro de Lencioni útil.

O livro de Lencioni usa um modelo de 5 disfunções (a pirâmide de é invertida aqui para mostrar como a confiança é a disfunção mais básica, e que as demais são construídas sobre ela)

• Ausência de Confiança
  • Membros da equipe que que não sejam realmente francos uns com os outros sobre seus erros e fraquezas tornam impossível construir uma base de confiança.
• Medo do Conflito
  • Equipes em que falte confiança são incapazes de se engajar num debate e entusiasmado de ideias.
• Falta de Comprometimento
  • Incapazes de compartilhar suas opiniões durante um debate aberto, os membros da equipe raramente (talvez até nunca) se comprometem com as decisões.
• Perda de Responsabilidade
  • Sem comprometimento com um plano de ação claro, mesmo as pessoas mais focadas e direcionadas normalmente hesitam em chamar atenção de seus pares para ações e comportamentos que pareçam contraprodutivos para a equipe.
• Desatenção para os Resultados
  • Desatenção para os resultados acontece quando os membros da equipe põem suas necessidades individuais (como reconhecimento pessoal ou desenvolvimento de sua carreira) ou mesmo necessidades de seus setores acima dos objetivos coletivos da equipe.

Varma aponta que:

… por mais que as práticas ágeis ajudem explicitamente na ‘descoberta de melhores maneiras de se desenvolver software’, também direciona sutilmente o aspecto das disfunções da equipe. Sem precisar pedir diretamente às pessoas que modifiquem seu comportamento, as práticas ágeis ajudam na superação de algumas das disfunções mais comuns nas equipes, criando uma base sólida sobre a qual a equipe pode desenvolver suas atividades. Quando as disfunções de equipe de mais baixo nível tiverem sido eliminadas, haverá uma forte base de confiança mútua, além de uma propriedade e responsabilidade dos compromissos da equipe, o que contribui para que ela mantenha seu foco nos resultados coletivos sem descambar para questões de promoção pessoal..

Segue um resumo de algumas conclusões de Varma:

Confiança:  Além das óbvias práticas de construção da confiança (práticas ágeis recomendam o diálogo cara-a-cara, feedback diário, retrospectiva), equipes ágeis também são pequenas, de forma que os membros da equipe não competem pois geralmente devem ter habilidades e atribuições complementares entre si.  

Conflito: Equipes ágeis se empenham juntas nas atividades como definições de trabalho, tomadas de decisão, apresentação para os clientes e retrospectivas. Ainda que a maioria desse trabalho conjunto possa potencialmente incentivar um clima de competição, a abordagem ágil favorece o que Lencioni chama de "conflito produtivo" – em que as equipes têm reuniões interessantes e animadas, extraem e exploram ideias de todos os membros da equipe e minimizam questões políticas.

Comprometimento: Práticas ágeis recomendam fortemente que todas as coisas sejam dirigidas e estejam sob controle da equipe – e o progresso e o sucesso podem ser meramente medidos pelo grau de envolvimento que tenha sido experimentado pela equipe..

Responsabilidade: Além da ênfase das recomendações Agile sobre comprometimento claro e responsabilidade frequente, equipes ágeis são pequenas e trabalham com forte colaboração; o trabalho de cada membro da equipe fica visível, criando uma responsabilização pessoal (pelo trabalho em equipe e não por pressão superior).

Resultados: As entregas pequenas e frequentes de software funcionando incluem transparência sobre o progresso e o valor entregue, o que reduz as possibilidade de que grandes falhas aconteçam; em particular, desde que, depois de cada iteração, o progresso da equipe seja medido em termos de valor de negócio entregue..

Fonte: InfoQ

segunda-feira, 10 de agosto de 2009, 17h18

Recentemente o erro no sistema de preços da loja online da Fnac fez a rede varejista oferecer TVs LCD, computadores e leitores de Blu-ray por R$ 9,90, preço irrisório frente aos reais valores de cada equipamento, comercializados normalmente por mais de R$ 9 mil. A falha ocorreu no sistema automático que libera promoções a partir da meia-noite.

Cerca de 100 consumidores aproveitaram o valor excessivamente baixo para fechar compras. No entanto, a negociação foi desfeita, em virtude do erro do software. Caso fosse concretizada a operação, os prejuízos seriam superiores a R$ 900 mil. A situação poderia ter sido evitada, reduzindo custos e riscos, se fossem feitos avaliações do sistema antes de serem utilizados para operações importantes ou não.

Existe ainda a questão da imagem da empresa perante seu público-alvo. Certamente bancos, companhias de cartão de crédito, de telecomunicações ou e-commerce, por exemplo, sofreriam impactos gigantescos – não somente financeiros, se suas redes ou sistemas ficassem indisponíveis a seus clientes, mesmo que por alguns instantes.

Encontrar erros e defeitos em um sistema de informação passa a ser cada vez mais estratégico aos negócios. Se a companhia detecta esses erros, ela precisa eliminá-los e prevenir-se para que eles não ocorram futuramente, obtendo indicadores de qualidade e performance na produção do software.

No setor de tecnologia, nem sempre se pode garantir que todos os programas funcionem corretamente, sem a constatação de erros humanos. Muitas vezes, o grande número de fórmulas, atividades, algoritmos complexos, o tamanho do projeto a ser desenvolvido e a quantidade de pessoas envolvidas no processo aumentam ainda mais a probabilidade de falha. O prejuízo gerado pelo retrabalho faz com que as empresas percam, por ano, US$ 1,5 bilhões. De acordo com pesquisas realizadas na área, foi mostrado que 81% dos orçamentos de empreendimentos de Tecnologia da Informação (TI) são gastos em manutenção, deixando somente 19% para novas funcionalidades.

Realizar todos os tipos de testes pertinentes, antes de comercializar software ou solução no mercado, deveria ser regra.

*Rafael Krug Marques, Diretor da Zero-Defect Test House.

Fonte: TI Inside Online

Postado por Abel Avram, traduzido por Victor Franzonatto em 11 Ago 2009 03:15 PM

Rick Strahl criou CodePaste.NET, um site que permite compartilhar .NET Code Snippets (trechos/fragmentos de código .Net) entre usuários de redes sociais e IM.

É difícil inserir código em páginas de redes sociais e janelas IM porque o código de formatação normalmente se perde, ou o número de caracteres é limitado, entre outras razões similares. CodePaste.NET permite qualquer um colar Code Snippets em uma caixa de texto e, em seguida, clicar em um botão Colar. O trecho (snippet) recebe uma URL que pode ser copiada a partir da barra de endereços do navegador e distribuída. Qualquer pessoa pode visualizar o snippet, e os usuários cadastrados podem comentar e editá-lo. Desta forma, trechos de código podem ser enviados até mesmo ao longo do Twitter.

O site oferece sintaxe highlighting para as seguintes linguagens: C#, VB.NET, JavaScript, HTML, ASP.NET, JavaScript, XML, CSS, SQL, T-SQL, e FoxPro. Numeração da linha de código pode ser habilitada, e o código pode ser copiado para a área de transferência com um clique.

Os snippets podem ser recuperados como JSON, XML usando “?format=json” (ou xml) após a URL, ex: http://codepaste.net/pouviy?format=xml. Também possui suporte a RSS e ATOM para fornecer listas.

Todo o código fonte do site está disponível para revisão.

Pastie, um site semelhante, oferece o mesmo serviço mas de uma escolha muito maior de línguagens, incluindo Java, Ruby, C + +, Python, Perl, PHP, Pascal, YAML, entre outros.

Fonte: InfoQ

Postado por Boris Lublinsky, traduzido por Samuel Carrijo em 07 Ago 2009 03:43 PM

Arnon Rotem-Gal-Oz inicia seu post  "CRUD é ruim para o REST", afirmando:

Analisando superficialmente, parece que os dois combinam (tanto tecnicamente quanto arquiteturalmente), porém se aprofundarmos a análise um pouquinho, veremos que isso não é verdade em nenhum dos dois aspectos.

Hoje, a implementação mais comum do estilo arquitetural REST é baseado no protocolo HTTP e, consequentemente, nos verbos do HTTP: POST, GET, PUT e DELETE. É comum desenvolvedores implementarem esses verbos mapeando-os em termos CRUD – Create, Read, Update e Delete (Criar, Ler, Atualizar e Excluir). Um mapeamento típico é de 1 para 1:

• o verbo GET normalmente é mapeado para o CRUD Read (Leitura), embora o GET forneça algumas funcionalidades a mais do que um mapeamento SELECT padrão.
• o verbo DELETE normalmente é mapeado para o CRUD Delete (Excluir).
• o verbo PUT normalmente é mapeado para CRUD Update (Atualizar), mas com algumas ressalvas:
  • O PUT requer um recurso substituto completo, enquanto no Update o recurso pode ser parcial.
  • O PUT pode ser usado para criar um recurso (quando a URI é definida pelo cliente)
• o verbo POST é normalmente mapeado para o CRUD Create (Criar) mas ele só dá suporte à criação de um recurso filho. O POST também pode ser usado para realizar atualização parcial de um recurso.

Na opinião de Arnon:

Os verbos HTTP são mais orientadas a documentos do que orientandos a bancos de dados – enquanto você pode atualizar, excluir e criar novos recursos, isso não é exatamente CRUD no "sentido banco de dados" da palavra – pelo menos quando se trata de utilizar verbos HTTP.

Mas o maior motivo pelo qual o CRUD não é um paradigma adequado para REST é arquitetural. O coração de REST é a implementação da máquina de estados do protocolo utilizando hipermídia. Arnon cita Tim Ewald:

… E eis o que passei a entender. Todo protocolo de comunicação tem uma máquina de estados. Em alguns protocolos ela é muito simples, em outros ela é mais complexa. Quando você implementa um protocolo via RPC, você cria métodos que modificam o estado da comunicação. Esse estado é mantido como uma caixa preta na outra extremidade. Devido ao estado do protocolo estar escondido, é mais fácil entender as coisas do jeito errado. Por exemplo, você pode chamar o Process antes de chamar o Init. As pessoas têm procurado formas de evitar estes problemas por um longo período de tempo através de anotações de informações sobre o tipo da interface, mas eu não conheço nenhuma solução largamente adotada. O fato de o estado do protocolo estar encapsulado por trás das chamadas a métodos que modificam esse estado de maneiras não-óbvias, o versionamento passa a ser algo interessante.

A essência do REST é tornar os estados do protocolo explícitos e endereçáveis através de URIs. O estado atual da máquina de estados do protocolo é representada pela URI chamada e da representação do estado que você obteve. Você pode alterar o estado fazendo uma chamada à URI do estado desejado. A representação de um estado inclui as ligações com os outros estados para os quais pode mover a partir do estado atual. É exatamente assim que aplicativos baseados em navegador funcionam, e não há nenhuma razão para que o protocolo do seu aplicativo não pode trabalhar dessa mesma maneira. (O protocolo de publicação ATOM é o exemplo canônico, embora seja fácil pensar que a essência dele são as entidades, e não uma máquina de estados.)

Seguido do artigo de John Evdemon, explicando por que serviços do tipo CRUD são um anti-padrão SOA, Arnon explica as desvantagens do CRUD REST:

• Ele contorna toda a ideia de "Serviços" – não há lógica de negócios.
• Ele expõe a estrutura interna dos dados ou do banco de dados ao invés de um contrato bem elaborado.
• Favorece a ideia de ignorar os serviços de verdade e partir direto para os seus dados.
• Ele cria uma serviço (a fonte de dados) que é uma bolha.
• Favorece a criação de "semi-serviços" (as várias "interfaces" dessa bolha) que ignoram alguns aspectos de computação distribuída.
• É a arquitetura cliente-servidor em pele de cordeiro.

Arnon termina o seu post reenfatizando que apenas a adoção de padrões como HTTP, XML, JSON (embora possa ser útil) não constitui REST – é necessário adotar a arquitetura REST.

Esse post é um importante lembrete de que REST, assim como SOA, não é um conjunto de padrões e APIs populares, mas sim um paradigma arquitetural, que deve ser compreendido e seguido.

Fonte: InfoQ

Postado por Vikas Hazrati, traduzido por Fernanda Stringassi de Oliveira em 07 Ago 2009 12:01 PM

Os Backlogs estão sob críticas constantes há algum tempo. Mary Poppendieck sugeriu que o produto backlog seja eliminado se não está satisfazendo o objetivo desejado. Semelhantemente,  Jeff Patton sugeriu que backlogs enxutos falham em transmitir uma visão de alto nível do sistema. Ele sugeriu o uso de um mapa de histórias como alternativa . Além disso, para dar mais sentido para o backlog, Serge Beaumont sugeriu um interessante modo de particionar o backlog o qual mapeia para um fluxo e faz com que o backlog tenha sua existência respeitada.

De acordo com o Serge,o fluxo do “estar preparado” envolve o trabalho do product owner para selecionar NOVAS histórias, deixá-las no estado de PREPARADAS, e então a equipe poderá começar a trabalhar nelas e processá-las até o estado de PRONTAS.

Serge sugeriu particionar o backlog nas 4 áreas abaixo para manter o fluxo consistente.

1. itens que estão no Sprint atual,
2. itens que estão Preparados, ,
3. itens que você está preparando, e
4. o restante: novas coisas.

“Novas" e "Preparadas" são buffers priorizados, "Preparando" e "No Sprint" são Trabalho-Em-Progresso.

• Buffer priorizado: Novo – O product owner ainda não começou a trabalhar nestes itens. Este é um excelente momento para praticar uma triagem e se livrar daqueles itens que parecem adicionar pouco valor. Esta lista precisa ser priorizada com base na experiência de negócio, avaliação dos benefícios, urgência de negócio, etc.
• Trabalho-Em-Progresso: Preparando – Esta é a lista principal onde o PO gasta grande parte do tempo tentando deixar o item no estado PREPARADO. De acordo com Serge, este é o momento onde o PO precisa puxar as coisas com base em sua capacidade. Esta partição também refletiria a velocidade do product owner. O PO precisa perguntar questões e solicitar respostas para cada item do backlog para então refiná-lo e deixá-lo no estado PREPARADO.
• Buffer priorizado: Preparado – O buffer PREPARADO precisa ter uma lista priorizada com 1.5 – 2 iterações de conteúdo de trabalho para que a equipe possa pegar itens adicionais para a iteração se eles terminarem mais cedo. Serge mencionou que ter mais do que 2 iterações de conteúdo de trabalho no buffer de PREPARADO constituiria desperdício.
• Trabalho-Em-Progresso: No Sprint – Estes são os itens do backlog que estão sendo implementados no sprint atual.

Portanto, a quebra do backlog em 4 áreas o alinha bem com o fluxo de transformar o item do estado NOVO em PREPARADO e PREPARADO em PRONTO. Isto também ajudaria na redução de acúmulo em qualquer uma das partições e cada partição seria capaz de obter itens baseando-se na capacidade da equipe e do product owner.

Fonte: InfoQ