CENTRO UNIVERSITRIO ANHANGUERA DE SO PAULO

UNIDADE CAMPO LIMPO

CURSO: TECNOLOGIA EM GESTO DA TECNOLOGIA DA INFORMAO

ATPS DE NOVAS TECNOLOGIAS

PROFESSOR: ALEXANDRE ALVES FREITAS

ANDR FERREIRA TORRES

RA 3715657906

CARLOS ALFREDO RODRIGUEZ

RA 7251614816

CESAR SANTIAGO DE OLIVEIRA

RA 7032517936

FABIANO DE MORAES LIMA

RA 7631712728

LUANA DOMINGOS BRAZ

RA 7247599151

MARIA LUCIA GOMES DE OLIVEIRA

RA 7249607661

MARTA MOURA DA TRINDADE

RA 7633740325

SRIE 4 e 5 SEMESTRE

SO PAULO

MARO DE 2015

CENTRO UNIVERSITRIO ANHANGUERA DE SO PAULO

UNIDADE CAMPO LIMPO

CURSO: TECNOLOGIA EM GESTO DA TECNOLOGIA DA INFORMAO

ATPS DE NOVAS TECNOLOGIAS

PROFESSOR: ALEXANDRE ALVES FREITAS

SRIES: 4 e 5 SEMESTRE

SO PAULO
MARO DE 2015

Introduo:

A finalidade deste trabalho fornecer uma viso compreensiva de como estruturado os

princpios de desenvolvimento gil alm de suas aplicaes ao longo do seu desenvolvimento. As
tcnicas mais utilizadas hoje pelo mercado de desenvolvedores e como so maleveis suas
aplicaes no dia-a-dia da equipe de desenvolvimento.
A abordagem de como a dinmica do processo, seus membros prximos na assistncia diria, a
motivao de cada equipe entre outros fatores que no transcorrer de tal trabalho trataremos.
O cronograma de atividades em breves perodos para entrega em fases ao cliente divulga como
ponto forte a forma de trabalho na naturalidade, na codificao e a cooperao da equipe para
finalizar cada atividade.

Sumrio:
Etapa 1 ......................................................................................................................................... 05
Passo 1 ......................................................................................................................................... 05
Passo 2 ......................................................................................................................................... 05
Passo 3 ......................................................................................................................................... 08
Passo 4 ......................................................................................................................................... 09
Scrum ........................................................................................................................................... 09
XP ............................................................................................................................................... 10
LSD .............................................................................................................................................. 11
AUP ............................................................................................................................................ 11
Etapa 2 ......................................................................................................................................... 12
Passo 1 ......................................................................................................................................... 12
Passo 2 ......................................................................................................................................... 13
Scrum ........................................................................................................................................... 13
Caractersticas de Scrum .............................................................................................................. 14
Backlog de Produto e backlog de sprint ...................................................................................... 15
Planejamento de Sprint ................................................................................................................ 15
Scrum Simplificado ..................................................................................................................... 16
Algumas caractersticas de Scrum ............................................................................................... 16
Agendando discusses dirias ...................................................................................................... 16
Scrum Solo ................................................................................................................................... 17
Referncias Bibliogrficas ........................................................................................................... 18

ETAPA 01

Passo1:
Leitura do link Manifesto gil
Passo 2:

A maior prioridade consiste em satisfazer o cliente, atravs da entrega adiantada e

persistente de software de valor. O foco a satisfao do cliente; Essa satisfao obtida
entregando ao cliente o que ele deseja, software que traga solues ou benefcios para o
seu negcio. Todavia, isso no basta. Esse software deve ser entregue de forma contnua e
adiantada, para permitir a validao do produto ao longo do desenvolvimento e iniciar o
fluxo de retorno do investimento o mais rpido possvel.

Aceitar mudanas de requisitos, mesmo no fim do desenvolvimento. Processos geis se

adequam a mudanas, para que o cliente possa ter vantagens competitivas. Como o foco
alcanar a satisfao do cliente, mesmo no fim do desenvolvimento do software, caso o
cliente queira fazer alteraes, sero feitas do agrado dele. Sendo assim a alterao que o
cliente solicitou cria vantagens competitivas sob o software.

