Hospedagem Profissional

Hospedagem Profissional
Clique aqui e ganhe US$ 10,00 para testar durante 1 mês a melhor hospedagem: Digital Ocean!

domingo, 19 de agosto de 2012

Lançada versão Release Candidate do PrimeFaces 3.4

Foi lançada recentemente a versão Release Candidate do PrimeFaces 3.4, com vários componentes inovadores como Mindmap por exemplo, que permite a criação de mapas mentais dinamicamente.

Realmente o PrimeFaces vem se dispontando entre as implementações da especificação JSF, e vale a pena dar uma conferida.

Outra iniciativa que achei bem legal foi o trailler que fizeram dessa nova versão, confiram:


PrimeFaces 3.4 Trailer from cagataycivici on Vimeo.

Mais informações:

Site PrimeFaces - http://www.primefaces.org
RoadMap - http://code.google.com/p/primefaces/wiki/Roadmap


Obs. E dá-le Bootstrap no novo site do PrimeFaces!

sexta-feira, 10 de agosto de 2012

RichFaces Bootstrap

Ótima notícia: Uma nova versão do RichFaces está no forno, e vai utilizar o Twitter BootStrap como biblioteca de componentes.

O projeto já está bem avançado conforme o engenheiro da JBoss Brian Leathem divulgou em seu blog:

I’m happy to share the news that the RichFaces community has started an effort to wrap Twitter Bootstrap with the RichFaces CDK. If you haven’t yet heard, Twitter’s Bootstrap project is a set of HTML/CSS/js “widgets” that you can use for building a website/web application with an emphasis on a fluid layouts that adapt well to mobile devices. The RichFaces community effort centres around providing a set of first-class JSF components built using these Bootstrap widgets via the RichFaces CDK.
O legal disso tudo é que tanto o Twitter BootStrap quando o RichFaces BootStrap estão disponíveis no GitHub.

Alguns exemplos:

b:buttonDropdown

The buttonDropdown can be used to provide alternate actions for a button on your page:

b:gridContainer

The bootstrap grid components (gridContainer/gridRow/gridColumn) provide a powerful means to layout your page. Being proper JSF components, they are also valid JSF execute/render targets.


Mais informações:

- Site Twitter BootStrap http://twitter.github.com/bootstrap
- Código Fonte https://github.com/twitter/bootstrap

- Site RichFaces BootStrap http://bootstrap-richfaces.rhcloud.com
- Código Fonte https://github.com/richfaces/sandbox

- Blog Brian Leathem http://www.bleathem.ca

quinta-feira, 9 de agosto de 2012

Tutorial simples parte 2: git branch e merge

Esse tutorial faz parte de uma série de 3 artigos que explicam a utilização do Git e foi escrito e publicado pelo Codexico no blog codexico.com.br o qual detém todos os méritos pelo conteúdo de extrema qualidade e utilidade.

A parte 1 (Como usar o git e o github) foi sobre instalar o git, ssh-key, criar um projeto no github e os commits básicos.

Em projetos super simples tudo bem, mas para qualquer coisa maiorzinha já é melhor usar branchs, é fácil também, nem tirei o simples do título do post.

Vou abordar os branchs de forma educacional, como se fosse um projeto de uma só pessoa. A parte 3 trará uma visão mais prática, com um fluxo de trabalho completo e voltado para equipes, graças ao git ainda será simples.

Será usado o mesmo repositório da parte 1.

Branch

Para criar um branch no diretório do projeto:

1

$ git branch parte2

Atenção, somente foi criado o branch, o git não mudou para ele, qualquer alteração ou commit será feito no master. O git mostra onde está:

1
2
3

$ git branch
* master
  parte2

Para mudar para o branch é necessário um checkout:

1
2

$ git checkout parte2
Switched to branch 'parte2'

Os dois passos podem ser substituídos por um só (mas é sempre bom saber de onde veio):

1

git checkout -b parte2

Agora sim as modificações serão feitas no branch correto. Que tal criar um diretório, uns arquivos e também alterar o README da parte 1?

1
2
3
4
5
6

mkdir parte2
touch parte2/testeparte2
git add .
git commit -m "arquivo para testes da parte2"
vim README
git commit -a -m "README parte2"

Foram criados dois commits, ambos no branch parte2, um push agora não irá alterar nada no repositório.

Merge

Para enviar as modificações é necessário primeiro um checkout para voltar ao master, depois o merge com o branch e então o push.

