O Google cada dia está mais maroto!
Qualquer dia, ele vai abrir o gTalk e saíra falando comigo, é impressionante! Me espanto com a dominação do google a cada manhã de trabalho, são 6 abas abertas no meu Firefox e neles estão Gmail, Google Adsense, Google Analytics, Orkut, Google Reader. Estou começando a achar, que eles sabem tudo o que eu faço…
No gerenciamento de projetos, a etapa de encerramento do Projeto, corresponde ao processo de integração, onde permite a finalização formal de todas as atividades de um projeto, ou de uma fase do mesmo.
Isso inclui a finalização de todas tarefas correspondes do projeto ou da fase, determinando procedimentos necessários para elaborar e verificar documentos de entregas do projeto. Assim como formalizar a aceitação da entrega pelo cliente ou patrocinador.
Nessa fase também, é considerado uma boa prática a elaboração de um documento para história do projeto, ou seja, um documento descritivo sobre o que de bom e ruim ocorreu no projeto, que junto com o toda documentação do projeto, sirva de base de conhecimento para próximos projetos.
Muitos pulam a fase de fechamento do projeto, porém é uma boa prática a ser feita para encerramento do mesmo, assim como, para tomar nota das lições aprendidas no projeto, para servir como base de conhecimento para próximos projetos.
Então uma boa dica e prática, é não esquecer de encerrar, encerrar o projeto não significa apenas fazer uma festa para os recursos envolvidos, além da festa o fechamento do escopo do projeto, e a elaboração de um documento das lições aprendidas, vai agregar grande valor de conhecimento para próximos projetos a serem executados.
Grande parte de nós “nerds” da WEB, ao menos já ouviu falar da guerra dos browsers, que ocorreu entre a Netscape e a M$. Pois a discovery brasil, divulgou um vídeo explicando como tudo ocorreu:
Vi no blog do vicente.
Na empresa onde trabalho, especificamente no projeto que estou. Estamos tentando aplicar o Scrum, ou seja uma metodologia rápida de gerenciamento de projetos. No Scrum esse título “metodologia” muitos autores consideram muito forte, gostam mais do termo “framework”, ou seja, uma ferramenta interligada com práticas a serem feitas. Porém, como nada é perfeito existem alguns empecilhos que estamos tendo que superar nesse projeto.
São alguns deles:
Porém no final das contas nem tudo está sendo negativo apesar de existir alguns fatores que estão complicando um pouco a maioria está ajudando muito no desenvolvimento do projeto.
Normalmente na organização a qual participo, não existia estimativas e resultados rápidos ou seja, o gerente de projeto, mesmo sem falar com a equipe já tem definido o dead line do projeto, assim como quem serão os recursos. Acontece com isso que, muitas vezes o dead line imposto pelo gerente de projeto, não atende a necessidade, ocorre “correria” entre os desenvolvedores que passam a aumentar sua jornada diária assim como abrir mão de finais de semana, e por conseqüência de tudo isso a qualidade do software passa a ter quedas drásticas, as famosas gambiarras, surgem e tem quaze 100% de chance de continuar a ficar no código até o encerramento do projeto, assim como pelo resto da existência desse software.
Porém no projeto que estamos trabalhando, e utilizando algumas práticas de Scrum, criamos inicialmente a lista de funcionalidades o famoso Product Backlog, e enviamos para o gerente de projeto que repassou para o cliente o mesmo estimou e conversou junto com o gerente de projeto o que era prioridade para esse projeto. Definido isso o gerente de projeto repassou para nós esse documento, e equipe que no início do projeto na parte de desenvolvimento era composta apenas de uma pessoa(eu), estimou as funcionalidades que estavam marcadas como alta na prioridade e que se julgou capaz de fazer em um período de 15 dias úteis, por desconhecer um pouco da tecnologia a ser utilizada, a estimação acabaram ficadas um pouco erronias, e colocamos para a primeira interação, preparamos então o primeiro Sprint, quebrando as funcionalidades em tarefas a serem feitas.
Durante o primeiro Sprint, diversas dúvidas sobre o projeto foram surgindo e as mesmas não estavam esclarecidas no brifieng preparado pelo gerente de projeto junto com o cliente, logo definimos que todas as dúvidas existentes que pudesses serem um empecilho para continuidade de uma tarefa, deveria ser anotada e mandada para o Gerente de Projeto, esse deveria repassar para o cliente para ele conseguir saciar essas nossas dúvidas. Esse atividade foi muito funcional, as coisas foram ficando mais esclarecidas, junto de uma prática que resolvemos aplicar, toda sexta-feira uma nova versão da aplicação em desenvolvimento é posta em um servidor que o gerente de projeto assim como o cliente tem acesso, com isso eles recebem um feedback de como as coisas estão indo e como estão sendo feitas. Isso nos ajudou muito a não perder o foco do Sprint, pois as dúvidas repassadas para o cliente poderia se tornar sim requisições de novas funcionalidades, e com as versões sendo mostradas para ele, era possível perguntar sobre o que realmente o queria naquela funcionalidade, mantendo o foco na interação.
Chegamos ontem ao fim do primeiro Sprint, todas tasks listadas neles foram completadas, as estimações como falei foram um pouco erradas pois o prazo de término era hoje, que nos daria um total de 8horas para fazermos mais tarefas. Porém mesmo assim foi muito satisfatório, já é possível usar boa parte do site, o cliente ficou feliz com o primeiro resultado, pediu algumas mudanças que serão feitas, e algumas novas funcionalidades, nada fora do comum. Todas elas foram postas no Product Backlog, e estão aguardando para o próximo Sprint.
Vamos ver como segue essa aventura, agora que o time de desenvolvedores por sua vez também aumentou, agora são 2 pessoas a desenvolver, em um total de 6 pessoas envolvidas no projeto. Com isso a comunicação aumenta, vamos ver como vamos conseguir controlar isso. Porém tenho boas esperanças de o projeto se sair muito bem, e de conseguirmos convecer de o Scrum fazer parte da vida da empresa.