Mapeamento do Scrum para o nível G do MPS.BR

O nível de exigência por parte dos clientes no que diz respeito à qualidade e complexidade dos produtos aumenta a cada dia (MOREIRA, 2009). E para acompanhar a exigência do mercado, as empresas têm buscado cada vez mais a maturidade nos seus processos de software para atingir padronizações de qualidade e produtividade nacionais e internacionais, que são essenciais para a sobrevivência no mercado de TI (Tecnologia da Informação).

Por outro lado a evolução dos processos de desenvolvimento de software impactou na exigência do mercado, cada vez mais querem softwares melhores e mais baratos, prazos mais curtos e orçamentos mais reduzidos, requerendo equipes menores e mais produtivas. As empresas cada vez mais estão investindo em processos que permitam ganhar produtividade e qualidade, pois nosso dia a dia está cada vez mais dependente de softwares que funcionem de forma segura e precisa (BARTIE, 2006).


Neste contexto, esse artigo propõem mapear as práticas do Scrum aos resultados esperados do nível G do MPS.BR (Melhoria de Processo do Software Brasileiro) para que as empresas tenham a possibilidade de definirem processos que produzam software com alto padrão de qualidade e sejam certificados e reconhecidos nacionalmente, tendo ainda, uma produção de software ágil e eficiente.


Para cada resultado esperados dos processos exigidos pelo nível de maturidade G serão diagnosticados como:

- Satisfeita: quando em Scrum possuir práticas explícitas que sirva como evidência na avaliação do MPS.BR e que cubra completamente o resultado esperado em questão.

- Parcialmente satisfeita: quando em Scrum possuir práticas explícitas que sirva como evidência na avaliação do MPS.BR e que cubra pelo menos parte do que o resultado esperado define.

- Não satisfeita: quando em Scrum não houver nenhuma prática explícita que seja evidência na avaliação do MPS.BR.




Processo: Gerencia de Projetos – GPR
- GPR 1. O escopo do trabalho para o projeto é definido.

- Análise: Em Scrum, o Product Backlog e o documento de visão, criados durante a fase de planejamento, provêem a definição do escopo do projeto. Com esse escopo inicial, é possível estimar a quantidade de iterações e o tempo de desenvolvimento necessário para o desenvolvimento do produto.

- Diagnóstico: Satisfeita.

- GPR 2. As tarefas e os produtos de trabalho do projeto são dimensionados utilizando métodos apropriados.

- Análise: As tarefas e produtos de trabalho são estimados em cada Sprint. As estimativas são feitas utilizando métodos que envolve toda a equipe desde do Scrum Master até o desenvolvedor, e cada Sprint a equipe se torna mais apta a estimar corretamente. Portanto, os métodos para estimar as tarefas e produtos são apropriados.

- Diagnóstico: Satisfeita.

- GPR 3. O modelo e as fases do ciclo de vida do projeto são definidas.

- Análise: Em Scrum, o projeto tem um ciclo de vida iterativo/incremental e que pode ser definido em quatro fases: Planejamento, Preparação e escalonamento, Desenvolvimento e Entrega.

- Diagnóstico: Satisfeita.

- GPR 4. O esforço e o custo para a execução das tarefas e dos produtos de trabalho são estimados com base em dados históricos ou referências técnicas.

- Análise: Em Scrum as tarefas e produtos de trabalho são estimados a cada sprint. Estas estimativas são baseados em dados históricos, isto é, na experiência que a equipe teve em outros projetos e no projeto em questão a medida que avança o seu desenvolvimento. Contudo, Scrum não define que as estimativas devem ser documentadas.

- Diagnóstico: Parcialmente satisfeita.

- GPR 5. O orçamento e o cronograma do projeto, incluindo marcos e/ou pontos de controle, são estabelecidos e mantidos.

- Análise: Com as estimativas de esforço do Product Backlog e uma idéia da produtividade da equipe, estabelece-se um primeiro cronograma do projeto através da divisão em Sprints de trinta dias. esse cronograma é automaticamente atualizado à medida que o projeto se desenvolve e as funcionalidades são re-priorizadas. O orçamento do projeto, no entanto, não está contemplado nas atividades do Scrum e nem sempre pode ser calculado diretamente do cronograma. Os marcos são feitos ao final de cada Sprint, o progresso do projeto e o cumprimento dos compromissos é revisado na reunião de Sprint Review.

- Diagnóstico: Parcialmente satisfeita.

