Va 03

\
O seu canal sobre processos geis
As 5 Doenas do Gerenciamento de Projetos
Causa n 3: Sndrome do Estudante
Utilizando Metodologias geis para atingir MPS.BR nvel F na Powerlogic
Case de implantao de processos geis com MPS.BR

Mtricas e o Desenvolvimento gil Aperfeioamento de Projetos geis Brincando com a UML em Cores OpenUP: Uma Introduo
Agile e MPS.BR
Cobertura do Java Brasil 2007 Cobertura do Scrum Gathering em Londres News e Referncias geis
Ano Viso gil Edio 03 Edio 01 Revista II
www.visaoagil.com 1
Sprint Backlog
Conhea os temas selecionados para essa edio(iterao).
News
Pgina 04

Causa n 3: Sndrome do Estudante Pgina 05
Humor de Projetos
Pgina 08
Referncias geis
Pgina 09
Utilizando Metodologias geis para atingir MPS.BR nvel F na Powerlogic.

Pgina 10
Mtricas e o Desenvolvimento gil.

Pgina 18
OpenUP: Uma Introduo

Pgina 25
Aperfeioamento de Projetos geis

Pgina 29
Cobertura do Java Brasil 2007

Pgina 35
Brincando com a UML em Cores

Pgina 40
Cobertura London Scrum Gathering

Pgina 44
Revista Viso gil Edio 03
Editorial
Ol caro amigo agilista, essa terceira edio muito importante para ns, primeiro por comemorar mais uma edio de nossa revista, e segundo por nos
Equipe Viso gil Diretor Editorial:

Manoel Pimentel Medeiros
possibilitar celebrar junto a voc esse novo que est comeando e que ser muito importante e agitado para toda a comunidade agile no Brasil. Para realmente criar uma edio especial, decidimos fazer um trabalho bem diferente das edies passadas, dessa forma, voc amigo leitor, ter acesso a um nmero maior de artigos, com contedos inditos, ricos e atualizados. Nesta edio, para realmente implementar esse conceito, estamos trazendo vrios temas como: Gesto de Projetos, Modelagem com UML em Cores, Mtricas geis, Open-UP, Aperfeioamento de projetos geis, cobertura do evento Java Brasil 2007 e at do mais importante evento internacional de Scrum, o Scrum Gathering de Londres. Para abrilhantar ainda mais esta edio, temos um completo case sobre a implantao de processos geis para obteno da certificao MPS-BR na empresa PowerLogic, alm claro, das j tradicionais sees de News, Referncias geis e Humor de Projetos. Portanto caro amigo, esperamos que voc goste de mais esse nosso trabalho e, principalmente, queremos que saiba que a Revista Viso gil um espao para a participao e evoluo de toda a comunidade agile no Brasil. Paz e sucesso. Manoel Pimentel Medeiros Diretor Editorial
Diretor de Marketing:
Alexandre Magno Figueiredo
Assessoria Administrativa:
Manuella Bulco Medeiros
Atendimento ao leitor
e-mail: manoelp@gmail.com site: www.visaoagil.com
Edies Anteriores
Qualquer edio anterior pode ser baixada gratuitamente no site www.visaoagil.com
Artigos
Se voc est interessado em ver seus artigos sobre prticas adgis pblicados em nossa revista, por favor envie-os para manoelp@gmail.com para que possamos apreci-los. Sua colcaborao sempre bem vinda.
Publicidade
Se voc est interessado em fazer alguma ao de marketing em parceria da Revista Viso gil, entre contato conosco atravs do email axmagno@gmail.com, e teremos o maior prazer em trabalharmos juntos.
News
Veja aqui as novidades do mundo gil
Treinamento Gerenciamento de Projetos de Software com Scrum, com Alexandre Magno agenda para fevereiro e maro: So Paulo: www.caelum.com.br Porto Alegre: www.aquasoft.com.br
Workshop AGILE IMMERSION em maro de 2008 www.fratech.net
FISL 9.0 - Frum Internacional Software Livre em Porto Alegre em abril de 2008 http://fisl.softwarelivre.org/9.0
Workshop de Gesto e Desenvolvimento gil com FDD em Florianpolis-SC em maro de 2008 www.heptagon.com.br
CHICAGO SCRUM GATHERING em abril de 2008 www.scrumalliance.org
Workshop Modelagem gil com UML em cores e DDD em maro de 2008 www.fratech.net
Artigo

Causa n 3: Sndrome do Estudante
Tradutor: Adail Muniz Retamal
diretor da Heptagon Tecnologia da Informao Ltda, empresa de consultoria e treinamento focada na aplicao da Teoria das Restries em geral, e da Corrente Crtica em particular, Engenharia de Software, metodologias geis de gerenciamento e desenvolvimento de software, Adail Engenheiro Eletricista/Eletrnico, atuou como consultor, instrutor e arquiteto de solues para a Borland Latin America por 4,5 anos. Lecionou em universidades pblicas e privadas. palestrante, articulista e est escrevendo um livro. Adail pode ser contatado em adail@heptagon.com.br.
Autor: Allan Elder

presidente da No Limits Leadership, Inc., uma empresa de consultoria dedicada a ajudar as organizaes a entregar mais projetos, mais rpido, atrves da liderana eficaz.
A Sndrome do Estudante tambm conhecida como procrastinao. A grande diferena a razo para adiar o trabalho. Procrastinar ser preguioso ou irresponsvel. A Sndrome do Estudante um mecanismo de defesa natural. Significa adiar o trabalho at o ltimo momento possvel, no porque somos preguiosos, pelo contrrio, estamos trabalhando duro. Todos camos presas da Sndrome do Estudante ocasionalmente. Ela ganhou esse nome pela forma como os estudantes lidam com o dever de casa. Imagine seu professor dizendo que voc tem uma prova final em 19 semanas. Ele lhe d todo o material, o livro, os objetivos que sero testados e a data. Quando voc comea a estudar? Na vspera da prova. Por qu? Voc tem tempo, por isso. Outras tarefas pressionam mais e, portanto, voc atrasa o incio de uma tarefa at o ltimo momento, para lhe dar tempo de completar outro trabalho, muito provavelmente tambm sendo feito no ltimo momento. Revista Viso gil Edio 03 5
As 5 Doenas do gerenciamento de Projetos
Geralmente as pessoas dizem que no podem estimar com qualquer preciso o quanto uma tarefa ir durar. Eu discordo. A evidncia para esta afirmao que as pessoas realmente sabem o ltimo minuto possvel que elas tm para iniciar uma tarefa, ou arriscar atrasar. Quando foi a ltima vez que voc adiou algo at o ltimo minuto e foi capaz de escolher o ltimo minuto real? Voc trabalhou a noite toda para completar a tarefa e imprimiu o resultado exatamente antes da grande reunio. O papel ainda est morno na entrega, mas voc conseguiu. Esse problema torna-se mais srio quando consideramos as implicao sobre a qualidade. Sim, voc escolheu o ltimo momento possvel para completar uma tarefa, mas qual foi a conseqncia em potencial sobre a qualidade? Se algo desse errado no haveria tempo para consertar. Com qual freqncia voc erra a escolha do ltimo minuto em tarefas importantes? Eu sugiro que raro. Eu sei disso por experincia prpria. Portanto, podemos concluir que a maioria das pessoas realmente sabem o quanto uma tarefa ir levar (dada alguma probabilidade) quando elas podem se dedicar a ela. Se voc quer estimativas mais precisas (mas nunca precisas), identifique a data de entrega e pergunte-se: Se eu iniciar esta tarefa no ltimo minuto, quando isso seria? Agora voc tem a estimativa da durao da tarefa.
Se as pessoas ainda no esto certas sobre o quanto uma tarefa durar, provavelmente porque no sabem quando elas conseguiro todas as entradas necessrias para realmente comear a tarefa, sem ter que parar e coletar mais informao. Isto no um problema. Lembre aos recursos que esto fornecendo as estimativas que voc s est interessado em quanto tempo levar para completar as tarefas sem interrupes, com todas as entradas necessrias disponveis. Depois documente as entradas necessrias para assegurar que no lhes ser pedido que iniciem uma tarefa sem que tais entradas estejam sob sua posse. Seu trabalho como gerente do projeto garantir que eles tenham o que necessrio para realizarem o trabalho deles.
Enquanto voc sobrecarregar as pessoas com tarefas e permitir que elas inflacionem os prazos para acomodar outras tarefas, voc perpetuar a sndrome do estudante. Esse problema ampliado pela multi-tarefa. Ns temos nossa equipe trabalhando em mltiplas tarefas com duraes inflacionadas e esperamos que eles priorizem tais tarefas. Tarefas urgentes tero precedncia sobre as tarefas importantes. Isto encoraja o embutimento de segurana nas tarefas, que fornece mais tempo do que o realmente necessrio, ento atrasamos o incio das tarefas at que tenhamos absolutamente que comear, devido s demandas concorrentes. E o que acontece quando a tarefa realmente encontra um problema? Onde est a segurana? (Uma pergunta melhor seria: Quando a segurana?) Est no passado. No podemos us-la mais (ver Figuras 5 e 6). Note, no desenho, que quando embutimos a segurana ns, mentalmente, colocamos a proteo no final da tarefa. Porm, devido sndrome do estudante, ns no comeamos a tarefa imediatamente e, portanto, comeamos a tarefa tarde.
A dificuldade da estimao das tarefas no conhecer o quanto a tarefa durar, mas chutar quantos outros fatores devem ser considerados, j que sabemos que no nos ser permitido trabalhar na tarefa sem interrupo.
As 5 Doenas do gerenciamento de Projetos
Quando o problema ataca, a segurana com a qual contvamos j no est mais disponvel. Algumas pessoas enfatizam que tudo isto no pode ser verdade. Na verdade, quando minha equipe me fornece uma estimativa eles quase sempre atingem essa estimativa. Isto pode ser verdade. Entretanto, verdade porque uma profecia autorealizvel. A tarefa torna-se vtima das questes mencionadas anteriormente, fazendo com que seja completada como previsto, porque as pessoas querem ser vistas como confiveis. Como voc pode ver, se a tarefa iniciada imediatamente e no h problemas srios, a segurana embutida consumida pela Lei de Parkinson. Se ns no comearmos a tarefa imediatamente e ocorre um problema, a tarefa ser atrasada. Se comearmos a tarefa atrasada (sndrome do estudante) e nada d errado, ns completamos a tarefa no prazo. De um jeito ou de outro, a segurana foi gasta. Esse um tempo que fez com que a durao do seu projeto seja estimada muito alm do que era necessrio. Isso tambm torna seu projeto menos competitivo.
Humor de Projetos
Quem disse que a vida em um projeto no divertida?
http://www.phidelis.com.br
Referncias geis
Veja aqui, alguns sites e blogs indispensveis para o mundo gil
Blog de Danilo Sato, O cara fera, e em seu blog tm muito material sobre XP, Scrum, Arquiteturas, Java e Ruby. URL: www.dsato.com
Site do XProgramming.com, mantido pelo grande Ron Jettries, um verdadeiro Gur que se transformou em uma forte referncia sobre Extreme Programming no mundo inteiro. URL: www.xprogramming.com 9

Autora: Isabella de Araujo Fonseca
Certified Scrum Master, atua desde 1999 como consultora em e-Business para grandes empresas utilizando JEE. Atualmente gerente da equipe de desenvolvimento e de projetos do eCompany Portal - primeira soluo de EIP (Enterprise Information Portal) do pas e do eCompany Process - soluo de definio e controle de Processos Corporativos integrada ao Gerenciamento de Projetos (EPM e APM), de Requisitos e de Produtos (ALM).
Capa
Autora: Ana Cludia Grossi

Oito anos de experincia profissional na rea de tecnologia da informao, atuando em qualidade, configurao, validao, verificao, coletas de medies e auditorias no processo de desenvolvimento de projetos web JEE. Forte atuao na gerncia de Quality Assurance, como garantia de qualidade de produtos, gerenciando equipe de Analistas de Testes, utilizando metodologias como Agile SCRUM e XP.
Autora: Fernanda Alves

