Lies em Agilidade do Desenvolvimento Web-Based O autor descreve duas iniciantes empresas de Internet que adotaram uma modelagem eficaz,

eficiente e prticas de documentao, um deles pegou uma comum, a abordagem baseada em equipe e a outra a abordagem arquiteto-chefe. Eles encontraram um "sweet spot", onde os esforos de modelagem pode proporcionar um benefcio significativo sem incorrer nos custos de documentao onerosa. No auge da revoluo da Internet, fomos inundados por alegaes de que as regras fundamentais do negcio tinham mudado. Para suportar esse novo paradigma de negcios, novas empresas surgiram virtualmente durante a noite, muitas vezes entregando software muito bom muito rapidamente. Eu queria saber se as regras de desenvolvimento de software tambm haviam mudado. Fomos assistir a uma mudana de paradigma na forma como desenvolvemos software? Havia algo no conceito de "desenvolvimento no tempo da Internet"? Em abril de 2000, a bolha da internet estourou e o mundo dos negcios foi trazido de volta realidade, descobrindo que os fundamentos do negcio no haviam mudado. No entanto, no ficou to claro se as regras fundamentais de desenvolvimento de software mudaram. Eu trabalhei como consultor de processos de software para duas empresas na Internet durante o boom - vamos cham-los XYZ.net e PQR.com para proteger suas identidades, j que ambos ainda esto em atividade. XYZ.net focada em servios fundamentais de infraestrutura para os usurios da Internet, quando me juntei a eles, estavo prestes a comear a trabalhar em sua terceira gerao de software para apoiar a sua oferta inicial ao pblico. PQR.com era um varejista de produtos eletrnicos no processo de rearquitetura do seu sistema para apoiar o seu crescimento projetado e posicionar-se para um IPO no futuro. Os dois fatores comuns entre as empresas foram meu envolvimento e o fato de que ambas as organizaes esto enfrentando o crescimento do negcio fenomenal, portanto, necessidade de rearquitetar e reconstruir seus sistemas. Eles tambm foram contratar de novos desenvolvedores para ajud-los a este novo software: XYZ.net cresceu de trs para 30 colaboradores em menos de um ano, e PQR.com tinha crescido a partir dos dois fundadores originais para e 25 desenvolvedores em um perodo de tempo similar. Ambas as empresas sentiram que precisavam de um processo de software mais maduro que inclui modelagem de software. Ambas as organizaes tinham pessoal muito jovem (mdia de idade era de 25 e tinham cultura orientada equipes). Alm disso, ambas as empresas queriam definir e formar o seu pessoal em uma verso do Rational Unified Process adaptada para atender s suas situaes especficas, com extenses de processos de software. Ambas as organizaes queriam ser capazes de declarar aos potenciais investidores que eles estavam usando um processo de software credenciado, mas no queriam a burocracia desnecessria para atras-los. Ambas as organizaes necessitavam melhorar as suas prticas de modelagem, o gerenciamento snior sentiu que apesar de terem desenvolvedores talentosos e brilhantes, eles no foram to eficazes quanto poderiam ser. Os desenvolvedores nas duas organizaes tinham sentimentos mistos sobre isso, com atitudes que vo desde " sobre o tempo" at "modelagem um desperdcio de tempo, tudo que eu preciso de cdigo fonte." A verso adaptada do RUP era necessria para incluir um processo de modelagem de arquitetura corporativa que defina suas infraestruturas tcnicas e de aplicao. Este esforo de arquitetura corporativa foi alm do escopo do RUP, a qual investigou o processo de software para um nico projeto ao invs de um portfolio de projetos. Alm disso, ambas as organizaes necessitavam de abordagens eficazes para a sua modelagem e documentao em projetos