- GPR 6. Os riscos do projeto são identificados e o seu impacto, probabilidade de ocorrência e prioridade de tratamento são determinados e documentados.

- Análise: No Scrum não há identificação e monitoramento explícito e sistemático dos riscos do projeto, com seu respectivo impacto e probabilidade de ocorrência, como sugere o nível G do MPS.BR. No entanto, riscos são possíveis impedimentos, e, portanto, podem ser levantados durante a Daily Meeting, e anotados na Impediments List, gerando um levantamento iterativo dos riscos.


- Diagnóstico: Parcialmente satisfeita.

- GPR 7. Os recursos humanos para o projeto são planejados considerando o perfil e o conhecimento necessários para executá-lo.

- Análise: No começo do projeto é realizada a alocação do time e da infra-estrutura necessária para todo o desenvolvimento. O Scrum Master e o Product Owner são responsáveis por garantir os recursos e a continuação do projeto, através das reuniões ao início de cada iteração e da remoção de impedimentos levantados pelo time. O time, que é um grupo multifuncional e auto-gerenciado, deve, na medida do possível, ser criado contendo os conhecimentos e as habilidades (técnicas e de negócio) necessárias para desenvolver o Product Backlog.

- Diagnóstico: Satisfeita.

- GPR 8. As tarefas, os recursos e o ambiente de trabalho necessários para executar o projeto são planejados.

- Análise: As tarefas, os recursos e o ambiente de trabalho são planejados na elaboração do Product Backlog e no documento de Visão que são previstos no Scrum.

- Diagnóstico: Satisfeita.

- GPR 9. Os dados relevantes do projeto são identificados e planejados quanto à forma de coleta, armazenamento e distribuição. Um mecanismo é estabelecido para acessá-los, incluindo, se pertinente, questões de privacidade e segurança.

- Análise: Em Scrum não há orientações para verificar se existe um plano para gerência de dados listando todos os documentos gerados no projeto, distribuição dos mesmos e mídia para armazenamento, proteção (segurança e sigilo) e recuperação desses dados.

- Diagnóstico: Não satisfeita.

- GPR 10. Planos para a execução do projeto são estabelecidos e reunidos no Plano do Projeto.

- Análise: Em Scrum, o documento de Visão e o Product Backlog representam o plano em alto-nível do projeto, com os requisitos funcionais e não-funcionais e o porquê do desenvolvimento do projeto. O Time, Scrum Master e Product Owner revisam os planos e compromissos no início e no final de cada Sprint, durante a reuniões de planejamento (Sprint Planning) e revisão (Sprint Review).

- Diagnóstico: Satisfeita.

- GPR 11. A viabilidade de atingir as metas do projeto, considerando as restrições e os recursos disponíveis, é avaliada. Se necessário, ajustes são realizados.

- Análise: Em Scrum, a viabilidade é definida pelo time em cada Sprint, já que nas reuniões de planejamento de cada Sprint (Planning Meeting) o time define quais das funcionalidades é viável para eles finalizar durante o período do Sprint. Os ajustes são feitos nas reuniões de retrospectiva (Retrospective Meeting) no qual se tem maior conhecimento do time da produtividade e da complexidade do projeto.

- Diagnóstico: Satisfeita.

- GPR 12. O Plano do Projeto é revisado com todos os interessados e o compromisso com ele é obtido.

- Análise: O compromisso com o plano é obtido continuamente no início de cada Sprint quando as atividades a serem desenvolvidas são negociadas com o Product Owner e o time.

- Diagnóstico: Satisfeita.

- GPR 13. O progresso do projeto é monitorado com relação ao estabelecido no Plano do Projeto e os resultados são documentados.

- Análise: Em Scrum, o Product Burndown e as reuniões diárias (Daily Meeting) provêem a visibilidade necessária para monitorar o andamento do projeto e conferir desvios no plano. O Sprint Burndown também contribui para isso, mostrando diariamente a velocidade do time e se as funcionalidades que vão ser entregues ao final do período.

- Diagnóstico: Satisfeita.

- GPR 14. O envolvimento das partes interessadas no projeto é gerenciado.

- Análise: Em Scrum o envolvimento dos interessados é garantido pelo Product Owner (que os representa na definição do escopo e das prioridades) e pelo Scrum Master (que deve garantir o cumprimento das regras do Scrum). Evidências indiretas desta participação, como atualizações no Product Backlog, mostram que os stakeholders estão envolvidos no projeto.

- Diagnóstico: Satisfeita.


- GPR 15. Revisões são realizadas em marcos do projeto e conforme estabelecido no planejamento.

