16 de maio de 2009
Atualização do Site de Apostilas
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
3 de maio de 2009
Site de Apostilas, apresentações e documentos
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
1 de maio de 2009
Scrum – Vantagens e Desvantagens
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:
- 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).
- 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.
- 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.
- 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.
- 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:
- 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.
- 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.
- 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.
- 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!
15 de abril de 2009
Scrum X RUP
O RUP (ou IRUP após a aquisição da Rational pela IBM) é um método da engenharia de software, que utiliza a abordagem da análise orientada a objetos em sua concepção. Utiliza a UML (Unified Modeling Language ou Linguagem de Modelagem Unificada) como base para sua documentação do sofware. Utiliza o ciclo de vida do sofware em espiral ou iterativo, aonde é possível determinar o tamanho de cada iteração, tendo assim, um pedaço ou release do sofware de tempos em tempos, o que nada impede que toda a iteração seja o sofware como um todo (não recomendável, é claro).
O RUP preza pela documentação (tanto visual utilizando a notação da UML como escrita), controle de escopo, controle dos requisitos, controle da qualidade, pelo time com papéis bem definidos, etc, etc.
O RUP, apesar de ser uma metodologia pesada, aconselhável para grandes times e grandes projetos, é possível de se adaptar para projetos menores, tornado-o "utilizável" em projetos de menor escala com equipes menores.
O Scrum, é uma metodologia (ou framework como alguns defendem) baseada no métodos ágeis (manifesto ágil) que parte do principio, que produto pronto é produto "rodando". O Scrum defende a idéia de mais código e software rodando do que documentação, mais negociação do que avaliação de escopo x contrato.
No Scrum não existem papéis definidos como no RUP. Só existem 3 funções: Product Owner (PO), Scrum Master (SM) e Time (Team). Essa equipe faz tudo: define requisitos, analisa a melhor forma de implementar, treina os usuários, implanta e controle escopo (será que controla?).
É uma metodologia bastante ágil, aonde se pode ter entregáveis (ou funcionalidades) prontas em um espaço de tempo bem curto, algo que pode varia entre 2 a 4 semanas.
É baseada também no metodo espiral da engenharia de software, que leva em conta o o processo de iteração, mas ao contrário do RUP, aonde você fica livre de determinar o tamanho da iteração, no Scrum o tempo máximo é de 4 semanas, que são chamados de Sprint´s.
Conclusão:
Não vou dizer quem é melhor que quem... mas em resumo, as duas metodologias são bastante parececias em alguns principios mas bem diferentes em outros. A escolha entre uma ou outra, vai desde o tamanho do projeto, tamanho de equipe, até mesmo o tamanho da empresa que deseja adotar um dos métodos.
Já vi várias empresas terem sucesso tanto com Scrum como com RUP, assim como, já vi projetos de implantação de RUP e Scrum afundarem... não tem como dizer qual é a melhor, somente vivenciando e definindo aonde você e sua empresa quer chegar.
Até a próxima, prometo escrever mais sobre essas duas metodologias, e vocês poderão tirar suas conclusões.
Não deixem de conferir os links:
pt.wikipedia.org/wiki/IBM_Rational_Unified_Process
pt.wikipedia.org/wiki/UML
www.scrum.org.br (Scrum user-group no Brasil)
scrum4you.wordpress.com (blog fo Boris, um nome importante no "meio" Scrum)
9 de abril de 2009
Seus executáveis estão grande? Compacte-os
O UPX é um aplicativo gratuito, capaz de compactar os executáveis de sua aplicação, tornando-os menores para que possam ser transportados mais facilmente.
Ele mantém o executável da forma original, sem comprometer seu funcionamento, deixando até 50% menor que o arquivo original (já cheguei a 70% menor).
Isso ajuda muito, quando fazemos atualizações de aplicações e que depende de uma rede interna com alto tráfego de dados. Com aplicativo menor, o consumo de banda será bem menor na hora de atualizar os executáveis.
Veja alguns exemplos de compactação:
Winamp.exe --> Tamanho Original: 1.314 kb depois de compactá-lo: 507 kb
winword.exe --> Tamanho Original: 11.756 kb depois de compactá-lo: 5.725 kb
Se estiver com medo de ter algum problema como defeitos no software depois de compactá-lo, fique tranquilo, é muito difícil ocorrer. Utilizo ele em ambientes de produção já há algum tempo e não tive problemas até hoje.
Também não há uma redução de performance ao abrir o executável, não que seja perceptível.
Também não sobrecarrega memória ao usar o aplicativo compactado.
Não há necessidade instalar nada nas máquinas para executar o aplicativo compactado, já que ele permanece com a extensão .exe e é executado normalmente, como se não tivesse compactado.
Se interessou? Então baixe o UPX no site upx.sourceforge.net e teste.
6 de abril de 2009
Apoio Gerencial
Os textos dão uma boa noção de Fluxo de Caixa, Custos Diretos e Indiretos, Formação de Preço de Venda, o que é Contabilidade, Ativos, Passivos, entre outras dicas, informações e o mais interessante, com exemplos simples, que facilitam o entendimento.
Se você é daqueles que está começando, ou quer entender um pouco mais de regras de negócio, vale a pena passar lá e baixar alguns destes documentos, pelo menos, quando você for fazer uma entrevista com algum cliente seu, ou quando estiver desenvolvendo um software, não vai ficar "boiando" na conversa, quando o usuário começar a falar de "débitos" e "créditos" da contabilidade, nem o que custo direto e indireto....
O site é www.sebrae.com.br/atendimento/instrumentos-de-apoio-gerencial.
1 de abril de 2009
Seus arquivos nas nuvens
Todos tem uma conta no Windows Live, ou se preferir, do MSN, mas nem todos viram esse serviço que a Microsoft oferece gratuitamente no seu site www.windowslive.com do qual permite você armazenar até 25 GB de arquivos, é isso mesmo 25GB.
Se você precisava de espaço na internet para postar seus arquivos, acho que encontrou... pois 25GB é um bom espaço.
Com esse serviço você pode disponibilizar seus arquivos na internet, podendo compartilhá-los com quem quiser ou torná-los públicos para que qualquer pessoa possa baixar.
O serviço não é novo, a algum tempo já existem provedores que oferecem discos vituais... mas ainda não tinha encontrado nenhum que fosse de 25GB e de graça.
A Google, por exemplo, não tem (ainda, pois há rumores do gdrive).
Para usá-lo é muito simples, basta se conectar no site do windows live (use o link acima), usando sua conta do MSN e habilitar o serviço, acessando o menu do site "Mais", irá se abrir várias opções, e uma delas é o SkyDrive.
Lá você poderá criar novas pastas, criar pastas particulares, aonde só você poderá acessar, pastas públicas para postar arquivos comuns e compartilhá-los com seus amigos.
Ao postar um arquivo público, o SkyDrive oferece uma opção de enviar um link para esses arquivos públicos para os contatos do seu MSN ou para qualquer e-mail de sua preferência.
Desta vez, a Microsoft saiu na frente com esse serviço gratuito.
Bom, como nem tudo são "flores", o tamanho de cada arquivo é de no máximo 50 mb, ou seja, não dá pra deixar um filme inteiro lá para alguém baixar, você terá que quebrá-lo em vários arquivos menores. :-(