individuais. Embora o RUP claramente tenha includo processos de modelagem sofisticadas, cada organizao sentiu que a abordagem RUP para a modelagem era demasiado pesado para o desenvolvimento Internet-based e queria encontrar uma maneira de trabalhar melhor. Ambas as organizaes necessitavam de abordagens eficazes para a sua modelagem e documentao em projetos individuais. Arquitetura comum Para arquitetar a nova gerao de software, a XYZ.net criou uma equipe de arquitetura que compreendia os lderes tcnicos de cada equipe de desenvolvimento, o vice-presidente de sistemas, o diretor de tecnologia, o gerente de garantia de qualidade e testes e vrios desenvolvedores seniores. Na primeira semana a equipe reuniu-se vrias tardes para identificar onde estavam indo, quais eram seus requisitos fundamentais, em seguida, reuniram-se para propor uma arquitetura inicial para apoiar essas necessidades. Quando eles no estavam modelando a nova arquitetura, todos trabalhavam em seus normal cotidiano. XYZ.net estava em operao contnua: ningum poderia simplesmente parar de evoluir o software existente. Isto teve o benefcio lateral de dar s pessoas tempo para refletir sobre a arquitetura proposta, bem como de discutir idias com colegas de trabalho. Durante as sesses de modelagem de arquitetura, eles desenharam diagramas na lousa. No incio, a equipe tentou utilizar uma ferramenta CASE conectado a um projetor, mas achei que isso seja insuficiente - a pessoa que opera a ferramenta no conseguia acompanhar a conversa, e a ferramenta no era suficientemente flexvel para satisfazer as nossas necessidades (era necessrio mais do que os diagramas de UML). A lousa tambm requisitou pouco treinamento para trabalhar e permitiu-lhes rapidamente alternar entre os modeladores. As pessoas forneciam dados e idias, questionavam suposies, compartilhavam experincias passadas, e at mesmo falar sobre potenciais estratgias de implementao. A ferramenta mais simples permitiu-lhes trabalhar juntos como uma equipe. Sempre que eles necessitavam de documentao permanente, eles simplesmente desenhavam os modelos em papel e depois digitaliz-los para produzir cpias eletrnicas. Ocasionalmente, a equipe iria capturar o modelo em uma ferramenta CASE, mas a abordagem do scanner foi mais comum porque alguns desenvolvedores tinham acesso ferramenta CASE devido a incompatibilidades de plataforma. A equipe desenhou diagramas UML, mas descobriu que precisava de uma gama muito maior de tcnicas - alguns do software foram escrito em linguagens procedurais, ento eles precisavam de diagramas non-object como grficos de estrutura. Eles tambm desenharam diagramas de fluxo de dados para retratar questes de fluxo de trabalho e diagramas de forma livre para retratar a arquitetura tcnica do sistema. Uma vez que o modelo de arquitetura inicial era no lugar, eles continuaram a se encontrar quase semanalmente (apenas quando necessrio). As reunies eram normalmente uma ou duas horas de durao e sempre incluiam uma agenda informal, que identificava uma ou mais questes a serem abordadas. O proprietrio de cada questo foi responsvel por explicar, o que ele ou ela viu como a soluo provvel, e as repercusses potenciais desta abordagem. Muitas vezes, algum vinha para uma sesso de arquitetura com o problema resolvido quase que totalmente, o grupo simplesmente analisava e fornecia feedback adequado. As apresentaes foram tipicamente feito em "giz-discusso" de forma, em que o proprietrio poderia descrever um problema, desenhando-o no quadro branco. Isso funcionou bem, porque muitas pessoas j estariam familiarizados com a questo, tendo sido envolvidas em discusses anteriores com o proprietrio fora das sesses de modelagem de arquitetura.

A introduo de um arquiteto-chefe Tomando uma abordagem diferente, PQR.com decidiu contratar um experiente desenvolvedor snior como arquiteto-chefe, um "velho garoto" em seus 30 e poucos anos que j tinha