Entregar software funcionando com frequncia, na escala de semanas at meses com

preferncia aos perodos mais curtos. Entregar a seus clientes, com frequncia, partes do
produto prontas, em cada entrega, o retorno ao investimento do cliente permite adquirir o
feedback, sobre o que j est pronto. Assim podemos adaptar s necessidades do cliente
incrementando o software, reduzindo os riscos do projeto.

As pessoas relacionadas aos negcios e desenvolvedores devem trabalhar diariamente em

conjunto, durante todo o curso do projeto. Pessoas de negcios e desenvolvedores do
produto tem o objetivo de garantir a gerao de valor para os clientes e para atingir esse
objetivo, cooperam o tempo todo durante o projeto, interagindo com frequncia. Esse
05

princpio combate o cenrio de incompatibilidade comum em projetos de desenvolvimento

de software, nos quais pessoas de negcios que frequentemente incluem os prprios clientes
do projeto e desenvolvimento raramente se comunicam e muitas vezes, esto em lados
opostos.

Construir projetos em torno de indivduos motivados dando a eles o ambiente e suporte

necessrio, e confiar que faro seu trabalho. O software construdo por pessoas. O
ambiente, o suporte e a confiana para realizar seu trabalho so os fundamentais fatores
para sua motivao. Esse princpio se ope a crena de que o produto se constri em
torno das melhores ferramentas e processos, e no das pessoas, como por exemplo, se
amparando nos melhores instrumentos de monitorao e controle externos.

O mtodo mais eficiente e eficaz de transmitir informaes para uma equipe de

desenvolvimento, atravs de uma conversa face a face. A melhor forma de comunicao
entre membros de uma equipe e o mundo externo a comunicao face a face, que
direta e enriquecida pela entonao de voz, olhar e linguagem corporal entre outros
fatores. Quando a comunicao presencial no vivel uma boa prtica fazer o
melhor uso possvel da tecnologia disponvel para se aproximar da comunicao face a
face. Esse princpio se ope a utilizao de documentos, e-mail, telefone e
teleconferncia, entre outros como formas padro de comunicao em um projeto.

Software funcional a medida primria de um progresso. O progresso do software ocorre

na medida que partes do produto que signifiquem valor so entregues aos clientes do
projeto. Esse princpio se ope prtica de gerar artefatos como prottipos e extensos
documentos de planos e especificaes e assim, crer que se progrediu no projeto. Isto
tambm combate gerao de qualquer artefato e partes do produto que no gerem valor
para os clientes do projeto.

Processos geis promovem um ambiente sustentvel. Os patrocinadores, desenvolvedores

e usurios, devem ser capazes de manter indefinidamente, passos constantes. Busca
promover um ritmo constante e sustentvel para o trabalho da equipe que desenvolve o
06

produto, o que se torna possvel quando esse ritmo apoiado por todos os envolvidos,
incluindo usurios e patrocinadores. Entretanto, ao se exigir dessa equipe um
compromisso com mais trabalho do que ela capaz de produzir, so muitas vezes
adotadas horas extras, o trabalho em fins de semana e a pressa exagerada para se cumprir
o prazo de entrega, por exemplo. Essas prticas podem levar a insatisfao dos membros
da equipe de desenvolvimento, a uma menor produtividade e uma menor qualidade no
produto gerado.

Contnua ateno excelncia tcnica e bom designer, aumenta a agilidade. O produto

projetado com qualidade e produzido com excelncia tcnica permite que seja facilmente
ser modificado e, assim, aceite a mudana como natural no processo de seu
desenvolvimento. Assim, a alta qualidade no produto gerado essencial para manter-se a
Agilidade. Esse princpio se ope crena de que, para se obter velocidade e
flexibilidade no desenvolvimento do produto, a qualidade deveria ser sacrificada. Na
realidade, exatamente o oposto.

Simplicidade: a arte de maximizar a quantidade de trabalho que no precisou ser feito.