Consultora em Gerenciamento de Projetos (APM e EPM) e Processos. Atua em levantamento, anlise, desenho e descrio de processos corporativos para modelos de melhoria de processos utilizando metodologias diversas.
Este artigo apresenta o trabalho realizado na Powerlogic Consultoria e Sistemas para o programa de Melhoria Contnua de Processos MPS.BR Pioneira em mtodos geis, a Powerlogic procurou combinar a agilidade natural destas metodologias e a maturidade adquirida por meio do MPS.BR, constituindo uma experincia concreta na busca de resultados positivos para processos de TI. 1. Introduo A Powerlogic Consultoria e Sistemas uma empresa brasileira, com sede em Belo Horizonte, com 12 anos de existncia atuando no segmento de desenvolvimento de produtos e solues e de servios de fbrica de software. Como projetos piloto para implantao do processo de melhoria contnua da Powerlogic, a rea a ser avaliada, primeiramente, foi a de Produtos (P&D).
10
Como principal objetivo desta iniciativa, a Powerlogic teve seu foco voltado para a melhoria da qualidade do desenvolvimento de seu processo e produtos, conseqente satisfao do resultado apresentado a seus clientes e, tambm, melhores condies de trabalho de seus colaboradores. A alta gerncia, em uma deciso estratgica, optou por estudar e adotar modelos de qualidade, como MPS.BR. Contribuindo tambm para esta deciso figuram o crescimento da empresa nos ltimos anos, o aumento no quadro de funcionrios e diversos projetos sendo executados em paralelo. Desse modo, a Powerlogic procurou padronizar e institucionalizar seu processo visando alcanar patamares mais altos de qualidade para manter o crescimento em escala organizada. A primeira meta alcanada foi a avaliao MPS.BR nvel F. Para tal, um grupo de anlise e estudo dos processos da empresa Software Engineering Process Group (SEPG) foi formado e designado para levantamento do contexto atual. A instituio implementadora escolhida foi a ASR Consultoria e Assessoria em Qualidade, de So Paulo, conhecida por seu trabalho frente implantao e manuteno de sistemas de Gesto da Qualidade. Em junho de 2007, o processo da Powerlogic foi considerado aderente s reas de processo nvel F, tendo sido avaliado em 5 projetos. A prxima meta alcanar o nvel C de maturidade. Os trabalhos sero iniciados em dezembro de 2007 visando aprimorar diversas reas do processo, como por exemplo, Engenharia de Software, de Reuso, Controle de Qualidade, Gerncia de Riscos e, ainda, a melhoria contnua do processo propriamente dito. Este artigo tem por objetivo relatar a experincia da empresa, que iniciou seus trabalhos em meados do Revista Viso gil Edio 03
ano de 2006, estudando o modelo de qualidade, verificando a viabilidade de implantao e adequao s necessidades da empresa, analisando o processo atual, sugerindo melhorias e buscando a reduo de conflitos e melhor retorno de investimento. A seo 2 trata da utilizao de metodologias geis como SCRUM e XP para alcance de certificao nvel F do MPS.BR. A seo 3 apresenta o processo MPS.PLC. A seo 4 trata das melhorias percebidas e impacto nas reas envolvidas e a seo 5 apresenta as consideraes finais.
2. Desenvolvimento Antes de pleitearmos esta avaliao, ainda era possvel encontrar processos pouco formais, mal documentados e planejados. Quase sempre estvamos reagindo, e no planejando. Ao nos depararmos com o mtodo gil SCRUM, houve uma grande identificao. Alguns pontos foram importantes para que decidssemos aplicar em nossa empresa: a dissociao com os processos da Engenharia Civil, o desenvolvimento iterativo e incremental e a premissa de que software funcionando medida de progresso e que isso nos diz mais sobre o andamento projeto do que documentao compreensiva. Problemas como imprevisibilidade, rudos de comunicao, documentaes extensas que pouco ajudam no processo, por exemplo, precisam ser encarados de forma diferente e exigem que no sigamos passos semelhantes entre os diversos projetos existentes, que possuem peculiaridades que apenas com a implementao propriamente dita afloram. Alm disso, tarefas do processo de desenvolvimento de software fazem parte de um processo criativo, no linear e no palpvel, fazendo com que modelos incrementais e iterativos se apresentem como a melhor soluo diante da realidade dos projetos Powerlogic. 11
Novos modelos de processos e mtodos esto sendo estudados e propostos para tentar suprir essas necessidades, tentando organizar o caos existente na maioria dos casos e garantir o sucesso dos projetos, fatos que nem sempre so fceis de alcanar. Mtodos geis como SCRUM e XP e ainda MPS.BR so exemplos destas novas propostas. O SCRUM uma das tcnicas geis que mais crescem no mundo atualmente e pode ser facilmente acoplado a outros frameworks de processo (tais como Processo Unificado), com facilidade, quando necessrio. No h restries quanto adio de formalidades no SCRUM, desde que realizados luz dos valores e princpios do Manifesto da Agilidade. O SCRUM possui trs principais papis: Product Owner, Scrum Master e Scrum Team. O primeiro tem a responsabilidade de definir quais sero as diretrizes principais do projeto (Release) e requisitos de alto nvel (Product Backlog), priorizar de acordo com as necessidades do mercado e aprovar ou reprovar as entregas feitas. ele quem define o Sprint e Release Goal. O Scrum Master o lder do SCRUM e responsvel por garantir que o Scrum Team trabalhe em condies adequadas, removendo impedimentos, solucionando dvidas e assegurando a produtividade de cada membro. Alm disso, deve garantir que o processo definido est sendo seguido e sugerir rea de Gerncia de Processos possveis alteraes no processo. J o Scrum Team, uma equipe auto-organizada responsvel pelo produto gerado ao final de cada ciclo (Sprint), que estima o tamanho de cada requisito (Selected Backlog) a ser implementado e se compromete em atingir o Sprint e Release Goal definidos.
O MPS.BR um programa para Melhoria de Processo do Software Brasileiro, que visa aprimorar a qualidade no desenvolvimento de software das empresas brasileiras. Buscando associar estes conceitos, os princpios e valores de mtodos geis foram relacionados e mapeados em todo o ciclo de vida do software a um ou mais de um princpio do Manifesto da Agilidade verificando sua aplicabilidade. Estes princpios abordam aspectos do desenvolvimento como anlise, projeto, implementao, testes, alm de outros, como gerenciamento de projetos e de mtricas de satisfao do produto final entregue. As reas de processo do MPS.BR foram cuidadosamente relacionadas com as caractersticas dos mtodos geis. Desse modo, foram discutidos gerncia de requisitos, planejamento e acompanhamento de projetos, gerncia de configurao, garantia de qualidade de software e medio e anlise, presentes no nvel F do MPS.BR e sua aplicabilidade ao SCRUM e XP. Merece destaque a constatao de que a adoo de modelos de qualidade de software, como o MPS.BR, traz um maior formalismo ao processo, agregando valor com a qualidade de software desenvolvido. Dessa maneira, temse que, apesar dos modelos de qualidade e metodologias geis possurem fundamentos inicialmente pensados como divergentes, eles puderam facilmente complementar um ao outro e restaurar o equilbrio em nosso processo de desenvolvimento de software. O trabalho inicial executado foi o de levantamento e desenho do processo existente. Descrevemos uma primeira verso do processo, que est sendo melhorado a cada dia e aplicado em projetos para verificao da adequao do mesmo. Melhorias significativas foram percebidas com o processo inteiramente institucionalizado e funcionando em um fluxo contnuo e de fcil entendimento. Atualmente, o processo se encontra na verso PDS_P&D_v18. 12

O produto eCompany Process, desenvolvido internamente em JEE, nos apia no gerenciamento dos projetos e tambm no suporte e anlise de nosso processo para a rea. Toda a documentao do processo se encontra a um clique de distncia para todos os envolvidos. Reunies dirias de 15 minutos so executadas (Daily Scrum) para acompanhamento do projeto. Utilizamos o Agile Radiator, um quadro branco que exibe requisitos (Selected Backlogs) pendentes, em andamento e finalizados para Sprint corrente. Alm disso, ele tambm evidencia os impedimentos e riscos identificados durante o . O plano de projeto (Release Plan) afixado neste mesmo quadro para informaes adicionais do Release e para melhor comunicao entre os envolvidos. O eCompany Process est integrado a um produto de portal corporativo, tambm da Powerlogic, chamado eCompany Portal, formando uma rede de conhecimento de todos participantes do ecossistema corporativo. Paralelamente, nos deparamos com o modelo MPS.BR, que analisado inicialmente, se apresentava muito formal e pouco aderente nossa realidade. Por outro lado, entendemos seus conceitos consistentes, com resultados comprovados e com grande aceitao por toda a comunidade. Poderamos ento continuar com os benefcios do SCRUM e XP e ainda conseguir um nvel de maturidade MPS.BR to sonhado? Como nosso objetivo alar vos mais altos, no poderamos deixar de tentar fazer esta fuso tornar-se realidade. MPS.BR diz o que fazer, mas no impe o como fazer. Metodologias geis so um conjunto de melhores prticas que contm informaes especficas de como fazer e estamos, desta forma, pesquisando, trabalhando e colocando em prtica o que tanto acreditamos. Revista Viso gil Edio 03 13 Esta etapa tem o objetivo de definir a estratgia de atuao do Scrum Team e o planejamento das etapas do trabalho. A partir do planejamento aprovado, podero ser feitos o acompanhamento e o controle do resultado. Dentro do Pre-game, h a definio de um novo Release de um produto baseado na lista de Product backlogs cadastrados para o mesmo, seguido de uma estimativa preliminar de custo e prazo. Os riscos so levantados, identificados e aes apropriadas para minimizar estes so cadastradas. A matriz de restrio utilizada neste momento a fim de que acordos de ajuste sejam estabelecidos, em consenso entre os stakeholders, definindo-se as dimenses que sero priorizadas (Tempo / Custo / Qualidade / Escopo). O Scrum Team definido atravs da identificao das habilidades requeridas para o projeto e posterior consulta matriz de competncia que mapear os recursos adequados. 3.1 - Pre-game
Figura 1 Processo Powerlogic para rea de P&D
3. Processo Powerlogic O processo subdivide-se inicialmente em trs grandes fases, cada uma delas iterativas e com produo de resultado em espiral, acrescentamos tambm algumas atividades no item Monitoramento e Controle que acontecem durante todo o Release desenvolvido.

3.2 - Development Esta etapa tem o objetivo de pr em prtica o plano de ao (Release Plan) estabelecido pelo Scrum Team, Scrum Master e Product Owner. realizada de forma iterativa, atravs de ciclos de "tempo fechado" (Time-Boxed) em 30 dias corridos, que so Sprints, seguidos de 15 dias de testes da equipe de controle de qualidade (QA Team), chamado de Post-Sprint. Em um Sprint, 3.3 - Post-game Esta etapa tem o objetivo de realizar um fechamento e avaliao do Release como um todo, inclusive liberando produto para clientes e refletindo-se acerca das prticas empregadas, indicadores finais e aprendizado em geral. portanto, so executadas atividades de refinamento de requisitos, anlise, projeto, desenvolvimento e testes, devendo resultar em um incremento do produto funcionando para o Product Owner ao final do , na reunio de Sprint Review. A reunio de reviso do ciclo, chamada Sprint Review, realizada ao final de todo Sprint, com a conduo do Scrum Master e participao de Product Owner e Stakeholders. Uma apresentao do produto com as novas funcionalidades feita de modo a demonstrar sua aderncia com o Sprint Goal estabelecido. Este processo se inicia novamente, para cada novo Sprint.
Figura 2
Fase Development
Durante os Sprints, as reunies de Daily Scrum ocorrem diariamente, onde se discutem o trabalho realizado no dia, as tarefas para o dia seguinte e os impedimentos que surgiram. Durante esta reunio, so realizados a redistribuio, reviso e ajustes. Ela visa a atender o acompanhamento e monitoramento do planejado para o projeto. O Scrum Master incumbido de remover impedimentos no prazo mximo de 24 horas corridas. Os riscos so continuamente monitorados e planos de contingncia so definidos.
Nesta etapa, ocorre a reunio de Release Review. Esta reunio consiste em uma demonstrao do produto final do ponto de vista do cliente, discusso com os stakeholders e levantamento de lies aprendidas. A documentao final, CD com o e funcionalidades j testadas so o resultado final desta fase. 3.4 - Monitoramento e Controle O Monitoramento e Controle do Release tm o objetivo de garantir o bom andamento planejado nas reunies de planejamento. Este acompanhamento executado pelas reunies de: Daily Scrum (reunio de acompanhamento do status report do Sprint),
14