construdo sistemas escalveis antes. Ele passou a semana inicial com a aprendizagem da empresa sobre o negcio e a situao atual dos sistemas, principalmente por meio de discusses com diretores de TI e equipe de operaes. Ele ento trabalhou pequenas sesses de modelagem para identificar exigncias arquiteturais, bem como potenciais solues arquiteturais. Sua abordagem foi a realizao de sesses de uma hora "giz-discusso" envolvendo duas ou trs outras pessoas, seguido de vrias horas de modelagem em particular com uma ferramenta de diagramao e um processador de texto para explorar e documentar o que tinha aprendido. Ele, ento, postou suas modelos como pginas HTML na rede interna, onde todos, desenvolvedores e pessoas em negcios, poderia v-las e potencialmente fornecer feedback. Era muito comum as pessoas agendarem uma reunio improvisada com ele para discutir o seu trabalho ou simplesmente para lhe enviar um e-mail. Documentando a arquitetura A principal diferena em suas abordagens foi como documentao arquitetural foi atualizada ao longo do tempo. Ambas as organizaes escolheram documentar sua arquitetura para torn-la disponvel para todos os desenvolvedores de software. Suas abordagens tinha vrias semelhanas interessantes: A documentao oficial foi baseada HTML. Ambas as empresas escolheram HTML (e imagens JPEG ou GIF) para apoiar a ampla gama de sistemas operacionais utilizados os desenvolvedores, tornando assim a documentao acessvel a todos. Alm disso, os desenvolvedores j estavam intimamente familiarizados com HTML e tinha as ferramentas existentes para ver e editar os documentos. Eles criaram apenas a documentao geral. Para manter a sua eficcia, as duas empresas documentada apenas informaes gerais referentes arquitetura, Registravam as informaes crticas que os desenvolvedores precisavam saber para entender como funcionava. A documentao foi focada principalmente em torno de um diagrama de arquitetura mostrando servios de software principais implantados dentro do ambiente tcnico, com descrio da viso geral de cada servio de software ou sistema e links apropriados para as pginas de documentao mantidas por equipes de projetos individuais. A impresso da documentao de arquitetura teria sido no mais que 15 pginas. A arquitetura da informao no era especial. As bases de dados e sistemas de armazenamento de arquivo apareceram no diagrama da arquitetura do sistema, juntamente com aplicaes e servios de software. A equipe de dados foi tratada como qualquer outra equipe do projeto: todas as equipes forneciam funcionalidades que outras equipes necessitavam, e cada equipe era cliente de vrias outras equipes. Isto era necessrio para todos trabalharem juntos para resolver qualquer problema de configurao e de gerenciamento de release. Isto era diferente de muitas organizaes onde a equipe de dados considerada uma equipe de infraestrutura corporativa que oferece suporte a equipes de desenvolvimento de aplicaes. Em ambas as empresas, cada equipe era uma equipe de infraestrutura. Modelagem e documentao foram esforos separados. Ambas as empresas perceberam que o ato de modelagem e o ato de escrever documentao so dois esforos distintos. No passado, a maioria dos desenvolvedores no tinha experincia significativa em modelagem, da mesma forma era a utilizao de ferramentas CASE sofisticadas que geraram documentao detalhada. Depois de experimentar vrias sesses de modelagem, usando ferramentas simples como a lousa, aps algum escrever o resumo da documentao apropriada (se houver), eles descobriram que poderiam alcanar os benefcios da modelagem sem incorrer nos custos de escrever e manter documentao pesada. A principal diferena em suas abordagens foi como documentao arquitetural era atualizada ao longo do tempo. PQR.com teve um proprietrio designado para documentao, o arquitetochefe, enquanto XYZ.net tomou uma abordagem mais comum e permitido a qualquer usurio atualizar a documentao. No PQR.com, as pessoas eram obrigadas a discutir primeiro as suas

sugestes com o arquiteto-chefe, que, em seguida, agia em conformidade. No XYZ.net, as pessoas em primeiro lugar falavam com o proprietrio percebido de uma parte da documentao, normalmente a pessoa inicialmente atribudo a esse aspecto da arquitetura, e depois atualiz-lo em conformidade. Ningum parecia abusar desse privilgio mudando documentao arquitetural para promover seus prprios objetivos polticos. Uma razo era que os desenvolvedores XYZ.net eram uma equipe unida. Segundo, porque todas as pginas HTML foram manejados sob o sistema de controle de verso, houve um registro de quem mudou cada pgina.

