quinta-feira, 26 de maio de 2011

A Descrição do Trabalho do Scrum Master… Quase Perfeita!

she-ra

As Competências Pessoais para um Scrum Master:

  • Deve ser Líder Servidor;
  • Deve ser comunicativo e social;
  • Deve ser facilitador;
  • Deve ser assertivo;
  • Deve ser o primeiro a notar as diferenças e os problemas que possam surgir;
  • Deve ser entusiasmado;
  • Deve ser capaz de melhorar continuamente;
  • Deve ser capaz de resolver conflitos;
  • Deve ser capaz de liderar uma equipe auto-organizada;
  • Deve ser transparente no desenvolvimento do crescimento do negócio.

Habilidades Técnicas para um Scrum Master:

  • Compreender os fundamentos básicos do desenvolvimento iterativo;
  • Compreender os processos e metodologias e pode falar sobre eles para equipe e demais funcionários da empresa;
  • Compreender os fundamentos básicos dos processos de desenvolvimento de software e procedimentos;
  • Compreender o valor das autorizações para a entrega feita por uma equipe de desenvolvimento;
  • Entender a entrega incremental e o valor das métricas;
  • Entender o  rastreamento do atraso, o gráfico de burndown, a velocidade e a definição de tarefas;
  • Familiaridade com as práticas ágeis, ambientes orientados a serviços e melhores práticas de desenvolvimento.

Fonte:

“The Perfect ScrumMaster Job Description”:

http://agilescout.com/the-perfect-scrummaster-job-description/

Ta-ta for now

Padrão de Codificação

coding standard

Se todos os desenvolvedores adotarem um padrão único de codificação, tudo funcionaria melhor. Sendo mais fácil de manter, estender, refatorar e integrar o código. E conseqüentemente, diminuindo conflitos de código.

Felizmente, as IDE’s modernas são triviais para aplicação de vários tipos de formatação.

Fonte:

“Coding Standard”:

http://www.versionone.com/Agile101/Coding_Standard.asp

Ta-ta for now

domingo, 15 de maio de 2011

Gestão de Stakeholder e Princípios

partes interessadas

Stakeholders significa partes interessadas. O termo stakeholders no desenvolvimento de software é dado aos financiadores, gestão executiva, clientes e, outros que têm interesse financeiro no produto ou serviço. Porém há mais pessoas e grupos que podem ser considerados partes interessadas no desenvolvimento do produto de software.

Gestão de Stakeholder é uma área de gestão estratégica que oferece modelos para identificação e mapeamento de stakeholders. O pensador na área R. Edward Freeman e, autor do livro “Strategic Management: A Stakeholder Approach and Managing for Stakeholders”, encoraja o uso mais amplo do termo stakeholders. Ele identifica sete técnicas de criação de valor para os stakeholders:

  • Incluindo avaliação dos stakeholders;
  • Análise do comportamento dos stakeholders;
  • Compreensão dos stakeholders ​​em maior profundidade;
  • Avaliação das estratégias dos stakeholders;
  • Desenvolvimento de estratégias específicas para os stakeholders;
  • Criar novos modelos de interação para os stakeholders;
  • Desenvolver estratégias de criação integrada de valor.

Princípios da Gestão de Stakeholder

Os dez de princípios da Gestão de Stakeholder:

  • Os interesses dos stakeholders devem andar juntos ao longo do tempo;
  • Precisamos de uma filosofia de voluntariado para envolver os stakeholders e  gerenciamento de relacionamentos entre nós mesmos, ao invés de deixá-lo para comando;
  • Precisamos encontrar soluções para os problemas, que satisfaçam os stakeholders simultaneamente;
  • Tudo o que fazemos serve os stakeholders;
  • Trabalhamos com propósito de preencher o nosso compromisso com os stakeholders;
  • Temos necessidade de comunicação com os stakeholders, não somente os amigáveis;
  • Os stakeholders são ​compostos por pessoas reais;
  • Temos necessidade de generalizar a abordagem do marketing;
  • Trabalhamos engajados com os stakeholders primários e secundários;
  • Estamos em constante monitoramento e redesenho dos processos para torná-los melhores e servir os nossos stakeholders.