Sprint Review (reunio de encerramento do Sprint), Release Review (reunio de encerramento do Release) Retrospective Meeting (reunio de O planejamento da disponibilidade dos recursos levando em considerao impedimentos e horas de Diversos apontamentos, tais como percentual de andamento etc., real, so ou apropriaes continuamente vrias vezes ao de horas trabalhadas, novas verses dos artefatos de cdigofonte, coletados dia). E (diariamente retrabalho j identificados, horas gastas em reunies, atendimentos externos, frias, etc, foi executado. Dessa maneira, foi garantida a participao real de cada membro envolvido. Planejar o planejamento foi um grande benefcio resultante. Identificao e categorizao dos riscos antecipando possveis problemas. Esta prtica proporcionou uma viso mais ampla sob todos os aspectos do projeto (custo, prazo, etc); Alinhamento de metas e planejamento. O Release 4. Melhorias Percebidas At o momento, melhorias significativas foram percebidas em relao ao desempenho do Scrum Team e na qualidade do produto final. Os indicadores criados para as reas de processo Gerncia de Projetos e Gerncia de Requisitos, principalmente, proveram importante feedback para a equipe e criou metas a serem alcanadas por cada um. Eles apiam na tomada de deciso e criam atmosfera Indicadores de de busca de melhoria de contnua. Definio de indicadores do Scrum Team e individuais estimularam o alcance de melhores resultados. (Indicadores de produtividade, percentual de retrabalho e percentual de desvio previsto x real). Gerncia Configurao e Sprint Goals so definidos com o consenso de todos os envolvidos promovendo comprometimento e visibilidade. As estimativas de tamanho dos requisitos so efetuadas pela prpria equipe de desenvolvimento durante as reunies de planejamento. Esta prtica faz com que o planejamento se aproxime da realidade, uma vez que o profissional que executa o mesmo que estima; retrospectiva do Sprint/Release). Para a fase de Pre-game, algumas melhorias se destacaram:
informaes do tipo "previsto x realizado" so disponibilizadas para o Scrum Master, Product Owner e Stakeholders. Quadros brancos mantm as informaes mais importantes disponveis, afixados em local visvel para toda a organizao.
asseguraram que as prticas determinadas foram seguidas provendo maior controle das verses geradas e integrao contnua. prticas de Gerncia de Qualidade para Processo garantem a institucionalizao e desempenho do processo e produtos de trabalho, atravs das Qualidade de Processo, deve nas reas apresentar envolvidas. Ao identificar problemas, a Gerncia de proposies de solues e melhorias, e acompanhar suas deliberaes at sua finalizao. Revista Viso gil Edio 03
Melhorias percebidas para a fase de Development: Gesto a vista via Agile Radiator, provendo feedback real e imediato e reunies de inspeo contnua;
15

A integrao contnua trouxe resultados importantes e informaes essenciais para o planejamento e acompanhamento do projeto. O commit cdigo fonte, associado ao requisito que deu origem, propicia rastreabilidade em ambos os lados. Uma matriz de rastreabilidade foi construda para se obter estas informaes facilitando a anlise de impacto; Menos interrupes para o Scrum Team, visto que o Scrum Master tem a responsabilidade de assegurar que a equipe trabalhe orientada ao Sprint/Release Goal. A equipe fica focada e consegue Impediment entregar o combinado. Conceito Backlogs proporcionando Melhorias percebidas durante a fase de Development, mas aps o fim de cada Sprint: Reunio de Retrospective Meeting, onde ocorre a coleta das lies aprendidas do projeto. Avalia-se o que deu certo (What went well WWW) e o que deu errado (What can be improved) alimentando o projeto e tambm o processo; Reunio Retrospective Meeting 2, onde se avalia se algo est sendo feito com relao ao que foi levantado durante o primeiro Retrospective Meeting. Sabe-se onde est e aonde quer chegar. A definio em consenso do Sprint/Release Goal possibilita melhor visibilidade e norteia o caminho a seguir para cada envolvido.
identificao e gerncia de interrupes e apropriao correta nestes itens pelo Scrum Team; Retrabalhos so abertos pelo QA Team mediante aprovao do Scrum Master. So considerados requisitos emergenciais garantindo a estabilidade do produto; Reunies de reestimativa (Estimating
Melhorias organizacionais percebidas: Gerncia de Qualidade de Processo: esta nova rea criou uma zona de desconforto sadia, fazendo com que as pessoas dem o melhor de si e concretize aes para o objetivo maior organizacional. Ela prov apoio total conduo dos projetos, executa a manuteno do processo, aceitando sugestes e inserindo melhorias necessrias e executa auditorias para garantia da execuo do processo; Gerncia de Configurao: esta rea garante a integridade dos itens de configurao do Release, apia a gerao de baselines e integrao contnua;
Meetings) e de elucidao de requisitos (FollowUp Meetings) ajudam na execuo dos requisitos pelo Scrum Team; Integrao de equipe: conceito de pilha entre requisitos estimulando a troca de conhecimento, uma vez que o requisito no possui dono. Cada membro pode executar atividades de mdulos diferentes, utilizando Pair Programming quando necessrio. O conceito de cdigo compartilhado tambm importante, dado que o mesmo ser modificado/revisado por diferentes recursos; Revista Viso gil Edio 03
16