- Análise: Ao final de cada Sprint, o progresso do projeto e o cumprimento dos compromissos é revisado na reunião de Sprint Review.

- Diagnóstico: Satisfeita.

- GPR 16. Registros de problemas identificados e o resultado da análise de questões pertinentes, incluindo dependências críticas, são estabelecidos e tratados com as partes interessadas

- Análise: Durante as reuniões diárias, o time reporta e analisa os problemas encontrados, registrando-os em um quadro branco, cartões de papel ou na Impediments Backlog. Além disso, é responsabilidade do Scrum Master identificar e resolver impedimentos o mais breve possível.

- Diagnóstico: Satisfeita.

- GPR 17. Ações para corrigir desvios em relação ao planejado e para prevenir a repetição dos problemas identificados são estabelecidas, implementadas e acompanhadas até a sua conclusão.

- Análise: O Scrum Master é responsável por resolver os impedimentos assim que eles são identificados. No entanto, não há registro ou evidências do planejamento e monitoramento dos impedimentos, impedindo um acompanhamento dessas ações de correção.

- Diagnóstico: Parcialmente satisfeita.

Observamos portanto, que 70,59% dos resultados esperados são satisfeitos nas práticas do Scrum, sendo que 17,65% são parcialmente satisfeitos e apenas 11,76% não são satisfeitos.



3.2. Processo: Gerência de Requisitos – GRE

- GRE 1. O entendimento dos requisitos é obtido junto aos fornecedores de requisitos.

- Análise: Considerando o envolvimento dos stakeholders, percebe-se que as práticas de Scrum contribuem para garantir e manter uma boa comunicação e colaboração entre o time e os fornecedores de requisitos. Portanto os requisitos são obtidos com a intensa participação dos fornecedores de requisitos.

- Diagnóstico: Satisfeita.

- GRE 2. Os requisitos de software são aprovados utilizando critérios objetivos.

- Análise: Em Scrum são aprovados os requisitos com os fornecedores de requisitos porem não utilizando critérios objetivos.

- Diagnóstico: Não satisfeita.

- GRE 3. A rastreabilidade bidirecional entre os requisitos e os produtos de trabalho é estabelecida e mantida.

- Análise: Em Scrum não há nenhuma prática que prevê isto.

- Diagnóstico: Não satisfeita.


- GRE 4. Revisões em planos e produtos de trabalho do projeto são realizadas visando identificar e corrigir inconsistências em relação aos requisitos.

- Análise: Em Scrum revisões freqüentes são realizadas a cada iteração (Sprint Review) e diariamente (Daily Meeting), inclusive com ajuda de gráficos (Product Burndown e Sprint Burndown).

- Diagnóstico: Satisfeita.

- GRE 5. Mudanças nos requisitos são gerenciadas ao longo do projeto.

- Análise: No Scrum sugere que os requisitos prioritários para fazer parte do Sprint não sejam alterados depois que o Sprint começou, porem se ver a necessidade de mudança o Sprint é interrompido e é feito uma nova reunião de Planning Meeting, a fim de modificar conforme a necessidade. Esta modificação é registra na nova versão do Product Backlog e do Sprint Backlog.

- Diagnóstico: Satisfeita.

Observamos portanto, que 60% dos resultados esperados são satisfeitos nas práticas do Scrum e apenas 40% não são satisfeitos.



Em conclusão tem-se portanto, que o Scrum atende em 68,18% os processos do nível G de MPS.BR. Portanto, nota-se que é possível obter certificação de qualidade do software utilizando-se as boas práticas de uma metodologia ágil, o Scrum, desde de que adapte as poucas práticas que o MPS.BR exige.

Read More

“Desnivelamento de Expectativas” – um grande vilão (Parte II)

No último post eu falei um pouco sobre o perigo de se ter expectativas desencontradas em qualquer tipo de relacionamento. Neste post, eu falarei um pouco sobre como isso pode ser potencialmente terrível(!) num projeto.

O que significa ter expectativas diferentes para um projeto? Basicamente significa esperar produtos ou resultados diferentes durante ou no final de um projeto - e isso é muito comum. Um dos motivos – você pode dizer – é que o cliente não sabe o que quer. De fato isso às vezes acontece, contudo na maioria das vezes, ele sabe o que quer, só não sabe como – é aí que mora o perigo. Então surge a pergunta, como conseguir realizar o que o cliente quer e da forma que ele quer? Um bom Levantamento de Requisitos é o passo inicial(e fundamental) para isso.