Fonte:

“Stakeholder Management” by KEN POWER:

http://systemagility.com/2010/10/17/stakeholder-management/

“Principles of Stakeholder Management, Agile, and Lean” by

KEN POWER:

http://systemagility.com/2010/10/27/principles-compared/

terça-feira, 10 de maio de 2011

Motivação 3.0

supersenna

A motivação nada mais é que o motivo para ação.

Assim sendo, temos três tipos diferentes de motivações:

  • Motivação 1.0: Percebia o homem como ser biológico, lutando apenas pela sua sobrevivência;
  • Motivação 2.0: Presumia que os humanos reagiam a recompensas e punições em seu meio ambiente, ou seja, essa motivação extrínseca;
  • Motivação 3.0: O homem tem impulso de aprender, criar e melhorar o mundo.
    Essa motivação é intrínseca.

“A Motivação Extrínseca tem origem em fatores externos ao indivíduo, como qualquer recompensa monetária. O indivíduo faz a tarefa para ser recompensado ou para não ser castigado. A punição ou a recompensa é o “combustível” que faz mobilizar o sujeito.” Jorge Elói

“A Motivação Intrínseca tem origem em fatores internos ao indivíduo, esta relaciona-se com a sua forma de ser, os seus interesses, os seus gostos. Neste tipo de motivação, não há necessidade de existir recompensas, visto que a tarefa em si própria, representa um interesse para o sujeito, algo que ele gosta ou está relacionado com a forma de ele ser. Este tipo de motivação é constante, visto que depende unicamente do sujeito e não de fatores externos.” Jorge Elói

“Escolhe um trabalho de que gostes, e não terás que trabalhar nem um dia na tua vida.”

Confúcio

Vídeo sobre O Mundo 3.0 -- A Motivação 3.0:

http://youtu.be/xxPaAVOa0QY

Vídeo TED de Daniel Pink e a surpreendente ciência da motivação (legendado):

http://on.ted.com/9DOE

Fonte:

O Mundo 3.0 -- A Motivação 3.0 por cmconsultoriaonline:

http://youtu.be/xxPaAVOa0QY

“Daniel Pink e a surpreendente ciência da motivação” por Daniel Pink:

http://on.ted.com/9DOE

“Motivação: Extrínseca Vs Intrínseca” por Jorge Elói:

http://www.psicologiafree.com/areas-da-psicologia/psicologia_clinica/motivacao-extrinseca-vs-intrinseca

Multidisciplinar não é Saber Tudo

multitarefa

Uma equipe multidisciplinar não é uma equipe sabe tudo. Na realidade, uma equipe multidisciplinar é composta por profissionais especialistas que se empenham em ajudar os seus colegas em outras tarefas.

Assim todos integrantes da equipe aumentam seus conhecimentos e, na falta de algum colega a equipe não ficará na mão.

Analisando atualmente as vagas do mercado de TI, noto que as mesmas exigem diversas tecnologias. Fico pensando no caso de um DBA, esse geralmente é especializado em mais de um banco de dados. Um DBA também poderá ajudar na modelagem de dados e programar, mas exigir que seja um excelente Webdesigner é exagerado, popularmente falando pode quebrar um galho.

O mesmo acontece com pessoal da analise e programação, que são capazes de montar tranqüilamente uma tabela no banco de dados. Mas saber alocar e reorganizar as tablespaces para tabela é tarefa para um DBA, pois exige conhecimento profundo de banco de dados.

Também vi exigências para analistas de negócios (BA) que mais parecia buscar analista de qualquer negócio que faz de tudo na TI, recomendo um excelente artigo do Professor Rildo Santos: “Analista de Negócio ou "Analista de Qualquer Negócio faz de tudo na TI"”. O foco do analista de negócios é facilitar a entrega de valor para o cliente e trabalhar junto à equipe para esse objetivo, ou seja, um facilitador entre o cliente e a equipe para entendimento do negócio.