5. Consideraes Finais Este artigo apresentou parte da experincia vivida pela Powerlogic no processo de implantao do programa de qualidade de desenvolvimento de software MPS.BR, inspirado pelas escolas geis, em especial o processo SCRUM. Foi apresentada parte do processo e evidenciadas as melhorias percebidas para as reas envolvidas aps a institucionalizao do mesmo. Situaes pouco previsveis e surpresas desagradveis durante o processo de desenvolvimento de software so, infelizmente, comuns. Entretanto, no h como evitar os casos fortuitos. A empresa busca o aprendizado tambm com os erros, com poucos desvios. Apresentar resultados continuar sendo importante, mas esperase estar ligado tambm qualidade, que tambm produz resultados e traz consigo trabalho bem feito, maior produtividade e organizao. Dessa forma, como prximo passo, est a avaliao para obteno do nvel C do MPS.BR a ser realizada em um prazo de 18 meses a partir de dezembro de 2007. CMM Referncias Bibliogrficas Agile Alliance, 2002. Agile Manifesto,
http://www.agilealliance.org Boehm, B., Get Ready for Agile Methods, with Care, Computer, 35, 1 (January 2002) 64-69. Paulk, M. C., Extreme Programming from a Perspective, IEEE Software, 18, 6 (November/December 2001) 1-8. Schwaber, K., Scrum Development Process, in OOPSLA Business Object Design and Implementation Workshop, J. Sutherland, et al., Editors. 1997, Springer: London. Schwaber, K; Beedle, M, Agile Software
Development with Scrum, Prentice Hall, (October 2001). Takeuchi, H. and I. Nonaka, The New New Product Development Game.Harvard Business Review, 1986(January-February).
17
Artigo
Mtricas e o Desenvolvimento gil
Autor: Victor Hugo Germano Bacharel em cincia da computao pela Universidade federal de Santa Catarina, especializado em Gesto estratgica de TI. Atualmente trabalhando na empresa Audaces auxiliando no processo de adoo de metodologias geis.
Introduo
Devido ao custo elevado em se manter um departamento de TI (profissionais caros e equipamentos mais caros), so necessrias formas de se garantir que o investimento feito esteja realmente gerando o resultado esperado. Infelizmente, medida que nos aprofundamos no assunto, seguindo modelos tradicionais de desenvolvimento e desempenho, verificamos que falta clareza na utilizao de ferramentas de mensurao, e que estamos a todo momento medindo aquilo que no importante, deixando de lado o que realmente justifica a utilizao da TI: a agregao de valor ao negcio. Isto : garantir que a organizao que suporta uma equipe de TI - seja atravs de um projeto ou estrutura empresarial - consiga obter vantagens competitivas atravs dos insumos gerados pela rea tecnolgica Revista Viso gil Edio 03 18
Ao invs disso, o foco das mtricas tradicionais est em atributos de software e consumo oramentrio. Podemos citar: pontos de funo criados, horas trabalhadas, nmero de linhas de cdigo por desenvolvedor ou ainda oramento gasto. Tais mtricas so reflexo da dificuldade que as empresas possuem em determinar o que deve ser medido na rea de TI, e superestimando o valor de tais itens cria-se uma viso mope de um projeto. Pontos de Funo so a tentativa de encontrar uma medida universal de complexidade para projetos. Isto , interpretando os requisitos de um sistema poderamos encontrar o seu tamanho real, assim como pode-se determinar com exatido a distncia entre So Paulo e Porto Alegre em kilmetros, por exemplo. Esta proposta assume que se saiba de antemo todo o escopo de um projeto, e exige que se estipule tudo que o sistema pode fazer antes de determinar sua quantidade de Pontos de Funo. Isto vem de encontro real ao Desenvolvimento gil, que assume escopo de um sistema como sendo uma entidade mutvel, e incentiva a adaptao mudana em detrimento da previsibilidade e dos problemas relacionados tentativa de definir como claramente linhas de um escopo.
pletamente ao trabalhar mais do que o necessrio, criando dificuldades de relacionamento e de participao no projeto, bastante contrria prtica Semana de 40 Horas do XP, que faz aluso tentativa de encontrar a causa raiz dos problemas antes de trabalhar alm do horrio, evitando cometer um erro para corrigir outro erro. Perceba a complexidade que criar e fomentar tais medidas. Seguindo o modelo taylorista de gerncia, assumimos a necessidade de mensurar individualmente performance, e utilizar indicadores individuais para cobrar produtividade de indivduos de uma equipe, comparandoos com aqueles com as melhores marcas. Infelizmente os resultados podem ser desastrosos. Uma equipe deve possuir uma identidade nica, que projetada ao mundo externo como reflexo de seu comprometimento com o projeto, e no como uma srie de indivduos que trabalham por si em detrimento do grupo. comum nestes casos que problemas de relacionamento ocorram dentro da prpria equipe por causa da competio gerada para saber "quem o melhor".
As Ferramentas geis
A definio de sucesso, particularmente nos dias de hoje, Medidas cdigo por em funo da habilidade da equipe ao reagir mudana, no a capacidade de seguir um plano. A forma com que as equipes so medidas influencia diretamente em sua adaptabilidade. Adaptao ao invs de aderncia traz sucesso. Jim Highsmith
desenvolvedor ou horas trabalhadas sempre levam a problemas maiores. Um programador, quando cobrado em linhas de cdigo, evitar qualquer tipo de reutilizao ou refactoring para passar a impresso de ser produtivo quando na verdade ele est ampliando ainda mais a complexidade dos sistemas em que trabalha, dificultando sua manuteno. Ou ainda ele poder degradar-se com-
19
Tradicionalmente encaramos projetos atravs da trindade custo - escopo - prazo. E realmente, por muito tempo tais indicadores foram os principais medidores de performance. No existia a necessidade de mensurar o valor de negcio entregue ao trmino de um projeto, nem mesmo o quo saudvel sua execuo foi para a equipe. Entretanto, se quisermos alcanar os maiores benefcios do Desenvolvimento gil, necessrio ampliar este modelo encontrando formas mais adequadas de indicar sucesso e incentivar nossas equipes a se tornarem mais produtivas. Por isso o foco concreto na comunicao aberta e adaptao atravs do feedback. Alm, obviamente, das mtricas de produtividade. Baseado demonstrou conhecimento a no Efeito Hawthorne, de produtividade que de
Modelos geis em sua concepo j promovem um jogo completo de mtricas que podem ser coletadas de forma transparente. Testes unitrios, anlise da qualidade de cdigo e outras medidas tcnicas podem ser inclusive automatizadas no processo de Integrao Contnua. A unidade comum de trabalho - a histria - o fundamento para medidas de gerenciamento de projetos e qualidade de alinhamento de negcio. importante lembrar que todo o ferramental existe para dar suporte tomada de deciso, identificando o mais rpido possvel desvios e corrigindo o curso de um projeto. No escreva, mostre!! Fato: somos serem visuais. A compreenso que temos do mundo est associada forma que o enxergamos medida que ele evolui. Nos esquecemos, em nossos projetos, da importncia de apresentar informaes de forma visual a todos os envolvidos. Ao invs disso, restringe-se o acesso a informaes vitais de progresso, num modelo de alienao claro, que apenas inibe o comprometimento. Na tentativa de controlar todos os procedimentos de um projeto, nos afogamos em diagramas complexos, documentaes que muitas vezes servem como justificativas, caso fracassemos.
mudana de tal
trabalhadores atravs do simples fato deles terem medio, Mike Griffths apresenta a idia de que mtricas efetivas no devem, em nenhum momento, atrapalhar a qualidade do projeto (medir linhas de cdigo no o caso!), e deve estar direcionado a elementos chave para o desenvolvimento. seguinte reflexo: Donald Reinertsen prope a
Primeiro, deve ser simples, mtricas ideais so geradas automaticamente no sentido de que no necessrio esforo extra para serem produzidas. Segundo, devem ser relevantes. Isto , o controle deve ser feito pelas mesmas pessoas que esto sendo medidas. Psiclogos j descobriram que quando as pessoas acreditam que podem controlar alguma coisa, elas estaro mais motivadas para control-la. Mensurar uma equipe por algo que ela no tem controle apenas causar estresse, insatisfao e alienao. Terceiro, deve ser focado em indicadores de conduo. Mea olhando para o futuro, e utilizando tais dados para relatar o passado. mais fcil medir o tamanho de uma fila de testes do que medir o tempo de processamento dos testes individuais pelo fato de que o tamanho da fila um indicador de conduo para futuros atrasos no processamento do teste.
20
Enquanto isso, no incomum encontrar dentro de um projeto expresses do tipo: "Mas agora j tarde demais! No podemos refazer o cronograma e o oramento...". Os Mtodos geis tentam transformar a avaliao de um projeto em uma atividade diria, realizada por toda a equipe, evitando que riscos e problemas sejam ignorados por meses de desenvolvimento. Muito mais difcil esconder problemas dentro de um projeto gil, uma vez que o fluxo contnuo de valor deve ser estabelecido. Como forma de ampliar a comunicao e a colaborao da equipe, propomos um ambiente de trabalho que possa refletir de maneira clara, objetiva e aberta, os resultados e progressos de um projeto. Mais do que frequentemente voc perceber em ambientes geis inmeros quadros e post-its na parede. Existe muita relevncia nesse modelo de apresentao, e uma vez que a equipe responsvel pelo sucesso de um projeto, cabe a ela a funo de avaliar problemas e tomar as devidas decises corretivas mitigando problemas.
Alm do grfico Burndown que trataremos abaixo, existe ainda uma curva indicando tarefas no planejadas. Do lado direito do quadro, existem os espaos para divulgao das tarefas a serem realizadas em uma iterao. So subdivididos em atividades planejadas e no planejadas para a iterao, e a indicao de quais destas esto finalizadas. No canto extremo direito, h uma pequena tabela com as atribuies de cada integrante da equipe, que atualizada atravs das reunies dirias.
Entenda como funcionam grficos no Desenvolvimento gil:
BurnDown O grfico Burndown bastante associado ao Scrum, e o impacto causado nas equipes nas primeiras utilizaes bastante motivador. Simples e direto, o modelo uma relao entre Esforo Estimado para uma iterao e sua completude atravs do tempo. No grfico abaixo, so apresentadas duas linhas: a azul apresenta a quantidade de esforo que necessrio para finalizar todas as funcionalidades, servindo como uma linha mestra equipe. Diariamente o grfico ser atualizado e as funcionalidades finalizadas tero seu valor desenhado no grfico, apontando o real estado do desenvolvimento em comparao estimativa original.
A imagem acima foi retirada do ambiente de desenvolvimento da empresa Audaces Automao Industrial. Aps alguns ciclos, de forma adaptativa a equipe construiu um quadro que correspondesse a suas necessidades de exposio de resultados. Revista Viso gil Edio 03
21
CFD - Cumulative Flow Diagrams
Funcionalidades completas versus funcionalidades restantes uma mtrica vital. Ao trmino de um dia de trabalho, a quantidade de funcionalidades geradas e no o nmero de linhas de cdigo ou pontos de funo que geram valor para o cliente. "Funcionalidades Completas" significam aceitas pelo cliente (ou seu proxy) - no apenas codificadas e testadas - j que no agregam nenhum valor at o momento que estiverem completamente finalizadas (pronto igual a pronto mesmo!). Na verdade, cdigo escrito e no aceito pelo cliente considerado inventrio, e Ainda num projeto Scrum, a equipe seguindo os princcios do Lean Thinking, isto puramente desperdcio. Complementar ao BurnDown Chart do Scrum, trazendo a relao de requisitos completos, requisitos restantes e requisitos em desenvolvimento, segue abaixo um modelo do grfico chamado Cumulative Flow Diagram acompanha seu progresso sobre o planejamento inicial do projeto ao trmino de cada Sprint. O eixo horizontal do Projeto ou Release do grfico abaixo apresenta as Sprints; o eixo vertical nos mostra a quantidade de trabalho restante ao incio de cada ciclo. Tal trabalho restante pode ser apresentado em qualquer unidade de medida que a equipe desejar: story points, dias ideais, complexidade,etc.
22
No exemplo acima, o progresso indicado pela completude da faixa verde no decorrer do projeto. Importante notar a mudana de proporo relacionada faixa superior, indicando aumento de User Stories no decorrer do projeto. Esta mudana pode indicar um problema relacionado comunicao entre produto e desenvolvedores. Parking-Lot Chart A idia utilizar agrupadores para reunir requisitos com o mesmo domnio e montar um grfico contendo Domnio, Nmero de histrias em cada domnio, nmero de pontos de histria e a completude. Teve sua origem no modelo de desenvolvimento Feature Driven Development. As cores do grfico apresentam onde o progresso est sendo feito, reas de preocupao e itens no iniciados. Pode-se ter uma viso bastante real do estado atual do projeto, sendo eficiente para apresentaes em reunies de status, mostrando diretoria uma fotografia dos principais pontos do projeto, facilmente organizado em uma folha A4, assim como Carlos Slim, homem mais rico do mundo, acredita ser o imprescindvel para a tomada de deciso. Brent Barton, Dan Rawsthorne e Ken Schwaber apresentam um modelo bastane ilustrativo de como um grfico desse tipo deve ser confeccionado. As cores so importantes pois indicam posies em que se deve tomar mais ateno ou ainda a finalizao de um domnio todo.
23
TF: Running, Tested Features Representa a quantidade de requisitos que esto passando em todos os testes de aceitao. facilmente gerado utilizando ferramentas automatizadas de teste. O raciocnio simples, e idealmente deve parecer com a imagem abaixo:
Um dos princpios do desenvolvimento gil justamente garantir que software em funcionamento seja entregue ao cliente, ampliando a agregao de valor. Podemos encarar o fato de construirmos softwares com bugs tambm como desperdcio, j que problemas no desenvolvimento no agregaro valor ao cliente e causaro retrabalho da equipe, evitando novamente que sejam entregues funcionalidades nas prximas iteraes. Alm disso, mudanas nos requisitos ou histrias podem ter um significado positivo ou negativo. Positivo quando cliente est mais experiente e est aperfeioando as estrias, garantindo que a equipe possa ampliar o conhecimento do processo de negcio. Mas muitas mudanas podem significar que o projeto esta instvel, que se deve gastar um pouco de mais tempo na hora de descrever uma estria e elucidar requisitos. Com a inteno de identificar algum possvel erro na entrega de valor pela equipe, apresento do grfico abaixo, intencionalmente desenhado manualmente por Ron Jeffreis.
Tambm conhecido como Burn-Up chart. Qualquer anomalia no comportamento desta imagem deve ser encarada como um problema, j que, teoricamente, os requisitos implementados devem passar em todos os testes. Evoluo, Defeitos, Mudanas No decorrer de um projeto alguns defeitos podem ser encontrados. Mesmo utilizando todas as tcnicas geis que favorecem a produo de sistemas com melhor qualidade, seria ingenuidade acreditar que Bugs no aparecero. Sendo assim, importante aferir o quanto de trabalho est sendo despendido na correo de problemas no desenvolvimento. Bugs podem significar que a aceitao de testes pelo usurio est em falta ou mesmo o processo de engenharia de software necessita ser revisto. Talvez seja necessrio utilizar mais a fundo o TDD.
Concluses Mtricas so necessrias, sejam para cobrar ou avaliar o progresso dos projetos. O principal benefcio de utiliz-las em projetos geis ter informaes o mais rpido possvel, de maneira objetiva e clara, ajudando a tomada de deciso. Logo nas primeiras iteraes de um projeto j possvel ter visivelmente idia de quais so os problemas, e no haveria assim espao para justificar fracassos e riscos desconhecidos. Entretanto, preciso mudar conceitos sobre o que deve ser medido, e de que maneira esta mensurao no afetar o trabalho da equipe. Valorize acima de tudo a comunicao direta entre equipe e gerncia, tirando o melhor proveito da utilizao do Desenvolvimento gil. 24
Artigo
Autor:Jos Papo
Jos Papo engenheiro de software e mestre em engenharia de computao pelo IPT. Professor da graduao e ps-graduao na Universidade So Judas Tadeu. Possui as certificaes IBM Certified Solution Designer Rational Unified Process V7.0, IBM Certified Specialist for Requirements Management w/Use Cases, IBM Certified Solution Designer Object Oriented Analysis and Design vUML 2, I BM Rational Solution Sales Professional, Certified Scrum Master, ITIL Foundation Certified Professional e OMG UML 2.0 Certified Professional.
OpenUP Uma Introduo OpenUP um processo enxuto, baseado no Unified Process, que possui um ciclo de vida iterativo e incremental. O OpenUP tambm foi elaborado como uma filosofia gil, pragmtica e que foca na natureza colaborativa do desenvolvimento de software. um processo de baixa cerimnia e que no indica nenhum tipo de ferramenta especfica. Uma das caractersticas visveis do OpenUP que a disciplina de gesto de projetos uma adaptao do Scrum (processo gil emprico com foco nos aspectos de gesto de projetos, sem entrar em detalhes da engenharia de software).
25
O OpenUP possui princpios (isto , se voc no seguir um dos princpios voc no est na realidade adotando o processo como se deve) semelhantes verso 7 do RUP. Eles so: Balancear prioridades competidoras para maximizar o valor aos envolvidos do projeto.
Micro-Incrementos O esforo de cada membro da equipe organizado em micro-incrementos. Estes representam pequenas quantidades de trabalho que produzem uma continuidade mensurvel de progresso do projeto. Um micro-
incremento pode representar o resultado de algumas horas ou de alguns poucos dias de trabalho para uma pessoa, ou para um grupo de pessoas trabalhando colaborativamente. Cada micro-incremento deve ser bem definido para que a equipe possa monitorar e controlar o progresso dirio. Cada micro-incremento especificado em um item de trabalho (work item). Essa uma das diferenas de outros processos como o RUP e o Scrum. Todos os requisitos e atividades do projeto OpenUP sero associados a um item de trabalho. No existe diviso entre fluxos como caso de uso, cenrio, mudana e defeito. Como esses requisitos e atividades podem ser grandes, possvel dividir um item de trabalho em vrios itens de trabalho menores, at ficar com um nvel de granularidade aceitvel (de preferncia no ultrapassar trs dias).
Colaborar
para
alinhar
interesses
compartilhar entendimento.
Focar cedo na arquitetura para minimizar riscos e organizar o desenvolvimento. Evoluir para continuamente obter feedback e melhorar. O OpenUP pode ser mais facilmente
entendido atravs dos seus ciclos de visibilidade, representados na figura 1. Vamos falar sobre cada um deles separadamente, na seqncia do ciclos mais curto at o ciclos mais longo, para dar uma viso clara de como a vida em um projeto OpenUP.
Vamos a dois exemplos concretos:
Definir a Viso do Produto uma atividade que pode levar vrias semanas. Para assegurar a monitorao do progresso dirio voc deve dividir esse item de trabalho em itens de trabalho menores. Identificar de trabalho os Envolvidos do projeto bons e Identificar as restries seriam dois desses itens que representam microincrementos.
Figura 1 Ciclo de Vida do OpenUP (Fonte: OpenUP verso 1.0)
26
Implementar a soluo uma atividade que pode levar muito tempo se for baseada em casos de uso ou mesmo cenrios de caso de uso. Para assegurar o progresso contnuo mais interessante dividir esse item de trabalho em vrios micro-incrementos. Uma forma poderia ser criar um item de trabalho menor para projetar e implementar um subfluxo ou apenas um passo de um caso de uso ou cenrio.
Cada iterao deve iniciar com uma reunio de planejamento de iterao. Toda a equipe deve participar. Esse perodo deve durar de um a dois dias e j elabora tambm detalhes arquiteturais de alto nvel, bem como a ordenao e o detalhamento dos itens de trabalho em micro-incrementos. Depois desse perodo a equipe executa a iterao. importante lembrar que o time deve utilizar a integrao contnua e builds dirios.
Para fornecer ainda mais disciplina, um build A aplicao evolui atravs da execuo de vrios itens de trabalho simultaneamente. A equipe utiliza tcnicas de reunies dirias e tambm ferramentas de colaborao para conseguir transparncia no trabalho de equipe. Ao mesmo tempo, progresso contnuo demonstrado atravs da integrao contnua de micro-incrementos durante cada dia do projeto. estvel semanal deve ser produzido. Uma ateno maior dos analistas de testes deve se concentrar nos builds semanais. Nos ltimos dias de uma iterao o foco deve ser na correo de defeitos do incremento executvel. A iterao termina com uma avaliao do que foi construdo versus o objetivo planejado no incio da iterao. A equipe tambm realiza uma retrospectiva para obter lies aprendidas da iterao e melhorar aquilo que no funcionou to bem durante a iterao. Ciclo de Vida da Iterao As iteraes no OpenUP tm como objetivo primordial focar a equipe na entrega de resultados de valor aos clientes, a cada ciclo curto de algumas semanas (o tempo de iterao varivel, mas o OpenUP recomenda iteraes de 2 a 6 semanas). No final de cada iterao a equipe, obrigatoriamente, deve entregar um build executvel do software, j implementado e testado. Este build conter um incremento do produto. Os processos de planejamento, estimativa e monitoramento do progresso de cada iterao se baseiam nos itens de trabalho. O plano de iterao corrente costuma incluir sempre os itens de trabalho de maior prioridade. Revista Viso gil Edio 03 27 O OpenUP, como outros processos geis, valoriza muito times auto-organizados. Isto significa que a equipe como um todo responsvel por organizar o trabalho e determinar como melhor atingir seus compromissos. Transparncia, comunicao aberta e comprometimento pessoal so fundamentais para a auto-organizao funcionar. O OpenUP assume que o gerente de projetos atue mais como um lder educador, um lder servidor e um coach. Ele, portanto, deve eliminar o estilo chefesubordinado de seu paradigma.
Ciclo de Vida do Projeto O OpenUP organiza um conjunto de
OpenUP Futuro O OpenUP apenas o processo mais famoso dentro de uma famlia de processos sendo desenvolvida. J existem disponveis as extenses OpenUP/XP, OpenUP/Scrum e OpenUP/DSDM. Alm disso, ser possvel adicionar plug-ins ao OpenUP para enderear questes como arquitetura orientada a servios (SOA), arquitetura dirigida a modelos (MDA), desenvolvimento de sistemas embutidos, J2EE, .NET, entre outros. A verso futura do RUP ser nada mais que um empacotamento do OpenUP e toda uma srie de plug-ins adicionais que permitiro ao engenheiro de processos customizar o processo de sua empresa de acordo as necessidade especficas de cada projeto. Experimente o OpenUP. Faa o download ( gratuito) e aproveite a oportunidade de usar um processo gil que utiliza os conceitos do processo unificado, j muito difundido no mercado brasileiro.
iteraes em fases. Essas fases possuem o mesmo nome das fases contidas no Processo Unificado (Unified Process) e no Rational Unified Process (RUP). Cada fase termina com um marco, que possui como objetivo mitigar um determinado tipo de risco tipicamente importante para os envolvidos do projeto:
Iniciao: eliminar riscos relativos ao caso de negcio do projeto. Elaborao: eliminar riscos arquiteturais e tcnicos do projeto. Construo: eliminar riscos de no construir as funcionalidades prioritrias do ponto de vista dos envolvidos. Transio: eliminar riscos de homologao, testes beta, implantao do sistema em produo e migraes de sistemas legados.
Portanto, as fases do OpenUP nada mais so que marcos para reduo de riscos. Conforme mostra a figura 2, o OpenUP busca reduzir o risco logo no incio do projeto ao mesmo tempo que agrega valor.
Link para o Eclipse Process Framework: http://www.eclipse.org/epf/
Link direto para o OpenUP: http://www.eclipse.org/epf/downloads/openup/openup_downlo
Figura 2 Reduo de risco e gerao de valor durante o ciclo de vida do projeto OpenUP (Fonte: OpenUP verso 1.0)
28
Artigo

