Equiparação de tipos entre SQL Server e C#

Boas pessoal!!!

Uma das coisas que sempre preciso é de uma tabela de equiparação de tipos entre sql e c# e agora estou colocando essa tabela aqui pra ajudar todo mundo!

 

SQL Server data type          CLR data type (SQL Server)    CLR data type (.NET Framework)  
varbinary                     SqlBytes, SqlBinary           Byte[]  
binary                        SqlBytes, SqlBinary           Byte[]  
varbinary(1), binary(1)       SqlBytes, SqlBinary           byte, Byte[] 
image                         None                          None

varchar                       None                          None
char                          None                          None
nvarchar(1), nchar(1)         SqlChars, SqlString           Char, String, Char[]     
nvarchar                      SqlChars, SqlString           String, Char[] 
nchar                         SqlChars, SqlString           String, Char[] 
text                          None                          None
ntext                         None                          None

uniqueidentifier              SqlGuid                       Guid 
rowversion                    None                          Byte[]  
bit                           SqlBoolean                    Boolean 
tinyint                       SqlByte                       Byte 
smallint                      SqlInt16                      Int16  
int                           SqlInt32                      Int32  
bigint                        SqlInt64                      Int64 

smallmoney                    SqlMoney                      Decimal  
money                         SqlMoney                      Decimal  
numeric                       SqlDecimal                    Decimal  
decimal                       SqlDecimal                    Decimal  
real                          SqlSingle                     Single  
float                         SqlDouble                     Double  

smalldatetime                 SqlDateTime                   DateTime  
datetime                      SqlDateTime                   DateTime 

sql_variant                   None                          Object  
User-defined type(UDT)        None                          user-defined type     
table                         None                          None 
cursor                        None                          None
timestamp                     None                          None 
xml                           SqlXml                        None

Bom, por hoje é isso, até mais!

Deixe um comentário

Ouse discutir

Hoje estava conversando com minha esposa e para variar discordamos de um assunto qualquer. Depois de um pouco de discussão parei para analisar que as discussões quando bem utilizadas servem para abrir novas portas. Então pensei, e no mercado de trabalho como isso funciona? Quantas pessoas tem coragem de discutir de forma sadia em seus empregos? E quantas pessoas estão preparadas para discutir e abrir mão de seus conceitos (e até de preconceitos)? Entramos em outra discussão que é o medo, várias pessoas tem medo de discutir e arcar com alguma consequência mais drástica. E até na série de tv House existe uma exploração do médico com sua equipe da discussão para alimentar ideias. A discussão é muito bem vinda quando todos os lados querem ver o bem de um objetivo comum, como quando estamos trabalhando em algum projeto e ideias diferentes vem a tona. A discussão, quando sadia, leva a uma melhoria no projeto. E o que seriam discussões não sadias? Seriam discussões com base em ego, sem propósito. Isso deve ser evitado a todo custo, pois gera um atrito desnecessário a equipe. Segue um link muito interessante: http://www.ted.com/talks/margaret_heffernan_dare_to_disagree.html

Deixe um comentário

O que é eXtreme Programming – Parte 5

 

Hoje vamos abordar o conjunto de práticas da XP, que engloba gerenciamento e engenharia de software. Quando vemos empresas falando que usam Scrum e XP geralmente são algumas práticas da XP que o pessoal usa nas sprints do Scrum. Um ponto que acho muito importante é que todas as praticas reforçam umas as outras, conforme a imagem abaixo:

clip_image001[4]

Bom vamos às práticas:

Jogo do Planejamento: Tanto a equipe de Desenvolvimento quanto as pessoas da área de negócios precisam manter sua comunicação aberta para discutir aonde e como chegar. O pessoal de negócios deve decidir sobre:

Escopo: Quanto do problema deve ser resolvido para chegar a uma solução que retorne valor para o cliente

Prioridade: Qual dos itens é mais importante para o cliente? O que deve ser desenvolvido primeiro que dará ao cliente uma vantagem competitiva no mercado, ou que diminuirá seu trabalho?

Data de entrega: Sabemos sempre que o cliente quer tudo para ontem, mas do tudo que deve ser feito o que fara a diferença e quando fara a diferença?

Mas a área de negócios não pode tomar toda a decisão sozinha, o time deve ajudar com:

Estimativas: Quanto tempo levará para implementar uma determinada funcionalidade?