Não é errado um profissional de TI saber mais de uma tecnologia, alias todos que conheço dominam várias tecnologias e sempre buscam mais conhecimentos, através de cursos ou autodidatamente. Mas saber tudo não existe. Um gastroenterologia é um clinico geral, mas não poderá fazer uma cirurgia no coração.

“Ninguém ignora tudo, ninguém sabe tudo. Por isso aprendemos sempre.”

Paulo Freire

Ta-ta for now

domingo, 1 de maio de 2011

Estimando Estórias com Planning Poker

Estimativa uma das principais atividades em processos ágeis. Através da estimativa é feita avaliação da dimensão de uma estória.

Estimativa com Planning Poker

Agora imagine que cada membro da equipe está segurando um baralho de cartas contendo as seguintes cartas:

clip_image001

Note que série de cartas é mais ou menos parecida com a Fibonacci's series.

O Product Owner lê todos os itens do backlog rapidamente tirando dúvidas. E a equipe escolhe um item do backlog (estória) de fácil resolução. Esse item será referência com peso 2 e depois o próximo item é estimado.

Sendo assim, o Product Owner explica o próximo item do backlog (estória) e pergunta para equipe:

clip_image002

Todos integrantes da equipe escolhem uma carta para estimar a estória.

O Scrum Master sendo o mediador pede para equipe estimar a estória e cada integrante da equipe vai mostrar uma carta:

planning poker 2

1º. Rodada da estimativa da estória com Planning Poker:

clip_image004

1) O integrante da equipe que colocou a carta menor terá que justificar o porquê da estimativa menor. No caso o integrante “A” é um analista programador experiente.

2) O integrante “D ”que colocou a carta maior terá que justificar o porquê da estimativa maior.

3) Os demais integrantes da equipe vão apenas ouvir quem estimou a maior e a menor e, ninguém entrará em conflito por causa da estimativa.

4) Se todos entraram em um consenso sobre estimativa da estória, não precisará da próxima rodada. Mas isso é muito difícil.

2º. Rodada da estimativa da estória com Planning Poker:

clip_image005

1) O integrante da equipe que colocou a carta menor terá que justificar o porquê da estimativa menor. No caso o integrante “A” é um analista programador experiente.

2) O integrante “D ”que colocou a carta maior terá que justificar o porquê da estimativa maior.

3) Os demais integrantes da equipe vão apenas ouvir quem estimou a maior e a menor e, ninguém entrará em conflito por causa da estimativa.

4) Se todos entraram em um consenso sobre estimativa da estória, não precisará da próxima rodada. Mas isso é muito difícil.

3º. Rodada da estimativa da estória com Planning Poker:

clip_image007

A equipe entrou em um consenso sobre estimativa da estória. O Scrum Master poderá intervir somente se equipe não chegar a um acordo.

Note que os integrantes “B”, “C” e “D” concordaram com a justificativa do integrante “A” e fizeram uma reavaliação de suas estimativas.

Por que a série de números estranhos?

Os números mais elevados têm menor granularidade. Por quê?

Por várias razões:

  • Acelerar o processo de estimação pela limitação do número de escolhas;
  • Evitar uma falsa sensação de precisão para as estimativas altas;
  • Incentivar a equipe a dividir estórias grandes em menores.

Uma estória com estimativa alta (estimativa>20) é aconselhável quebrar em estórias menores. Assim evita o desperdício e estórias menores permitem uma estimativa com mais detalhes.

Cartas Especiais

A carta “0” significa que essa estória está feita.

A carta “?” significa que não se sabe nada sobre estória.

A carta “xícara de café” significa que “É necessário uma pequena pausa para cansaço.".

Obs.: Tempo estimado para sessão de Planning Poker é de 4 horas.

Fonte:

“Planning Poker”:

http://www.crisp.se/planningpoker

Palestra Scrum uma Abordagem Prática - Com Eric Calvacanti:

http://www.egenial.pro/pt/repositorio

Ta-ta for now