Parte I: Uma Viso Sistmica
Autor:Alisson Vale
Tem mais de 15 anos de experincia com desenvolvimento de software e a mais de 6 anos lidera projetos de software dos mais variados tipos e tamanhos. Hoje Lder de Projeto e Diretor da Phidelis Tecnologia, onde lidera a equipe de desenvolvimento da soluo acadmica oferecida pela empresa.
E-mail: alisson.vale@phidelis.com.br Weblog: http://www.phidelis.com.br/blogs/alissonvale
A essncia do funcionamento de um projeto gil est na sua capacidade de aprender e de se adaptar com esse aprendizado. A maioria das metodologias geis estabelece prticas que nos ajudam a ampliar essa capacidade em nossos projetos. A prtica mais comum o uso de sesses conhecidas como Retrospectivas. Mas ser que estamos preparados para ir alm e entender os princpios que esto por trs dessa prtica? Nesse artigo, escrito em duas partes, eu convido o leitor a pensar sobre melhoria contnua e sobre os vrios aspectos que cercam o tema.
29
Na teoria darwinista, a adaptao evolutiva o instrumento de sobrevivncia das espcies em ambientes altamente competitivos. Ela lhes atribui a capacidade de se adequar aos mais complexos cenrios para preservao da vida. O processo de seleo natural, se analisado sob o ponto de vista sistmico, resulta no aperfeioamento contnuo das espcies por meio da execuo de um incomensurvel nmero de ciclos de vida e morte, onde caractersticas adquiridas ao longo do tempo so postas prova. Dentre tais caractersticas, as que influenciarem positivamente a sua capacidade de sobrevivncia so naturalmente absorvidas, enquanto que as que impactarem negativamente nessa capacidade sero descartadas. A espcie adquire, assim, conhecimento, habilidades, memrias e influenciada por um longo comportamentos,
Alis, correes sistemticas de pequenos erros cometidos devido a falsas suposies so, para o mtodo gil conhecido como Adaptive Software Development (Highsmith, 2000), a chave para o funcionamento dos seus ciclos de especulao, colaborao e aprendizado. A palavra Especulao, nesse mtodo, j d o tom necessrio para a compreenso de que um ciclo se inicia com base em algo pouco conhecido (Especulao); que trabalhado colaborativamente (colaborao); e que se tornar muito bem conhecido ao seu final (Aprendizado). No contexto do aperfeioamento contnuo, a percepo adequada desse entendimento gira em torno de saber que para ter um processo que seja melhor hoje do que ontem, necessrio (1) especular sobre algo que precisa ser melhorado conquistada. O Manifesto gil (AgileAlliance, 2001) enderea a questo do auto-aperfeioamento ao afirmar que um time de projeto deve refletir, em intervalos regulares, sobre como ser mais efetivo, e assim afinar e ajustar seu comportamento apropriadamente. Todo incremento, iterao ou liberao de release cria, para a equipe de projeto, uma grande oportunidade de recomeo. Recomeo leva ao aprendizado, e aprendizado leva melhoria. A maioria dos mtodos, metodologias e frameworks geis tambm estar estabelecendo suas prticas e definindo suas idias sobre melhoria contnua. Processos baseados em Extreme Programming ou Scrum, por exemplo, utilizam as chamadas Reunies de Retrospectiva para discutir e deliberar sobre o qu funcionou e o qu pode melhorar. Alistair Cockburn sugere Workshops de Reflexo(Cockburn, 2001) como prtica para o estmulo melhoria contnua em sua famlia de metodologias conhecida como Crystal. (2) colaborar para que tal melhoria seja alcanada e (3) aprender e incorporar a melhoria
processo de aperfeioamento e adaptao contnua. Certamente, o mais fantstico processo de autoaperfeioamento conhecido hoje pela cincia. A adaptao e o aperfeioamento contnuo geram um processo evolutivo que emerge das relaes sistmicas dos organismos com o seu meio ambiente. tambm Em projetos geis, seus processos emergem das relaes sistmicas
estabelecidas entre as pessoas envolvidas no projeto (stakeholders) e o seu meio de negcio. A capacidade de adaptao elemento essencial de diferenciao do modelo gil em relao aos processos tradicionais para desenvolvimento de software. Os pequenos ciclos de avaliao e aprendizado que o compe desafiam equipe e cliente a evolurem seu processo por meio da deteco, anlise, correo e absoro sistemtica de conhecimento sobre erros, ineficincias ou falsas suposies encontrados durante seu tempo de vida.
30
Outras
propostas
geis
como
Deming acreditava que o aperfeioamento contnuo era um mecanismo-chave para gerar a necessria vigilncia constante no s na qualidade do que est sendo produzido, mas tambm no rendimento do sistema produtivo. Ele tambm inovou ao propor que os mecanismos de melhoria sobre o processo de trabalho deveriam estar nas mos de quem executa o trabalho, no somente de quem o gerencia ou o supervisiona. Assim, responsabilidade de toda a equipe participar dos processos de obteno de mtricas, identificao e anlise de problemas e do planejamento e execuo das aes de melhoria planejadas. Deming tambm foi um dos primeiros a propor o Ciclo de Schewart (mais conhecido como o ciclo PDCA) como instrumento prtico para viabilizar o modelo de aperfeioamento contnuo. Em um projeto gil, o ciclo Plan-Do-Check-Act se manifesta de vrias maneiras diferentes. Nesse tipo de projeto, aperfeioamento e adaptao so uma necessidade. O PDCA o instrumento base para a conduo desse processo. No PDCA, a equipe precisa: (1) Planejar: identificar e analisar os problemas, planejar aes para resolv-los (2) Fazer: executar aes para resolv-los (3) Checar: medir e verificar a eficcia das aes executadas (4) Agir: adaptar o plano de melhorias, incorporando no s as melhorias obtidas, mas tambm o novo aprendizado obtido.
DSDM(DSDMConsortium, 2007), OpenUP (The Eclipse Foundation, 2007) e MSF for Agile Software Development (Microsoft Corporation, 2006) explicitam como princpio bsico de trabalho a melhoria contnua. O OpenUP recomenda como prtica fazer perguntas e verificar suposies sobre o projeto regularmente. O Agile MSF estabelece como princpio a idia de aprender com todas as experincias. A aplicao desse princpio leva a projetos que permitem a seus membro se beneficiarem de lies aprendidas por meio do cometimento de erros, e por meio da repetio de prticas de sucesso. Seja qual for a tcnica utilizada, na prtica o processo de melhoria contnua gira em torno de, dentre outras coisas, buscar melhores maneiras de (1) aumentar a quantidade do tempo em que a equipe est envolvida com atividades que geram valor para o cliente por meio de software funcional; e (2) de aumentar a qualidade do tempo em que a equipe est envolvida com atividades que visem garantir as condies de segurana, estabilidade funcional, compreensibilidade e manutenibilidade do software que est sendo desenvolvido.
As Origens A idia do aperfeioamento contnuo Retrospectivas: PDCA na Prtica A prtica de definir uma reunio cclica, ao fim de cada iterao do projeto, para discutir estruturadamente sobre como melhorar o processo ilustra bem o PDCA.
remonta a meados da dcada de 1950 quando Edward Deming, estatstico americano, levou seu modelo de produo orientado pela qualidade para a indstria japonesa(Deming, 2003).
31
Em uma Reunio de Retrospectiva de um projeto gil, comum o uso de tcnicas para identificar, priorizar, analisar, definir problemas e sugerir aes que gerem melhorias para o processo. A tcnica mais utilizada consiste em se usar uma folha de flip-chart ou um quadro branco onde se desenha duas grandes reas: uma para identificao do qu funcionou bem, onde a equipe cola post-its que identificam prticas, ferramentas ou atividades que geraram bons resultados durante a iterao; e uma outra para identificao dos pontos que poderiam ser melhorados, onde outros post-its indicaro problemas ou dificuldades percebidos pelos vrios membros da equipe durante a iterao. Dentre os problemas elencados, a equipe pontua, por meio de votos e discusso, aqueles problemas que cada um acha terem o maior impacto para o rendimento do projeto como um todo. Isso importante, pois os membros da equipe devem votar no problema que eles entendem afetar mais o projeto naquele momento, no naqueles problemas que afetam mais o seu prprio trabalho. Os problemas mais votados, sero aqueles que obtero uma maior ateno da equipe no prximo ciclo. Por fim, a equipe discute e planeja as aes que sero tomadas para resolver os problemas encontrados. O PDCA com instrumento de
A fase Do ocorre no ciclo seguinte quando a equipe tenta realizar as aes planejadas. O Check se dar na prxima reunio de retrospectiva, quando as coisas boas e os problemas sero novamente discutidos. Mesmo que o problema no tenha sido solucionado, ele agora revela-se mais bem conhecido. O elemento Act se manifesta quando a equipe absorve esse aprendizado, discutindo novas solues, mudando sistematicamente sua maneira de enxergar o mesmo problema. Em projetos geis, o padro sistmico de adaptao e aperfeioamento que faz a equipe controlar o processo, evitando que o processo controle a equipe. Entender o ciclo PDCA e identificar seu funcionamento dentro do projeto fundamental, pois ele estabelece esse padro sistmico cujo resultado a incorporao de pequenos elementos de controle sobre a complexidade do projeto. o padro que garantir a sustentabilidade do projeto a longo prazo.
Entendimento sistmico Um engano comum em projetos geis a viso de que a melhoria contnua visa apenas aumentar a produtividade do time como um todo. Eu diria que isso apenas parte de uma abordagem mais ampla. A Toyota, por exemplo, enxerga o rendimento de um sistema (no nosso caso de um projeto) segundo uma rede complexa de influncia dos chamados elementos de avaliao primrios: qualidade, produtividade, custo, segurana e atendimento ao cliente (Liker & Meier, 2007). Em seu modelo de melhoria contnua (o kaizen), toda e qualquer ao de resoluo de problemas executada por meio do entendimento de suas influncias nos elementos de avaliao primrios.
aperfeioamento contnuo pode ser visto claramente nessa tcnica: o Plan aparece no momento em que a equipe levanta os problemas do ciclo anterior (postits), realiza a devida anlise e priorizao (votao discutida) e estabelece as aes de melhoria.
32
Um defeito, por exemplo. Que elemento de avaliao primria voc acha que ser mais afetado por uma grande incidncia de defeitos no seu produto? Se voc respondeu qualidade talvez voc ainda no esteja pensando no problema sob a tica do pensamento sistmico (Senge, 1990). Uma anlise sistmica sobre esse tipo de problema indicaria que todos os elementos de avaliao primria seriam duramente afetados. Mais defeitos significa menos qualidade e mais insatisfao do cliente. Para resolver a insatisfao a equipe aumenta a demanda por inspees manuais. Para resolver os problemas de qualidade gerados pelos defeitos haver mais retrabalho, o que diminuir a produtividade e aumentar o custo do projeto. Quando todas essas relaes no so corretamente compreendidas sob o ponto de vista do sistema produtivo, o caminho mais comum estabelecer causas superficiais ou aes pontuais para resolver o problema.Veja como fcil para uma equipe, em uma tpica reunio de retrospectiva, estabelecer causas e aes pontuais para resoluo de problemas sistmicos : Lder de Projeto: Pessoal, chegamos concluso de que o nosso principal problema hoje o aumento no nmero de bugs. O que podemos fazer para resolver isso? Desenvolvedor 1: Acho que deveramos gastar mais tempo testando antes de fazer a entrega. Lder de Projeto: Mas isso vai significar diminuir o ritmo de entregas! Deve haver outro jeito. Desenvolvedor 2: Acho que por a tambm. No fundo, estamos sacrificando nossa qualidade para produzir mais. Temos que rever nossas estimativas. Lder de Projeto: Porqu nossos testes unitrios no detectam os problemas? No poderamos tentar aumentar sua abrangncia?
Desenvolvedor 1: No sabemos. Temos 80% de cobertura, mas mesmo assim os bugs aparecem. H muito cdigo de interface grfica no coberto. Alguns bugs vem da. Outros surgem de situaes que realmente no tnhamos previstos. Lder de Projeto: OK. Vamos tentar conversar com nosso cliente para diminuir o nmero de entregas na prxima iterao e verificar se isso vai ajudar a ganharmos mais tempo para os testes.
A princpio no h nada de errado nessa reunio sob o ponto de vista gil. A equipe elencou seus problemas, votou o que acha mais importante, discutiu as suas causas e estabeleceu algumas aes para resolver aquilo que mais importante no momento. O grande problema com essa reunio que ela conduzida sob falsos pressupostos. O lder inicia com a pergunta: O qu podemos fazer para resolver isso?, ou seja, parte-se direto para a soluo sem primeiro tentar entender quais so as reais causas do problema. A pergunta mais indicada talvez fosse Porqu temos tantos defeitos?. Partir direto para a soluo pode lev-lo a dar o tiro certo no alvo errado. Como a equipe est acostumada a usar o pensamento linear para identificar o problema, ela se concentra em tentar resolver um sintoma, no a doena em si. O pouco tempo para testes no a causa do problema, apenas um sintoma. O desenvolvedor 1 d uma soluo que resolve o problema do desenvolvedor (seu cdigo ser mais testado), mas no resolve o problema do projeto. Ele colocou apenas dois dos quatro elementos bsicos de avaliao em sua anlise, ignorando que o custo tambm aumentaria e que a satisfao do cliente seria afetada, pois ele comearia a receber menos funcionalidades. O desenvolvedor 2 parece ser influenciado pelo desenvolvedor 1 e o ratifica mantendo o foco qualidade versus produtividade, como se fossem elementos antagnicos.
33
O pensamento linear os leva a achar que a nica maneira de aumentar a qualidade diminuindo a produtividade. Hoje a administrao moderna j sabe que o aumento da qualidade um dos principais fatores de influncia no aumento da produtividade. Ou seja, aumentar a qualidade no vai diminuir a produtividade, muito pelo contrrio, vai aument-la! O problema aparece quando voc tenta separar as atividades de qualidade das atividades de produo. Na verdade, agindo dessa maneira, tenta-se aumentar o controle do que est sendo produzido, no necessariamente sua qualidade. Os defeitos continuaro a serem introduzidos no produto. O aumento no controle atua apenas aumentando a capacidade do projeto de encontrar defeitos, no de evit-los. Isso feito, por exemplo, adotando a prtica de inspees intensas ao fim de um ciclo de desenvolvimento (tambm comuns em processos tradicionais). As inspees, se utilizada como nico elemento de quality assurance, so ineficientes pois permitem que o processo seja conduzido sem qualidade at que o setor de qualidade receba o produto para testes. Nessa abordagem, a qualidade no garantida, ela delegada para um outro time. Qualquer investimento em qualidade, realizado dessa maneira, pode sim significar reduo de produtividade e de tempo de entrega. De fato, no estaramos ajudando a aumentar a qualidade nesse caso, apenas tentando ganhar proteo e segurana contra os nossos prprios erros. Depois de ouvir a opinio dos desenvolvedores, o lder de projeto faz sua primeira incurso na direo de tentar entender o problema. Mas, repare que mais uma vez o foco desviado da causa (Porqu os testes unitrios no detectam o problema?) para a soluo (E se aumentarmos sua abrangncia?). Esse um comportamento comum nesse tipo de reunio. As pessoas ficam muito ansiosas para chegar a uma soluo e se esquecem de tentar entender o problema. Revista Viso gil Edio 03
No momento seguinte a reunio toma uma direo inusitada. Comea-se a discutir sobre o porqu os testes unitrios no detectam os bugs?, ao invs da pergunta inicial que estava tentando ser respondida como reduzir o nmero de defeitos?. Testes unitrios so timos instrumentos para evitar defeitos, mas eles no so os nicos responsveis por evit-los. No se pode apostar todas as fichas de qualidade do seu projeto em apenas uma prtica. A qualidade como um fluido que deve ser colocado para lubrificar cada engrenagem do processo. Uma engrenagem sem o fluido ser um potencial ponto gerador de defeitos. A reunio termina com um plano de ao delineado sem nenhuma compreenso das reais causas do problema. No cenrio em questo, bem provvel que as aes tomadas gerem o efeito desejado a curto prazo. Porm, no longo prazo, quando a equipe se acomodar ao novo nvel de produtividade, ou que pior, quando ela for pressionada para a re-estabilizao dos nveis de produtividade, o problema dos defeitos surgir ainda com mais intensidade. A causa-raiz no foi resolvida. Na parte 2 deste artigo: A soluo da Toyota para o aperfeioamento contnuo; - Identificao de problemas
- Anlise ; - Anlise da causa-raiz;
- A tcnica dos 5 porqus