Comparando as duas abordagens de modelao O processo do projeto foi semelhante em ambas as organizaes: sistemas foram desenvolvidos em um ambiente de maneira altamente iterativo. Vamos comparar as duas abordagens para modelagem arquitetural corporativo em relao a vrios fatores crticos: Calendrio. XYZ.net a equipe de arquitetura necessitou menos tempo de calendrio para desenvolver sua arquitetura inicial e depois a evoluir ao longo do tempo, porque vrias pessoas trabalharam nele em paralelo. Aceitao e Compreenso A abordagem comum tomada por XYZ.net claramente resultou em rpida aceitao por parte dos desenvolvedores, por duas razes. Primeiro, porque os representantes de cada equipe de desenvolvimento participaram da equipe de arquitetura, e eles efetivamente "venderam" a arquitetura aos seus companheiros, muitas vezes simplesmente por pedir sua ajuda quando eles estavam trabalhando em partes da arquitetura. Em segundo lugar, todos poderiam atualizar a documentao da arquitetura que eles pediam, promovendo assim um senso de propriedade. Custo. Abordagem PQR.com necessitou de menos esforo global porque o arquitetochefe realizou a maior parte da modelagem arquitural, permitindo que os seus colegas de trabalho se concentrar em outras tarefas. Controle. O arquiteto-chefe da PQR.com forneceu uma nica fonte de controle, ainda que aquele tenha se tornado um ponto de estrangulamento, s vezes. A abordagem em equipe forneceu vrias vises, as quais trabalhavam em qualquer dado aspecto da arquitetura, embora a sua propriedade compartilhada da documentao fornecesse oportunidades para o mal (embora para o meu conhecimento nunca tenha ocorrido). Eficcia. Ambas as abordagens resultaram em arquiteturas escalveis que atenderam as necessidades de suas respectivas organizaes. Compatibilidade com o Processo. Ambas as abordagens funcionaram bem dentro de um ambiente RUP, embora a abordagem arquiteto-chefe, parecia ser mais bem sintonizada com o RUP que a abordagem de arquitetura comum.

Modelagem de Projeto especfico O processo do projeto foi semelhante em ambas as organizaes: sistemas foram desenvolvidos em um ambiente altamente iterativo e lanado de forma incremental em pequenos ciclos que variavam de seis a doze semanas, dependendo do projeto. O departamento de marketing escrevia os documentos iniciais requisitos, geralmente declaraes de alto nvel necessidades. Os chefes do departamento de TI e os condutores dos projetos fizeram uma verificao da realidade sobre esses documentos para ideias de retrabalho irrealistas antes de apresent-los s equipes. Sesses de modelagem ocorriam medida que cada equipe de projeto requeria alguma reunio dos membros da equipe com os stakeholders apropriados para trabalhar com uma questo em detalhes. Estes esforos de modelagem foram semelhantes aos realizados pela equipe de arquitetura XYZ.net: pessoas conheceram e trabalharam com os modelos como uma equipe, em torno de uma lousa. Muitas vezes, eles iriam desenvolver vrios modelos ao mesmo tempo, talvez vrios casos de uso, juntamente