Evita-se o desperdcio no desenvolvimento do produto ao no se realizar trabalho que no
necessrio. Exemplos comuns de desperdcios incluem desenvolvimento de
funcionalidades de que os clientes no precisam ou de solues desnecessrias e
complexas, planejamento com nvel de detalhes maior do que se pode ter em um
determinado momento e uso ou gerao de artefatos desnecessrios.

As melhores arquiteturas, requisitos e designers emergem de times auto organizveis.

Equipes com maior autonomia so mais eficientes. Essas equipes auto organizadas
trabalham em direo a metas acordadas, mas tm a liberdade de decidir qual a melhor
forma de realizar esse trabalho e, assim, so responsveis e responsabilizadas por seus
resultados. Dessa forma, geram um melhor produto.

07

Em intervalos regulares, o time reflete em como ficar mais efetivo, ento, se ajustam e
otimizam seu comportamento de acordo. Para se tornar cada vez mais efetiva, a equipe
regularmente inspeciona suas formas de trabalho, identifica pontos de melhoria e se
adapta de acordo, promovendo a melhoria incremental contnua. a inspeo e adaptao
que o time realiza em seus processos de trabalho.

O manifesto contm quatro valores fundamentais:

1- Os indivduos e suas interaes acima de procedimentos e ferramentas; Os indivduos
completam as mquinas e no podem ser comparados a elas.
2- O funcionamento do software acima de documentao abrangente; A ideia por trs
deste item que para o usurio do software mais importante que o software esteja funcionando
do que pginas e mais pginas demonstrando como o software deve funcionar. Usurios tendem
a aproveitar muito melhor o tempo aprendendo como o software do que com diagramas
descrevendo de maneira tcnica as tcnicas empregadas no desenvolvimento do software. Ainda
sim esta documentao no algo a ser desprezado, pois ainda representam o melhor guia para o
entendimento do por que e como um sistema construdo e como utilizar o sistema.
3- A colaborao dos clientes acima da negociao de contratos; Se a equipe trabalha como
parceira do cliente e entrega valor, com certeza o cliente a contratar para outros projetos.
4- A capacidade de resposta a mudanas acima de um plano pr-estabelecido; A equipe
deve sempre responder s mudanas do software, quando um plano j estabelecido pelo cliente
alterado.

Passo 3:

08

Pesquisar e relacionar ao menos 4 outras metodologias geis (alm do XP). Sua pesquisa
deve permitir escrever uma breve descrio de seu histrico e definirem, em linhas gerais, suas
caractersticas.
Passo 4:

Scrum Scrum um mtodo de desenvolvimento gil de software criado por Jeff

Sutherland e a sua equipe de desenvolvimento de software. O mtodo foi criado no incio dos
anos 90 e recentemente ganhou incrementos nos mtodos grficos atravs de Schwaber e Beedle.
Assim como os demais modelos de desenvolvimento gil o Scrum possui princpios consistentes
com o manifesto gil. O Scrum indicado para projetos com prazos apertados, requisitos que
esto sempre sendo modificados e que so crticos para o negcio. Este mtodo define um
conjunto de aes de desenvolvimento, so eles: o Backlog que onde registra-se todo o trabalho
pendente (requisitos ou funcionalidades) organizando-os por prioridades. Ressalta-se que novas
funcionalidades podem ser adicionadas a esse Backlog a qualquer momento introduzindo as
alteraes do usurio. Porm, o gerente do produto deve avaliar esta funcionalidade e atualizar as
prioridades; Temos tambm como uma ao do Scrum as Sprints que so algumas
funcionalidades do Backlog que podem ser atendidas num prazo curto, de no mximo 30 dias.
nas Sprints que o trabalho de desenvolvimento realmente ser realizado para entregar o mais
rpido possvel um incremento de software operacional ao cliente. Quando as Sprints j esto
ocorrendo no devemos fazer alteraes e possveis modificaes devem ser realizadas nas
prximas Sprints; Outra ao do Scrum so as Reunies que tipicamente so curtas (15 minutos)
e realizadas diariamente pela equipe Scrum. Nesta reunio diria so feitas trs perguntas
bastante pontuais para todos os membros da equipe:
"O que voc realizou desde a ltima reunio da equipe?", "Quais obstculos esto
encontrando?" e "O que planeja realizar at a prxima reunio da equipe?". Estas perguntas
ajudam todos a entenderem o que cada um fez no dia anterior, se tem alguma dificuldade para
realizar o trabalho atual e o que se pretende fazer hoje. Esta reunio considerada muito
importante porque ajuda a equipe a revelar problemas o mais cedo possvel, tambm ajuda a
disseminar o conhecimento. Uma dica importante que nem todas as equipes acham a reunio
09