Consequências: O time deve sempre orientar o cliente e a área de negócios para as consequências das escolhas deles, como por exemplo, trabalhar com determinada linguagem ou SGDB pode ajudar ou atrapalhar dependendo do tipo do produto a ser desenvolvido.

Processos: Como o time vai trabalhar, quais métricas vão usar?

Cronograma detalhado: O que será feito em cada história? Qual o item de maior risco do projeto? O time deve opinar junto à área de negócios sobre o que deve ser desenvolvido primeiro, atacando de preferencia os itens críticos logo de cara.

Entregas Frequentes: Cada entrega deve ter o menor tamanho possível que traga o maior valor possível para o negócio. E cada entrega deve fazer sentido, nada de fazer funções que não tenham sentido para mostrar que esta entregando alguma coisa, cada entrega deve sempre ter função definida e valor gerado.

Metáfora: Uma ou mais frases que mostrem qual o caminho do projeto, mostrando claramente o que o projeto faz, qual a sua utilidade. E uma metáfora pode mudar no meio do caminho, quando se descobre alguma coisa nova, ou há uma mudança nos rumos do projeto. A metáfora seria como uma descrição da visão panorâmica do projeto, e como uma visão ela deve nos mostrar o caminho a ser tomado.

Projeto Simples: Os pontos fundamentais para um projeto bem feito, com qualidade e simples são:

Ter e executar testes sem falhar.

Não ter código duplicado.

O código deve expressar o que ele deve fazer para os programadores.

Acrescente o que você precisa quando você realmente precisar.

Todos os pontos acima fazem você ser cuidadoso com seu código, e um grande ponto da simplicidade é: Desenvolva somente o necessário para resolver o problema. Geralmente somos condicionados a pensar no futuro, a tentar adivinhar o que vai ser necessário. Na XP você deve apenas resolver o problema, o futuro é incerto e provavelmente o que você teme não chegará a acontecer. E se acontecer seu sistema será simples o bastante para que ele seja resolvido sem dores de cabeça.

Teste: Seu programa deve ser testado continuamente, pois os testes além de dizerem que aquele trecho esta funcionando trazem segurança para futuras alterações. E quando falamos de teste não estamos só falando de teste de unidade, mas também de teste de funcionalidade que seus clientes devem fazer para terem a segurança que determinada funcionalidade atende o que eles desejam.

Refatoração: A refatoração do código é um dos itens mais importantes, pois o código deve sempre estar da melhor forma possível e nem sempre acertamos um código de primeira. A refatoração deve ser feita por todo o time em todo o código, sempre que você for trabalhar em alguma funcionalidade e ver que pode melhorar alguma coisa faça.

Programação em Par: Uma das práticas mais polemica da XP, a programação em par é a melhor ferramenta para a disseminação de conhecimento e nivelamento dentro de uma equipe. Apesar da XP pregar que todo o código deve ser produzido em par, em minha opinião existem casos em que não há necessidade da programação em par, como por exemplo, a realização de um CRUD (desde que você não tenha nenhum estagiário na sua equipe, senão até no CRUD é bom fazer pareamento com o estagiário para ele ganhar aprendizado e confiança). E aquela história de que eu poderia estar aproveitando dois programadores em funcionalidades diferentes em vez de dois em uma funcionalidade única é real? Na minha experiência e da do Kent Beck não (olha eu me igualando ao Kent rsrsrsr). O que ocorre quando realmente esta se programando em par é que você tem duas pessoas analisando um problema, logo uma esta programando e o parceiro pode ir analisando o código escrito e já ir pensando em testes, vendo se pode melhorar alguma coisa, enfim, os dois estão concentrados em resolver o mesmo problema e o velho ditado que duas cabeças pensam melhor que uma neste caso é a mais pura verdade. Mas ai você lendo este texto vai me falar “Denis, você ali em cima realmente, por quê?”. Eu disse o realmente porque se você não tiver uma equipe realmente comprometida à programação em par não vai funcionar, pois a pessoa que não esta com o teclado e mouse vai estar com o smartphone ou tablet navegando, olhando o twitter, vendo e-mail e nada de ajudar na solução do problema. Uma equipe motivada é tudo em qualquer metodologia, mas no XP é fundamental.

