Anlise Orientada a Objetos com UML

Grupo de estudo:
y

12 de dezembro

2009
What We Know About Agile Software Devepment?

Sandro S. Geraldo (sandrosg@gmail.com) Aline Morais da Silva Antonio CesarSgarbi Ayres Arminda Coelho

y y y

SUMRIO:
1 O QUE NS SABEMOS?...................................................................................... .................... 3 2 O QUE DESENVOLVIMENTO GIL DE SOFTWARE?...................................................3 3 METODOLOGIAS GEIS ........................................................................................................ 4 4 CONCLUSO ............................................................................................................................ 8

5 REFERNCIAS ................................................................................................................. ........ 8

1 - O QUE NS SABEMOS?
Sabemos que o desenvolvimento gil teve um enorme impacto na forma como o software desenvolvido, e veio como reao ao modo tradicional de desenvolvimento. Uma pesquisa de 2005,do E.U. e Europa, por exemplo, revelou que: 14% das empresas estavam usando mtodos geis, e 49% das empresas conscientes dos mtodos geis estavam interessados em adotar. Fonte: apud - Software and Services in Large Enterprises,BusinessTechnographics, Forrester Research, 2005; www.forrester.com/Research/Document/Excerpt/0,7211,38659,00.html

2 - O QUE DESENVOLVIMENTO GIL DE SOFTWARE?

H alguns anos, um grupo de profissionais veteranos na rea de software decidiram se reunir em uma estao de esqui, nos EUA, para discutir formas de melhorar o desempenho de seus projetos. Embora cada envolvido tivesse suas prprias prticas e teorias sobre como fazer um projeto de software ter sucesso, cada qual com as suas particularidades, todos concordavam que, em suas experincias prvias, um pequeno conjunto de princpios sempre parecia ter sido respeitado quando os projetos davam certo. Com base nisso eles criaram o Manifesto para o Desenvolvimento gil de Software, freqentemente chamado apenas de Manifesto gil, e o termo Desenvolvimento gil passou a descrever abordagens de desenvolvimento que seguissem estes princpios, que so apresentados a seguir: Estamos descobrindo maneiras melhores de desenvolver software fazendo-o ns mesmos e ajudando outros a faz-lo. Atravs desse trabalho, passamos a valorizar:
y y y y

Indivduos e interao entre eles mais que processos e ferramentas; Software em funcionamento mais que documentao abrangente; Colaborao com o cliente mais que negociao de contratos; Responder a mudanas mais que seguir um plano.

Ou seja, mesmo havendo valor nos itens direita, valorizamos mais os itens esquerda. O Manifesto gil, criado em 2001, descreve a essncia de um conjunto de abordagens para desenvolvimento de software criadas ao longo da ltima dcada. A mais conhecida delas o Extreme Programming, tambm conhecida pela abreviao XP, uma metodologia criada por Kent Beck no final dos anos 90.

3 - METODOLOGIAS GEIS 3.1 - XP Extreme Programing

Todos que se envolvem com desenvolvimento de software tm um sentimento sobre aquilo que realmente importa. Uma pessoa pode achar que o que realmente importa pensar cuidadosamente em todas as decises de design concebveis antes de implement-las. Outra pode achar que importante mesmo no ter nenhum tipo de restries sobre sua liberdade pessoal. O maior problema que eu encontro em relao ao que as pessoas "sabem" sobre desenvolvimento de software que elas se concentram em aes individuais. O que realmente importa no como uma pessoa se comporta, mas sim como os indivduos se comportam como parte de uma equipe e como parte de uma organizao. Por exemplo, as pessoas so apaixonadas por estilos de codificao. Apesar de haver estilos que so sem dvidas melhores que outros, a questo mais importante em relao a estilos de codificao que a equipe como um todo escolha adotar um estilo em comum. Estilos de codificao muito peculiares e os valores revelados por eles, liberdade pessoal a qualquer custo, no ajudam a equipe a ter sucesso. Se todos na equipe se concentrarem naquilo que importante para a equipe, em que devem se concentrar? XP se baseia em cinco valores para guiar o desenvolvimento:
y y y y y