Estratgias para otimizao de processos por meio de Reunies de Retrospectiva;
Referncias
AgileAlliance. (13 de Fev de 2001). Agile Software Development Manifesto. Fonte: http://www.agilemanifesto.org Cockburn, A. (2001). Agile Software Development. Addison-Wesley. Deming, W. E. (2003). Saia da Crise. (M. A. Mendes, Trad.) So Paulo: Editora Futura. DSDMConsortium. (2007). Acesso em 18 de 11 de 2007, disponvel em DSDM.org: http://www.dsdm.org Highsmith, J. (2000). Adaptive Software Development. Dorset House Publishing. Liker, J. K., & Meier, D. (2007). O Modelo Toyota: manual de aplicao. (L. B. Ribeiro, Trad.) Porto Alegre: Bookman. Microsoft Corporation. (2006). Process Templates - MSF For Agile Software Development. Acesso em 18 de 11 de 2007, disponvel em Microsoft Web Site: http://msdn2.microsoft.com/enus/teamsystem/aa718801.aspx Senge, P. (1990). The Fifth Discipline. New York: Doubleday. The Eclipse Foundation. (2007). OpenUp. Acesso em 18 de 11 de 2007, disponvel em http://www.epfwiki.net/wikis/openup/
34
Cobertura
Java Brasil 2007

Uma Conferncia gil para profissionais Java
Autor: Felipe Rodrigues

