Livro - Gerenciando projetos de software usando Visual Studio Team System
Olá Pessoal,
Hoje estou aqui para divulgar o lançamento de mais um livro do meu amigo Ramon Durães – MVP Visual Studio Team System.
Tive o prazer de acompanhar este projeto e inclusive, tenho um depoimento escrito na contra capa do livro :) e recomendo, material de Primeira Qualidade de um dos maiores especialistas do mercado.
O Livro é claro, fala sobre Gerenciamento de projetos usando esta incrível ferramenta de ALM. Abaixo, seguem algumas informações retiradas do blog do autor.
O Visual Studio Team System é a plataforma da Microsoft para gerenciamento de projetos de software. Você pode utilizá-lo para controlar a versão do código fonte da aplicação e do banco de dados, acompanhamento de atividades, documentação e testes de software.
Com o Visual Studio Team System você vai encontrar uma plataforma aderente a todos os projetos de software, seja ele pequeno, médio ou grande o que tem permitido o seu uso em soluções num grande número de clientes que estão satisfeitos com todo o processo de reengenharia que é possibilitado com o Visual Studio Team System.
Gerenciando projetos de software usando Visual Studio Team System
1. Application Lifecycle Management
2. Team Foundation Server
3. Metodologia de Desenvolvimento
4. Work Items
5. Team Foundation Server Version Control
6. Arquitetura
7. Desenvolvimento
8. Testes
9. Banco de Dados
10. Visual Studio Team System Web Access
11. Relatórios
12. Team Foundation Build
Esse livro foi projetado para atender qualquer profissional ligado a área de desenvolvimento de software como: Gerente de projetos, Arquitetos, Desenvolvedores, Testadores e Administradores de banco de dados. Ao acompanhá-lo você terá acesso a uma nova visão sobre o desenvolvimento de software, ampliando seus conhecimentos sobre técnicas modernas aplicadas, podendo ser lido por completo ou diretamente nas áreas de interesse conforme a atuação no projeto.
“O Visual Studio Team System é um produto excepcional para o acompanhamento das etapas de desenvolvimento de um projeto de software. Tenho plena convicção de que este livro irá esclarecer paradigmas do desenvolvimento de software, devido ao profiundo conhecimento do Ramon Durães e sua didática empregada nos seus textos. – Rodolfo Roim, MVP Lead Brasil”
“Ciclo de vida de desenvolvimento de software é algo ao mesmo tempo importante e complexo. O VSTS simplifica e dá poder a quem o utiliza, e um livro como este é como um manual de instruções, abrindo as portas desta importante ferramenta. – Giovanni Bassi, MVP C#”
“O Visual Studio Team System é a ferramenta ideal para controle total de um projeto de desenvolvimento de software. Neste livro o autor apresenta os principais recursos do produto com um enfoque totalmente de mercado, ou seja, você tem uma leitura que será toda aproveitada em um cenário real no dia a dia. – Alexandre Tarifa, MVP Visual Basic”
“O Visual Studio Team System é hoje, sem sombra de dúvida, a melhor ferramenta de Application Lifecycle Management (ALM) do mercado, e um livro escrito por um dos maiores especialistas no assunto aqui no Brasil, Ramon Durães, só tem a agregar para os entusiastas no assunto e todos os profissionais que ocupam um papel no ciclo de desenvolvimento de software. – Evilázaro Alves, MVP Connected Developer System”
Para acompanhar e saber mais detalhes cadastre-se em http://www.vstsbrasil.net
Um forte abraço.
Evilázaro Alves
MVP, MCTS, MCBMSS, MCP
Não insistam no Modelo de Desenvolvimento de Software Cascata.
Olá pessoal,
O post de hoje é mais um post opinativo do que o que geralmente posto que sejam notícias e novidades tecnológicas. Quero colocar aqui, a experiência profissional que vivi a alguns meses em uma empresa que representa um software de ERP. O assunto que gostaria de falar hoje é sobre processo de desenvolvimento de software, alguns modelos de processos e o que vivenciei nesta empresa.
Imagine uma situação, em 2009 vc em uma grande empresa de software fazendo o seu trabalho e então é convidado para uma reunião onde serão apresentados os processos de desenvolvimento de software da empresa e os novos COORDENADORES. Uma situação extremamente normal em qualquer empresa de software, nada como analisar, discutir e até mesmo melhorar todo o processo produtivo de software não é mesmo?
Chegando à reunião, vários desenvolvedores, estagiários, COORDENADORES e Gerentes de Projetos, ou seja, praticamente todos os papéis de um desenvolvimento de Software, eis que quem começa a reunião, para apresentar o processo de desenvolvimento é um GERENTE DE PROJETOS. Bom, o cara não tem experiência nenhuma com desenvolvimento de Software, aliás, ele tem experiência em CUSTOMIZAÇÃO da ferramenta o que pode ou não ser considerado um desenvolvimento de software dependendo do ponto de vista.
Feito isto, ele inicia mostrando um fluxograma em que contém várias fases do desenvolvimento e o básico que é:
· Análise
· Desenvolvimento
· Testes
· Homologação
· Produção
Já começa a reunião perguntando pra um estagiário “o que é a etapa de análise?”, neste momento, já percebi como seria a reunião (uma imensa demonstração de que o gerente de projetos é quem tem o conhecimento de como se desenvolve um software, e ele estaria lidando com macacos). Em cada parte do processo ele ia perguntando quem sabia o que aquela etapa significava. Vamos parar aqui e imaginar a cena:
Uma sala, de uma grande empresa de software de ERP repleta de Desenvolvedores ou Customizadores como costuma chama – los, e o cara me pergunta o que é cada etapa do processo? Tipo, estas cinco fases que citei acima é conhecida até por quem desenvolve em ACCESS (Sim, eu conheço gente que desenvolve em Access. Aliás, conheço até empresa que vive de produto feito em Access), mas enfim, a reunião seria um saco, enquanto ele falava, eu analisava o fluxograma e percebi que não passava de um modelo cascata de desenvolvimento de Software e que, na verdade, o modelo deles pregava que, toda a análise seria feita antes mesmo da codificação iniciar e que, somente depois da especificação de requisitos pronta, é que o desenvolvedor colocaria a mão na massa.
Dentro do processo pregava que, a especificação deveria voltar para o Consultor funcional quantas vezes fosse necessário até que ficasse “boa” o suficiente para que o desenvolvedor pudesse seguir com seu trabalho.
Não sou o maior especialista do mundo em processo de desenvolvimento de software, pra isto, tenho amigos Mvps super competentes que tratam deste assunto e quando preciso realmente de um deles, é só recorrer que tenho a melhor ajuda especializada do mercado, porém, não precisa ser nenhum mestre da computação pra saber que a Engenharia de Software tenta fazer o Modelo Cascata funcionar tem só 40 anos.
Para comprovação do que eu estava imaginando e também claro, para meu desespero total (pois estava perdendo meu tempo em que poderia estar estudando algo interessante, vendo e-mails ou mesmo trabalhando hehehe) ele me solta a seguinte frase:
“E para comprovar como estamos evoluindo em nossas exigências de especificação funcional, estamos na DÉCIMA versão de uma determinada especificação funcional para uma customização do cliente X”
Pessoal, eu quase caio da cadeira, eu quase pensei que na verdade não ouvi aquilo e sim, que por eu estar imaginando que estavam pensando de forma em Cascata eu teria pensado aquilo e achado que ele falou isto até que ele repetiu.
Eu ergui a mão e perguntei, mas décima versão?
E ele disse sim, pois estamos muito exigentes agora.
Eu perguntei, e o CLIENTE? Como fica? Como são tratados os prazos do CLIENTE? Ele simplesmente espera pacificamente NÓS resolvermos os problemas internos e chegarmos há uma versão de especificação?
Gagueja daqui, gagueja dali, muito veja bem e então ele fala:
Infelizmente, nós desenvolvedores precisamos tirar o nosso da reta pq os Consultores Funcionais não fazem uma boa especificação e tudo acaba estourando no desenvolvimento.
Pela primeira vez na reunião, ele falou uma coisa sensata, os consultores não estavam fazendo realmente uma boa especificação e isto prejudica o desenvolvimento, porém, fiz a seguinte contra – argumentação.
Vocês já perguntaram para os consultores se, eles SABEM levantar requisitos? Afinal, eles são consultores funcionais e muitos deles eram usuários do sistema e estão passando para consultoria, praticamente nunca participaram de um processo de desenvolvimento de customização. Já propus uma vez a diretoria em fazer um Workshop para os consultores explicando como Extrair Requisitos, mostrando alguns padrões de especificações e minha idéia foi simplesmente ignorada.
Bom, mais gagueja daqui, mais veja bens e escuto:
Sua opinião é muito boa, mas não funcionaria pq geraria um problema político e os consultores não aceitariam nossa ajuda, afinal pensariam que estaríamos tentando ensinar o trabalho deles.
Dai, neste momento teve a intervenção de outro COORDENADOR da empresa, que acabou de entrar na empresa. O cara é PSCICOLOGO, ASTROLOGO E VIDENTE hehehehe (ESTAVA ENSAIANDO ESTA TIRADA HA TEMPOS) e tenta explicar todo o problema emocional que poderíamos causar na equipe de Consultores Funcionais da empresa.
Neste momento, desisti de vez da reunião, mas eu era obrigado a continuar. : )
Pessoal, saindo da reunião, procurei os coordenadores da consultoria e perguntei se poderíamos trabalhar em conjunto para que chegássemos a um entendimento de como montar a especificação e propus o workshop. A aceitação foi de 100% e ainda gostaram da idéia, pois todos alegaram ter a oportunidade de aprender algo novo, algo que poderia ajudar ELES MESMOS em não voltar tanta especificação.
Este Workshop é claro, vai ser transformado em algo comercial que colocarei aqui no blog pra quem tiver interesse. :)
Então pessoal, o motivo do post é dizer o seguinte:
O MODELO CASCATA NÃO FUNCIONA se ouvir algum gerente maluco falando isto, intervenham, será o melhor pra vocês.
Caso vocês queiram conhecer um pouco mais sobre alguns processos de desenvolvimento de Software, sugiro um WebCast do Arquitect Academy que foi organizado pelo meu amigo da Microsoft Alexandre Nardi. Clique aqui para baixar o WebCast.
Um forte abraço.
Evilázaro Alves
MVP, MCTS, MCBMSS, MCP