com alguns esboos de tela, alguns diagramas de sequncia e um diagrama de classe. Eles no tinham "sesses de modelagem de caso de uso" ou "sesses de modelagem de classes" - eram apenas sesses de modelagem. No XYZ.net, as equipes de desenvolvimento tinham de um a oito membros, todos voltados para uma parte de cobertura da infraestrutura. Em um determinado momento, cada equipe estaria em um lugar diferente no ciclo de vida do projeto. s vezes duas ou mais equipes teriam de agendar seus lanamentos simultaneamente para permitir vrias dependncias do subsistema. As equipes sabiam dessas dependncias, porque trabalharam em estreita colaborao com os desenvolvedores de outras equipes, muitas vezes andando pelos corredores ou subindo as escadas para sentar e conversar. Estas sesses de modelagem eram diferentes dos tradicionais. Em primeiro lugar, eles iterativamente faziam a quantidade mnima necessria para iniciar a codificao, com a maioria das sesses de modelagem com durao de 10 minutos a uma hora. Em segundo lugar, a meta de cada sesso de modelagem era explorar uma ou mais questes para determinar uma estratgia para avanar, o objetivo no era simplesmente produzir um artefato. Seu objetivo era modelo, no para produzir modelos. Desenvolvedores trabalharam com escritores tcnicos para produzir as notas de release, procedimentos de instalao e documentao do usurio. As notas de release foram a documentao formal para os subsistemas, escrito como pginas HTML e colocados online para que todos os desenvolvedores internos pudessem v-los. As notas de release tipicamente resumiam os requisitos recm-implementados, o projeto (diagramas foram tipicamente digitalizao de seus esboos preliminares e foram publicados como arquivos JPEG), e uma lista dos arquivos que compunham o subsistema. Felizmente, os desenvolvedores XYZ.net j estavam produzindo notas de release seguindo este processo em seus dias pr-modelagem, ento a nica mudana que eles precisavam para implementar foi adicionar os diagramas de design que apresentaram uma viso geral do seu trabalho. No incio, alguns desenvolvedores incluram diagramas detalhados em suas notas de release, mas rapidamente descobriram que eles forneciam pouco valor. Quando os desenvolvedores queriam informaes mais detalhadas, eles iam direto ao cdigo fonte, que eles sabiam estava atualizado. Os desenvolvedores tambm trabalharam em estreita colaborao com os engenheiros de teste. Os desenvolvedores precisavam de ajuda para testes de unidade, e os engenheiros de teste precisava de ajuda para aprender o software para desenvolver testes de aceitao para isso. Antes, para que o software pudesse ser colocado em produo, o departamento de garantia de qualidade primeiro tinha de test-lo para garantir que ele cumpriu suas exigncias, foi devidamente documentado, e se integrou com os outros subsistemas. O processo de desenvolvimento funcionava de forma semelhante em PQR.com, com equipes de trs a seis pessoas. Desenvolvedores de diversas equipes trabalharam juntos, ajudando uns aos outros quando necessrio. Desenvolvedores PQR.com tomaram uma abordagem mais formalizada para documentao, escrever documentos de requisitos, documentos de projeto, e notas tcnicas de release. Os documentos de requisitos basearam-se nos documentos de requisitos de marketing iniciais e os modelos de requisitos foram produzidos a partir deles. O documento de requisitos foi escrito em paralelo com o desenvolvimento do documento de design (projeto) e o cdigo fonte e foi finalizado normalmente durante uma semana de uma iterao passada: as equipes trabalharam de forma iterativa, no em srie, para que eles pudessem reagir s novas exigncias e mutvel, conforme necessrio. Um documento de requisitos inclua um diagrama de caso de uso e casos de uso detalhados para o release, bem como as regras de negcio relacionadas, requisitos tcnicos (no funcionais) e restries conforme necessrio. Os documentos de projeto inclua especificaes de tela quando aplicvel (normalmente apenas uma imagem JPEG de uma pgina HTML) e diagramas de viso geral aplicveis, tambm, os desenvolvedores de cdigo fonte preferida de diagramas de projeto detalhado. Uma interessante semelhana entre as duas empresas foi a sua abordagem aos dados: os seus esforos de dados foram tratados como projetos de desenvolvimento. No entanto, as equipes de dados trabalharam diferentes do que as outras equipes de projeto, investindo mais tempo na