diria apropriada para ser feita na parte da manh, isto porque alguns membros comeam
a trabalhar no turno da tarde ou porque as pessoas no possuem um humor muito bom pela
manh, tente avaliar essas questes e decida o melhor momento.
No Scrum tambm temos um lder de equipe que chamado de Scrum Mster. Ele responsvel
por conduzir a reunio diria e avaliar as respostas dos integrantes. O objetivo do Scrum Master
tambm remover obstculos.
Por fim, o SCRUM tambm trabalha com a ideia de entrega de incrementos de software ao
cliente, ou Demos. Essa funcionalidade permite ao cliente avaliar e dar feedbacks para a equipe.
Como as Demos so realizadas durante os incrementos, pode ser que no tenhamos toda a
funcionalidade completa, mas teremos funes que possam ser entregues dentro do prazo
acertado com o cliente.
XP A metodologia Extreme Programming (XP) enfatiza o desenvolvimento rpido do
projeto e visa garantir a satisfao do cliente, alm de favorecer o cumprimento das estimativas.
As regras, prticas e valores da XP proporcionam um agradvel ambiente de desenvolvimento de
software para os seus seguidores, que so conduzidos por quatro valores: comunicao,
simplicidade, feedback e coragem. A finalidade do princpio de comunicao manter o melhor
relacionamento possvel entre clientes e desenvolvedores, preferindo conversas pessoais a outros
meios de comunicao. A comunicao entre os desenvolvedores e o gerente do projeto tambm
encorajada. A forma de comunicao um fator chave na XP: procura-se o mximo possvel
comunicar-se pessoalmente, evitando se o uso de telefone e o envio de mensagens por correio
eletrnico. A simplicidade visa permitir a criao de cdigo simples que no deve possuir
funes desnecessrias. Por cdigo simples entende-se implementar o software com o menor
nmero possvel de classes e mtodos. Outra idia importante da simplicidade procurar
implementar apenas requisitos atuais, evitando-se adicionar funcionalidades que podem ser
importantes no futuro. A aposta da XP que melhor fazer algo simples hoje e pagar um pouco
mais amanh para fazer modificaes necessrias do que implementar algo complicado hoje que
talvez no venha a ser usado, sempre considerando que requisitos so mutveis

10

LSD - O Desenvolvimento de Software Enxuto ou Lean Software Development (LSD)

adaptou os princpios da fabricao enxuta da indstria para o mundo da engenharia de software.
Entre os princpios do desenvolvimento enxuto tem-se: eliminar desperdcios, incorporar
qualidade, criar conhecimento, adiar compromissos, entrega rpida, respeitar as pessoas e
otimizar o todo.
Cada um desses princpios foi adaptado ao contexto do processo de software. Para citar um
exemplo, o eliminar desperdcio, no contexto de um projeto de software gil interpretado como
no adicionar recursos ou funes obscuras, avaliar possveis impactos do custo e cronograma de
qualquer requisito que seja solicitado, eliminar etapas do processo que sejam suprfluos, etc.

AUP - O Processo Unificado gil ou AgileUnifiedProcess (AUP) adota uma filosofia