Felipe Rodrigues de Almeida (felipero@gmail.com) Arquiteto Java com experincia de 5 anos em desenvolvimento de sistemas distribudos. Atualmente trabalha na arquitetura de sistemas de GeoProcessamento e, conduz projetos e eventos na Fratech TI. Participa ativamente do desenvolvimento do framework Struts2 e mantm o projeto open-source BoxSQL ( http://boxsql.dev.java.net/). Passa o tempo livre curtindo e cuidando de seus 4 ces.
Nos dias 2, 3, 4 e 5 de Novembro aconteceu o evento Java Brasil 2007, que possua o seguinte slogan: Conferncia gil para profissionais Java. Imagino que ao ler esse slogan logo abaixo de um nome to forte como Java Brasil 2007, fica a impresso de que isso muito mais marketing do que qualquer outra coisa. Algumas pessoas poderiam criar uma certa expectativa de que seria um evento comum, como tantos outros, falando unicamente sobre java. Outras poderiam pensar que o evento no tinha foco de assunto e que isso poderia tornar o contedo muito superficial. A verdade sobre isso que, do ponto de vista da Fratech, um evento sobre Java no deve ser apenas um evento sobre tecnologia, mas sim um evento sobre desenvolvimento de software e, dessa forma percebemos a necessidade de falar sobre as formas de se desenvolver software hoje em dia e conseqentemente sobre desenvolvimento gil. O Java Brasil em 2007 comeou a partir de uma idia informal, minha e do Manoel Pimentel, sobre organizao de um evento diferente no Brasil, e principalmente um evento que fosse at o publico e no ao contrrio. O nome inicial seria Viso Java, pois a idia da revista Viso gil era muito recente. Com o tempo a idia foi ganhando fora e devido ao foco de cada um, o evento ganhou o nome de Java Brasil, pois a imagem que tnhamos era de que seria um evento itinerante. Revista Viso gil Edio 03 35
Cobertura Java Brasil 2007
Mas
como
comear?
Nunca
havamos
organizado um evento e no tnhamos a mnima idia de como fazer isso. Decidi envolver a Fratech na organizao pois dessa forma o evento teria uma infraestrutura para sua organizao. Mesmo com o apoio da Fratech, tivemos vrias surpresas ao longo da nossa jornada. Dificuldades e falta de tempo prejudicaram e muito o marketing inicial do evento. Problemas de infraestrutura nos servidores de nosso antigo provedor tambm impediram um pouco o acesso aos site do evento. Tambm tivemos boas surpresas, como o interesse de vrias empresas na iniciativa e a efetivao de algumas parcerias. A parte mais fcil foi conseguir palestrantes. Como vocs j devem saber, a comunidade Java extremamente unida e disposta a ajudar. O que segue agora um review de tudo que aconteceu nos 4 dias de evento do Java Brasil 2007. 1 Dia Workshops A idia inicial deste dia era realizar 4 horas de workshop de Struts2 e em seqncia 6 horas de Agile Aps 5 meses entre a idia inicial e o acontecimento tcnica, com do uma evento, o resultado que consegumos foi um evento de alta qualidade organizao extremamente flexvel e com habilidade para as mais diversas situaes ocorridas. Isso permitiu a realizao de um evento orientado ao pblico, possibilitando um feedback imediato de boa parte dos congressistas e palestrantes. O feedback se resume nas seguintes palavras: Valeu muito a pena!. Immersion. Mas aps algumas conversas com os participantes, percebemos que nem todos tinham interesse em participar do workshop de struts2. O resultado foi a realizao em paralelo dos dois workshops. Dessa forma, ouvindo a opinio de cada participante, pudemos aprender sobre o foco de cada um e direcionar o evento para a satisfao geral. Os workshops aconteceram como esperado e atenderam todas as expectativas. Conseguimos alguns dos melhores profissionais do Brasil para falar de assuntos de seus respectivos domnios. Referncias nacionais e internacionais sobre assuntos j comuns, fato que aumenta o mrito profissional. No evento foi anunciado uma estratgia de continuar a produzir eventos desse tipo no ano de 2008, e com apoio de algumas empresas, pretendemos realizar um srie de eventos com formatos variados ao longo do pas.
Workshop de Struts 2 Com Ian Roughley(Struts2 Team Leader) e Felipe Rodrigues(Fratech)
36
Struts 2 No workshop de Struts2, que eu ministrei ao lado de Ian Roughley, comeamos falando dos princpios bsicos e comparaes entre a verso antiga e a verso nova do framework. Ao terminar de falar sobre o bsico, o participantes escreveram sua primeira aplicao do dia, uma aplicao de login que foi evoluda para um CRUD usando conceitos mais avanados. Na seqncia introduzimos conceitos de Model Driven Development e Model Driven Actions, falando sobre best pratices e design patterns. O exerccio foi a migrao de nosso exemplo para Model Driven. Neste ponto passamos a utilizar conceitos de validao por XML e posteriormente por Annotations. Terminando com um formulrio complexo de edio de vrios objetos ao mesmo tempo. O ponto forte do workshop foi a interao entre os participantes e os facilitadores. Resoluo de customizaes sugeridas por cada participante e auxlio na execuo dos exerccios possibilitaram que todos os terminassem com um aplicao completa e funcional, incluindo aqueles que nunca haviam desenvolvido com o framework. Agile Immersion Com uma abordagem extremamente prtica e dinmica, Manoel Pimentel conduziu os participantes ao longo de 8 horas de workshop. Com uma seqncia de explicao e aplicao de conceitos, o workshop passou por temas como, Revista Viso gil Edio 03
Modelagem gil, M3, UML em Cores, FDD, SCRUM
alm de dinmicas focadas em exposio de conceitos do dia-a-dia de um time gil. O tpicos abordados foram:
Modelos de produo Ciclos de vidas Os 12 princpios geis O Manfesto gil Conhecendo o Scrum Os Papis no Scrum Product Backlog Sprint Planning Meeting Planning Pocker Scrum Daily Meeting Sprint Burndown Sprint Review Sprint Retrospective Melhorando a engenharia atravs da FDD M3- Modelagem Baseada em Mapas Mentais UML em Cores Estimativas Mtricas Um projeto do "zero" - Dinmica Prtica de construo
de um revista usando os processos geis. Scrum com outras metodologias como XP, FDD e TOC
Dinmica no WorkShop Agile Imersion Com Manoel Pimentel(Viso gil)
37
Durante o workshop os participantes foram divididos em equipes onde cada equipe tinha a responsabilidade de produzir uma revista. Podendo experimentar um processo gil com direito a todas as best pratices possveis.
Logo aps a abertura comearam as palestras, todas com alto nvel de qualidade. Para manter a idia do slogan sempre real, havia sempre opes de contedo gil em todos os horrios. Houveram alguns problemas com a falta de alguns
Dentre os participantes encontramos pessoas altamente capacitadas e com boa experincia em projetos, qualidade utilizando do workshop metodologias realizado. geis os constantemente, fato que s veio a reforar a Todos participantes afirmaram que tiveram oportunidade de visualizar erros e acertos em seus processos, assim como aprender novas abordagens para situaes crticas. Durante as pausas, entre uma atividade e outra, o comentrio que se ouvia era sobre a animao do workshop. A energia dispensada pelo facilitador foi vital para o sucesso do workshop, terminando com praticamente 2 horas a mais do que o planejado, devido a iterao com o publico. Acredito que todos tenham aprendido muito e que a troca de experincias foi muito maior do que o esperado. 2 Dia Incio da Conferncia No segundo dia aconteceu uma abertura, introduzindo todos aqueles que apoiaram e tornaram possvel a realizao do evento. Contamos com a presena de Ari Dias Neto (IBM), Manoel Pimentel (Viso gil), Ian Roughley (Struts2 Project Leader), Rubens (Orolix), Eduardo Guerra (Mundo Java) e Justino (Powerlogic)
palestrantes,
mas
tudo
foi
contornado
de
forma
sustentvel. Na opinio de todos, faltou um painel com as mudanas nos horrios das palestras atualizado, o que facilitaria muito a escolha da sala
Abertura da Conferncia Da esquerda para direira: Eduardo

Guerra(Mundo Java), Ari Dias Neto(IBM), Felipe Rodrigues(Fratech), Manoel Pimentel(Viso gil) Rubens(Orolix) e Justino(PoweLogic)
Do incio ao final do dia contamos com a presena de 113 pessoas participando do evento. No final do dia participamos de uma descontrao, com msica ao vivo e um Pub bar no hall do evento. Os palestrantes e os participantes se misturaram em conversas dos mais variados temas. Nesta hora todos tiveram oportunidade de encontrar e fazer amigos. Foi muito interessante a participao de todos os palestrantes do dia, que ao se reunirem puderam mostrar uma outra aptido alm da tcnica. Mas s quem participou pra saber. O ponto forte da noite foi a troca de conversa fiada entre participantes, organizadores e palestrantes.
38
3 Dia Quase no fim Domingo chuvoso, depois de um sbado longo, o dia comeou com poucas pessoas nas salas, porm isso foi se modificando conforme o pessoal ia acordando. :-) Como no primeiro dia, 2 palestrantes que no puderam vir, e o ilustre Alisson Vale nos agraciou com suas idias propondo-se a realizar 2 palestras no lugar de Adail Muniz que no pde comparecer por motivos familiares. Neste dia tambm tivemos a palestra de Alexandre Magno, que explicou o Scrum de forma brilhante e tivemos a realizao de um workshop sobre Scrum, ministrado pelo Rodrigo Yoshima. Dessa vez um workshop um pouco mais especfico, visando consolidar os conceitos do desenvolvimento gil com Scrum.
Foram apresentados conceitos sobre a separao entre as camadas de uma aplicao, mostrando como solucionar problemas especficos de implementao com alguns Design Patterns. No final do Mini-curso tivemos a participao do Ian Roughley com uma boa discusso sobre arquitetura de sistemas que utilizam componentes distribudos como EJB3.
Palestra sobre Metodologias geis Com Allison Vale(Phidelis)
4 Dia Seminrio Powerlogic No quarto dia tivemos a realizao do III Seminrio Tcnico Professional Java EE Open-Source Etapa de Campinas, onde contamos com a presena de Paulo Alvim, Diretor de Tecnologia da Powerlogic, que foi
Palestra sobre Scrum Com Rodrigo Yoshima(ASPERCOM)
responsvel
por
apresentar
as
solues
de
produtividade da powerlogic que agora esto disponveis na regio de Campinas atravs da Fratech. Dentre os participantes tivemos a presena da Nortel, Embrapa e O mini curso de Design Patterns tambm aconteceu com participao de Felipe Rodrigues e Manoel Pimentel, falando sobre modelagem gil e simplicidade na informao a ser passada. Os participantes modelaram uma pequena aplicao usando os conceitos de UML em cores e Modelagem gil, conceitos explicados no Mini-Curso. TRT. Meu sentimento pessoal de que o evento foi abrilhantado pela qualidade do pblico presente e pela participao efetiva deste pblico, assim como o empenho dos profissionais que conduziram os temas. Eventos como esse trazem network profissional, possibilitando novas oportunidades na carreira, alm de nos dar a oportunidade de aprender e reafirmar conceitos que diferenciam os excelentes dos bons. A frase mais ouvida no feedback dos participantes foi Java Brasil, quem no foi, perdeu!. E que venha 2008!!! 39
Artigo

Conhea nesse artigo, uma forma divertida e eficaz para modelagem de software.
Autor:Manoel Pimentel Medeiros

Engenheiro de Software, com mais de 15 anos na rea de TI, atualmente trabalha com projetos Java pela Rhealeza(SP), tambm Diretor Editorial da Revista Viso gil, Colunista da Revista Java Magazine, Membro da Agile Alliance, participa do time de Desenvolvimento do NetBeans, Lder do projeto BoxSQL, Fundador do XPNorte, do NUG-BR e do PrPatterns e frequentemente palestra em eventos sobre processos e tecnologias. Maiores informaes em: http://manoelpimentel.blogspot.com
Introduo: Na grande maioria dos projetos, existe uma enorme lacuna nas atividades relacionadas a engenharia de software, principalmente na disciplina de modelagem. E como essa uma atividade primria para o bom e claro entendimento acerca do escopo de um produto, grande parte dos fracassos desses projetos, se originam exatamente nessa restrio. importante observar que existe um enorme paradoxo na relao de modelagem x projeto, pois quando no se peca pela ausncia de tcnicas de modelagem, se peca pelo excesso de artefatos e tcnicas aplicados em projeto. Por isso, j existem vrias solues que visam simplificar esse processo de criao e leitura de modelos. Tambm j existem uma gama de tcnicas que estimulam boas prticas de modelagem em projetos, dentre algumas, podemos citar: a FDD(Feature Driven Development), MDA(Model Driven Architecture), DDD(Domain Driven Design) alm claro, de prticas mais essenciais como a prpria Orientao a Objetos. Revista Viso gil Edio 03 40
Portanto, uma tima proposta para facilitar a modelagem de software, a UML em cores e iremos entender um pouco mais sobre seu funcionamento nos tpicos abaixo. Histrico da UML em Cores Resumidamente, a UML em cores foi inicialmente proposta e por teve Peter grandes
Figura 01 - Viso Arquitetural da Modelagem
Coad(www.petercoad.com)
contribuies de Eric Lefebvre e Jeff De Luca , que aps vrios anos de experincia em modelagem de aplicaes para diversos segmentos e de variados tamanhos, chegaram a concluso que, todas as entidades encontradas nas aplicaes que j haviam sido criadas, seguiam um certo padro de existncia e comportamento, com base nessas observaes, foi criado um agrupamento em grandes categorias, afim de melhor identificar essas tais entidades. Essas categorias, foram chamadas de arqutipos, e para realmente criar uma boa separao visual entre eles, foi atribudo cores diferentes para cada um, e essas por sua vez, adicionam um fator semntico ao modelo, ajudam a diminuir a variao no processo de modelagem e padronizam o entendimento entre a equipe de negcio e a equipe de TI. Foco no domnio Um grande conceito relacionado a UML em cores, o Domain Neutral Component, ou em bom portugus Domnio Neutro de Componentes, que uma forma de criar modelos baseados no domnio da aplicao (objetos e regras de negcio, como por exemplo: Cliente, Produto, Status, Venda, Etc.), possibilitando que esses modelos, sejam totalmente independentes das outras camadas da aplicao como a de apresentao e de integrao, como voc pode observar na figura 01 . Revista Viso gil Edio 03
Figura 02 - Exemplos de arqutipos sugeridos pela UML em Cores
Conhecendo os Quatro Arqutipos: Observe tambm que conforme voc pode ver na figura 02, a UML em Cores sugere o uso de 04 arqutipos, representados por cores diferentes, e nesse tpico, voc vai entender os conceitos e as aplicaes tpicas para cada um.
41
Momento-Intervalo
Papel Arqutipo representado pela cor amarelo,
O primeiro arqutipo que iremos analisar, ser o Momento-Intervalo, que representado pela cor vermelha ou rosa, que simboliza entidades que possuem um tempo de vida bem definido, ou seja, ela nasce e deixa de existir em um espao de tempo bem definido e momentneo na realidade de negcio da aplicao. Dessa forma, esse arqutipo normalmente usado para entidades como Pedido de Venda, Pedido de Compra, Processo de Matrcula, Processo de Admisso, etc. Uma interessante variao desse arqutipo, o Momento-Intervalo-Detalhe, que representa entidades fracas que dependem de outras entidades Momento-Intervalo para sua existncia, um bom exemplo disso e: Itens de uma venda ou Itens de uma compras que dependem de uma entidade do tipo pedido de compra ou de venda.
normalmente usado para simbolizar uma entidade que tm um papel muito bem definido na aplicao, exemplo: Cliente, Fornecedor, Funcionrio. Outra aplicao desse arqutipo, para representar uma especializao de uma entidade Pessoa-Lugar-Coisa, por exemplo, em um software acadmico, uma mesma pessoa, pode desempenhar os papeis de Funcionrio e de um Aluno.
Descrio Representado pela cor azul, o arqutipo descrio, usado para entidades fracas que servem como metainformaes sobre outra entidades, ou seja, usado para definir caractersticas de uma determinada coisa. Existem bons exemplos para aplicao de arqutipo, pois vejamos: Podemos us-lo para entidades como Status(Ativo,Inativo, Cancelado) Turno (Manh, Tarde, Noite) Estado Civil (Solteiro, Casado, Divorciado, Vivo). Uma boa regra que tenho adotado par usar esse arqutipo, procurar por entidades fracas que tendem a no ter um grande volume de dados e sua existncia seja mais esttica na aplicao, ou seja, baixa ocorrncia de inseres e alteraes. Exemplo Prtico: Vamos agora, montar um exemplo prtico para demonstrar o uso da UML em cores para modelagem de domnio de uma aplicao de venda.
Pessoa-Lugar-Coisa
Esse arqutipo, que representado pela cor verde, uma das mais genricas e abstratas das formas, pois usado exatamente para representar qualquer entidade que seja uma pessoa(fsica ou jurdica) ou algum lugar(Departamento, Cidade, Pas) ou alguma coisa(Centro de Custos, Produtos, Tributos).
42