Propriedade Coletiva: Todo mundo é dono do código e ponto. Não deve existir nenhuma funcionalidade em que só exista uma pessoa no time que mexa. Todo mundo pode e deve trabalhar em todo o sistema, sem reservas. Isso da um senso de responsabilidade em todos de manter tudo em ordem.

Integração Continua: Não adianta eu ter iterações de duas semanas se cada programador só vai integrar o código que esta fazendo quando terminar o prazo. A integração deve ser feita sempre no termino de uma tarefa. E nessa integração o par que programou deve acompanhar os resultados dos testes para ver se não quebrou nada. E quanto menor for o código integrado mais fácil é de se fazer a analise caso de alguma coisa errada.

Semana de 40 Horas: O time não é uma maquina que faz trabalho sem parar e o projeto não é um projeto de chão de fabrica aonde as pessoas abaixam a cabeça e cada um faz seu trabalho sem pensar. Programar exige muito e quanto mais cansado estiver seu time menos ele vai render. Uma semana de hora extra pode ser bem aceito, mas duas semanas seguidas quer dizer que existe alguma coisa errada nas suas estimativas ou com seu time e que você deve analisar isso e não continuar forçando o time com uma carga horaria desmotivadora.

Cliente presente: Esta é outra pratica controversa, pois geralmente o cliente não vai ter alguém para disponibilizar a acompanhar a equipe enquanto é feita aquela funcionalidade, mas isso seria o ideal. Ter sempre uma pessoa do cliente para tirar dúvidas ali do seu lado, verificando sempre se esta tudo certo é o melhor dos mundos, mas caso isso não seja possível deve-se entrar em acordo com o cliente para que o time tenha acesso o mais rápido e fácil possível às pessoas da empresa para matar suas dúvidas.

Padrões de Codificação: Se temos o time trabalhando em tudo a todo o tempo devemos ter um padrão a ser seguido para que quando o programador A for alterar alguma coisa que o programador B fez, ele saiba como as coisas devem estar. Se não existe padrão um código pode estar bom para mim e ruim pra você. Com uma padronização saberemos quando o código esta ruim ou bom (na maioria das vezes).

No próximo post vamos falar de como todas essas práticas trabalham juntas apoiando umas as outras.

Abraços.

Deixe um comentário

O que é eXtreme Programming–Parte 4

Antes de falarmos sobre as práticas da XP vamos falar de uma coisa muito importante que aparentemente as equipes "esquecem", que são as atividades básicas do desenvolvimento de software:

Codificar: A melhor forma de aprender sobre o projeto em que estamos trabalhando é usando o código fonte. No final das contas tudo roda em cima do código fonte, o sistema que o cliente vai usar na entrega, o aprendizado do time sobre o projeto é com o código fonte, enfim o código fonte é o maior valor integrável do projeto.

Testar: A melhor forma de saber se seu código fonte esta fazendo o que realmente deve fazer é testando. O teste mostra exatamente se o código está fazendo o que deve realmente fazer.

Ouvir: Na nossa profissão vemos vários colegas (ou nós mesmos) que acham que sabem tudo e só existe uma verdade: Desenvolvedor não sabe nada. Por mais que você acha que conhece a rotina de trabalho do seu cliente, procure ouvir sempre o que ele tem a dizer, o que ele tem a mostrar e aprenda com ele. Outro ponto importante é a parte de teste, como testar se você não sabe o que deve testar? Logo testes devem ser feitos e acompanhados pelo seu cliente para que eles mostrem exatamente o que deve ser feito e testado.

Projetar: Podemos seguir a sequencia, ouvir, fazer um teste, codificar e executa-lo. Poderíamos ficar neste ciclo por algum tempo, mas sem projetar nada em algum momento ficaria impossível de continuar neste ciclo pois tudo estaria desorganizado. Mas e quando devemos projetar? Veremos nas praticas que projetamos todo o tempo.

Enfim estes são os pilares do trabalho de um time de desenvolvimento. Gosto muito de uma definição do Kent Beck:

"Então você codifica porque se você não codificar não terá nada. Você testa porque se você não testar você não saberá quando você terminou de codificar. Você ouve porque se você não ouvir você não saberá o que codificar ou o que testar. E você projeta para que você possa codificar, testar e ouvir indefinidamente. Isso é tudo. Estas são as atividades que devemos ajudar a estruturar."

