Arquivos da categoria: Engenharia de Software

PMBOK 4ª edição – Rapidinho

O PMBOK (Project  Management Body Knowledgment) é um guia,  ou como muitos lugares definem, um conjunto de boas práticas, criado pelo PMI – Project Management Institute para auxiliar a todos que estejam envolvidos com gerenciamento de projetos. Foi publicado na forma de livro e hoje encontra-se em sua 4ª edição, sendo a principal bibliografia para todos que desejam obter certificação em Gestão de Projetos.

O conteúdo do guia é formado por um conjunto de conhecimentos, escritos em linguagem universal (sem termos técnicos), para que possa ser útil a profissionais de todas as áreas e facilite assim a troca de experiências sobre o assunto.

Na sua 4ª edição, o PMBOK é constituído por 42 processos, 5 grupos de processos e 9 áreas de conhecimento.

O fato do PMBOK ser um guia composto por boas práticas, significa que Continue lendo

Controle de Versões – Rapidinho

Cá estamos de novo!

O que é um sistema de controle de versões?

Um sistema de controle de versão, para muitos, é o software responsável por armazenar a documentação, código-fonte, bibliotecas e todo o restante  dos arquivos utilizados em um projeto de desenvolvimento de software, vulgo “repositório”.

É, mais ou menos.

No desenvolvimento de software, muitas pessoas trabalham com os mesmos arquivos e nestes promovem constantes mudanças. Por esse motivo Continue lendo

Web 3.0 – Internet Inteligente.

Vocês já ouviram falar sobre Web 2.0, que foi um termo criado no ano de 2004 para designar as mudanças que estavam acontecendo no modo de utilizar da web, onde usuários deixaram de utilizar páginas como simplesmente um jornal ou um panfleto, e passaram a colaborar com o conteúdo online.

Na web 1.0 existia papéis fixos de quem fornecia a informação (aquele que criava a página) e de quem era fornecido pela informação disponível.

Já na Web 2.0 houve a revolução, agora podemos fazer parte da grande engrenagem de informação através dos mais variados sites disponíveis, onde podemos participar de redes sociais ( facebook , orkut, twitter, etc e etc mesmo), ler e compartilhar informações em wikis (como por exemplo, o wikipedia), armazenar e recuperar nossas informações em qualquer lugar (exemplo, o openDrive” ), utilizar mashups, que é a utilização de uma aplicação disponibilizada por outros em nosso próprio site, sites como o google maps (ferramenta de geoprocessamento), FeedBurner (blogs), Del.icio.us (para acessar os sites favoritos de qualquer lugar), entre muitos outros exemplos, a colaboração e interatividade certamente são as palavras que resumem bem a web 2.0.

Poderia continuar escrevendo sobre Web 2.0 por muitas horas, porque há muita disponibilidade de serviços variados para os usuários, muitas pessoas em toda parte do mundo usufruem destes serviços e muitos alegam que não conseguiriam viver sem estas facilidades digitais.

Apesar de tudo isso, se observarmos adequadamente, ainda falta algo para facilitar de vez a nossa vida. Continue lendo…

RUP(Rica Utopia Pobre) Parte 2

Olá povo, estou aqui para continuar a serie de posts sobre a minha experiência com RUP, no ultimo artigo eu falei sobre a minha antiga empresa e o que aconteceu com ela quando resolveram adotar essa metodologia, expliquei as dificuldades que enfrentamos e ainda que essa mudança não foi uma boa escolha, pois o sistema não foi entregue e a maturidade da empresa não era satisfatória para essa metodologia.

Agora vou falar sobre a minha atual empresa Continue lendo…

Todos de pé!

Enfim, chegamos até aqui!

Depois de estimar tarefas, planejar iterações, brincar de Pôquer do planejamento e muito mais, precisamos nos reunir para alinhar o andamento do projeto.

Mas como sempre, nosso tempo é muito curto. Reuniões levam tempo, e esse tempo mais na frente pode deve fazer falta. O que faremos então, já que é preciso manter toda a equipe informada e caminhando junto? Continue lendo

Quebrando em Tarefas!

Quando levantamos nossas funcionalidades, utilizamos roteiros de usuários ou histórias do usuário (user stories) para conhecer o nosso provável escopo do projeto. As histórias são representadas com um simples cartão que contém informações como título da funcionalidade, uma breve descrição, um campo para colocarmos nossa estimativa de tempo e um espaço para o cliente dar uma prioridade. No entanto, para começarmos a execução do projeto precisamos de um pouco mais. Continue lendo

RUP(Rica Utopia Pobre) ou A vida como ela é.

Resolvi escrever sobre essa metodologia após muitos aborrecimentos e tristezas no coração sendo meu principal intuito o de compartilhar minhas experiências com a mesma, coloquei esse nome no post,, pois ela é extremamente Rica de documentos e burocracias, uma Utopia que as grandes empresas gostam de seguir, as quais não conseguem enxergar que o RUP é Pobre de informação, assim como dizia o Renato Russo “O que é demais nunca é o bastante”. Continue lendo

Terminando a tempo!

No post passado aprendemos como estimar nossas funcionalidades para dar ao cliente um prazo. Somando as estimativas chegamos a um número final. Porém, como levamos em consideração o tempo que 1 desenvolvedor sozinho seria capaz de concluir cada tarefa, devemos agora dividir esse número pela quantidade de programadores na equipe

Finalmente, esse é o nosso prazo! Mas não se anime, o cliente quase nunca concorda.

Suponhamos que ele exija proponha um prazo menor. Teremos então que re-planejar nosso cronograma, ou seja, estabelecer o tempo de nossas iterações. Mas como saber se nossa equipe é capaz de fazer no tempo que ele pediu? Continue lendo…

Quanto tempo leva? – Planning Poker

No post passado começamos a falar sobre princípios de como desenvolver software usando como base a leitura do livro Use a Cabeça: Desenvolvimento de Software. Foi explicado que dividindo o nosso projeto em iterações podemos nos aproximar daquilo que o cliente realmente precisa, obtendo seu feedback e mostrando o andamento do projeto em pequenas partes de Software funcional.

Vimos também que é muito importante que o cliente priorize as funcionalidades a serem desenvolvidas, pois temos um prazo a cumprir e nem sempre tudo caberá no período acordado para entrega do produto.

Para dar ao cliente um prazo, a nossa equipe precisa realizar a estimativa de tempo de cada tarefa a ser construída durante o nosso processo de desenvolvimento. Uma forma de se fazer é Continue lendo

Desenvolvimento de Software não é especulação!

Um software de qualidade necessariamente precisa atingir os 3 princípios básicos de qualquer projeto:

* Requisitos do cliente //afinal esse é o motivo do projeto
* Prazo //sejamos pontuais, like british people
* Custo //pedir mais dinheiro é uma coisa muito feia

Itere sempre!

Clientes são ansiosos e entregar-lhe pedaços de software funcional por mais simples que sejam Continue lendo