Dica: TAB autocompleta os comandos e também os nomes dos branchs.

1
2
3

git checkout master
git merge parte2
git push origin master

Foi enviado o código mas o github não percebeu que havia um branch pois o branch está somente na máquina local, para enviar o branch ao repositório o push muda um pouco:

1

git push origin parte2:parte2

O formato é o seguinte git push repositorioRemoto nomeLocalDoBranch:nomeRemotoDoBranch, assim dá para enviar com um nome diferente se quiser.

1
2
3
4

git checkout parte2
vim parte2/testeparte2
git commit -a -m "texto teste"
git push origin parte2:parte2

Agora sim dá para ver que existe um branch, olha lá https://github.com/codexico/tutorial-github/network

Quando não for mais usá-lo, o branch pode ser deletado com:

1

git branch -d nome-do-branch

Legal, já deu pra perceber que dá por exemplo para trabalhar em uma nova funcionalidade do projeto sem alterar o código principal. Quando tudo estiver pronto, os testes passaram e tal, pode ser feito o merge e só então enviar para o repositório.

Pronto, acabou o básico sobre branch e merge com git.

Branch e Merge exemplo 2

Até agora foi muito básico, normalmente enquanto se está trabalhando num branch aparece um bug para ser arrumado no master, ou outro branch também está sendo trabalhado, ou seu sistema de desenvolvimento é dividido em produção, desenvolvimento, homologação e outros, são muitas possibilidades, cada lugar trabalha de uma maneira. Na parte 3 terá mais sobre isso.

Agora um exemplo um pouquinho mais trabalhado:

1
2
3
4
5
6
7

git checkout -b funcionalidadeX
touch funcionalidadeX
git add .
git commit -m "funcionalidadeX iniciada"
vim funcionalidadeX
git add .
git commit -m "funcionalidadeX parcialmente executada"

Foi iniciado um branch para a funcionalidadeX e depois de alguns commits ela ainda não está finalizada.

Então apareceu um bug no master que precisa ser corrigido rapidamente (colocar o link da parte2 antes do texto da parte2 do README, urgente né, o usuário é fogo).

1
2
3
4
5
6

git checkout -b bug42
vim README
git commit -a -m "bug 42 corrigido"
git checkout master
git merge --no-ff bug42
git branch -d bug42

Foi criado um branch para o bug, o bug foi corrigido, voltou ao master, foi dado um merge para incluir as alterações no master e então o branch foi deletado. A opção –no-ff é utilizada para forçar a criação de um commit, sem ela o merge não cria commit e fica mais difícil recuperar o código anterior.

Agora é só completar a funcionalidade X.

1
2
3
4
5
6
7

git checkout funcionalidadeX
vim funcionalidadeX
git commit -a -m "funcionalidadeX finalizada"
vim README
git commit -a -m "README atualizado com a funcionalidadeX"
git checkout master
git merge --no-ff funcionalidadeX

Correu tudo bem? Pode ser que sim, o github vai fundir o código da funcionalidadeX com o master, que já contém a correção do bug. Mas e se a correção conflita com as alterações da funcionalidade X? Neste caso o git mostra um alerta e não permite o merge, mas mostra os conflitos:

1

git status

Os conflitos precisam ser corrigidos manualmente e então o merge será aceito. O git inclui marcações no código dos arquivos em conflito para ajudar na resolução do conflito.

Com um fluxo de trabalho melhorzinho dá para evitar muitos conflitos, logo mais na Parte 3 do tutorial…

No final os merges ficaram assim:
 

Para finalizar uma tag:

1
2

git tag -a v2.0 -m 'parte 2'
git push origin v2.0

Referências:

Pro Git – Basic Branching and Merging
github – Working with remotes
nvie.com – A successful Git branching model

Fonte: http://codexico.com.br/blog/linux/tutorial-simples-parte-2-git-branch-e-merge/

Tutorial simples: Como usar o git e o github

Esse tutorial faz parte de uma série de 3 artigos que explicam a utilização do Git e foi escrito e publicado pelo Codexico no blog codexico.com.br o qual detém todos os méritos pelo conteúdo de extrema qualidade e utilidade.

Ultimamente estou envolvido em vários projetos ao mesmo tempo com várias equipes diferentes, então controle de versão é essencial.

Segue um manualzinho básico para iniciar com o git, espero atualizar e complementar este passo-a-passo com mais exemplos logo.

