Blog.Impact

A resposta é simples: medindo!

Se você nunca medir, nunca saberá o tempo que leva. Todo trabalho de estimativa baseia-se na experiência (registros passados) do tempo que levou. Medir o tempo pode parecer uma coisa simples, mas é importante ser sempre pessimista, problemas podem ocorrer, e todo o tempo que ganhou no projeto, pode ser perdido na última tarefa.

Estimativa é um indicador, e como qualquer outro indicador, você precisa de uma referência. Se você nunca mediu seu tempo, comece agora, sem esses dados suas estimativas serão chutes, e a entrega do projeto na data marcada será uma loteria.

Divida todo seu trabalho em tarefas equivalentes. Reduza seu nível ao mais operacional possível, onde você possua apenas instruções de trabalho. Um exemplo disso é uma tarefa “Programar formulário de cadastro de pessoas”. Reduzindo ao nível mais operacional possível, você evita que a evolução das tarefas possam ser mensuradas (a tarefa A está 78% concluída) e acabem não mostrando sua real evolução dentro do projeto.

Isso não é novo, o SCRUM prega isso, e nele uma tarefa só pode estar pendente, em andamento ou concluída. Estou no início dos meus estudos sobre SCRUM, e pode ter muita coisa que eu entendi errado, mas de qualquer forma, aprendi uma porção de coisas bacanas que podem ajudar mesmo não sendo o padrão correto.

Meu maior problema era definir o que seria uma estória e o que seria uma tarefa. Um exemplo que me ajudou a definir isso esta no livro Scrum and XP from the Trenches e segue abaixo de maneira simplificada:

Quebrando suas estórias em estórias menores

Quebrando estórias em tarefas

Então, defina suas estórias, suas tarefas e então inicie seus trabalhos. Leia sobre SCRUM e XP para ter uma idéia melhor, acredito que isso lhe ajudará muito mesmo, não apenas no seu trabalho, mas para organização de sua vida.

Após o início dos seus trabalhos, acompanhe a evolução do seu trabalho x tempo. Esse indicador é muito importante e será, após a conclusão dos trabalhos, seu indicador base. Vai ser com ele que você saberá o tempo real necessário para concluir um número X de tarefas. É um número aproximado, mas é melhor que número nenhum.

Com isso, você terá uma estimativa real – aproximada, mas real – do potencial de trabalho que tem em mãos. Como ele será possível definir os trabalhos que poderão ser feitos em determinado tempo e até planos para melhoria desse potencial, como treinamentos, aumento do número de pessoas na equipe ou até mesmo troca de membros que possam não estar se adequando a forma de trabalho.

1. InfoQ: Scrum and XP from the Trenches
2. Scrum na Wikipedia
3. Implementing Scrum
4. Planning Poker Game

Essa semana me deparei com um problema: meus modelos que herdavam do modelo User, faziam parte de uma associação polimórfica, onde cada tipo distinto de usuário, poderia ter um vepiculo. Esse problema é documentado no manual, e para utilizar STI com associações polimórficas é necessário uma pequena alteração no seu modelo.

O meu problema era, que ao chamar current_user.vehicles.find ele pesquisava por veículos com owner_type igual a User.

Quando utilizo associações polimórficas, eu preciso de dois campos para isso, o campo que armazena o código, id, e o campo que armazena o tipo, type. Como minha associação se chama owner, meu modelo possui dois campos owner_id e owner_type.

Mas na hora do meu cadastro, o tipo armazenado no veículo era Manager, que é um modelo STI de User.

Para o uso de associações polimórficas com STI eu preciso de um pequeno ajuste no meu modelo Vehicle para que ele armazene a classe base do objeto que estiver sendo fornecido como owner, como está no código abaixo:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

class Vechile < ActiveRecord::Base
  belongs_to :owner, :polymorphic => true

  def owner_type=(sType)
     super(sType.to_s.classify.constantize.base_class.to_s)
  end
end

class User < ActiveRecord::Base
  has_many :vehicles, :as => :owner, :dependent => :destroy
end

class Manager < User
end

class Administrator < User
end