Observe que estamos usando um modelo extremamente simples, que pode ser criado usando editores de textos ou ferramentas grficas ou ferramentas cases e o que mais legal, que a UML em cores, favorece o uso de post-its, o que uma ferramenta muito prtica e eficaz para a atividade de modelagem. Portanto, veja na figura 02 abaixo, que temos algumas entidades bsicas de uma aplicao de venda. Veja que nesse exemplo, criamos um modelo abrangente, sem muitos detalhes acerca dos atributos, mtodo e dos relacionamentos de cada entidade, vale ressaltar que essa viso, proposta feita pela tm uma FDD(Feature atividade segue a Driven chamada Referncias - Livro em ingls sobre UML em Cores: Coad Peter, Eric Le Febvre & Jeff De Luca, Java Modeling in Color with UML - Enterprise Components and Process, Prentice Hall, Upper Saddle River, NJ, 1999 Materiais em portugus sobre FDD em: Concluso Espero que esse artigo tenha alcanado seu objetivo principal, que de despertar seu interesse sobre o tema, e principalmente sua curiosidade em aplicar essa tcnica em seus projetos e avaliar os benefcios oferecidos por ela.
Development), onde nos ciclos de concepo e planejamento, "Desenvolver um Modelo Abrangente", que consiste em elaborar um modelo com uma idia inicial acerca da aplicao e a cada ciclo do projeto, esse modelo vai ganhando mais detalhes e mais aderncia ao negcio da empresa, porm, como o foco desse artigo no se aprofundar em FDD, sugiro que olhe as referncias no final do mesmo, e pesquise maiores informaes sobre esse tema.
http://www.heptagon.com.br
Figura 03 - Exemplo prtico de um modelo usando as tcnicas de UML em Cores.
43
Cobertura
London Scrum Gathering

Cobertura em Londres do mais importante evento internacional sobre Scrum
Autor: Alexandre Magno

Alexandre Magno lder de projetos de software onde utiliza principalmente metodologias e processos geis. Atua na rea de software h mais de 15 anos, j tendo participado de projetos de variadas dimenses de lead time, escopo e investimento. Foi o primeiro Certified Scrum Practitioner da Amrica Latina, sendo hoje membro do comit da Scrum Alliance para avaliao de novos CSPs. Magno o fundador do grupo Scrum-Brasil e atualmente responsvel pelos servios de agile da Caelum (www.caelum.com.br). Contato: axmagno@gmail.com / http://amagno.blogspot.com
Duas vezes por ano a Scrum Alliance(www.scrumalliance.org), organizao que representa a comunidade Scrum ao redor do mundo, realiza o Scrum Gathering. Este evento, que normalmente conta com edies de primavera e outono, se prope a ser uma grande reunio dos praticantes do Scrum espalhados pelo mundo. A ltima edio deste evento foi realizada em novembro passado na capital inglesa e contou com uma mdia de 200 (duzentos) participantes nos 5 (cinco) dias de evento. Por mais que o predominante fossem participantes ingleses, franceses e norte-americanos, tivemos um grande nmero de praticantes do Egito, Alemanha, Austrlia, Rssia, Turquia, Marrocos e muitos, muitos mesmo, da ndia. Infelizmente, mas como eu j imaginava, eu era o nico brasileiro no evento, at porque alm da distncia territorial entre Brasil e Inglaterra, a distncia de cmbio entre o Real e a Libra fazem com eventos nas terras da rainha sejam realmente de alto custo para ns brasileiros.
44
O Evento O London Scrum Gathering foi realizado na Dexter House, uma casa de eventos ao lado da London Bridge, entre os dias 12 e 16 de novembro de 2007. Os dois primeiros dias de eventos estavam reservados para a realizao do treinamento Certified Scrum Master a ser ministrado por Ken Schwaber e Mike Cohn. Para os trs dias seguintes, montar uma agenda particular para o evento era um desafio para qualquer profissional interessado em Scrum. Eram muitos nomes importantes da
Cocktail no estilo tea break.
comunidade e muitas palestras com assuntos interessantssimos acontecendo paralelamente. O evento estava dividido em 5 (cinco) trilhas:
Aps um tradicional tea break britnico chegou a hora da verdade! A minha apresentao tinha como propsito mostrar os porqus da grande resistncia sofrida pelas abordagens geis (com foco em Scrum) nas empresas ao redor do mundo. Joseph Pelrini da Logo aps o almoo, assisti a palestra Why Scrum Projects Fail? apresentada por Metaprog e Jiri Lundak da Lwenfels Partner (Suia). Foi uma palestra muito legal, que tocou muito no lado humano que Scrum envolve e forneceu grandes e importantes conselhos para as Scrum Retrospectives. Na seqncia, para ltima palestra do dia, escolhi assistir ao Mike Cohn da Mountain Goat (USA) falando sobre o processo de transio para agile, uma palestra tambm recheada de dicas valiosssimas. 15 de novembro, o segundo dia
Scrum in the large Human Side of Scrum Scrum Skills Product Owner issues Scrum Experiences
Alm disso, um desafiador Open Space estava reservado para o ltimo dia de evento e seria facilitado por ningum menos que Rachel Davies, da AgileExperience. Sabine Canditt, Ken Schwaber, Kenny Rubin, Nigel Baker, Mike Cohn, Henrik Kniberg, Geoff Watts e Roman Pichler eram outros grandes nomes que tornavam mais desafiadora aindaa tarefa de escolher a qual prxima palestra assistir. 14 de novembro, o primeiro dia
O Keynote deste dia foi apresentado por Pirkka O evento foi aberto atravs de um Keynote do Bruce Radloff da TeleAtlas , mas infelizmente no pude acompanhar visto que a minha palestra era logo na seqncia, e ento alm do nervosismo eu estava ocupado deixando tudo pronto na minha sala de apresentao. Revista Viso gil Edio 03 Palomki da F-Secure (Finlndia) que falou sobre o desafio de espalhar Scrum por todos os cantos da empresa. Na seqncia a colega Sabine Canditt (CSP da Siemens) executou uma das mais brilhantes palestras do evento, fiquei impressionado em ver como a Siemens vem usando Scrum pra quase tudo. 45
Depois disso, sala lotada para assistir ningum mais ningum menos que ele: Mr. Scwaber, com sua palestra The Enterprise and Scrum. Para quem j havia lido o seu ltimo livro (com o mesmo ttulo) nenhuma surpresa, mas de qualquer forma ouvir os detalhes do dia-a-dia da implantao de Scrum em uma empresa por um de seus criadores foi uma experincia mpar. O Keynote seguinte (da British Telecom) - que
foi excelente e divertidssimo por sinal era pra ter sido a ltima apresentao do dia, mas Ken Schwaber presenteou-nos com uma sesso "extra" de 4 horas intitulada Scrum Update...MAGNFICO! O mais legal aqui foi ver todos aqueles grandes nomes que citei anteriormente sentados no papel de aluno de Ken Schwaber, lado-a-lado com voc, discutindo sobre: como aplicar, ensinar e tudo mais com Scrum. 16 de novembro, o ltimo dia Como eu j mencionei, o ltimo dia do evento foi reservado para a execuo de um Open Space no qual cada grupo tinha que conduzir durante um dia a difcil tarefa de organizar uma edio do evento Scrum Gathering. Os desafios eram muitos...a cada conjunto de minutos, Product Owners ilustres tais como Ken Schwaber e Kenny
Palestra do Mike Cohn
46
e por a vai. At na minha palestra (coitado de mim) vi dois admirveis praticantes de Scrum assistindo, perguntando e se interessando pelo tema. Alm disso, e no menos importante, gostei do evento pois ali se reuniam profissionais que realmente estavam interessados na prtica de Scrum, e no em discursos extremamente filosficos de gente que nunca nem sequer se preocupou em utilizar Scrum de verdade no seu dia-a-dia. Scrum, mais do que para ensinar ou discutir em listas,
Open Session
PRINCIPALMENTE para se praticar. Como disse Nigel Baker da BT Praticar mais que tagarelar!; Por fim, aconselho qualquer membro da nossa comunidade a participar da prxima edio do Scrum Gathering, que acontecer em Chicago de 14 a 16 de abril de 2008. Mais detalhes sobre o London Scrum Gathering
http://www.scrumalliance.org/events/2--london-scrum-gathering
Rubin apresentavam obstculos a serem conduzidos pelo Scrum Master de cada time (papel rotativo). O aprendizado nestas sesses de Open Space foi enorme e o saudosismo no final do dia foi grande. Concluso Participar deste meu primeiro Gathering foi uma experincia fantstica. Por mais que meu investimento tenha sido reduzido pelo fato de ter sido palestrante, acho que mesmo se eu tivesse ido apenas como participante, ou seja, fazendo todo o investimento necessrio, o evento teria me retornado cada centavo gasto (e olha que no so poucos). Mais que as palestras, que foram de alto nvel mesmo, o networking e o turismo (que querendo ou no sempre bem vindo), acho que a principal lio e o que mais valeu desta viagem foi ter visto a postura da comunidade internacional de Scrum. Fiquei impressionado com a simplicidade e fome de conhecimento de cada pessoa que ali conheci, e tambm em ver grandes nomes se colocando durante o evento inteiro no papel de aluno, assistindo palestras, perguntando...Ken Schwaber assistindo Mike Cohn, Kenny Rubin assistindo Roman Pichler, Revista Viso gil Edio 03
Download das palestras do London Scrum Gathering

http://www.scrumalliance.org/resources
Chicago, a prxima parada

http://www.scrumalliance.org/events/5--scrum-gathering
Agenda dos Open Sessions
47
Apoios
www.heptagon.com.br
www.tc4digital.com
48

Va 03

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Va 03

Hochgeladen von

Copyright:

Verfügbare Formate

\

O seu canal sobre processos geis

As 5 Doenas do Gerenciamento de Projetos

Causa n 3: Sndrome do Estudante

Utilizando Metodologias geis para atingir MPS.BR nvel F na Powerlogic

Case de implantao de processos geis com MPS.BR

Ano Viso gil Edio 03 Edio 01 Revista II

As 5 Doenas do Gerenciamento de Projetos

Utilizando Metodologias geis para atingir MPS.BR nvel F na Powerlogic.

Mtricas e o Desenvolvimento gil.

OpenUP: Uma Introduo

Aperfeioamento de Projetos geis

Cobertura do Java Brasil 2007

Brincando com a UML em Cores

Cobertura London Scrum Gathering

Revista Viso gil Edio 03

Equipe Viso gil Diretor Editorial:

Alexandre Magno Figueiredo

e-mail: manoelp@gmail.com site: www.visaoagil.com

Qualquer edio anterior pode ser baixada gratuitamente no site www.visaoagil.com

Revista Viso gil Edio 03

Workshop AGILE IMMERSION em maro de 2008 www.fratech.net

CHICAGO SCRUM GATHERING em abril de 2008 www.scrumalliance.org

Revista Viso gil Edio 03

As 5 Doenas do Gerenciamento de Projetos

Autor: Allan Elder

As 5 Doenas do gerenciamento de Projetos

Revista Viso gil Edio 03

As 5 Doenas do gerenciamento de Projetos

Revista Viso gil Edio 03

Revista Viso gil Edio 03

Revista Viso gil Edio 03

Utilizando Metodologias geis para atingir MPS.BR nvel F na Powerlogic

Autora: Ana Cludia Grossi

Autora: Fernanda Alves

Revista Viso gil Edio 03

Utilizando Metodologias geis para atingir MPS.BR nvel F na Powerlogic

Utilizando Metodologias geis para atingir MPS.BR nvel F na Powerlogic

Revista Viso gil Edio 03

Utilizando Metodologias geis para atingir MPS.BR nvel F na Powerlogic

Utilizando Metodologias geis para atingir MPS.BR nvel F na Powerlogic

Revista Viso gil Edio 03

Utilizando Metodologias geis para atingir MPS.BR nvel F na Powerlogic

Utilizando Metodologias geis para atingir MPS.BR nvel F na Powerlogic

Utilizando Metodologias geis para atingir MPS.BR nvel F na Powerlogic

Revista Viso gil Edio 03

Mtricas e o Desenvolvimento gil

Mtricas e o Desenvolvimento gil

Revista Viso gil Edio 03

Mtricas e o Desenvolvimento gil

Revista Viso gil Edio 03

Mtricas e o Desenvolvimento gil

Entenda como funcionam grficos no Desenvolvimento gil:

Mtricas e o Desenvolvimento gil

CFD - Cumulative Flow Diagrams

Revista Viso gil Edio 03

Mtricas e o Desenvolvimento gil

Revista Viso gil Edio 03

Mtricas e o Desenvolvimento gil

Revista Viso gil Edio 03

OpenUP: Uma Introduo

Revista Viso gil Edio 03

OpenUP: Uma Introduo