serial (sequncia linear de atividades) para o que amplo e iterativo para o que particular. Este
processo possui atividades nas fases clssicas adotadas pelo Processo Unificado: Incio,
Elaborao, Construo e Transio. Dentro de cada uma das atividades a equipe itera ou se
repete para alcanar a agilidade e entregar incrementos de software para os usurios finais.
importante que essa entrega seja mais rpida quanto possvel.
A AUP possui seis atividades, na qual a equipe ir sempre iterar. As atividades so:
1) Modelagem: Modelos UML representando o negcio so criados. Os modelos
devem ser suficientemente bons e adequados para permanecer gil.
2) Implementao: Modelos so traduzidos para o cdigo-fonte.
3) Teste: A equipe projeta e executa uma srie de teste a fim de descobrir possveis
erros e para assegurar que o cdigo-fonte se ajuste aos requisitos.
4) Aplicao: a entrega de um incremento de software e a aquisio de feedback
dos usurios finais com base neste incremento.
5) Gerenciamento de Configurao e Gerenciamento de projeto: No contexto da AUP,
gerenciamento de configurao refere-se ao gerenciamento de alteraes, riscos e
de controle de qualquer artefato persistente que so produzidos pela equipe. O
gerenciamento de projeto controla o progresso de uma equipe e coordena suas
atividades.
11

6) Gerenciamento de Ambiente: Coordena toda a infraestrutura de processos

incluindo padres, ferramenta e outras tecnologias de suporte disponveis para a
equipe.
Como vimos nesse artigo, um processo de software tem como caracterstica um conjunto
de atividade que conduzem o desenvolvimento do produto de software.
Um processo tem como caracterstica a definio de quem realiza uma atividade e quando
faz-la. Um Modelo de processo uma descrio simplificada de um processo onde se definem
as atividades, especificam-se os produtos gerados nas atividades e indicam-se os papeis das
pessoas envolvidas. As empresas normalmente definem seus prprios modelos de processos,
juntando o que tem de melhor nos diferentes modelos de processos existentes. Outras empresas
preferem adotar um modelo de processo que seja mais adequado ao seu contexto.

ETAPA2

Passo1:
Esses valores apresentados no manifesto gil so os provveis motivos da evidncia das
metodologias geis, visto que entre as pessoas que assinaram o manifesto encontram-se os
criadores de vrias metodologias como XP, SCRUM, entre outras. Eles declararam que mais
importante que seguir um processo massivo apenas por que a empresa o adotou saber o que as
pessoas pensam disso, pensar em motivar as pessoas que desenvolvem os projetos de software,
alimentar a comunicao, a franqueza e a colaborao dessas pessoas entre si de modo que todos
entendam que possuem um objetivo comum, desenvolver um produto de qualidade. Mais
importante do que fazer documentao em excesso desenvolver um software que funcione
corretamente e atenda as expectativas do cliente. importante colaborar com o cliente, mais do
que negociar novos contratos. Eles entendem que mudana algo bom, desde que essa mudana
12

agregue valor ao produto para o cliente. Realizar mudanas envolve obter um software de
qualidade, vendo qualidade do ponto de vista da satisfao do cliente.
Como disse antes, algumas prticas das metodologias geis no so novidades, mas o
novo foco apresentado pelos valores e princpios do movimento gil agradam e esto dando
muitos resultados, porm se as empresas derem importncia apenas as prticas apresentadas
pelas diversas metodologias, esquecendo dos valores e princpios do Agilemanifesto.org, essas
tambm tenderam a ser mais algumas metodologias que no funcionam e causam novos
problemas, e sero apresentadas como pssimos exemplos por futuros xiitas que tero novas
metodologias como a bala de prata que resolve todos os problemas da engenharia de software.
Passo2:
SCRUM
um dos mtodos da metodologia gil para gerenciamento de Projetos. Scrum vem
sendo amplamente adotado por empresas como o portal Terra e a Globo.com, justamente por
atender com preciso s necessidades do desenvolvimento de software e sites.
Inicialmente, o Scrum foi concebido como um estilo de gerenciamento de projetos em
empresas de fabricao de automveis e produtos de consumo, por Takeuchi e Nonaka no artigo
"The New NewProductDevelopment Game" (Harvard Business Review, Janeiro-Fevereiro
1986). Eles notaram que projetos usando equipes pequenas e multidisciplinares (crossfunctional) produziram os melhores resultados, e associaram estas equipes altamente eficazes
formao Scrum do Rugby (utilizada para reincio do jogo em certos casos). Jeff Sutherland,
John Scumniotales, e Jeff McKenna documentaram, conceberam e implementaram o Scrum,
como descrito abaixo, na empresa Easel Corporation em 1993, incorporando estilos de
gerenciamento observados por Takeuchi e Nonaka. Em 1995, Ken Schwaber formalizou a
definio de Scrum e ajudou a implant-lo em desenvolvimento de software em todo o mundo.
Scrum junta conceitos de Lean, desenvolvimento iterativo e do estudo de Hirotaka
Takeuchi e Ikujiro Nonaka. A funo primria do Scrum ser utilizado para o gerenciamento de
projetos de desenvolvimento de software. Ele tem sido usado com sucesso para isso, assim como
Extreme Programming e outras metodologias de desenvolvimento.
13