O git serve para versionamento local, você pode compartilhar de algumas maneiras, a mais fácil é com serviços online. Neste exemplo vou usar o github, testei também o projectlocker, que dá repositórios private grátis,  mas não gostei. Outro que parece legal é o Codaset, ainda não testei.

1) Instalar git

1

$ sudo apt-get install git-core

É necessário gerar uma chave ssh e fazer um cadastro em algum repositório git. ( Esta etapa não é exatamente sobre o git, mas sobre a segurança dos repositórios. )

Confira se vc já tem alguma chave com um "ls ~/.ssh/", se já existir uma você pode utilizá-la ou gerar uma nova:

1

ssh-keygen -t rsa -C "comment"

"comment" é só um lembrete para saber do que se trata a chave, normalmente usa-se o seu nome de usuário do serviço que vai usar, por exemplo o github.

Falando nisso, está na hora de criar um usuário lá (http://github.com), vai lá que eu espero…

Depois de logado vá para https://github.com/account e clique em "SSH Public Keys" e "add another public key". A cópia da chave precisa ser exata(eu ia escrever que 'precisa ser precisa' mas é feio né), então pode-se fazer assim:

1
2

sudo apt-get install xclip
cat ~/.ssh/id_rsa.pub | xclip -sel clip

Aí é só colar com um Ctrl+V normal. Agora já dá para se comunicar com o github:

1

ssh git@github.com

Vai aparecer "ERROR: Hi codexico! You've successfully authenticated, but GitHub does not provide shell access", não se assuste com o ERROR, o que interessa é que o github te reconheceu. Qualquer duvida tem o help do github: Generating SSH keys (Linux).

Por padrão o git vai pegar o usuário do sistema, para que seu nome de usuário do github apareça corretamente use os comandos:

1
2

git config --global user.name "Your Name"
git config --global user.email codexico@gmail.com

2) Criar Projeto no github

1) Podemos criar um novo projeto ou usar um existente. Para criar um novo vá até o github e no alto da página clique em "Dashboard" e depois em "New Repository".

Crie um espaço para o projeto no comnputador:

1
2

$ mkdir nomedoprojeto
$ cd nomedodiretorio

2) Iniciar um git neste diretório:

1

$ git init

Saída do comando:

1

Initialized empty Git repository in /nomedodiretorio/.git/

Deve aparecer um diretorio oculto .git, neste .git ficam as configurações que serão usadas para este projeto.

Por exemplo:

1
2
3

$ ls .git
branches config description FETCH_HEAD HEAD hooks index info logs
objects refs