Comunicao Coragem Feedback Respeito Simplicidade

3.1.1 Comunicao: O cliente de um projeto de software tem um conjunto de problemas que deseja solucionar com o sistema em desenvolvimento e possui algumas idias sobre que funcionalidades podem resolv-los. Por sua vez, desenvolvedores possuem conhecimento sobre aspectos tcnicos que influenciam a forma de solucionar o problema do cliente. Para que os desenvolvedores compreendam o que o cliente deseja e este ltimo entenda os desafios tcnicos que precisam ser vencidos, preciso que haja comunicao entre as partes. 3.1.2 Coragem: Costuma-se dizer que a nica constante em um projeto de software a mudana. Clientes mudam de idia com freqncia, mesmo quando fecham contratos nos quais, teoricamente, assumem o compromisso de no alterar o que est na especificao. Eles mudam porque aprendem durante o projeto e descobrem problemas mais prioritrios a serem solucionados ou formas mais apropriadas de resolv-los. Embora isso seja natural, gera uma preocupao para a equipe de desenvolvimento que, de tempos em tempos, precisa alterar partes do sistema que j estavam prontas, correndo o risco de se quebrar o que j vinha funcionando. 3.1.3 Feedback: Algumas pessoas seriam capazes de caminhar na beirada de um precipcio com os olhos fechados, ou colocar a maior parte do seu dinheiro em um investimento com elevada chance de prejuzo sem acompanh-lo de perto. Entretanto, a maioria das pessoas provavelmente manteria os olhos bem abertos em ambos os casos. Isso particularmente verdade no caso de equipes trabalhando com XP. Elas acreditam que projetos de software so iniciativas freqentemente caras, arriscadas e com um histrico repleto de falhas, o que as leva a simples concluso de que provavelmente o projeto em que esto envolvidas tambm enfrentar falhas e problemas, como habitual na rea de software.

   $ #       8  # $ "        @ %   B ) & $ " $       %      % 8

      !  @   "  $ A  %     % %    !    6  " " $  ! !       @ %       8

 $ $ ) 9  ) 9  (   %       $ % 8         @         ) 9  (   @ & 6  (        " " $ " $  ) )  (  @%       ) 9  (   !         % 8 

 $   $ " " "      !   7    !   & %       ) )   #          # $  $ 5   6    !         " $  $  & %      ) )  )  

3.1.4 Respei R it i R it i l l j t

    & %   " $         " $     !  #       " "   # !               

3.1.5 Si pli i

 " 5    !  5   (  $ 3          4   !   " "           2 ) " & %  1  !        0 % " " "   )  )   ('

3.2 - Scrum

i l R i M ti i i t

l i

ily

j t

ti i

i i

it

j ti i i

i l i

i t

li

ti

t l l

tB

t l i il i l (ti i t j t ti i j t l

i t t i i i

i t

e:

i t

y t t

i l N i i l

i l

i t

t i tR t V j il t

i i i

tB

t i i i

i )

t t l l

i t i i

i ti

it

li

it i i t t i i i J ti i

j t

ti

it

it

j t t i t i t M t l i i

i i

i t i tB

it

i ti

ti i t l

i M t

t i

li t i M ti tB l i i i t

i i

t i

i t

j t

l i

ti

N t

ti i

ti t

i t

i t t

i l i

i t

i l

3.2.1 - Sprint Planning Meeting

O Sprint Planning Meeting uma reunio na qual esto presentes o ProductOwner, o Scrum Master e todo o Scrum Team, bem como qualquer pessoa interessada que esteja representando a gerncia ou o cliente. Durante o Sprint Planning Meeting, o ProductOwner descreve as funcionalidades de maior prioridade para a equipe. A equipe faz perguntas durante a reunio de modo que seja capaz de quebrar as funcionalidades em tarefas tcnicas, aps a reunio. Essas tarefas iro dar origem ao Sprint Backlog.