E para que estas atividades tenham o melhor resultado possível usamos as práticas da XP, mas vamos ver cada uma delas detalhadamente nos próximos post´s.

Abraços.

Deixe um comentário

O que é eXtreme Programming – Parte 3

Os valores são a base para a XP, mas como os valores são muito amplos temos um alicerce para nos ajudar, a saber, que estamos seguindo os valores de uma forma precisa, que a XP chama de princípios. São eles:

Feedback Rápido: O feedback é muito importante, mas não podemos ter esse feedback muito tarde, pois assim não saberemos se o que esta sendo feito esta correto. E tendo o feedback a segunda parte é aplica-lo o mais rápido possível, assim teremos sempre um curto espaço de tempo entre o feedback dado pelo cliente e seu retorno ao mesmo. O aprendizado desta forma é muito mais concreto, diria até palpável, do que ter um feedback demorado ou mesmo ter um feedback rápido mas não coloca-lo em pratica.

Simplicidade presumida: Este é um dos princípios que os desenvolvedores tem mais dificuldade em assimilar, pois somos condicionados desde pequenos a planejar para o futuro. Mas na XP temos sempre que pensar no presente, no que estamos desenvolvendo agora, no problema que estamos resolvendo agora. Mesmo sabendo que mais para frente teremos mais itens a adicionar no software que esta sendo construído quem garante que realmente usaremos estes itens, que eles realmente serão necessários? Vamos manter a solução o mais simples possível para resolver simplesmente aquele problema, e vamos confiar em nossos conhecimentos técnicos para que quando outras alterações apareçam as façamos da melhor forma possível.

Mudanças incrementais: Mudanças grandes devem ser feitas em pequenos passos. Quanto menor o passo mais fácil de saber para onde ele esta levando. E quanto maior o problema, mais fácil resolve-lo dividindo em partes.

Aceitação de mudanças: Toda mudança no software é bem vinda, pois geralmente ela é um feedback mostrando qual o caminho que o desenvolvimento deve seguir.

Alta qualidade: Este é um dos principais princípios, pois dentro das quatro variáveis de desenvolvimento de projetos (escopo, custo, tempo, qualidade) ela é a única que não deveria ser uma variável, pois quando se trabalha sem qualidade não se tem orgulho do trabalho feito. Qualidade no seu trabalho leva a orgulho do produto final. Os únicos valores que a qualidade deve aceitar são “excelente” e “insanamente excelente”.

Estes são os princípios fundamentais, vamos falar sobre os princípios menos fundamentais:

Ensinar Aprendendo: Em vez de colocar uma cartilha com “Faça XYZ depois de WKX” ou “Faça 30 testes unitários” vamos mostrar como chegamos a nossos padrões, vamos ensinar como analisar o que deve ser feito, como saber se a quantidade de testes esta boa.

Investimento inicial pequeno: Este é um item controverso. Devemos tentar enxugar o máximo possível para começar a desenvolver, mas esse máximo pode ser um para mim e outro para você, então estes pontos tem que ser debatidos por clientes e desenvolvedores, para se chegar a um bom consenso.

Jogar para ganhar: Apesar de parecer um item relevante, ele mostra a sua importância em ver a diferença entre jogar para ganhar e jogar para não perder. A maioria dos times de desenvolvimento cerca-se de documentos para que no fim se der alguma coisa errada eles estejam “protegidos” pela documentação. Temos que ter consciência que estamos todos no mesmo time e jogamos todos do mesmo lado, então vamos dar o melhor de nós e fazer tudo da melhor forma possível.

Experimentação concreta: Cada vez se desenvolve alguma coisa no projeto e não se testa a probabilidade de que esteja errado é grande. E isso acontece também com requisitos. Todas as ações do projeto deveriam ser testadas, claro que usando sempre o bom senso.

Comunicação honesta e franca: Toda a equipe deve ter em mente que a comunicação é um dos itens mais importantes do projeto e no mesmo devemos ter liberdade para comunicar tudo o que esta ocorrendo de bom e ruim a todos sem ter medo de represarias, ironias ou preconceitos.

Trabalhar a favor dos instintos do pessoal e não contra ele: Pessoas gostam de ganhar, de trabalhar em um projeto que tenha qualidade, que seu trabalho seja reconhecido e a melhor forma de conseguir isso é deixando a equipe se auto gerenciar, sabendo que cada um vai fazer o que escolher, vai dar o seu melhor.

