Arquivo da tag: engenharia de software

Livros que li em 2013 – por Gabriel Rubens

Olá a todos…
Sem dúvida esse foi um dos anos que mais aprendi, foi um ano incrível. Apesar de ter estudado muito menos do que eu planejava por não ter me organizado muito bem no primeiro semestre (acho que não li nada no primeiro semestre), não por falta de tempo como foi a desculpa de muitos, mas por não ter conciliado muito bem todas as coisas. Mas como disse, mesmo assim foi um ano em que aprendi muito, me foquei bastante em Engenharia de Software, mais precisamente em Scrum, XP e Kanban, não só nos livros como nas leituras de artigos, mas é claro que li muito sobre programação e também aprendi muitas coisas novas nisso, realmente posso dizer que me tornei um programador melhor.
Mas vamos a lista de livros de 2013:

Guia da Startup: Como startups e empresas estabelecidas podem criar produtos web rentáveis (comprar)

Scrum in Action: Agile Software Project Management and Development

Scrum Guide (baixar)

Scrum Gestão ágil para projetos de sucesso (comprar)

Continue lendo

Livro Scrum: Gestão ágil para projetos de sucesso

Olá,
Há alguns dias acabei de ler mais um livro sobre Scrum, e dessa vez foi o primeiro livro brasileiro sobre o assunto (até onde eu saiba) que é o Scrum: Gestão ágil para projetos de sucesso da editora Casa do Código.

O livro tem uma abordagem um pouco semelhante ao Guia Scrum, só que é bem mais completo. Deu pra aprender bastante sobre a essência do Scrum e um pouco mais, pois o livro trás alguns tópicos que não fazem parte do “Scrum puro”, mas que acaba sendo uma necessidade em alguns projetos. 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

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