modelagem detalhada. Em ambas as empresas, os grupos de dados utilizaram uma ferramenta CASE para criar modelos de dados fsicos de seus esquemas de banco de dados relacionais. A ferramenta gerava fazia engenharia reversa de definio de dados linguagem de cdigo (DDL), incluindo triggers de banco de dados, fazendo o esforo adicional de modelagem detalhada valer a pena. Ranks Vrias pessoas em XYZ.net no apreciam a necessidade de um maior esforo na modelagem e documentao. Isto foi devido a um ou mais fatores: eles se perceberam como programadores hard-core, eles preferiam trabalhar sozinhos ou com outros de mentalidade semelhante, ou seja, suas habilidades pessoais necessitavam de melhorias. Alm disso, eles geralmente no tm uma boa modelagem e habilidade com documentao, como a maioria de seus colegas de trabalho. Uma combinao de presso dos pares e a capacidade de ver "o caminho que os ventos estavam soprando" os motivou a ir junto com a adoo de uma verso adaptada do RUP, embora com um pouco resmungos. A validao solitria requer menor ao disciplinar: o chefe de desenvolvimento teve algumas conversas pessoais com ele, ele no foi autorizado a seguir em frente com o projeto atual at que ele tenha escrito a documentao e o departamento de garantia da qualidade tenha a aceitado, e sua promoo a lder da equipe foi colocada em espera por alguns meses. Houve poucos problemas na PQR.com, provavelmente porque sua equipe foi mais conscientes dos benefcios de modelagem para comear. As pessoas tinham diferentes nveis de habilidades de modelagem, ento eles receberam treinamento, mas ningum foi ativamente em antagonismo com aumento dos nveis de modelagem, desde que receberam treinamento. Comparao com o desenvolvimento do projeto tradicional Como isso foi diferente das prticas tradicionais de desenvolvimento, particularmente de instanciaes RUP tpicos? A partir do 50.000 - baixo nvel, no era diferente de todo. Ambas as empresas identificaram necessidades e, em seguida, arquitetaram, projetaram, codificaram, testaram e implantaram seu software. No entanto, ao nvel de ambiente, houve algumas diferenas interessantes. Primeiro, o desenvolvimento comeou com o modelo de arquitetura corporativa. Para encaixar com e explorar outros sistemas, todas as equipes do projeto comearam com o atual modelo de arquitetura corporativa, pois mostrava como os seus esforos se encaixam no todo global. Quando as equipes de projeto aprofundaram os detalhes, s vezes eles descobriram a necessidade de atualizar a arquitetura, o que fizeram seguindo as prticas escolhidas sua organizao, descrito anteriormente. Desenvolvimento tambm foi altamente iterativo. As equipes de projeto fizeram um pouco de modelagem, codificao e testes e, em seguida, repetiam se necessrio. Eles no tomaram a abordagem de srie completamente o desenvolvimento e aceitar o modelo de requisitos, em seguida, o desenvolvimento e aceitao de um modelo de anlise, e assim por diante. Isto os leva a reagir rapidamente s mudanas em seus mercados altamente competitivos e entrega rpida de software para seus usurios finais. Alm disso, a modelagem foi racionalizada. Eles modelavam o suficiente e, em seguida, iniciavam a implementao, evitando paralisia da anlise enquanto ao mesmo tempo mostrando seus modelos atualmente trabalhados (ou no) e escrevendo cdigo com base nelas. Alm disso, ambas as organizaes utilizaram ferramentas de modelagem simples. Com exceo das duas equipes de dados, os projetos preferiram esboos simples em lousas do que diagramas criados usando ferramentas CASE sofisticadas. Isso acelerou o processo de modelagem, embora possa ter retardado o desenvolvimento quando os desenvolvedores no

poderia gerar automaticamente o cdigo de seus modelos - uma caracterstica de muitos instrumentos modernos - ou fazer engenharia reversa de cdigo existente para criar diagramas para ajud-los a compreend-lo. Finalmente, a documentao nos dois projetos foi mnima. Ambas as empresas melhoraram a qualidade de sua documentao do sistema e conseguiu encontrar o "sweet spot", onde era apenas o suficiente para satisfazer as suas necessidades e nada mais. Muitos projetos tradicionais produziam documentao muito mais do que o necessrio, reduzindo suas capacidade de implementar novos recursos e s vezes at fazendo com que o projeto falhe completamente. Definir a fundao para a modelagem gil Minhas experincias sobre estes dois projetos forneceu ideias significativas para o que viria a ser a metodologia Modelagem gil. AM uma metodologia baseada na prtica para eficaz modelagem e documentao de software baseados em sistemas. Princpios e valores orientam as prticas de AM, destinados aplicao diria por profissionais de software. AM no difcil e rpido, nem um processo prescritivo - em outras palavras, ele no define procedimentos detalhados sobre como criar um determinado tipo de modelo. Em vez disso, fornece conselhos sobre como ser efetivo como um modelador. Isto diferente de metodologias de modelagem como Iconix ou Catlise que sugerem uma coleo especfica de artefatos de modelagem e descrevem como criar esses artefatos. Onde Iconix promove modelos de caso de usos, diagramas de robustez, diagramas de seqncia UML e diagramas de classe UML, AM sugere que voc aplique vrios modelos sobre seus projetos e os artefatos adequados para a situao. AM complementar modelagem mais tradicionais metodologias, ele no substitui Iconix e Catlise mas presta assessoria complementar para melhorar a sua eficcia com eles. mbito AM simplesmente modelagem e documentao. Ele foi criado para ser usado em conjunto com outros processos de software geis como Extreme Programming, Scrum, e o mtodos de desenvolvimento de sistema dinmicos, bem como "quase geis" instanciaes do Processo Unificado. AM adota os valores de XP a simplicidade, feedback, coragem, comunicao e - e estende-lo com humildade. Estes valores so utilizados para derivar uma coleco de princpios (ver Tabela 1) que, em vez da unidade da MA prticas (ver Tabela 2). Nada sobre isso verdadeiramente novo. uma reformulao de conceitos que muitos profissionais de software tm vindo a seguir por anos. Tabela 1 Os princpios de modelagem gil Princpios fundamentais Assumir simplicidade Aceitar a mudana Mudanas incrementais Modelar com um propsito Vrios modelos Trabalho de qualidade Feedback rpido Software o seu principal objetivo Permitir o prximo esforo o seu objetivo secundrio Travel ligth Princpios complementares O contedo mais importante do que a representao Todo mundo pode aprender com todos os outros Conhea os seus modelos