O Levantamento de Requisitos consiste numa etapa em que o Gerente de Projetos (ou um Analista de Requisitos) mapeia e documenta o que o cliente espera do resultado do projeto. Esse mapeamento, e naturalmente a documentação disto, é importante, por que esses dados serão a base para todo o planejamento do que será feito.

Muita informação? Então vamos voltar ao básico, e você verá que faz sentido. O PMBOK apresenta uma abordagem que destaca um projeto como tendo três fatores fundamentais e chama isto de “restrição tripla”. A “Restrição Tripla” é composta de Custo, Tempo e Escopo*. A arte do projeto (e o grande desafio do Gerente de Projetos) reside realizar o gerenciamento, e conseqüentemente, o equilíbrio deles.

Isso é vital, pois uma vez que eles são interdependentes, se mudar um dos três, os outros muito provavelmente serão afetados. Menor prazo pode significar mais recursos. Maior escopo pode significar um projeto com mais tempo e por aí vai.

Agora começamos a entender por que, mesmo com um tempo definido, e o custo definido, se não existir um ESCOPO definido tudo pode ir por água a baixo, não é verdade? Uma verdade simples, mas que nem sempre é notada.

Muitos projetos se encaixam no exemplo acima. Até porquê, para o cliente, os fatores tempo e custo, em geral, podem ser mais facilmente definidos. Então a arte de nivelar as expectativas está, também, no escopo bem definido, detalhado e ACORDADO.

Notaram o destaque no “acordado”? – Pois é, isso é fundamental. Dentro do contexto do Gerenciamento de Projetos o documento que guarda essas informações é chamado de “Declaração de Escopo”. A declaração de escopo é um artefato que guarda TUDO que será realizado no projeto, inclusive as premissas, restrições e entregáveis.

O Escopo é algo tão importante que o PMPBOK na versão de 2004 criou um processo, ainda na fase de iniciação(ou antes do planejamento), chamado de “Desenvolver a declaração do escopo preliminar do projeto”. E ele continua, “Este processo aborda e documenta os requisitos do projeto e da entrega, os requisitos do produto, os limites do projeto, os métodos de aceitação e o controle de alto nível do escopo. Em projetos com várias fases, este processo valida ou refina o escopo do projeto para cada fase.”

E na fase de Planejamento existem pelo menos dois processos ligados diretamente com o Escopo do projeto – o “Planejamento de Escopo” e a “Definição do Escopo”. O primeiro define a regra do jogo, ou “documenta como o escopo do projeto será definido, verificado e controlado e como a estrutura analítica do projeto será criada e definida.” E o segundo processo, define e documenta a declaração de escopo em si.

Não sei se ficou tudo muito confuso, mas apesar desses processos serem importantes, para projetos menores, uma declaração de escopo, bem definida, clara e acordada, pode ser suficiente.

Então ter o escopo perfeitamente definido logo no início é uma garantia de que ele não vai mudar, você poderia pensar. Não necessariamente, por dois motivos básicos – não somos perfeitos e as coisas mudam.

Existem fatores que podem mudar durante a execução do projeto, como questões econômicas(variação cambial, saúde econômica do cliente, etc) e disponibilidade de profissionais habilitados, apenas para citar alguns. Em outras palavras mudanças de escopo, não são incomuns, às vezes podem ser até desejáveis, e o importante é como gerenciar isso. Tal gerenciamento é um esforço necessário que deve ser realizado para que os resultados do projeto ainda sejam vantajosos para ambos os lados. Caso contrário, a melhor solução pode ser cancelar o projeto, e novamente, às vezes pode ser a melhor opção.

Uma forma de se ter certeza de que os resultados estão atendendo as expectativas do cliente, é realizar pontos de controle regularmente e também dividir o projeto em entregas menores e pré-definir que a cada entrega deverá ter um aceite formal do cliente. O primeiro ponto faz com que possa ser identificados problemas e desvios indesejáveis o quanto antes e realizar as devidas ações corretivas. O segundo é igualmente importante, uma vez que se existir um entregável não apropriado, ele pode ser “endireitado” o quanto antes, com uma taxa de retrabalho menor. Imagine se não fosse assim, você só descobriria na entrega que o cliente não gostou – seria um desastre não seria? Seria mais ou menos como você descobrir que sua noiva não quer casar com você no altar. Acho que já deu para entender a importância.

Para concluir, mantenha as expectativas niveladas nos seus projetos. Isso é um processo constante e começa com um levantamento competente, passa por um bom planejamento, um acompanhamento adequado e essencialmente, o comprometimento de seu cliente em cada etapa.