Porm, teoricamente pode ser aplicado em qualquer contexto no qual um grupo de

pessoas necessitem trabalhar juntas para atingir um objetivo comum, como iniciar uma escola
pequena, projetos de pesquisa cientfica, ou at mesmo o planejamento de um casamento.
Mesmo que o Scrum tenha sido idealizado para ser usado em gesto de projetos de
desenvolvimento de software, ele tambm pode ser usado para gerenciar equipes de manuteno,
ou como uma abordagem para gesto de programas: Scrum de Scrums.
Caractersticas de Scrum
- Cada sprint uma iterao que segue o ciclo PDCA e entrega um incremento de software
pronto.
- Um backlog um conjunto de requisitos, priorizado pelo ProductOwner (cliente);
- H entrega de um conjunto fixo de itens do backlog em uma srie de iteraes curtas ou sprints;
- Uma breve reunio diria ou scrum, onde cada participante fala sobre o progresso conseguido,
o trabalho a ser realizado e/ou o que o impede de seguir avanando (tambm chamado de
StandupMeeting, j que os membros da equipe geralmente ficam em p).
-Uma breve sesso de planejamento, na qual os itens do backlog para uma sprint (iterao) so
definidos uma retrospectiva, na qual todos os membros da equipe refletem sobre a Sprint
passada.
O Scrum facilitado por um Scrum Master, que tem como funo primria remover
qualquer impedimento habilidade de uma equipe de entregar o objetivo do sprint. O Scrum
Master no o lder da equipe (j que as equipes so auto organizadas) mas atua como um
rewall entre a equipe e qualquer influncia desestabilizadora. Outra funo extremamente
importante de um Scrum Master o de assegurar que a equipe esteja utilizando corretamente as
prticas de Scrum, motivando-os e mantendo o foco na meta da Sprint.
Scrum permite a criao de equipes auto organizadas, encorajando a comunicao verbal
entre todos os membros da equipe e entre todas as disciplinas que esto envolvidas no projeto.
Um princpio chave do Scrum o reconhecimento de que desafios fundamentalmente baseados
na experincia no podem ser resolvidos com sucesso utilizando uma abordagem tradicional de
"controle".
14

Assim, o Scrum adota uma abordagem emprica, aceitando que o problema no pode ser
totalmente entendido ou definido, focando na maximizao da habilidade da equipe de responder
de forma gil aos desafios emergentes. Um dos grandes defeitos do Scrum, porm, a
abordagem de "receita de bolo" do gerenciamento de projetos exemplificado no Project
Management BodyofKnowledge ou Prince2, que tem como objetivos atingir qualidade atravs da
aplicao de uma srie de processos prescritos

Backlog de produto e backlog de sprint

Um backlog uma lista de itens priorizados a serem desenvolvidos para um software. O
backlog de produto mantido pelo Proprietrio do Produto e uma lista de requisitos que
tipicamente vm do cliente. O backlog de sprint uma interpretao do backlog do produto e
contm tarefas concretas que sero realizadas durante o prximo sprint para implementar alguns
dos itens principais no backlog do produto. O backlog de produto e de sprint so, ento, duas
coisas totalmente diferentes, o primeiro contendo requisitos de alto-nvel e o segundo contendo
informaes sobre como a equipe ir implementar os requisitos.