Aceitação de responsabilidade: A imposição de qualquer trabalho com o tempo vai tirando o animo das pessoas. Para resolver isso a pessoa deve aceitar a responsabilidade e não ser imposta. Com isso o time vai se auto gerenciando e todos estão sempre fazendo o que gostam e o que não gostam, mas sempre por escolha e não imposição. Isso não quer dizer que você sempre fará o que quiser, mas se existem varias tarefas para serem feitas alguém escolherá ela, seja às vezes você ou outro membro do time.

Adaptação Local: Não existe uma bala de prata para seus problemas. A XP vai te mostrar muitos caminhos e você deve experimentar todos e depois disso você vai começar a modificar e adaptar, mas sempre tendo em vista os valores da XP.

Viajar com pouca bagagem: Os membros de um time devem sempre ter em sua consciência que tudo pode mudar, a única coisa que temos de certeza em um projeto é o teste e o código. E quando o teste ou o código não atende mais eles também devem ser descartados sem peso na consciência. Mantenha sempre o necessário.

Métricas genuínas: Na XP adotamos métricas que podemos manter. Por exemplo, é muito mais pratico dizer “Este item cabe dentro de uma iteração de 2 semanas” do que dizer “Este item vai demorar 14.567 horas para ser feito”. Vamos manter métricas que podemos confiar.

No próximo artigo vamos falar das práticas da XP.

Abraços.

Deixe um comentário

O que é eXtreme Programming – Parte 2

Vamos continuar com a introdução ao Extreme Programming, falando hoje sobre os valores do XP. Antes de tudo vamos deixa uma coisa muito clara: Os valores são à base desta metodologia. Não adianta nada saber de cor todas as praticas se você não conseguiu assimilar os valores, pois as praticas derivam dos valores.

Feedback

Esse é um ponto estratégico não apenas no XP, mas em qualquer metodologia ágil. Quando falamos de Feedback, estamos olhando um contexto amplo da palavra, ou seja, o feedback entre o cliente X time, time X cliente, time X time. O grande problema do modelo em cascata era que falávamos com o cliente no começo do projeto, no levantamento de requisito (cliente X analista) e depois disso só voltávamos a falar com ele no final do projeto, na implantação (desenvolvedor X cliente). Quase não existia Feedback neste meio tempo. Já o XP prega que devemos ter iterações curtas, entre 2 a 4 semanas. Com este tempo nas iterações, fazemos o levantamento das estórias que serão implementadas com o cliente (cliente X time), durante a iteração continuamos com o feedback do cliente (pratica do cliente presente) e depois devolvemos o feedback com software funcionando (time X cliente). Com isto temos uma troca muito grande de feedback, pois o cliente depois de 2 semanas consegue visualizar as estórias funcionando e avaliar se era realmente aquilo que ele queria e o time com o cliente presente consegue sanar qualquer dúvida que aparece rapidamente e sem intermediários. Com todo este feedback entre cliente e time, a afinação entre ambos acaba ocorrendo naturalmente, e o cliente já nas primeiras interações começa a perceber o que ele vai receber de valor. Entre time X time a maior forma de feedback vem com a programação em par, pois todos estão mexendo em todo o código em todos os momentos, logo a uma grande troca de conhecimento, e não apenas aquele velho gesto de eu só faço tal coisa, fulano só faz tal coisa. Outro feedback importante é o TDD e a integração continua, onde criamos teste que podem e devem ser validados durante todo o ciclo de vida do software, mostrando sempre que tudo esta em ordem.

Comunicação

O XP prega que você deve ter um membro do cliente presente juntamente com a equipe de desenvolvimento, ou caso ele não esteja presente que seja o mais acessível possível, para dizimar qualquer dúvida que aparece durante a interação, e nada melhor do que uma conversa cara a cara para resolver todos os problemas, dúvidas, etc. No XP um dos pontos que a empresa de desenvolvimento e o cliente têm que saber é que os dois jogam do mesmo lado, então nada de “me manda esta informação por e-mail para deixar documentado”. Vamos ter documentação sim, mas nada de paranoia de que o cliente não pediu isso ou aquilo, ou não recebi seu e-mail pedindo tal coisa, etc. No cara a cara o cliente vai esclarecer sua dúvida e vai ver se você realmente conseguiu entender o que ele quis dizer. E uma comunicação limpa, direta, é um dos meios mais eficazes para se conseguir sucesso em um projeto. Outro ponto importante na comunicação é a mesma entre os integrantes do time. Usando algumas práticas a comunicação se mantem clara, mas o esforço disso acontecer deve ser de todos.