3.2.2 - Daily Scrum

A cada dia do Sprint a equipe faz uma reunio diria, chamada Dail Scrum. Ela tem como objetivo disseminar conhecimento sobre o que foi feito no dia anterior, identificar impedimentos e priorizar o trabalho a ser realizado no dia que se inicia. Os Dail Scrums normalmente so realizadas no mesmo lugar, na mesma hora do dia. Idealmente so realizados na parte da manh, para ajudar a estabelecer as prioridades do novo dia de trabalho.
C C

3.2.3 Sprint Review Meeting

Ao final de cada Sprint feito um Sprint Review Meeting. Durante esta reunio, o Scrum Team mostra o que foi alcanado durante o Sprint. Tipicamente, isso tem o formato de um demo das novas funcionalidades. Os participantes do Sprint Review tipicamente incluem o ProductOwner, o Scrum Team, o Scrum Master, gerncia, clientes e engenheiros de outros projetos.

3.2.4 - Sprint Retrospective

O Sprint Retrospective ocorre ao final de um Sprint e serve para identificar o que funcionou bem, o que pode ser melhorado e que aes sero tomadas para melhorar.

3.3 Casos de Sucesso

Descries de casos reais de aplicao de mtodos geis e XP nos quais o projeto foi considerado um sucesso.

3.3.1 Assemblia Legislativa do Estado de So Paulo Assessoria e capacitao em desenvolvimento de software

Ao longo de 2005, um grupo de professores e alunos do IME/USP, dentre eles os Professores Alfredo Goldman e Fabio Kon, e o DairtonBassi, prestaram uma assessoria Assemblia Legislativa do Estado de So Paulo ALESP . Foi iniciado o desenvolvimento de um projeto para o Departamento de Recursos Humanos. Por ser um projeto muito complexo, com vrias especificidades, a equipe interna havia passado 18 meses fazendo uma detalhada anlise de requisitos. Ao sermos chamados, ao invs de "aprendermos" toda a lgica do negcio, para em seguida desenvolver o sistema, optamos por capacitar a equipe com um treinamento intensivo e fazer o desenvolvimento conjunto. Aps apenas trs meses de treinamento as primeiras linhas do cdigo j estavam sendo escritas. Aps oito meses de assessoria, com todas as prticas de XP
E D E D

implementadas e em uso dirio, o projeto foi apresentado para a direo da casa como uma parceria de sucesso. Em 2006, a parceria com a ALESP foi ampliada: temos mais membros da AgilCoop e alunos do IME trabalhando em conjunto e implementando mtodos geis no desenvolvimento e manuteno dos trs principais sistemas de software da ALESP incluindo no s o sistema de RH mas tambm o portal e o SPL, o sistema de apoio ao legislativo que utilizado para gerenciar o trabalho legislativo dos parlamentares.

3.3.2 Ikwa O Ikwa um canal de contedo, servios e networking para auxiliar estudantes e profissionais em suas decises e em seu crescimento acadmico e profissional.
o final de 2006, DairtonBassi e Danilo Sato assessoraram a criao da Ikwa, a primeira start-up Web 2.0 brasileira a receber investimento de venture capital. Eles montaram a equipe e implantaram uma metodologia gil de desenvolvimento de software. o incio de 2007, Dairton foi convidado para dirigir toda a rea de desenvolvimento e tecnologia da empresa. Em poucos meses, a equipe atingiu nveis elevados de flexibilidade e eficincia, conseguindo tornar o tempo de resposta a novas solicitaes extremamente baixo. ovas funcionalidades passaram a entrar em produo semanalmente, sem perda de qualidade e com um la out que recebe inmeros elogios de seus usurios. www.ikwa.com.br
F F F