Planejamento de Sprint
Antes de todo sprint, o Proprietrio do Produto, o Scrum Master e a Equipe decidem no
que a equipe ir trabalhar durante o prximo sprint. O Proprietrio do Produto mantm uma lista
priorizada de itens de backlog, o backlog do produto, o que pode ser repriorizado durante o
planejamento do sprint. A Equipe seleciona itens do topo do backlog do produto. Eles selecionam
somente o quanto de trabalho eles podem executar para terminar. A Equipe ento planeja a
arquitetura e o design de como o backlog do produto pode ser implementado. Os itens do
backlog do produto so ento destrinchados em tarefas que se tornam o backlog do sprint.

15

Scrum simplificado
Muitas organizaes tm sido resistentes s metodologias introduzidas em baixos nveis
da organizao. Porm, a adaptabilidade do Scrum permite que ele seja introduzido de forma
invisvel ("stealth"), usando os trs passos:
Agende uma demonstrao do software com seu cliente em um ms a partir de agora;
Como equipe, tome um ms para deixar o software pronto para uma demo, com
funcionalidades prontas, no simplesmente telas;
Na demonstrao, obtenha feedback e use-o para guiar o seu prximo ms de trabalho de
desenvolvimento

Algumas caractersticas de Scrum

- Clientes se tornam parte da equipe de desenvolvimento (os clientes devem estar genuinamente
interessados na sada);
- Entregas frequentes e intermedirias de funcionalidades 100% desenvolvidas;
- Planos frequentes de mitigao de riscos desenvolvidos pela equipe;
- Discusses dirias de status com a equipe;
- A discusso diria na qual cada membro da equipe responde s seguintes perguntas:
O que fiz desde ontem?
O que estou planejando fazer at amanh?
Existe algo me impedindo de atingir minha meta?
- Transparncia no planejamento e desenvolvimento;
- Reunies frequentes com os stakeholders (todos os envolvidos no processo) para monitorar o
progresso;
- Problemas no so ignorados e ningum penalizado por reconhecer ou descrever qualquer
problema no visto;
- Locais e horas de trabalho devem ser energizadas, no sentido de que "trabalhar horas extras"
no necessariamente significa "produzir mais".
16

Agendando discusses dirias

Um momento bom para as discusses dirias depois do almoo. Durante a manh pode ser
complicado. Estas discusses de status no demoram e uma forma eficiente de fazer estas
reunies seria ficar em p e em frente a um quadro negro. Como as pessoas tendem a ficar
cansadas aps o almoo, ter uma viva reunio em p nessa hora permite que a equipe mantenha a
sua energia alta. Como todos estiveram trabalhando durante a manh, suas mentes esto focadas
no trabalho e no em questes pessoais.

Scrum Solo
Scrum baseado em pequenas equipes. Ele permite a comunicao entre os membros da
equipe. Entretanto, h uma grande quantidade de softwares desenvolvidos por programadores
solos. Um software sendo desenvolvido por um s programador pode ainda se beneficiar de
alguns princpios do Scrum, como: um backlog de produto, um backlog de sprint, um sprint e
uma retrospectiva de sprint. Scrum Solo uma verso adaptada para uso de programadores solo.

17

Referncias:
http://wikipedia.com.br
http://www.slideshare.net/lorran33/padres-de-projeto-adapter-proxy-composite-e-bridge
http://www.devmedia.com.br/conheca-os-padroes-de-projeto/957
http://codeigniterbrasil.com/passos-iniciais/padroes-de-projeto-ou-design-patterns-o-que-saopara-que-servem-e-qual-sua-implicacao-de-uso/
www.teses.usp.br/teses/.../CelioMauroPlacerRodriguesDeAlmeida.pdf
www.madeira.ufpr.br/disciplinasklock/.../Apostila%20GP%20leitura.pdf

18