Sucesso e Bons Projetos.

Leandro Santoro.

*(Existem também duas vertentes sobre a questão do fator Qualidade – uma acha que ela é a resultante do equilíbrio dos três fatores, e outra, que é um quarto elemento, contudo isso é assunto para outro artigo ).

Read More

“Desnivelamento de Expectativas” – um grande vilão.

Um Namorado compra um presente caro, achando que vai agradar, contudo a namorada queria apenas ganhar um cartão com uma mensagem personalizada.

Um menino queria ganhar um novo jogo de vídeo game, e o pai leva ao cinema para ver um filme que ele não gosta.

Esse são alguns exemplos de “Desnivelamento de Expectativas”. Apesar de parecer banal, não se deixe enganar, expectativas desencontradas, são a razão de diversos problemas em relacionamentos, sejam interpessoais ou profissionais.

Para entender isso melhor, é importante explicar o que o termo significa. “Desnivelamento de Expectativas”, num relacionamento, acontece quando os envolvidos esperam coisas diferentes do outro. Isso pode ser bilateral ou unilateral, mas quando acontece, não é bom, e às vezes pode ser desastroso.

Para visualizar como isso pode ser desastroso, vejamos um exemplo, sob o ponto de vista de um acordo comercial.

Imagine que você contrate um pedreiro para construir uma casa. Você estipula um valor, mas não define muito bem como quer sua casa, só diz que quer uma casa azul com quintal e janelas. Não é preciso se esforçar muito para descobrir que alguém sairá com algum tipo de prejuízo. Se não se especificar o tamanho da casa, o número de quartos, a qualidade do material desejado, entre muitas outras coisas, os produtos finais podem ser BEM diferentes dos idealizados.

Isso acontece por que,se você não especificou direito, a casa que você imaginou certamente não é casa que o pedreiro imaginou. Talvez você tenha pensado no conforto, conveniência, e o aconchego que seu novo lar poderia lhe proporcionar, enquanto o pedreiro, por sua vez, tenha levado em conta variáveis como menor preço, menor tempo, ou menor esforço.

Situações como essa são comuns, especialmente em locais de trabalho. Já passou por situações em que seu chefe lhe pediu algo, e você fez seu melhor, e então, de repente, ele olha o trabalho e diz – “Não era bem isso que eu tinha em mente…”

Isso aconteceu por causa de uma falha no sistema de comunicação. Vamos lembrar como funciona esse tal sistema de comunicação?

Em primeiro lugar, para uma comunicação é necessário um emissor, um meio, e um receptor. Parece bastante simples, não é verdade? Contudo o perigo mora em banalizar isso, ou ter isso como algo automático – e de fato, não é.

O primeiro trabalho do emissor é codificar corretamente seus pensamentos, para que o receptor possa entendê-lo de forma correta. Depois ele envia essa informação por intermédio de um meio comum e, notem, ele se CERTIFICA, que o receptor recebeu a informação de forma correta. (Ainda existe outros elementos como o Ruído, por exemplo).

Que tal levar isso para a vida real? Vamos utilizar o exemplo anterior, o do seu chefe e você,

No exemplo anterior, o chefe era o emissor, a mensagem, foi passada verbalmente, e você era o receptor. Onde aconteceu o erro então? A menos que tenha acontecido um gesto de imperícia(para ser bem polido), aconteceu um erro de comunicação, ou seja o receptor não entendeu corretamente a mensagem. É isso? Quase . Uma vez que o emissor tem a responsabilidade de se certificar que receptor entendeu corretamente, podemos dizer que o Chefe deveria se certificar que você entendeu corretamente.

Como fazer isso? A melhor forma, é pedir que receptor repita a mensagem, e se certificar, por intermédio de perguntas, o que ele entendeu. Pode-se fazer perguntas como: “O que você pretende fazer, então?”, ou mesmo, “Entendeu, alguma dúvida?” ou coisas do tipo.

Naturalmente, isso não exime totalmente o receptor, ou você, de procurar refinar seu entendimento. Sim, o receptor tem uma parcela de responsabilidade também. Mas como fazer isso? Mais uma vez, por intermédio de perguntas como “Qual o objetivo/encaminhamento/contexto desse trabalho para que eu possa realizar o trabalho de forma mais específica?”, “Não consegui visualizar muito bem esse ponto, poderia completar meu entendimento?” ou mesmo “Existe alguma informação adicional que poderia completar meu entendimento, ou me auxiliar para realizar esse trabalho?” ou coisas do tipo.