Conhea os seus instrumentos Adaptao local Maximizar o investimento dos interessados Comunicao aberta e honesta Trabalhar com os instintos das pessoas

Tabela 2 prticas de modelagem gil Prticas bsicas Participao das partes interessadas ativa Aplique os artefatos corretos Propriedade Coletiva Considere a testabilidade Crie vrios modelos em paralelo Criar contedo simples Fazer modelos simplificados Exibir modelos publicamente Iterar para outro artefato Modelar em pequenos incrementos Modelar com os outros Prove com cdigo Prticas complementares Atualize apenas quando di Utilize as ferramentas mais simples Aplicar padres de modelagem Aplicar padres cuidadosamente Descarte os modelos temporrios Formalizar modelos de contratos Modelar para comunicar Modelar para entender Reutilizar os recursos existentes Lies Aprendidas XYZ.net e PQR.com foram bem sucedidas porque eles seguiram um conjunto de abordagens de bom senso. Vamos explorar as lies aprendidas em XYZ.net e PQR.com e ver como eles se relacionam com AM. Assunto Pessoas. Todos trabalharam juntos para fazer o esforo ser bem-sucedido - que era to simples como isso. Operamos sob uma filosofia nas linhas de "valor dos indivduos e interaes sobre processos e ferramentas" da Agile Alliance e princpio 131 Alan M. Davis, "As pessoas so a chave para o sucesso." Voc no precisa de tantos documentos como voc pensa. Ambas as empresas construram software de misso crtica muito rapidamente, o software que ainda est em operao h vrios anos mais tarde e que foi modificado significativamente desde ento - e fizemos sem criar montes de documentao. Fred Brooks fornece conselhos semelhantes com o que ele chama de hiptese documentria: "Em meio a uma lavagem de papel, um pequeno nmero de documentos tornam-se os pivs crticas em torno do qual toda a gesto do projeto evolui". Em suma, as equipes seguiram o princpio de "travel light", produzindo apenas o suficiente documentao e atualiz-lo apenas quando necessrio, bem nos moldes da prtica do AM "Atualize apenas quando di." A comunicao crtica. A quantidade de documentao necessria foi reduzida, porque ambas as organizaes tinha um alto ambiente de comunicao. Os desenvolvedores trabalharam em conjunto, face a face com os seus colegas de trabalho e clientes (tanto marketing e equipe de vendas ou o diretor de tecnologia). Modelos foram deixados nas

paredes para que todos pudessem v-los, como sugere AM com a sua prtica "modelos de exibio em pblico." Ao fazer isso, os desenvolvedores podem se referir aos modelos, ao explicar suas estratgias para os outros e muitas vezes recebiam informaes valiosas, muitas vezes sob a forma de perguntas, vindas de pessoas que haviam tomado a tempo para olhar para os modelos. Ns tinhamos redescoberto princpio 136 de Davis, "As habilidades de comunicao so essenciais", e seu oitavo princpio "Comunique-se com clientes e usurios." As ferramentas de modelagem no so to teis quanto voc pensa. Embora honestamente tentou usar a ferramenta de modelagem UML lder na poca, bem como uma oferta de software open source, as ferramentas simplesmente no oferecem uma grande quantidade de valor. Ns no estvamos interessados em criar uma grande quantidade de documentao, e as ferramentas no geravam o cdigo para o nosso ambiente de implantao. As ferramentas CASE teis foram apemas as ferramentas de modelagem de dados a partir do qual foram impressos diagramas e cdigo DDL gerado. Ns, no entanto, tiramos partido de algumas ferramentas simples, lousas e flip-charts, e era muito eficaz de faz-lo. Esta experincia reflete os resultados e as tcnicas centradas no usurio, pela comunidade de projetos no final dos dos anos 80 e capturado na prtica do AM "Usar as ferramentas mais simples." Voc precisa de uma grande variedade de tcnicas de modelagem em seu toolkit intelectual.

