segunda-feira, janeiro 19, 2009

CMMI e Agilidade

Em uma nota técnica do SEI sobre CMMI e Agile, há o seguinte parágrafo (pág. 8):

Chapter 3: Factors that Affect Perception

Section 3.2 Lack of Accurate Information

Discussion of Agile methods in CMM/CMMI settings was frequently peppered with anecdotes equating Agile with "no discipline." In fairness, the XP community (unintentionally) invited this censure. Even the name "extreme programming" conjures up an image of skateboard parks or the rule-breaking anarchy of off-piste snowboarding. Certain readings of the Agile Manifesto (excerpted in Section 5) might bear resemblance to this perception.

Traduzindo-se:

Capítulo 3: Fatores que Afetam a Percepção

Seção 3.2: Falta de Informação Acurada

A discussão dos métodos Ágeis nos círculos de CMM/CMMI foi frequentemente apimentada com piadas igualando Agile a "sem disciplina". Com justiça, a comunidade XP (não intencionalmente) gerou esta censura. Até o nome "programação extrema/radical" traz à mente a imagem de parques de prática de skate ou a anarquia de quebrar regras dos esquiadores de neve fora de pista. Certas leituras do Manifesto Ágil (ver fragmento na Seção 5) podem se assemelhar a esta percepção.


Custo intelectual X Horas de trabalho

Era uma vez uma empresa transportadora de cargas. Trabalhava transportando
cargas bilionárias, petróleo e toda essa espécie de coisas. A menina dos olhos da empresa era um grande e novíssimo navio, que fora fabricado ao custo de 2 bilhões de dólares. Um dia de serviço desse navio custava à empresa US$ 100.000 dolares. Após somente 6 meses de serviço, o navio
simplesmente parou de funcionar. Foram chamados técnicos e mais engenheiros e mais mecânicos do fabricante, que ao término de 1 mês não conseguiram resolver o problema de jeito nenhum. 30 dias com esse navio parado siginificava um prejuízo de 3 milhões de dólares para a empresa, e seus donos estavam à beira de um colapso nervoso quando foi dada a idéia de
chamar um especialista independente, que já tinha enfrentado problemas semelhantes e se saído muito bem, devido à sua experiência imensa com a complexa mecânica naval.

Eis que no dia seguinte, chega o especialista. Senta-se em frente a uma das partes do motor, tenta ligar, pressiona alguns botoes, balança a cabeça, murmura algo para si mesmo... e puxa uma chave de fenda da sua caixa de ferramentas. Desaparece por entre os motores por alguns instantes, e ao retornar diz: “problema resolvido”. Apenas ao toque de um botão, o motor
responde o navio começa a funcionar novamente no ato.

O presidente da empresa ficou impressionado, e perguntou ao especialista quanto ele lhe devia. O especialista respondeu:

- A conta é US$ 1 milhão, por favor.

O presidente da empresa ficou indignado, e falou:

- US$ 1 milhão por apenas alguns minutos de trabalho? Para apertar um parafuso? Eu sei que o meu navio é um navio de 2 bilhões de dólares, mas 1 milhão é absurdo! Pagarei somente se receber uma nota fiscal com todos os detalhes que justifiquem esse valor!

O especialista simplesmente balançou a cabeça afirmativamente e saiu.

Na manhã seguinte, o presidente recebe a nota fiscal com o serviço descriminado. Ao terminar a leitura, não hesitou e mandou que fosse paga no ato.

A nota fiscal dizia:

Serviços realizados:

Visita técnica – cortesia

Apertar um parafuso – US$ 0,10

Saber qual parafuso apertar – US$ 999.999,90”


Em suma, um problema que era remexido há um mês e sem solução foi resolvido em poucos minutos. Um erro comum é querer fazer comparações entre complexidade x tempo. Isso é errado. Quando estimamos em SCRUM utilizando planning poker, levamos em consideração o tamanho de uma história, relativo à sua complexidade – esqueça as horas. Trabalhamos com processos empíricos, lembram? Não dá para querer controlar como controlamos uma linha de
montagem.

E no final, uma estimativa é somente uma estimativa – não é uma previsão, e não precisam ser certas. Obviamente, quando atingimos uma certa regularidade e melhoramos nossa exatidão das estimativas, ganhamos mais previsibilidade e temos melhores condições de nos planejar para o futuro. Mas isso é uma coisa que vem naturalmente, assim como a velocidade do time (normalmente, entre 3 – 6 Sprints), e não pode ser forçada.

Esse texto foi redigido pelo Igor Macaubas da lista scrum-brasil.
segunda-feira, janeiro 12, 2009

Adicionar e remover elementos HTML com Javascript

As noções básicas

Conheçam uma eficiente solução para adição e remoção de itens em HTML utilizando javascript. O efeito é similar ao utilizado nos botões de anexar do google ao se adicionar um novo anexo ou remover.

Assim, você tem três elementos básicos: adição de eventos; criação e junção de elementos, bem como a capacidade para removê-los.

Por exemplo:

incluir evento / adição / remoção
* element.addEventListener(el, type, fn);
* parent.appendChild(element);
* parent.removeChild(element);



Para esta tarefa básica, utilizam-se essas duas ações como um "esqueleto" para agir com sua API que irá se adequar conforme o DOM object e o Event object.

Dom e Event

var Dom = {
get: function(el) { },
add: function(el, dest) { },
remove: function(el)
};

Event = {
add: function(el, type, fn) { }
};

Seu código pode ficar encapsulado quando se adiciona este comportamento ao evento de ‘load’.


Implementação

Event.add(window, 'load', function() {
// enclosed implementation here
});


Com isso, sua interface ganha em performance e em usabilidade.

O preenchimento dos campos.

Interface

var Dom = {
get: function(el) {
if (typeof el === 'string') {
return document.getElementById(el);
} else {
return el;
}
},
add: function(el, dest) {
var el = this.get(el);
var dest = this.get(dest);
dest.appendChild(el);
},
remove: function(el) {
var el = this.get(el);
el.parentNode.removeChild(el);
}
};
var Event = {
add: function() {
if (window.addEventListener) {
return function(el, type, fn) {
Dom.get(el).addEventListener(type, fn, false);
};
} else if (window.attachEvent) {
return function(el, type, fn) {
var f = function() {
fn.call(Dom.get(el), window.event);
};
Dom.get(el).attachEvent('on' + type, f);
};
}
}()
};


Implementação

Event.add(window, 'load', function() {
var i = 0;
Event.add('add-element', 'click', function() {
var el = document.createElement('p');
el.innerHTML = 'Remove This Element (' + ++i + ')';
Dom.add(el, 'content');
Event.add(el, 'click', function(e) {
Dom.remove(this);
});
});
});
segunda-feira, janeiro 05, 2009

Como utilizar um quadro em Scrum?




Esse vídeo da Sovis Sistemas elaborado pelo Jordano Gonzatto apresenta como a estrutura de um quadro organizado em timebox pode ser utilizado para um gerenciamento de negócios com Scrum.

Conheça, também, o trabalho desenvolvido pelo Bluesoft aqui.

Os 7 hábitos de pessoas altamente eficazes - Stephen R. Covey

Casais inteligentes enriquecem juntos - Gustavo Cerbasi

Investimentos inteligentes - Gustavo Cerbasi

Superdicas para se tornar um verdadeiro líder - Paulo Gaudêncio

Superdicas para vender e negociar bem - Carlos Alberto Júlio

Como se tornar um líder servidor - James Hunter

A estratégia do Oceano Azul - W. Chan Kim e Renée Mauborgne

A lógica do Cisne Negro - Nassim Nicholas