Atualização do Site de Apostilas

Depois de um longo e tenebroso inverno, eis que o site de apostilas foi atualizado....
Bom, não faz tanto tempo asim....

Adicionei para vocês, queridos leitores deste blog, mais 3 documentos. Agora sobre o MS-Project.
Para quem está iniciando o uso desta ferramenta, sempre se depara com uma questão: por onde começar?
Por isso, montei um roteiro básico de como montar um cronograma de um projeto, por onde e quais opções você deve acessar antes de sair preenchendo a planilha com suas atividades.
Também adicionei, uma apostila de como você pode acompanhar seu projeto, utilizando a técnica de valor agregado no MS-Project
E por fim, adicionei uma pequena apresentação, que fala um pouco sobre gerenciamento de projetos segundo o PMI.

Visite e baixe suas apostilas no site: http://site.pop.com.br/emersonz

Site de Apostilas, apresentações e documentos

Olá, acabei de colocar no ar um novo site, de minha autoria, para publicar meus documentos, apostilas, apresentações, exemplos e outros.
Ele conterá algumas coisas que publicarei neste blog em formato PDF para baixar e outras apostilas, apresentações e textos, que já produzi e venho reproduzindo ao longo dos anos.
A página é bem simples, mas está separada por assunto, pois o unico intuito é divulgar as minhas apostilas e não a de terceiros.
Para começcar, já disponibilizei 3 apostilas pequenas:
1. Apostila básica de UML
2. Apostila sobre RUP
3. Apostila sobre Design Patterns.

Visite a página e baixe os arquivos, são de uso livre, você pode ler, copiar, alterar desde que cite o nome do autor destes documento (no caso, eu) .

Endereço: http://site.pop.com.br/emersonz

Scrum – Vantagens e Desvantagens

Olá, hoje vou contar um pouquinho mais sobre o Scrum e o que estou achando deste framework ou processo (ou como você queira chamá-lo).

Na empresa que estou atuando atualmente, está em processo de implantação de uma metodologia baseada no Scrum. Nestes 5 meses que se passaram desde a adoção e implantação da metodologia percebi algumas vantagens e desvantagens da metodologia como um todo.

Vamos a algumas vantagens que percebi durante esse tempo:

1. Motivação maior dos programadores. O comprometimento dos programadores realmente aumentou assim como a motivação. Foi muito interessante ver o empenho dos desenvolvedores em atingir a meta que era de “entregar o sprint” ou seja, eles se comprometiam em entregar aquilo que eles disseram que iriam entregar no prazo de 1 sprint (na empresa, foi adotado Sprints semanais).
2. Visualização do projeto. Os projetos passaram a ter uma visualização melhor dentro da organização, antes ficavam ocultos e só os gerentes de projeto sabiam o que se passava no projeto. Como todo projeto passou a ter um Backlog com tudo que deve ser entregue fica mais fácil a visualização por todos os membros da equipe.
3. Diminuição dos bugs. O prazo deixa de ser o mais importante e a qualidade passa a ser o centro das atenções. O programador não tem mais um prazo que lhe é imposto e sim a equipe se compromete a entregar aquilo que ela consegue no prazo do Sprint (1 semana, 2 semanas, 1 mês), porém, tem que entregar sem nenhum erro e a funcionalidade não pode mais voltar com erro. Os índices na empresa mostraram que o re-trabalho diminuiu.
4. Prioridades podem ser alteradas. Isso realmente é uma vantagem em projetos em que o cliente tem dúvidas do que é mais importante. Quando se trabalha com metodologias como a do PMI, isso é travado, pois qualquer alteração na sequencia das atividades, detona o planejamento e a execução do projeto, mas com Scrum não, pois só não se mexe no Sprint, mas aquilo que ainda não foi planejado no Sprint, pode ser alterada sua ordem sem problemas, desde que já se tenha os requisitos da funcionalidade prontos.
5. Funcionalidade que agregam valor, vêem primeiro. Um dos itens que independente da metodologia pode ser aplicado, contudo, no Scrum esse critério é bastante enfático, pois o que agrega maior valor ao negócio do cliente, deve sim ser entregue primeiro mas muitos gerentes não se atentam a isso, preferem entregar o que é mais fácil primeiro (bem típico do ser humano... faz o que é mais fácil primeiro e deixa o difícil por ultimo).