Simplicidade

A maioria dos desenvolvedores já viu uma pesquisa que fala que 70% das funcionalidades de um software não são utilizados pelo cliente. Então fica a questão, para que desenvolver uma funcionalidade X se ela não vai ser utilizada. No XP devemos manter sempre as coisas o mais simples possível, tanto para evitar desperdício de desenvolvimento, quanto para tornar seu sistema mais fácil de testar, pois quando falamos em simplicidade, estamos não só falando do software em si, mas do desenvolvimento de sua estrutura. E fazer as coisas simples não quer dizer que será simples fazer. Muitas vezes o complicado é mais fácil do que o simples. E simplicidade não quer dizer sem qualidade, ao contrario, já que vamos fazer o mais simples possível, vamos manter sempre a qualidade.

A simplicidade também deve ser mantida no código, quanto mais simples seu código, mais fácil de entender, então nada de sair usando técnicas que não serão necessárias agora, vamos deixar isso para a refatoração no momento certo.

Coragem

Bom, a coragem é talvez um dos principais pontos, pois para utilizar o XP você vai ter que ter muita coragem de deixar várias raízes para trás e plantar novas idéias. É muito difícil para as pessoas deixarem sua zona de conforto, mas no XP você vai fazer isso direto, ou com eu vejo, você vai mudar sua zona de conforto, pois quando você assimila o XP ou qualquer outra metodologia ágil, ela se torna parte de você. No livro do Vinicius Manhães Teles ele cita uma lista de itens em que o desenvolvedor vai ter que ter coragem, entre elas: trabalhar com iterações, manter o sistema simples, permitir que o cliente priorize as funcionalidades, etc. Conforme fomos falando do XP, tudo nele requer coragem, então se você é muito apegado a sua zona de conforto sugiro que continue nela. Ou então jogue tudo pra cima e venha para o XP, onde te garanto que você vai sentir enorme prazer em trabalhar, e principalmente ver a satisfação de seu cliente!

Até

Denis.

Deixe um comentário

Introdução ao Extreme Programming–Parte 1

O XP (eXtreme Programming) é uma metodologia de desenvolvimento de software ágil, criada em 96 por Kent Beck, e é voltada principalmente para projetos em que os requisitos mudam constantemente e OO. Claro que se pode usar com um projeto em que os requisitos não mudem com frequência, mas na visão do XP as alterações são sempre bem vindas! Dentro do XP temos Valores e Princípios que vou listar a seguir e que vamos conversar sobre cada um deles em outros tópicos.

Valores:

Comunicação, Simplicidade, Feedback, Coragem.

Praticas:

Cliente Presente, Jogo do Planejamento, Stand Up Meeting, Programação em Par, Desenvolvimento Guiado a Testes(TDD), Refactoring, Código Coletivo, Código Padronizado, Design Simples, Metáforas, Ritmo Sustentável, Integração Continua, Releases Curtos.

Existem alguns livros em português sendo que destaco o do Vinícius Manhães Teles Extreme Programming. Alias o blog a Improveit é um grande local para informações sobre XP, Agile, etc.. Outro livro principal é Programação Extrema(XP) Explicada do Kent Beck.

No site da InfoQ Brasil também tem um livro traduzido muito bom, o Scrum e XP direto das trincheiras. Todos os meus post´s vão ser baseados nestes livros.

Agora um ponto bem interessante: Porque falar de XP e não de Scrum (que alias esta na moda hoje)?

Apesar de gostar muito do Scrum, em desenvolvimento se você pensar apenas no Scrum, você vai pensar apenas na gerencia. Mas sabemos que o desenvolvimento não é feito apenas de gerencia, mas também de engenharia, e o Scrum pelo menos até hoje não tem nada de engenharia (OK temos alguns treinamentos de scrum que abordam engenharia, mas não podemos pelo menos por enquanto falar que é Scrum). Em compensação, XP abrange toda a parte de engenharia necessária para termos um ótimo produto, com muita qualidade.

Até.

Denis.

Deixe um comentário