3.3.3 Laboratrio de Programao eXtrema Disciplina ministrada no IME/USP para alunos do ltimo ano do Bacharelado e para a psgraduao em em Cincia da Computao.
Desde 2001, temos ministrado a disciplina de Laboratrio de Programao eXtrema no IME/USP durante a qual cerca de 25 alunos em cada turma desenvolvem sistemas de software em conjunto, em grupos de 2 a 12 desenvolvedores. A disciplina dura 4 meses e ao final do semestre, prottipos de sistemas de software so entregues. Alguns dos sistemas entregues esto sendo utilizados atualmente no mundo real. A maioria dos sistemas desenvolvidos tem sido em ava e com interface Web utilizando arcabouos como struts e velocit . o entanto, j tivemos projetos utilizando outras tecnologias e linguagens como C++ e Smalltalk. Maiores informaes esto disponveis na pgina da disciplina.
F G I P H

3.3.4 Paggo Implementao de XP em uma empresa start-up.

Em 2005 Alexandre Freire foi convidado para implantar a metodologia gil de Programao eXtrema emuma start-up. Aps 6 meses, o grupo de tecnologia da empresa conseguiu transitar para sua adaptao de XP com sucesso e conseguiu investimentos que garantiram a criao da Paggo. Hoje em dia a Paggo aplica prticas geis no s na tecnologia, mas em todos os departamentos da empresa.

3.3.5 Locaweb
A Locaweb a maior empresa de hospedagens de sites da Amrica Latina. o final de 2006, Daniel Cukier comeou a usar XP na equipe de desenvolvimento de servios de voz LocaWeb Telecom . Usando a metodologia, a equipe conseguiu entregar funcionalidades de forma rpida e com baixo ndice de bugs.
I H F

A diretoria da empresa percebeu as vantagens dos mtodos geis e decidiu realizar um treinamento envolvendo toda rea de tecnologia. Em agosto de 2007, Daniel e Maurcio Dediana realizaram um curso para 85 pessoas das reas de desenvolvimento e produtos da empresa. A partir da, as equipes comearam a adotar Scrum e algumas prticas de XP. Os diretores ficaram muito satisfeitos com o resultado. Hoje a empresa muito mais eficiente em entregar software de qualidade para seus clientes. ale ressaltar que foram utilizados padres para introduzir novas ideias para disseminar a inovao dentro da empresa. Sem esses padres, talvez no tivesse ido to longe.
Q

4 CONCLUSO
O Desenvolvimento gil veio como soluo de muitos problemas para o contexto de negcios atuais. Entregas constantes de funcionalidades, controle mais efetivo do andamento do projeto, entre outros. Porm, ainda tem o desafio de quebrar algumas barreira como o Contrato de Desenvolvimento de Software e a suposta escassez de documentao. Mas no temos como negar os visveis benefcios das metodologias geis em um mundo de mudanas e competitividade acirrada em que uma funcionalidade no sistema da empresa pode ser o diferencial competitivo e fundamental.

5 REFERENCIAS
y y y y y

08/12/2009 14h48min Manifiesto gil - ttp://improveit.com.br/xp/manifesto_agil

08/12/2009 14h55min alores do XP - http://improveit.com.br/xp/valores 08/12/2009 15h00min Scrum - http://www.improveit.com.br/br/scrum/index 08/12/2009 15h01min Manifesto gil - http://www.agilemanifesto.org/ 10/12/2009 11h22min Falando sobre Scrum Alexandre Magno Figueiredo http://www.visaoagil.com/downloads/biblioteca/axmagnoFalandoScrum.pdf 10/12/2009 17h33min Comparao entre Metodologias geis e Tradicionais para o Desenvolvimento de Software MICHEL DOS SA TOS SOARES - http://www.dcc.ufla.br/infocomp/artigos/v3.2/art02.pdf apud - T. D b, Improvisation in Small Software Organizations, IEEE Software, vol. 17, no. 5, 2000, pp. 8287. apud - B. Boehm, Get Read for Agile Methods, with Care, Computer, vol. 35, no. 1, 2002, pp. 6469.
U T S R