As tcnicas da UML, embora til, no foram suficientes, ambas as empresas necessrios para a realizao do processo, interface com o usurio, e modelagem de dados. Alm disso, cada desenvolvedor entende algumas, mas nem todas as tcnicas de modelagem que estvamos usando, resultando em equipes de tropeo, s vezes porque algum iria tentar algum modelo usando uma tcnica mal adaptada. Estes conceitos so capturados, em princpio, AM da "Vrios modelos" e sua prtica "Aplicar o artefato direito", "Use a ferramenta certa para o trabalho" um conselho semelhante ao que nossos avs provavelmente disseram algum momento, O conceito de necessidade de mltiplas tcnicas de modelagem no nova; na dcada de 1970, os mtodos estruturados, tais como as promovidas por Chris Gane e Trish Sarson apoiou este conceito. Enquanto as equipes modelam, muitas vezes trabalham em dois ou trs diagramas em paralelo, cada um dos quais tem uma vista diferente sobre o que eles estavam discutindo, semelhante s prticas da MA "Criar vrios modelos em paralelo" e "Iterar para outro artefato ", respectivamente. Grande Projeto inicial no necessrio. Embora XYZ.net tenha passado algumas tardes na formulao de sua inicial estratgia arquitetural corporativa, que rapidamente comeou a funcionar. Da mesma forma, o arquiteto-chefe da PQR.com tambm criou um modelo inicial de alto nvel. Ento ele comeou a trabalhar com equipes individuais de implementao de partes do mesmo, atualizando seu modelo conforme necessrio. Ambas as empresas descobriram que elas no precisavam de semanas ou meses de modelagem e documentao detalhada para saber a verdade, que as horas foram suficientes. Em vez disso, eles trabalharam no lema da prtica AM "Modelo em pequenos incrementos", modelar a arquitetura um pouco e ento explorar estratgias de comprov-las ou simplesmente com o cdigo de comear a trabalhar no software propriamente dito. Em seu ensaio "Passar a Palavra", Brooks oferece conselhos semelhantes - que os arquitetos devem ser capazes de mostrar uma implementao de suas ideias, que deve ser capaz de provar que sua arquitetura funciona na prtica. Reutilize a roda, no reinvent-lo. Na XYZ.net, aproveitamos de software open-source sempre que podamos, a construo de sistemas de misso crtica foi realizada com rapidez e eficcia como resultado. Atravs de cdigo aberto, tinha redescoberto princpio 84 Davis: "Voc pode reutilizar sem um grande investimento." Ns reutilizado mais de software de fonte aberta apenas, mas que tambm adotou padres da indstria, sempre que possvel, existindo estratgias arquiteturais, sempre que possvel, e aplicados os padres de design quando aplicvel. Descobrimos que havia uma riqueza de material disponvel para ns quando optamos por reutiliz-lo, apoiando a prtica do AM "Reutilizar recursos existentes." Abordagens geis para desenvolvimento de software funcionaram para estas duas empresas Internet-based. Ambos XYZ.net e PQR.com aplicaram os existentes princpios comprovados de

desenvolvimento de software em novas formas de entregar complexa, software de misso crtica em um ambiente altamente iterativo e de forma incremental. As lies aprendidas se aplicam para alm do desenvolvimento da Internet: a maioria das organizaes podem se beneficiar de uma arquitetura compartilhada entre projetos, bem como mais eficaz e eficiente de modelagem e prticas de documentao. Muitos dos princpios e prticas modernas de processos de ponta de desenvolvimento de ponta so os mesmos (ou ligeiramente modificada) princpios e prticas do passado. Embora os fundamentos ainda so fundamentos, a maneira em que os fundamentos so aplicados mudou gil no prescritiva.