É importante dizer que bons relacionamentos, são resultado de uma boa comunicação. Note que nem sempre é necessário um nivelamento de valores, mas sim de expectativas. Isso significa que nem sempre você precisa pensar como o próximo, mas entendê-lo. Conseguiu identificar por que é importante ter(e manter) as expectativas em comum nos seus relacionamentos?

No próximo post, explicarei como o “Desnivelamento de Expectativas” pode ser muito prejudicial no Gerenciamento de projetos, e como se livrar (ou atenuar) esse inconveniente.

Até a próxima.

Leandro Santoro.

Artigo originalmente postado em http://walkingaround.wordpress.com/2008/11/02/desnivelamento-de-expectativas-um-grande-vilao/

Read More

Rápido pensamento sobre os processos

O fato é que um projeto pode acontecer de uma maneira muito mais saudável e agradável desde que os processos da empresa sejam seguidos - e desde que, eles façam todo o sentido para que o fluxo aconteça e ocorra da melhor maneira possível.

Distrair-se de um processo em meio à correria diária é muito fácil. Acabar passando por cima dele para resolver uma questão imediata é coisa corriqueira. A facilidade está aí. E os problemas acabam por vir. Soluções paliativas geram problemas duráveis.

É preciso ter confiança, entendimento e, acima de tudo, postura. Uma coisa não vai bem quando outra atropela e cabe ao GP, no dia-a-dia, conseguir aplicar o tal do processo. E fazer com que todas as partes entendam "onde, quando e porquê".


O quanto você, e as pessoas com quem você trabalha, conhece e aplica a metodologia? Será que é preciso mudar?

Read More

Dicas sobre gerenciamento de projetos

Olá amigos redatores e leitores!

Vi esta semana em um site algo bem interessante para nos ajudar a entender e refletir de forma prática sobre o Mundo do Gerenciamento de Projetos.

Aí vão duas dicas legais de como refletir sobre o assunto de forma divertida para quem gosta de filmes de ação: “O Vôo da Fênix (The Flight of the Phoenix)” e "Uma saída de Mestre (The Italian Job)".

Qualquer um destes filmes são uma perfeita aula de Gerenciamento de Projetos.

Os dois tem uma abordagem e visão gerencial bem interessantes dos projetos, visto que, eles expressam claramente quais os principais objetivos, como é feito o planejamento, quais os riscos, conflitos, motivação e desmotivação, união da equipe, ingerências e tudo que pode cercar uma realidade de um Projeto estão contidas nestas duas estórias.

Para quem gosta vale a pena ver ou rever de forma a pensar baseado nesta área de conhecimento.

Sinopse: O Vôo da Fênix (2004)
Frank Towns (Dennis Quaid) é um piloto de aviões de carga que, juntamente com seu co-piloto A.J. (Tyrese), é enviado para a Mongólia. A dupla tem a missão de retirar do local uma equipe de exploração petrolífera, já que o projeto fora interrompido. Pouco após a decolagem do vôo de volta, quando sobrevoam o deserto de Góbi, o avião enfrenta uma forte tempestade de areia, que arranca suas antenas e destrói o motor esquerdo. O avião sofre uma pane geral e Frank é obrigado a realizar uma aterrissagem forçada em pleno deserto. Com o avião avariado e sem chances de conserto, os 11 tripulantes se vêem presos no deserto e, para piorar, com pouca água e comida. Até que um dos sobreviventes, Elliott (Giovanni Ribisi), propõe uma idéia louca: construir um novo avião com os destroços do primeiro. A proposta é rechaçada por todos de imediato mas, com a situação se tornando cada vez mais crítica, eles decidem arriscar e levar o plano adiante.


Sinopse: Uma saída de Mestre (2003)
Charlie Croker (Mark Wahlberg) é um gênio do crime, que está decidido a recuperar um cofre repleto de ouro que fora roubado por seu ex-sócio Steve (Edward Norton), que o traiu. Para tanto ele conta com uma gangue formada pelo gênio da computação Steve (Seth Green), Handsome Rob (Jason Statham), o especialista em explosivos Left Ear (Mos Def), o arrombador de cofres John Bridger (Donald Sutherland) e ainda a bela Stella Bridger (Charlize Theron). O plano da gangue é recuperar o cofre em plena Los Angeles, criando para tanto o maior engarrafamento que a cidade já viu em sua história.

Espero que gostem desta dica!

Até a próxima um abraço [],

Read More