3) Adicionar o repositório, neste exemplo vou usar um que criei para este tutorial, pode ser também o repositório criado no passo 1, o endereço fica na página do projeto (neste caso https://github.com/codexico/tutorial-github):

1

$ git remote add origin git@github.com:codexico/tutorial-github.git

Formato do comando:

"git remote add" adiciona um repositório ao git que foi iniciado neste diretório, "origin" é o apelido para o projeto, "git@github.com:codexico/tutorial-github.git" é o endereço do projeto.

Resultado:(apareceu a parte [remote "origin"])

1
2
3
4
5
6
7
8
9

$ cat .git/config
[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
[remote "origin"]
url = git@github.com:codexico/tutorial-github.git
fetch = +refs/heads/*:refs/remotes/origin/*

4) Baixar(pull=puxar) o projeto:

1

$ git pull origin master

Formato do comando:

1

git pull apelidoDaOrigem apelidoParaDestino

Saída do comando:

1
2
3
4
5
6
7

remote: Counting objects: 52278, done.
remote: Compressing objects: 100% (10917/10917), done.
remote: Total 52278 (delta 40975), reused 51715 (delta 40669)
Receiving objects: 100% (52278/52278), 8.33 MiB | 189 KiB/s, done.
Resolving deltas: 100% (40975/40975), done.
From git@github.com:codexico/tutorial-github.git
* branch  master -> FETCH_HEAD

3) Usar o git

Exemplo (escolha um nome diferente para o arquivo teste):

1

$ touch testegit

1) Adicionar as alterações:

- Podemos adicionar somente uma alteração:

1

$ git add testegit

- Ou adicionar todas as alterações:

1

$ git add .

Neste passo as alterações ainda não estão sob o controle de versão, elas somente foram adicionadas para quando der um commit.

2) Comitar as alterações:

1

$ git commit -m "mensagem teste para o tutorial"

É obrigatório acrescentar uma mensagem.

Saída do comando:

1
2
3

[master de2f5ce] teste para o tutorial
    1 files changed, 1 insertions(+), 0 deletions(-)
    create mode 100644 testegit

Agora as alterações foram adicionadas ao controle de versão. Mas ainda estão somente na máquina local.

3) Enviar(push=empurrar) as alterações:

1

$ git push origin master

Saída do comando:

1
2
3
4
5
6
7

Counting objects: 4, done.
    Delta compression using up to 2 threads.
    Compressing objects: 100% (2/2), done.
    Writing objects: 100% (3/3), 288 bytes, done.
    Total 3 (delta 1), reused 0 (delta 0)
    To git@github.com:codexico/tutorial-github.git
    3be4c21..de2f5ce  master -> master

Se durante o tempo em que fez o pull e o push outra pessoa que também participe do projeto fez alterações o push será rejeitado. Então é necessário atualizar o projeto local antes de enviar novas alterações.

1

$ git fetch origin

Atualizar antes de enviar é uma boa prática a ser seguida para quem usa svn ou cvs e é obrigatória no git.

4)Pronto, confira as alterações no navegador acessando o endereço do projeto (http://github.com/codexico/tutorial-github neste exemplo).

Dica final: para que não precise digitar sempre a senha do ssh siga os passos desse link: http://help.github.com/working-with-key-passphrases/

Atualizado em 09/09/2010, mudei o repositório e adicionei instruções para gerar a chave ssh.

Fonte: http://codexico.com.br/blog/linux/tutorial-simples-como-usar-o-git-e-o-github/

terça-feira, 7 de agosto de 2012

10 ações para ter sucesso na adoção do Agile

Matéria interessante sobre o processo de adoção do Agile escrito por Allan Kelly no blog Target Trust

Ken Schwaber teria dito que apenas 30% das equipes que utilizam Scrum são bem sucedidas. Ken, em seu blog, afirma não se lembrar dessa afirmação; ele indica que apenas 30% se tornarão “excelentes equipes de desenvolvimento”.

Scrum em Porto Alegre

A afirmação de Schwaber está alinhada com vários estudos sobre a gerência de mudanças. Especialistas no assunto, tais como o professor de Harvard, John Kotter, afirmam que 70% dos grandes esforços de mudança organizacional irão falhar. Independentemente da perspectiva pela qual se olha para os estudos, o prognóstico não é positivo. Então, o que podemos fazer para garantir que estaremos entre os 30% que obtêm sucesso?

Aqui listo dez sugestões. A lista poderia ter um maior número de itens, mas esses dez me pareceram mais significativos que quaisquer outros. Já retirar algum reduziria muito a efetividade da lista. Aqui vai!

1) Utilize um quadro físico

Estou convencido de que a maior diferença entre as equipes que adotam o Agile com sucesso e as que falham (ou que ficam “travadas”) está na utilização de um quadro físico. Apesar de algumas equipes estarem distribuídas geograficamente e de existir tecnologia razoável para substituir o quadro físico por um virtual, mantenho a recomendação. Se for possível afixar um quadro em algum lugar onde muitos, senão todos, possam vê-lo, as chances de sucesso serão bem maiores.

É difícil explicar todas as razões para utilizar um quadro físico; é preciso experimentar e testemunhar seus efeitos. Parece ocorrer alguma espécie de mágica quando o mundo abstrato do software entra em contato com o mundo físico dos cartões e do quadro.

Visualizar o trabalho é apenas o começo: é importante aprender a interpretar o que o quadro está dizendo e a agir de acordo com isso.

2) Comece a coletar e usar métricas e estatísticas

Métricas, como velocidade, burn-down, defeitos identificados, defeitos registrados em log etc. não têm boa fama no desenvolvimento de software – por razões justas, em muitos casos. Mas não significa que não sejam úteis; apenas que têm sido vítimas de má escolhas ou de coletas mal feitas.

No mínimo, meça a velocidade da equipe e crie o gráfico de burn-down, ou um diagrama de fluxo cumulativo de trabalho (cumulative flow).

A beleza de trabalhar com Agile é que é bem fácil levantar algumas métricas simples. Quando as métricas se tornam complicadas, as pessoas não as entendem e é mais difícil aprender com elas. Da mesma forma que acontece com os quadros para visualização do trabalho, as métricas têm utilidade intrínseca, mas são muito mais úteis como ferramenta de aprendizado.

3) Envolva um coach/consultor

É possível adotar o Agile sem ajuda de terceiros; livros podem ser lidos, experimentações feitas e cursos realizados. Mas a falta de ajuda faz todo o processo ser mais lento e corre-se mais risco de ficar fora dos 30% de sucesso. Além disso, a adoção levará mais tempo, o que aumenta ainda mais o risco.

Não há grandes distinções, na minha opinião, entre um coach e um consultor ágil. Assim, independentemente de qual papel se escolha, o que se quer é alguém que seja capaz de:

  • Observar, examinar, interrogar e desafiar os conceitos sobre o que está sendo feito;
  • Oferecer ajuda em quais práticas e processos adotar e sobre a melhor forma de adotá-los;
  • Oferecer exemplos do que viram funcionar ou não em outros lugares, e como outras equipes atacaram problemas similares.

Pode ser necessário trabalhar com mais de um consultor/coach, pois poucos serão capazes de conhecer todos os processos, práticas, tecnologias, produtos e estratégias. Uma opção é ter um consultor/coach com dedicação integral, mas o modelo com o qual obtive mais sucesso foi o de ter o aconselhamento leve, juntamente com um sistema de mudanças “puxadas” (veja mais abaixo).

Apesar de não haver necessidade de um consultor/coach dedicado, deve haver um acompanhamento contínuo. Tenho praticado e escrito sobre o coaching ágil leve; seguindo este modelo procuro voltar às empresas em intervalos de aproximadamente um mês, para continuar o acompanhamento.

4) Ações no lugar de palavras

Ações valem bem mais que palavras. Não se pode prever os problemas e questões que vão emergir até que se comece a utilizar o Agile de fato. Falar sem agir gera mais expectativas, aumentando cada vez mais o risco de que o Agile pareça apenas outra moda passageira de gestão.

Fale sobre o Agile, planeje-se, mas não deixe de mergulhar na ação, pois não há substituto para isso. Aprenda com suas ações e melhore; refine. Utilize algumas métricas que possam indicar o que está acontecendo.

Em especial, não gaste muito tempo decidindo se é melhor utilizar XP, Scrum, Lean, FDD, DSDM ou Kanban. Todos são similares, e no final você acabará montando sua própria versão híbrida, de uma forma ou de outra.

5) Treine a todos e realize discussões envolvendo todo o grupo

As equipes não se tornam ágeis por decreto da gestão, apesar de ter havido várias tentativas nesse sentido. A leitura de livros funciona para alguns, mas a maioria dos livros permanece não lida ou simplesmente não é absorvida.

Explique para as pessoas o que é o Agile – ou pelo menos o que significa para a organização. É quase impossível achar alguém da área técnica que não tenha ouvido falar de Agile; mas o que cada um sabe, as partes que se lembram, são diferentes. É importante que todos partam de um entendimento comum.

Porém não pare por aí; abra tempo para discutir o que é o Agile para cada um, o que gostam e o que não gostam de fazer. O Agile é um esporte coletivo; sem um entendimento comum, cada um estará jogando um jogo diferente. Essas discussões devem começar nas sessões de treinamento, ao mesmo tempo em que a equipe chega a um entendimento compartilhado das técnicas ágeis.

6) Anime mas não force

Quem já trabalhou em empresas por alguns anos já viu mudanças organizacionais serem forçadas para todos: BPR, ISO 9000, Seis Sigma, CRM etc. Um dia alguém tem uma ideia e então o rolo compressor de mudanças é ligado, passando por cima de todos.

Vivemos em um mundo pós-moderno, pós-BRP, pós-demissões, pós-recessão, pós-tudo. Os funcionários não são crianças e já sabem tudo o que está acontecendo. Além disso, é comum haver redundâncias antes do início do movimento de mudanças, especialmente quando consultores estão envolvidos. Se houver necessidade de cortar pessoal, faça-o antes de mudar para o Agile.

Aplique um princípio Lean: puxe, não empurre. Quando se fala em “gerência de mudanças”, entra-se no mundo das mudanças “empurradas”; então proíba o uso dessas palavras.

Caso você esteja na gerência e queira introduzir o Agile, crie um movimento que gere entusiasmo com mudanças de baixo para cima, e forneça apoio de cima para baixo. Tentar uma adoção do Agile com uma abordagem unicamente de cima para baixo quase certamente resultará em fracasso – os funcionários são sempre céticos em relação a mudanças forçadas.

Procure entusiasmar indivíduos e equipes, faça-os pedir o uso do Agile. No lugar de impor mudanças, os gestores devem estimular a curiosidade das pessoas, fazer com que levantem dúvidas e peçam ajuda.

Faça tudo para que a “chama se acenda” e não deixe que se apague. Quando for pedido, ajude e forneça suporte a todas as necessidades. Permita gastos, abra espaço no orçamento para palestrantes, treinadores ou coaches. Apoie a ida a conferências; seja generoso. E envolva-se; também é preciso aprender – mesmo que se saiba que tudo o que o necessário é estar lá para quando o entendimento comum estiver construído. Aprenda a mudar também e a adequar seus próprios comportamentos de acordo com as necessidades.

7) Seja claro nas razões para adotar o Agile

Independentemente da posição que se ocupa – seja ela de engenheiro, analista de testes, gerente de projetos, diretor – entenda qual o problema que se quer resolver com o Agile. Entenda porque é importante mudar e o que esperar como resultado da mudança.

Não adote o Agile porque está na moda, mas sim para obter resultados reais. Procure entender o que as pessoas querem do Agile e o que isso pode melhorar na vida delas; entenda ainda o que a organização quer do Agile. Inovação? Cronogramas confiáveis? Menos defeitos?

É importante também compreender como cada membro da equipe enxerga os benefícios de se adotar o Agile. Se todos veem os benefícios, então (claro) haverá apoio na adoção; caso contrário, as mudanças serão difíceis. À medida que o Agile é adotado, utilize o que se esperava como resultados para escolher as ferramentas, otimizar seus processos e medir seu sucesso.

8) Adote tanto os aspectos técnicos quanto os de processo

A mudança do processo sozinha não é capaz de fazer tudo funcionar bem. Deve-se dar atenção aos aspectos técnicos também; melhorar a qualidade, dar apoio aos engenheiros, analistas de testes e outros que estejam realizando o trabalho.

Algumas empresas veem com desdém o lado técnico: a atitude parece ser de “isso é técnico demais” ou “eles que sujem as mãos”, ou ainda, “podemos mudar para um país com custos mais baixos”.

Caso essa seja sua visão, será difícil obter sucesso. Suje as mãos, fale com os engenheiros, adote o desenvolvimento orientado a testes (TDD), a refatoração; evite planejar a arquitetura toda de uma vez antes do desenvolvimento; aprenda a conviver com decisões difíceis de projeto e de evolução da arquitetura. Há ciclos de feedback positivo importantes nessas práticas.

9) Torne o fluxo de requisitos claro e limpo

Não basta melhorar apenas a parte da programação; a parte dos requisitos deve ser tratada também. Deve haver uma comunicação clara entre quem representa os requisitos (Product Owners, Gerentes de Produto etc.) e a equipe de desenvolvimento. Haverá muito mais negociações sobre o que fazer do que sobre quando fazer. Alguém precisa representar a equipe e se responsabilizar por essa parte do trabalho.

É comum que empresas tenham pouco pessoal para desempenhar este papel. O Agile torna esta escassez ainda mais grave, pois o gargalo nos requisitos terá efeito sobre o desenvolvimento.

Faça um exercício mental; pense no que aconteceria se o Agile duplicasse a produtividade dos desenvolvedores. Seria necessário o dobro do esforço no lado de requisitos. A princípio, pode-se apenas vencer um grande backlog, mas conforme se faz isso, o valor do que é entregue provavelmente entrará na descendente.

10) Mudanças estruturais e grupos funcionais

Monte suas equipes com as pessoas necessárias para fazer o trabalho sobre o qual são responsáveis; acabe com grupos funcionais (por exemplo, desenvolvedores de banco de dados e desenvolvedores de interfaces de usuário em equipes separadas). Esta é apenas a primeira de muitas mudanças organizacionais necessárias. Mas se esta falhar, será praticamente fim de jogo.

Equipes irão parar, ficar travadas, se precisarem pedir ajuda de outros grupos para ter acesso a habilidades especializadas ou obter permissões. Outros grupos têm outras prioridades, e pequenos impedimentos se acumulam, cada um tirando um pouco de velocidade da equipe, minando sua moral e tornando a adoção do Agile mais difícil.

Texto por Allan Kelly
Fonte: http://www.targettrust.com.br/blog