Bom, existem outras vantagens, mas vou deixar para outro dia... agora vamos a algumas desvantagens:

1. Projeto não documentado. No inicio, documentação parece ser inútil, muitos perguntam: “Para que gastar tempo escrevendo? Vamos codificar que é melhor”, contudo, existem projetos conturbados, requisitos mal escritos geram dor de cabeça mais tarde. A falta de documentação de software gera custos na hora da manutenção e no suporte, pois na hora de alterar alguma funcionalidade, sem documentação, o analista ou programador poderá ficar perdido ou alterar algo que não poderia ser alterado. Esse é um dos principais problemas que vejo na metodologia. Sugiro uma adaptação e não abandonar totalmente a documentação e sim ser mais seletivo, documentando aquilo que é necessário realmente.
2. Prazo. Bom, se a equipe de produção determina o prazo, como vamos passar uma posição ao cliente de quando o projeto acaba? Alguns dizem que é possível dar datas com o Scrum, mas não é a prática que é pregada. Vejo isso como um problema, pois o cliente sempre perguntará: “quando que vai terminar esse projeto?”... ou nunca perguntaram para você? Tudo bem, o cliente recebe funcionalidades periodicamente, assim você pode negociar o prazo final... porém, nem todo projeto é assim.
3. Falta planejamento do escopo. A metodologia não aborda nenhum tipo de planejamento do escopo apenas que deve-se ter um Backlog. Contudo, esse backlog sofre mudanças e fica a cargo da equipe avaliar e controlar esse backlog. A equipe tenderá sempre para o cliente, pois ele busca a satisfação do mesmo, porém, pode deixar escapar itens que não era para serem feitos, ou seja, o risco de ser feito itens fora do escopo aumenta e a empresa pode perder dinheiro com isso.
4. Papéis indefinidos. No Scrum só existem 4 pessoas: O usuário, o Product Owner (PO), o Scrum Master (SM) e o Team (time), mas cadê o analista de negócio, o analista de sistema, o testador.... ah sim, está tudo dentro do time... será que está mesmo? Um programador testar o que o outro fez, nem sempre funciona é necessário um testador que saiba o que está fazendo. Programador nem sempre sabe modelar, é necessário uma pessoa com experiência em análise de sistemas. O PO acredito que tem que ser o analista de negócio e o time tem que ser composto por pessoas com diversas competências, senão a coisa não funciona. Outro detalhe, o usuário, através do PO é quem diz ao time o que ele quer e pra que, mas as vezes, o usuário não sabe o que quer e ai entra o analista de sistema, que tenta interpretar o que o usuário deseja... mas no Scrum só existe o time. Se o time tiver as competências necessárias, funciona, caso contrário, vai sair você sabe o que.

Conclusão

Acredito que nenhum processo ou metodologia seja perfeita para sua empresa ou para a minha. Todas tem suas vantagens e desvantagens. Particularmente, gostei de várias teorias do Scrum, de outras, nem tanto. Mas como é um Framework, você pode adaptá-la para a sua realidade e criar um processo para a sua empresa. Por exemplo, na empresa não foi extinto o documento de requisito, que deve ser documentado e assinado pelo cliente, pois sabemos que sem esse documento, podemos facilmente perder o controle do escopo do projeto. O importante, é que sua empresa tenha um processo definido, que seja seguido por todos e que seja continuamente melhorado, seja ele derivado do Scrum, XP, RUP ou qualquer outra metodologia.

Até a próxima!