O primeiro dia da promoção “Divulgue o VS2010 e ganhe prêmios” foi bastante movimentado. Tivemos vários participantes comentando as novidades do produto, entre elas Entity Framework 4 com SQL Azure, dicas do novo Debug do VS2010, TDD e muito mais. Confira alguns posts interessantes:
Visual Studio 2010: facilitando a vida do desenvolvedor – Intro (@allistonCarlos)
Versões Express do Visual Studio 2010 (@kelps)
Criando tabelas no SQL Azure através do Entity Framework (@djonatastenfen)
Baixem o Beta2 do Visual Studio 2010 (@waltercoan)
Fixando variáveis no Debug do VS2010 (@marcelodeaguiar)
Quer acessar seu SQL Azure diretamente do VS2010? SQL Azure Explorer (@allistonCarlos)
Aplicando TDD no Visual Studio Team System 2010 (@allistonCarlos)
Silverlight 3 e F# no VS2010 (@djonatastenfen)
Visual Studio 2010: facilitando a vida do desenvolvedor Parte 1 - WPF 4 (@allistonCarlos)
Eu ainda não fiz a apuração (aliás isso vai dar um trabalho), mas tenho a impressão que o @allistonCarlos está levando por enquanto.
E devido ao grande sucesso da promoção e também atendendo a alguns pedidos que diziam que os prêmios estavam muito “mixurucas”, resolvemos adicionar alguns novos prêmios.
É isso aí, agora o vencedor além de ganhar um Voucher com 100% de desconto para qualquer certificação Microsoft e uma Mochila para Notebook, ganhará também um uma licença full do Visual Studio Team Foundation Server e também uma licença do Visual Studio Team Suite, a mais completa do pacote Visual Studio.
É isso galera, continuem postando e ganhe mais de R$ 5.000,00 em prêmios :-)
Abraços
André Dias
Divulgue o Visual Studio 2010 em seu twitter ou em seu blog e ganhe um Voucher para qualquer Prova de Certificação Microsoft 100% Free e uma Mochila para Notebook do TechNet.
Como funciona?
- Divulgando alguma notícia sobre o VS2010 no twitter: 1 ponto (Não vale RT e as mensagens devem ser sempre em português)
- Explorar alguma nova feature do VS2010 em seu blog: 10 pontos
- Publicar algum caso de sucesso utilizando o Visual Studio (qualquer versão): 30 pontos
Quem fizer mais pontos leva, não é sorteio. Publicou, levou !! :-)
Utilize a hash tag #VS2010PREMIO para que eu possa identificar o seu post.
A promoção será encerrada no dia 22/11 às 23:59 e o ganhador será divulgado no dia 23/11.
Tá esperando o que? Já está valendo!
Atualizado 10/11/2009:
Regras para Caso de Sucesso:
O caso de sucesso precisa ser público, logo deve estar publicado em seu blog ou até mesmo no site de sua empresa. Não é necessário divulgar detalhes do cliente como nome, contato ou nome do projeto, porém essas informações deverão ser enviadas para o meu e-mail para que o case seja validado.
Basicamente, você precisa nos dizer como o Visual Studio ou o Team Foundation Server o ajudou a obter sucesso com o projeto e se o seu caso de sucesso for classificado entre os melhores, poderá ser publicado no próprio site da Microsoft.
O meu e-mail é andre.dias [at] microsoft.com e você pode encontrar exemplo de casos de sucesso em http://www.microsoft.com/brasil/Casos/busca.aspx?Texto=Team+System
Abraços
André Dias
Hoje, tivemos mais uma reunião do grupo .NET Architects cujo tema discutido foi Scrum vs PMBOK. Foi uma reunião diferente do padrão que estamos acostumados já que não tivemos palestra e optamos por fazer uma mesa redonda para discutir o assunto. Apesar de termos convidados alguns PMPs para a discussão, não tivemos a presença de nenhum e inicialmente a defesa do PMBOK foi realizada por mim e pelo Victor Cavalcante. Durante a discussão, outros membros chegaram e nos ajudaram na defesa e o Giovanni Bassi liderou o lado do Scrum com o apoio de todos os outros membros presentes.
Tivemos aproximadamente 2 horas de discussão onde conversamos sobre os benefícios dos dois modelos, cenários adequados para cada modelo, formas de contratos, etc. Obviamente, as opiniões foram muito divergentes mas a mensagem final que ficou para mim foi "Scrum e PMBOK são complementares porém com algumas práticas conflitantes. Podemos combiná-los sempre que fizer sentido para o negócio e for necessário para garantir o ROI".
Quando cheguei em casa, eu publiquei um resumo da reunião no twitter, o que acabou chamando a atenção de algumas pessoas, entre elas o Renato Ferracini, vice-presidente do PMI-SP e acabamos iniciando uma nova discussão sobre o assunto através do twitter mesmo. Basicamente, o Renato apresentou uma visão muito alinhada com o que o Ricardo Vargas, presidente mundial do PMI, disse no último Scrum Gathering Brazil. Ele citou os benefícios da agilidade, a possível integração com o PMBOK, porém não abriu mão do comando-controle.
Como eu achei a discussão bastante interessante, eu extraí o conteúdo do twitter e publiquei abaixo para facilitar a leitura. Como vocês verão nas mensagens abaixo, fizemos um convite ao Renato para conversarmos melhor sobre esse assunto no grupo e em breve teremos novidades. Aguardem!!
Até a próxima
André Dias
--
andrediasbr: Saldo positivo no #DotNetArchitects hoje. Como não tinhamos ninguém para defender o #PMI, eu e o @vcavalcante fizemos esse papel.
andrediasbr: Apesar de não termos nenhum PMP na reunião, acho que a discussão foi válida. Algumas das mensagens que ficaram, foram:
andrediasbr: #PMBoK e #SCRUM são complementares porém com algumas práticas conflitantes. Pode-se combiná-los se fizer sentido para o seu negócio (ROI)
RenatoFerracini: @andrediasbr Pois é, eu tentei participar representando o PMI mas ñ deu. #DotNetArchitects #PMI
vcavalcante: @RenatoFerracini pena que você não pode ir, foi muito interessante.
RenatoFerracini: @vcavalcante Pois é, eu queria participar virtualmente mas soube tarde demais e não responderam minhas perguntas. Mas adoro estes assuntos!
RenatoFerracini: @andrediasbr Você poderia me dizer onde há conflito? Eu conheço bem ambos e não vejo nenhum. #PMBOK #SCRUM
andrediasbr: @RenatoFerracini No #PMBOK eu tenho a figura central do GP gerenciando todo o time. No #Scrum, o gerenciamento é realizado por todo o time.
RenatoFerracini: @andrediasbr Errado. No #PMBOK o GP compartilha o gerenciamento com a equipe. No #Scrum o Scrum Master faz o mesmo sem o "título" de GP.
RenatoFerracini: @andrediasbr O #Scrum dá nomes diferentes a práticas e funções conhecidas mundialmente e tenta vender isso como novo.
andrediasbr: @RenatoFerracini Sim, o GP pode compartilhar o gerenciamento com o time, mas a responsabilidade ainda é dele, o comando é do GP, correto ?
andrediasbr: @RenatoFerracini E se eu tenho alguém comandando, eu perco um dos princípios do Scrum é que ter um time auto-gerenciável.
RenatoFerracini: @andrediasbr É uma questão de atitude, André. Soft skills. Conhecendo sua equipe você pode saber o quanto compartilha e o quanto comanda.
RenatoFerracini: @andrediasbr O Scrum simplifica isso partindo da PREMISSA que a sua equipe terá apenas profissionais totalmente capacitados (seniores).
andrediasbr: @RenatoFerracini Renato, desculpe mas você está enganado, o #Scrum não tem essa premissa de trabalhar apenas com profissionais seniores.
andrediasbr: @RenatoFerracini Se eu tenho pessoas que não tem skills de auto-gerenciamento, isso é um impedimento e o ScrumMaster deve resolver isso.
RenatoFerracini: @andrediasbr Sim, eu sei. Sou Scrum Master também. Como eu falei, é um tipo de comando.
vcavalcante: @RenatoFerracini discordo desta última afirmação, eu conheço várias equipes que não tem apenas profissionais seniores.
vcavalcante: @RenatoFerracini e trabalham muito bem com scrum.
RenatoFerracini: @vcavalcante Mas não é o que diz o Scrum. Desse jeito se está trazendo RISCOS para o projeto.
vcavalcante: @RenatoFerracini em nenhum momento o Scrum fala que devemos trabalhar somente com profissionais seniores.
RenatoFerracini: @vcavalcante Bom, aí vou ter que procurar nas minhas referências para poder comprovar. Mas até onde eu saiba é sim.
giovannibassi: @renatoferracini Pois é. Premissa do Scrum: times autogerenciados, SEM gerente de projeto. A não ser que vc chame ele seja uma secretária.
RenatoFerracini: @andrediasbr Sempre existe um comando. O auto-gerenciável é apenas no que se refere aos pacotes de trabalho (sprints)...
andrediasbr: @RenatoFerracini Sim, sempre há comando, mas no nível executivo. Nas atividades de desenvolvimento, não há controle no Scrum.
RenatoFerracini: @andrediasbr Concordo plenamente. E é o mesmo que um bom gerente de projetos deve fazer, deixar a equipe se desenvolver...
RenatoFerracini: @andrediasbr ... Fica sem trabalhar de papo para o ar sem cumprir prazos para vc ver o que acontece.Se alguém te demite é pq vc É comandado.
andrediasbr: @RenatoFerracini Se eu ficar sem trabalhar, vou comprometer a meta do time. O próprio time vai me cobrar, não preciso de um gerente pra isso
RenatoFerracini: @andrediasbr Quem te demite, é o time ou o seu chefe?
andrediasbr: @RenatoFerracini Quem demite normalmente é o RH, não o GP. Ele apenas cita as razões, da mesma forma que o time scrum faz.
RenatoFerracini: @vcavalcante Ou no Scrum existe algum processo para prover treinamento à equipe?
vcavalcante: @RenatoFerracini o time pode detectar a necessidade de treinamento se isso se tornar um impedimento, ai entra o Scrum Master para resolver.
RenatoFerracini: @andrediasbr ... Gerente de projetos do tipo sargentão é ultrapassado há décadas. Lembra "O Monge e o Executivo"?
andrediasbr: @RenatoFerracini Eu sei, mas é um problema já relatado pelo Ricardo Vargas, há varios PMPs "Sargentão" que aplicam o PMBoK de forma errada
RenatoFerracini: @andrediasbr E eu concordo com ele. O RV é CSM, PMP e presidente do PMI. Ele, como eu, percebe que são coisas semelhantes...
RenatoFerracini: @andrediasbr ...Muitos PMPs precisam entender que controle não é andar com o chicote na mão! O Scrum ajuda a mudar essa visão.
andrediasbr: @RenatoFerracini Sim, no #ScrumGathering ele disse que acredita em Scrum e PMBoK juntos, só não acredita em times auto-gerenciaveis. :-)
vcavalcante: @RenatoFerracini mas não dá para usar scrum sem times auto gerenciaveis. Esse fou um questionamento que levantamos para o RV.
RenatoFerracini: @andrediasbr @vcavalcante @giovannibassi Gente, o papo está muito bom, fizemos um chat nesse Twitter agora. Vou tentar responder tudo...
andrediasbr: @RenatoFerracini Eu também acredito em Scrum junto com PMBoK, Scrum com CMMi, Scrum com XP .. Mas não dá pra afirmar que não há conflitos.
RenatoFerracini: @vcavalcante Eu acredito q isso funciona em um cenário q permite respostas lentas como essa. O ideal seria agir de forma mais pró-ativa, né?
RenatoFerracini: @vcavalcante Identificar a necessidade de treinamento ANTES que isso se torne um impedimento.
RenatoFerracini: @vcavalcante Mas aí que está, vc não precisa usar o Scrum exatamente como dizem esses "dogmas". Adapte-o à sua necessidade!
vcavalcante: @RenatoFerracini tudo bem, foi a conclusão que eu cheguei na reunião de hoje, podemos juntar mas teremos que ADAPTAR o SCRUM e o PMI.
RenatoFerracini: @vcavalcante Exatamente! Nada está pronto e garantido 100% hoje. O PMBOK é revisado a cada 4 anos por conta disso. E o Scrum, tem revisões?
vcavalcante: @RenatoFerracini até hoje não teve, até porque é um processo muito novo e além disso é um processo muito simples.
vcavalcante: @RenatoFerracini estou gostando muito desta conversa, você não quer participar de um encontro nosso para debatermos melhor?
RenatoFerracini: @vcavalcante Pode ser sim, mas onde vcs fazem? Eu tinha visto em algum lugar que não era em São Paulo... Aí fica mais difícil...
vcavalcante: @RenatoFerracini é em na Unip da Cidade Universitária, dá uma olhada aqui: http://bit.ly/a6POY
RenatoFerracini: @vcavalcante Legal, dá para ir sim. Me mantenham informado que na próxima eu apareço.
andrediasbr: @RenatoFerracini Renato, mas a ultima revisão do PMBoK foi justamente para incorporar práticas ágeis, correto?
RenatoFerracini: @andrediasbr Não, André. O PMBOK é revisado sempre. O que acontece é que agora tivemos um foco maior no que se chama de ágil...
RenatoFerracini: @andrediasbr ...mas o planejamento iterativo já existia há tempos, a segunda versão já falava em Rolling Wave Planning
RenatoFerracini: @andrediasbr A última versão foi bem mais além do que incorporar práticas dos agilistas. É uma melhoria contínua mesmo.
andrediasbr: @RenatoFerracini Sim, na verdade o conceito de iteração está descrito no paper original do Waterfall, mas eu nunca vi um PMP trabalhar isso.
RenatoFerracini: Para @andrediasbr @vcavalcante @giovannibassi RT @corneliusficht: Thushara writes World is bigger.Its bigger than SCRUM. http://ow.ly/15Rl60
andrediasbr: @RenatoFerracini Renato, qual a visão do PMI sobre os PMPs atualmente? Vocês acham que eles estão prontos para liderar projetos ágeis?
RenatoFerracini: @andrediasbr Claro que sim! Muitos já estavam há anos, mas devido a alguns maus exemplos parece que não. Mas não é a certificação q diz isso
RenatoFerracini: @andrediasbr Sou adepto do ágil desde 2006, e foram amigos PMPs que me levaram para esse "lado negro" da força. Então há PMPs ágeis sim...
RenatoFerracini: @andrediasbr @vcavalcante @giovannibassi Gente, vou sair do "chat" agora, mas terei o maior prazer de continuar essa conversa outro dia.
andrediasbr: @RenatoFerracini Ok Renato, foi um grande prazer participar deste "chat" com você. Espero continuarmos esse bate-papo em breve.
RenatoFerracini: @andrediasbr Com certeza, vamos conversar sim! Abraços!
Uma pergunta que tenho ouvido freqüentemente seja em listas de discussões, eventos ou mesmo em clientes é “Por que eu preciso do Team System?”. Normalmente, após essa pergunta eu ouço também uma justificativa muito comum dizendo que tudo o que o VSTS oferece já está disponível no mundo Open Source e é completamente gratuito.
Bom, para tentar responder a essa pergunta eu preparei uma série de comparações que espero que os ajudem a entender porque o Visual Studio Team System é diferente.
Antes de tudo, quero deixar claro que não sou contra software open source, alias já usei muito Eclipse, JUnit, Ant, Hibernate, CVS além de todas essas variações para a plataforma .NET, mas realmente não dá para comparar essa “Salada de Frameworks/Ferramentas Open Source” com o plataforma de ALM (Application Lifecycle Management) da Microsoft. Vamos lá então:
NUnit vs Visual Studio Test Edition (VSTE)
Essa eu acho que é a campeã! Já perdi a conta das vezes que ouvi o pessoal dizendo que o NUnit e o VSTE são a mesma coisa. Não, não são! O NUnit é um excelente framework para execução de testes unitários e apenas isso.
Antes de iniciar a comparação, deixe-me fazer algumas perguntas sobre o NUnit:
- Ele Faz Web Test?
- Faz teste de carga?
- Tem cobertura de código integrada?
- Oferece agentes para serem instalados em desktops para coordenarem um verdadeiro teste de carga?
- Tem integração com Work Items?
- Tem integração com Build?
- Ele gerencia testes manuais (Test Case)?
- Possui integração com o Visual Studio?
- Alimenta bancos de dados para eu extrair relatórios com informações sobre os testes?
Então meu amigo, não dá para compará-los. Para compará-los, precisaríamos fazer uma combinação de uma série de outros frameworks, como por exemplo, NUnit + NUnitReport + NCover + NCoverExplorer + NUnitAsp + NAnt + TestDriven.NET e por aí vai.
Imagens 1 e 2: NCoverExplorer e NUnit
Supondo que você teve muita paciência, um pouco de sorte e o seu gerente ainda te deu tempo para configurar todo esse ambiente (open source gratuito né?), agora você tem um ambiente minimamente respeitável. Você possui ferramentas para fazer testes unitários, testes web, cobertura de código, possui um relatório simples sobre o resultado dos seus testes, uma ferramenta para explorar cobertura dos seus testes e possui também a integração com build. Muito Bom! Será que agora dá pra comparar com o VSTE?
Para as tarefas mais comuns, como as citadas acima, nós vimos que realmente temos boas alternativas no mundo open source, mas quando falamos de ALM, nós estamos buscando algo mais, além de testar, queremos métricas para avaliar e melhorar nosso processo, queremos produtividade sem perder a qualidade e para isso, integração é fundamental. Não dá pra tratar testes de software com ferramentas isoladas em um ALM de verdade.
Vamos imaginar então que na sua empresa você tenha alguns relatórios que mostram quantos bugs estão abertos, a situação atual da build e até quantos testes foram executados na ultima build, mas você não tem nenhum histórico disso. Além de não ter histórico, esses relatórios são gerados por ferramentas diferentes e você não consegue cruzar as informações e saber o real status da qualidade do seu projeto. Você também não sabe se está melhor ou pior do que estava há um mês. Enfim, você tem um monte de pedaços de informação que não te ajuda em muita coisa. Infelizmente, este é um cenário bastante comum no mundo open source! Porém, você ainda pode customizar as ferramentas, mas aí já não dá mais pra dizer que é gratuito.
Agora vamos imaginar um relatório onde você possa visualizar a qualidade do seu projeto build a build, onde num determinado período você veja as builds geradas, a quantidade de testes que foram executados, a quantidade de testes que tiveram sucesso ou falharam, vamos supor ainda que você possa ver neste mesmo relatório o índice de code coverage por build além do número de bugs abertos em cada build. Fantástico, não? Esse relatório é o Quality Indicators e está disponível no VSTS sem que você precise coletar dados para gerá-lo, basta usar a ferramenta no dia a dia que em algumas semanas você terá um panorama completo da qualidade do seu projeto.
Imagem 3: Relatório de Quality Indicators do VSTS
Ainda com as comparações, quando estudamos a disciplina de ALM, vimos que ela é muito mais abrangente do que a simples construção do software, ela engloba governança, engloba operações de TI e como o próprio nome diz, todo o ciclo de vida da aplicação tem que ser gerenciado, incluindo evoluções futuras, melhorias de performance, etc.
Vamos pensar num outro cenário então onde ajustes de performance sejam necessários em uma aplicação que já está pronta. Vamos pensar numa aplicação de uma grande loja virtual hospedada em vários servidores, que após um determinado número de usuários, o tempo de resposta fica muito ruim. Como resolver esse problema?
Antes de sairmos adicionando mais servidores, processadores, memórias e discos mais rápidos, precisamos identificar onde está o gargalo. Mas como fazer isso? Talvez um teste de carga pudesse nos ajudar, correto?
Com o Visual Studio Test Edition, você pode fazer esse teste de carga. Na verdade, você pode ir muito mais além, você pode por exemplo coordenar 50 computadores ociosos para fazer um teste de carga realmente pesado. Além disso, você pode monitorar todos os contadores de todos os servidores utilizados pela aplicação e identificar exatamente o ponto gargalo dela. Chegando a descobrir que o primeiro erro de HTTP 404 ocorreu com 15 minutos de teste, com uma carga de 10.000 usuários simultâneos, o que elevou o processador do seu SQL Server a 100%, por causa do uso intenso de da procedure XYZ. Muti bom né? Eu sinceramente desconheço uma ferramenta open source que me ofereça isso.
Imagem 4: Relatorio do Teste de Carga do Visual Studio Test Edition
O mais curioso é que mesmo após citar todas essas features fantásticas do produto, às vezes eu ainda ouço coisas do tipo: “Poxa André, tudo isso é muito legal, mas eu não preciso disso.”. Ok, talvez você realmente não precise ter uma visão panorâmica da qualidade do seu produto e talvez não tenha cenários onde poderia tirar proveito de tudo que foi mostrado até agora, mas será que ainda assim o Visual Studio Test Edition oferece vantagens em relação as ferramentas Open Source? Adivinhem a resposta :-)
Testes Manuais
Sabemos que boa parte dos testes realizados ainda hoje, infelizmente, são manuais. Então, já que temos que conviver com isso, porque não gerenciá-los, versioná-los, extrair relatórios de testes manuais, saber quais testes manuais já foram realizados. Isso mesmo, incluí-los no ALM. Acho que nem preciso dizer que fazer isso com o VSTS, é moleza, correto?
Imagem 5: Ambiente de execução de testes manuais
Testes Unitários e Cobertura de Código
Neste momento você deve estar pensando: “Tá bom André, eu conheço muito bem o NUnit e NCoverage e quero ver você falar que o VSTS oferece alguma vantagem sobre eles”. É realmente você está certo, este é um ponto onde as ferramentas open source ficam bastante próximas do VSTS, porém ainda falta alguma coisa! Falta a integração e eu não estou falando da integração com a IDE, que por sinal já me dá um grande aumento na produtividade, estou falando novamente da integração no ALM.
Pessoal, é difícil competir com uma ferramenta tão integrada como o VSTS! O NUnit vai executar os meus testes? Sim! O NCoverage vai mostrar o índice de cobertura de código? É claro que vai. O que eles não vão oferecer é uma integração dos work items com esses resultados. E com isso eu não poderei criar um bug a partir do teste que falhou. E Conseqüentemente, não vou ter a rastreabilidade que o VSTS me oferece, me permitindo saber, por exemplo, que para concluir um determinado Caso de Uso, foram utilizadas 40 horas mais 3 correções de bugs que me geraram mais 16 horas e ter uma visão geral das horas utilizadas para concluir o caso de uso.
Sei que é triste, mas ainda não foi dessa vez que o open source ganhou do VSTS, mas bateu na trave. :-)
Imagem 6: Ambiente de execução de testes unitários com cobertura de código
Testes Web
Quando me falam desse tipo de teste, eu me lembro de uma aplicação que desenvolvi no início de minha carreira para uma empresa de RH onde parte da aplicação era um mega formulário para o usuário digitar o currículo dele. Um formulário cheio de validações, onde tínhamos que entrar com os dados corretamente para testá-lo e quando você clicava no submit e recebia uma tela de erro era um momento desesperador. Todos os dados perdidos e tínhamos que preencher todos os campos novamente desde o início.
Por que eu contei toda essa historinha? Simplesmente porque quase fiquei traumatizado e com LER nessa época e se eu tivesse o VSTE, todos os meus problemas estariam resolvidos :-)
Claro que isso é uma brincadeira para descontrairmos um pouco no final deste artigo, mas ela serve também para ilustrar um uso bastante interessante do teste web que te permite navegar por uma aplicação, gravar centenas de macros, salvá-las como testes web e reproduzi-las quantas vezes desejar inclusive fazendo uma integração com o servidor de build para execução destes durante o build.
Imagem 7: Ambiente de execução de testes web do VSTS
Bom pessoal, com isso nós finalizamos a primeira parte desta série, onde o meu objetivo era justamente mostrar a grande diferença que há entre o NUnit e o Visual Studio Test Edition e como pudemos ver fica até difícil estabelecer uma comparação justa devido a enorme diferença entre os produtos.
Procurei apresentar também as principais funcionalidades do Visual Studio Test Edition 2008, já que muita gente tem o produto e não conhece todo o potencial dele e já aproveito para adiantar que a versão 2010, com previsão de lançamento para o 1o. trimestre de 2010, está ainda melhor com uma nova ferramenta de testes independente do Visual Studio, gerenciamento de máquinas virtuais para testes, testes de aplicações Windows, enfim. Muita coisa nova vindo por aí.
Em breve, mais um artigo comentando sobre as outras funcionalidades do VSTS em relação a ferramentas open source.
Abraços e até a próxima.
André Dias
Ontem, durante o primeiro dia do TechEd Brasil 2009, fiz uma apresentação onde falei bastante sobre os métodos ágeis, focando principalmente em SCRUM e Extreme Programming e também mostrei como o Visual Studio Team System pode nos ajudar tanto com a práticas de engenharia quanto com as práticas de gerenciamento dos projetos ágeis.
Durante a palestra Utilizando metologias ágeis com VSTS: Scrum e XP, YES WE CAN! (ALM204), foram apresentadas várias demos onde o pessoal pôde ver um pouco sobre Integração Contínua, Código Padronizado, TDD e também como gerenciar o Kanban e visualizar gráficos como o Burndown dentro do VSTS.
Abaixo vocês podem visualizar os slides apresentados na palestra, além de links para baixar todas as ferramentas utilizadas.
Recursos Utilizados:
Máquina Virtual com Team Foundation Server e Visual Studio Team Suite
Template de Processo de Scrum da Conchango
Ferrameta para TaskBoard da Conchango
Abraços
André Dias
Recentemente, tenho participado de discussões envolvendo metodologias de gerenciamento de projetos e muito frequentemente a discussão acaba tomando o rumo das comparações, principalmente entre metodologias ágeis e metodologias tradicionais, ou sendo mais direto, comparando Scrum e PMBOK.
Como eu conheço apenas um dos lados, já que os únicos contatos que tive com o PMBOK foram através de gerentes PMPs, resolvi comprar um PMBOK para dar uma olhada e formar uma opinião mais realista sobre o assunto, ainda não recebi o livro, mas já comecei a dar uma lida nas Áreas de Conhecimento do PMBOK na internet e vi que temos algumas que não são cobertas pelo Scrum, por exemplo, o Gerenciamento de Custo.
Se formos olhar a definição do Framework Scrum na Scrum Alliance, realmente não encontraremos nada relacionado a Gerenciamento de Custo, então podemos afirmar que o Scrum não cuida desta prática formalmente, porém vamos analisar outros pontos:
Vamos assumir que um projeto possa ter custos indiretos, tais como aluguel, energia e computadores e também custos diretos, como despesas com viagens, hotel, taxi, refeições, telefone, salários dos colaboradores, etc. Vamos assumir também que o aumento descontrolado destes custos afeta consideravelmente a saúde do projeto e vamos assumir ainda que a empresa tenha uma área financeira / contábil que cuide de todas as receitas e despesas e que saiba, por exemplo, por quanto o projeto foi vendido, qual é o custo que o time está gerando para desenvolvê-lo e também tenha conhecimento sobre o percentual de rentabilidade que a empresa espera deste projeto.
Se em algum momento a área financeira perceber que a meta de lucratividade está sendo afetada, ela vai levantar a bola para alguém e no caso de projetos Scrum, provavelmente será para o Scrum Master. E o Scrum Master como um bom facilitador vai tentar negociar com o time para chegarem a uma solução.
Neste ponto a brincadeira começa a ficar interessante: o Scrum Master joga o problema na mesa e diz “Time, precisamos gastar menos! O que vocês sugerem?”. Se tivermos um time verdadeiramente Scrum várias sugestões devem surgir, como por exemplo, “Podemos parar de fazer hora extra”, “Podemos diminuir o número de viagens do PO ao cliente”, “Podemos reduzir nossos salários :-)” e por aí vai. Porém alguém pode dizer também “É verdade, podemos fazer tudo isso, porém nós nos comprometemos a aumentar a velocidade do time trabalhando mais horas por dia para atingir a meta, e se não fizermos isso não vamos cumprir a meta do projeto”.
Pronto, temos um conflito, o como dizemos no Scrum, temos um impedimento, onde a área financeira quer diminuir o custo do projeto para manter o % de lucratividade exigida pela empresa e essa decisão pode afetar a entrega do projeto. E como todos sabem, impedimento é um trabalho para o Scrum Master, ou seja, é de responsabilidade dele discutir com os executivos, falar com o setor financeiro, com o time e encontrar uma solução que mantenha tanto a saúde financeira da empresa quanto a saúde do projeto equilibrados.
Diante disso, podemos dizer que sim, existe Gestão de Custo no Scrum, mesmo que de forma indireta e que o Scrum Master é o responsável por essa área de conhecimento no processo.
Abraços
André Dias
Esta semana foi publicada uma nova página no MSDN dedicada a Migração e a Integração de Soluções com o Team Foundation Server.
O Migration and Integration Solutions consolida em um único lugar todas as ofertas de migração e integração com o TFS, incluindo ferramentas fornecidas pela Microsoft, ferramentas desenvolvidas por parceiros e pela comunidade, além de apresentar ofertas de parceiros de serviços nesta área.
Além das ferramentas já disponíveis no TFS como Visual Source Safe Converter, TFS Migration Tool for Rational ClearCase, na página podemos encontrar ferramentas para migração de CVS, StarTeam, Subversion e integração com o Quality Center (QC) e também um espaço dedicado para projetos do CodePlex.
A extensibilidade do VSTS é um dos pontos mais fortes que considero do produto já que ele nos permite trabalhar lado a lado com outras ferramentas disponíveis no mercado ou mesmo oferece uma forma fácil de migrar o seu ambiente já existente para dentro do produto. Eu já havia escrito sobre isso no meu blog antigo onde mostro inclusive um pequeno exemplo de como criar a sua própria ferramenta de migração caso nenhuma dessas seja suficiente.
Até a próxima
André Dias
Olá pessoal,
Após um bom tempo sem publicações, resolvi “ressuscitar” o blog e como vocês puderam acompanhar nas ultimas semanas, várias mudanças já aconteceram.
Eu não pretendo mudar o foco do blog, então ele continuará tratando de assuntos como TFS, VSTS, ALM, Processos, QA e esporadicamente eu tratarei de outros assuntos.
O que muda é a forma que o conteúdo será disponibilizado, além de posts, vocês poderão encontrar alguns vídeos para demonstrar cenários mais complexos e deixar a coisa uma pouco mais dinâmica. Além disso, dicas rápidas e outros comentários estarão disponíveis no meu twitter.
Ainda falando de mudanças, eu alterei a URL dos feeds RSS, então peço que se você acompanha esse blog através de um reader, por favor, atualize o endereço para http://feeds.feedburner.com/AndreDias. O endereço antigo ainda ficará disponível, porém com o feedburner terei melhores estatísticas que me ajudará a melhorar a qualidade dos posts.
Bom pessoal é isso. Espero que gostem das mudanças, que continuem acompanhando e que participem bastante comentando os posts, criticando e sugerindo melhorias.
Um grande abraço
André Dias
O título deste post pode até soar estranho, mas o recurso de Send Feedback do Windows 7, além de ser extremamente útil para a time do produto coletar informações sobre o uso do Windows, pode ser muito útil para documentarmos situações de bugs ou pontos de melhorias em nossas aplicações.
Isso é possível, pois o Send Feedback do Windows 7 possui um assistente para realizar captura de telas, identificando as ações que foram realizadas pelo usuário e gerando um relatório dessas ações passo a passo complementando com informações sobre o ambiente do usuário.
O vídeo abaixo mostra como podemos utilizar esse recurso disponível na nova versão do Windows.
Abraços
André Dias
Hoje eu tive acesso à versão atualizada do Chaos Report, para quem não conhece é aquele relatório famoso, sempre apresentado em palestras de gerenciamento de projetos e metodologias, que mostra taxas de sucessos e de falhas dos projetos.
Nos últimos anos, eu tenho participado ativamente de discussões sobre processos, metodologias, ferramentas de ALM, boas práticas de desenvolvimento, padrões, arquiteturas, qualidade, testes, enfim, nunca vi uma preocupação tão grande em fazer software da forma correta como nos últimos tempos, e eu tinha certeza que arrebentaríamos nas novas pesquisas, porém para a minha surpresa, o Chaos Report 2009 diz que pioramos em relação aos outros anos.
Como podemos ver nos dados acima, tivemos:
- 32% Sucesso (no prazo, dentro do orçamento e com escopo completo)
- 44% Mudaram (atrasaram, estourou o orçamento, e/ou reduziram escopo)
- 24% Falharam (cancelados ou nunca usados)
Segundo o relatório, nós estamos piores do que estávamos em 2004, no entanto, eu tenho vivido uma experiência bastante diferente da que o Standish Group divulga, com vários projetos com sucesso, algumas mudança e apenas uma falha e aí deixo as seguintes perguntas para vocês:
- Será que nada que fizemos nos últimos anos ajudou a aumentar o índice de sucesso dos projetos?
- Será que realmente estamos piorando ou será que o método de medição deste órgão está falho?
- Qual a experiência de vocês?
Abraços
André Dias
Várias pessoas já me perguntaram quais processos/metodologias/frameworks nós usamos na Microsoft para o desenvolvimento de softwares.
Não é segredo para ninguém que muita coisa na MS é feita utilizando o MSF (Microsoft Solutions Framework), principalmente no time de consultoria. Nos times de produtos, a coisa é mais aberta e cada time pode escolher como vai desenvolver o seu produto e neste cenário encontramos um pouco de metodologias ágeis (XP / Scrum) e, obviamente, MSF.
O mais bacana é que tenho visto cada vez mais pessoas dentro da MS falando sobre métodos ágeis, temos várias listas de discussões internas sobre o assunto e em uma destas listas encontrei um post fantástico onde uma gerente de projetos da Microsoft comenta a sua experiência da transição do modelo waterfall para o modelo ágil.
O post é um pouco grande, mas é bem engraçado, podemos ver algumas fotos do ambiente de desenvolvimento (o físico) além de aprender algumas dicas e lições. Enfim, é um post muito interessante e recomendo a leitura dos relatos da Sara Ford: http://blogs.msdn.com/saraford/archive/2009/03/16/how-i-learned-to-program-manage-an-agile-team-after-6-years-of-waterfall.aspx
Abraços
André Dias
Hoje eu recebi um e-mail de um amigo com uma sugestão, no mínimo, curiosa. Ele dizia algo mais ou menos assim: “André, por que você não sugere para o time do Visual Studio construir uma IDE parecida com o Eclipse. No Eclipse podemos fazer praticamente tudo através do teclado e no VS, se eu sair do trivial já tenho que ir pro mouse”.
Quando li esse e-mail, lembrei de outra pergunta de um palestrante de um evento que participei no final de semana perguntando se havia tecla de atalho para um determinado recurso do Visual Studio.
Como foram duas perguntam em seqüência, parei para pensar onde estava o problema: “Será que o produto realmente não permite toda essa interatividade via teclado ou será que é mal documentado?”.
Numa rápida busca, cheguei à conclusão que não é nenhuma das duas e podemos dizer que, no máximo, a documentação não é tão bem divulgada, mas vamos corrigir isso imediatamente.
Temos alguns pôsteres dedicados exclusivamente às teclas de atalhos do Visual Studio.
Divirtam-se e cuidado com a tendinite :-)
André Dias
Cenário 1: O usuário conecta uma planilha ou um cronograma ao Team Foundation Server, em seguida obtém alguns work items, faz algumas customizações como inserir cálculos, indicadores, agrupar algumas tarefas e passa a acompanhar o projeto por essas ferramentas. Um belo dia o usuário tenta abrir os documentos para ver o status do projeto e não consegue mais conectar-se ao servidor. Ele liga para o time de infra e descobre que o nome do servidor foi alterado. Tenta procurar alguma opção para alterar o nome do servidor, não encontra e acaba recriando os documentos.
Cenário 2: Bastante parecido com o Cenário 1, porém este é um pouco mais comum. O usuário conecta uma planilha ou um cronograma ao TFS, obtém WIs, faz as customizações necessárias e salva o documento. Vai para uma reunião em um cliente e quando tenta acessar as informações através de uma extranet descobre que a planilha está apontando diretamente para o servidor local da empresa e como não encontra nenhuma opção para alterar a URL do servidor, fica com uma “cara de ué” na frente do cliente e bota a culpa na Microsoft.
Já tive a “oportunidade” de passar por esses dois cenários no passado e até cheguei a publicar uma solução no meu blog antigo. Isso acontece simplesmente porque o add-in do TFS para o MS Office fixa a URL do servidor nos metadados dos documentos e não te oferece uma forma de atualizá-lo. Aliás, não oferecia, pois desde Março de 2008, o VSTS Power Tools já tem esse recurso disponível.
Para alterar a URL do TFS nos documentos do Office, basta utilizar a seguinte sintaxe:
tfpt changedocurl filespec /server:serverurl
Pronto! É só utilizar esse comandinho mágico que todas as suas planilhas/cronogramas passarão a apontar para os servidores corretos e você não precisará mais recriar documentos ou mesmo perderá a grande chance de mostrar todas as estatísticas do projeto para o seu cliente.
Abraços e até a próxima,
André Dias
Sempre vejo pessoas com dúvidas parecidas em relação ao Visual Studio Team System. Essas dúvidas variam entre licenciamento, diferenças entre versões do produto, vantagens do VSTS e dúvidas técnicas sobre como fazer gerenciamento de requisitos e gerenciamento de configuração.
Para a maioria dessas perguntas temos documentos que vão a fundo em todos esses pontos. Segue uma pequena lista abaixo:
Abraços
André Dias
Foi liberada recentemente a versão Beta1 do Visual Studio 2010. Como já era de se esperar o produto traz dezenas de novidades que você pode ver aqui, mas trouxe também alguns problemas que não tínhamos no Visual Studio 2008.
Tenho obtido feedbacks de algumas pessoas através do Twitter e também em algumas listas de discussão e é praticamente unânime o sentimento que o Visual Studio 2010 está mais lento.
Vários desses feedbacks já foram enviados ao time do produto que prontamente já nos deu uma resposta: “Estamos trabalhando no aumento da performance e temos metas bem agressivas para melhorar o tempo de Scrolling, digitação além de melhorar o tempo de abertura/criação de soluções.”
Eles citaram também que esse problema ocorre muito em cenários de uso de Remote Desktop ou computadores sem placas gráficas com renderização por hardware.
Se você está tendo problemas de performance com o Beta1 fora dos cenários citados acima, por favor entre em contato através do e-mail andre.dias [at] microsoft [dot] com para investigarmos o problema.
Abraços e Keep testing :-)
