quinta-feira, 22 de dezembro de 2011

Agile Talk 2012 em Belo Horizonte

Dia 07/01/2012, ocorrerá o primeiro evento da comunidade ágil de Minas Gerais. Assuntos como Agilidade, implantação do Scrum na Presidência da República e Lean Startup serão abordados.

Mais informações:

http://www.agilhes.com/agiletalk/

Fonte.: http://www.agilhes.com/agiletalk/

Ta-ta for now!

terça-feira, 22 de novembro de 2011

Vídeo: Sensibilidade feminina é essencial para uma líder by HSMInspiringIdeas

Uma das maiores líderes do país, a doutora Janete Vaz, fala sobre as características necessárias para a mulher enfrentar os os desafios e dificuldades para ser reconhecida e respeitada como líder:

http://www.youtube.com/watch?feature=player_embedded&v=OBcl39fFkgU

Fonte:

“Sensibilidade feminina é essencial para uma líder” by HSMInspiringIdeas:

http://www.youtube.com/watch?feature=player_embedded&v=OBcl39fFkgU

Ta-ta for now!

quinta-feira, 3 de novembro de 2011

A Cultura Ágil deve ser adotada por toda Empresa

employeesandorganization

A cultura ágil adotada apenas pela equipe de TI tem grande probabilidade de fracasso. Imagine somente o departamento de TI adotando a cultura ágil e os demais departamentos desconhecerem. Um exemplo, o departamento financeiro solicita um produto para TI, mas participa pouco do desenvolvimento do produto, e conseqüentemente o projeto fracassa.

Outro exemplo, o departamento comercial vende um produto com base no modelo cascata e a TI desenvolve usando ágil. Geralmente acontece uma adaptação do ágil nesta situação, um bom exemplo é o famoso ScrumBut.

A participação de toda empresa na cultura ágil, torna mais fácil adaptação inicial e a continuação. E conseqüentemente, a cultura de aceitação de mudanças e comprometimento de todos os colaboradores.

Mas não devemos ser utópicos, algumas empresas fracassam na cultura ágil. Assim como existem fracassos no modelo cascata, ou seja, a cultura ou o modelo esta ligada as características da empresa e dos colaboradores.

Ta-ta for now

sexta-feira, 21 de outubro de 2011

Vídeo usando JMeter para testar o RESTful

Um vídeo didático que mostra como fazer teste do webservices RESTFul usando JMeter:

http://www.youtube.com/watch?v=3xezjD-TKyE

Vale a pena conferir.

“Test de RESTful Web Services usando JMeter”:

http://www.youtube.com/watch?v=3xezjD-TKyE

Ta-ta for now!

terça-feira, 18 de outubro de 2011

Automatização de Testes através da Correção de Defeitos

homem

Ray Claridge discorre sobre uma idéia alternativa para automação de testes, através da correção de defeitos. Abaixo uma pequena síntese da idéia:

A cada defeito corrigido é verificado se a funcionalidade trabalha corretamente. E um script automatizado de testes é escrito para cobrir a funcionalidade. Assim sendo, lentamente com tempo é construído um pacote de teste de regressão, ao invés de tentar automatizar os testes a cada módulo.

É um ponto de partida rápido para automatizar os testes. Com o tempo e amadurecimento na automação, a opção pela tradicional automação por módulo, é uma idéia a ser pensada e considerada.

Fonte:

“An Alternative Approach to Automated Testing” by Ray Claridge:

http://www.testertroubles.com/2010/06/alternative-approach-to-automated.html

Ta-ta for now!

segunda-feira, 17 de outubro de 2011

Entrega Rápida

jegue 

O que é necessário para fazer uma entrega rápida?

Tenha as pessoas certas: As pessoas certas pensam por si mesmas, resolvem problemas, são pró-ativas e flexíveis, tomam as medidas apropriadas e decisões certas;

Mantenha as coisas simples: Mantenha os requisitos e as soluções simples. Encontre a maneira mais fácil de atingir o desejo do cliente;

Trabalhe em equipe: Trabalhe realmente em equipe, ajudando uns aos outros, para se certificar de que a equipe consegue atingir os objetivos almejados;

Elimine desperdícios;

Qualidade no desenvolvimento do produto. Elimine os erros ao máximo, entrega com qualidade sempre vem em primeiro lugar.

Fonte:

“Lean Principle #5 – Deliver Fast” by Kelly Watersttp://www.allaboutagile.com/lean-principles-5-deliver-fast/

Ta-ta for now!

quarta-feira, 12 de outubro de 2011

Evento Agile Night em Porto Alegre - 17 de outubro de 2011- Gratuíto

Evento Agile Night em Porto Alegre no dia 17 de outubro de 2011.

Palestras:

  • OnCast de Florianópolis;
  • ThoughtWorks;
  • GUMA;
  • 3 cases da RBS;
  • Painel no final.

Objetivo:

Discutir como implantar metodos ágeis em um contexto de desenvolvimento de produtos digitais e compartilhar experiências.

Inscrições http://www.rs.sucesu.org.br/inscricao/guma_agile

Evento limitado em 250 participantes.

Ta-ta for now!

sábado, 10 de setembro de 2011

1ª Conferência Brasileira de Análise de Negócios em Porto Alegre - RS

Do dia 22 a 25/11/2011, acontecerá a 1ª Conferência Brasileira de Análise de Negócios em Porto Alegre - RS. Os dias de cursos serão 22/11 e 23/11 e os dias de palestras serão 24/11 e 25/11.

Mais informações: http://babrazil.com/

Fonte: http://babrazil.com/

Ta-ta for now

domingo, 14 de agosto de 2011

O Sistema sem Fim

stars

O sistema sem fim começa com a previsão de tudo que deve ser feito no sistema, não adota entrega iterativa para o cliente e a comunicação é fraca.

Muitas vezes o sistema sem fim nem chega terminar pelos seguintes motivos:

  • Estouro do tempo de contrato;
  • Pedido do cliente;
  • Outros.

Um fato que deve ser analisado é que quase todo sistema sem fim adota o modelo cascata. Sendo que, depois da parada e retorno do sistema sem fim, quase toda equipe acaba adotando as seguintes melhorias:

  • Uma melhor comunicação;
  • Busca da colaboração do cliente;
  • Entrega iterativa de software funcional para o cliente;
  • Responder as mudanças;
  • Algum método ágil e boas práticas da engenharia de software.

Em suma, a cultura ágil é uma forma utilizada para sanar a história triste do sistema sem fim. Sendo assim, satisfazendo o cliente e mantendo a motivação da equipe. Pois afinal, software sofre mudança, e não dá para prever tudo como na construção de um prédio.

Fonte:

http://manifestoagil.com.br/

Ta-ta for now

segunda-feira, 8 de agosto de 2011

Agile Open Porto Alegre no dia 23 de Setembro de 2011

No dia 23 de setembro de 2011, será realizado Agile Open Porto Alegre. O evento será das 09 às 18 horas na UniRitter, campus Porto Alegre. Esse evento foi um sucesso em Campinas e Zurique.

Informações sobre o evento e inscrições no site: http://agileopenportoalegre.com/

Obs.: As inscrições são gratuitas.

Fonte:

http://agileopenportoalegre.com/

Ta-ta for now

domingo, 7 de agosto de 2011

Vídeo Falsas Certezas - Fabiano Milani

Uma conversa rápida de Fabiano Milano sobre crenças limitantes, ou seja, falsas certezas:

http://youtu.be/MmCoMP19tE8

Fonte:

“Conversa Rápida - Falsas Certezas - Fabiano Milani” by

adaptworks:

http://youtu.be/MmCoMP19tE8

Ta-ta for now

Vídeo Liderança técnica e bons líderes - Fabiano Milani by adaptworks

Uma conversa rápida de Fabiano Milano sobre a diferença da liderança técnica e bons lideres:

http://www.youtube.com/watch?v=_Gk3o8r8mkU

Fonte:

“Conversa Rápida - Liderança técnica não é sinônimo de bons líderes - Fabiano Milani” by adaptworks:

http://www.youtube.com/watch?v=_Gk3o8r8mkU&feature=related

Ta-ta for now

 

quarta-feira, 3 de agosto de 2011

Alguns Cuidados ao Aproveitar uma Funcionalidade

comida

A prática de aproveitamento de uma funcionalidade não é recomendável seguindo as boas práticas da engenharia de software. Mas com maturidade profissional e a corrida contra o tempo é muito utilizada, sendo assim vou citar alguns cuidados que devem ser tomados no aproveitamento de uma funcionalidade:

  • A funcionalidade que esta sendo aproveitando supre a necessidade do negócio? Lembre-se que você não é apenas um codificador e deve saber o negócio que esta desenvolvendo;
  • A duplicação de uma mesma funcionalidade em um sistema contribui para o crescimento desordenado do mesmo. Evite arquiteturas inchadas, se estão sendo duplicadas é sinal que são genéricas. Lembre-se do sistema Lean e diga não ao desperdício;
  • Aplique teste unitário na funcionalidade aproveitada ou genérica ao sistema. Quebrar o teste, refatorar e fazer o teste passar é mais uma contribuição na qualidade do negócio e código;
  • Aplique Clean Code na funcionalidade. Lembre-se da Regra do escoteiro: Deixe área do acampamento mais limpa do que quando você a encontrou. Mantenha seu código limpo como sua casa

Ta-ta for now!

quinta-feira, 21 de julho de 2011

Dicas para Escrever uma Boa Estória do Usuário

A estória do usuário é uma técnica de descrição dos requisitos ágeis. A Estória contém nome, uma breve narrativa e critérios de aceitação. É relativamente fácil de escrever, decompor e refinar. Algumas dicas na descrição de uma boa estória do usuário:

stories

  • Foco no usuário;
  • Use estórias para facilitar a conversa entre: a equipe, o cliente, o usuário e as partes interessadas;
  • Escrever estórias é um trabalho em equipe;
  • Mantenha sua estória simples e concisa;
  • Progressivas decomposições em estórias menores, melhoram a sua estória;
  • Não se esqueça dos critérios de aceitação;
  • Use temas para organizar suas estórias. Cada tema é um grupo de estórias relacionadas.
  • Use cartões de papéis;
  • Coloque as estórias em um lugar visível a todos.

Fonte:

“WRITING GOOD USER STORIES”:

http://www.romanpichler.com/blog/user-stories/writing-good-user-stories/

Ta-ta for now

terça-feira, 12 de julho de 2011

Bacalhau Somente no Prato

bacalhau

O bacalhau é um apelido dado para programa. Os programadores cobol usam muito o termo ainda.

Mas bacalhau não é uma boa prática de engenharia de software. Geralmente feito rápido, com testes fracos, orientado a reza e sem as boas práticas da engenharia de software. Resumindo, uma forma de apagar rapidamente um incêndio.

Afirmo também que o bacalhau não é exclusividade do cobol, existem vários bacalhaus em java, visual basic, clipper, asp, c++ e outras linguagens. E os ambientes que desenvolvem os bacalhaus são variados, vão desde bancos a empresas de telecomunicação.

Para acabar com bacalhau, que só faz o sistema crescer desordenadamente como um tumor maligno, existem algumas idéias:

  • Aplicação de boas práticas de engenharia de software;
  • Prática de testes;
  • Clean code;
  • E um consenso da equipe em favor da qualidade.

Moral da história: Não adianta fazer um lixo e ter que refazer várias vezes. O custo será mais alto.

Ta-ta for now

sábado, 25 de junho de 2011

Quando Analista de Negócios não faz o seu Papel

teatro 

Uma das grandes causas de fracasso de um projeto é a péssima analise do negócio. Isso acontece quando analista de negócios não faz o seu papel de facilitador entre o cliente e a equipe.

Não estou afirmando que analista de negócios deve saber tudo sobre o negócio. Mas procurar o cliente e as partes interessadas para aprender sobre o negócio e elaborar os requisitos do cliente, são processos que fazem parte do seu trabalho. Mantendo uma comunicação freqüente entre o cliente, as partes interessadas e a equipe.

Geralmente, o fracasso da analise do negócio é causada pela pouca comunicação com o cliente, as partes interessadas e a equipe. Conseqüentemente, analista de negócios acaba levantando requisitos sem valor para desenvolvimento do produto, frustrando o cliente com produto sem valor e a equipe pelo fracasso do projeto. Situação lamentável que leva ao retrabalho e a possível demissão do analista de negócios.

Ta-ta for now

Dependência e Comunicação Fraca em um Projeto

mãos

Era uma vez um grande projeto feito com base na cultura cascata. Esse projeto era composto por vários módulos como cadastro, vendas, compras, estoque, contabilidade, financeiro e outros. Existiam várias equipes e conseqüentemente pessoas trabalhando nele, mas muitas pessoas em um projeto nem sempre é a solução, pois a dependência com o cadastro era um grande gargalo que atrasava os demais módulos e a comunicação era extremamente fraca.

Saliento também que existia dependência entre os demais módulos, mas nada era comunicado e o ambiente não era informativo. Para ajudar a equipe de teste era totalmente isolada das demais equipes e ficava sem caso de uso para testar. Cenário lamentável.

Se projeto fosse feito usando a cultura ágil grande parte dos problemas seriam resolvidos. O módulo de cadastro teria maior prioridade de conclusão com mais de uma equipe trabalhando no módulo. As entregas seriam por iterações com aplicação de reuniões diárias curtas, boas práticas de engenharia de software, boa comunicação, ambiente informativo e cada equipe composta por um testador. Com certeza, já no módulo cadastro alguns requisitos seriam eliminados por não agregar valor, claro com a participação ativa do cliente em todas as iterações necessárias para o projeto.

Após a conclusão do módulo cadastro, as equipes poderiam trabalhar nos demais módulos, sem o caos da dependência com o cadastro e as demais dependências mapeadas e informadas.

Ta-ta for now

quinta-feira, 23 de junho de 2011

Ser Rejeitado e Continuar Amando o que Faz

reject

Assisti novamente o discurso de colação de Grau em Stanford - 2005, realizado por Steve Jobs. Nesse discurso ele contou três histórias de sua vida, e uma chamou bastante atenção: "Eu fui rejeitado, mas continuava amando."

Steve Jobs foi o criador do Macintosh na garagem dos pais, que deu origem Apple. Porém Steve Jobs foi demitido da Apple por divergências com um funcionário qualificado, contratado com a finalidade de impulsionar o crescimento da empresa.

Analisei a rejeição e conclui que ela tem um lado bom, acredite em mim. Steve Jobs e outros profissionais tiverem que recomeçar após rejeição. O que estimula a busca do conhecimento, a persistência, a criatividade e a inovação.

No caso de Steve Jobs impulsionou a criar a NeXT e a Pixar. E também encontrou amor de sua vida.

Steve Jobs voltou novamente para Apple, e hoje os cobiçados IPhone, IPad e Macbook são frutos da inovação dele e de colaboradores.

Por isso sempre persista. E busque o conhecimento para inovar e colher bons frutos.

Fonte:

“Steve Jobs - Discurso de colação de Grau em Stanford, 2005.”:

http://www.youtube.com/watch?v=rPIFP6_cimQ

Ta-ta for now

domingo, 19 de junho de 2011

A Cultura de Equipe Começa na Família

baby

A família é a primeira equipe de uma criança, não importando o tamanho ou a composição da família. Uma criança vai aprender  valores, princípios, auto-organização e socialização no dia a dia da família. E cabe a família estimular o espírito de equipe na criança, através de brincadeiras e jogos e, trabalhar a idéia que todos os membros da equipe são responsáveis pelo fracasso ou sucesso da equipe. Um bom exemplo de auto-organização estimulado pela família é quando uma criança é estimulada a guarda seus brinquedos em um organizador após brincar.

A fase da escolinha é que fornece a primeira convivência da criança com outras fora do ambiente familiar e, ajuda na formação do espírito em equipe. A criança começa a ouvir a opinião de outras e também opinar, sendo a primeira socialização fora de casa. As professoras da escolinha podem trabalhar o espírito de equipe nas crianças através aplicações de jogos e brincadeiras coletivas.

Já no ensino fundamental, médio e faculdade predomina o trabalho em grupo para infelicidade da formação do estudante. No trabalho em grupo, cada integrante pega um pedaço do trabalho, sem interação e sem colaboração entre os alunos. Para estimular o trabalho em equipe entre os alunos, cabe aos mestres incentivarem a colaboração e interação entre os alunos e assim formarem futuros integrantes de equipes.

segunda-feira, 13 de junho de 2011

Como Remover Desperdícios no Produto Backlog?

waste

Desperdícios consomem recursos valiosos e tiram o foco no que é importante. Para remover os desperdícios no produto backlog são necessários os seguintes passos:

  • Reduzir o inventário no produto backlog: Minimizar a quantidade de itens detalhados no produto backlog e incluir apenas itens que são essenciais para criar um produto de sucesso;
  • Evitar o excesso de produção: Focar nas funcionalidades mínimas necessárias para trazer vida ao produto, criando assim um produto valioso para cliente;
  • Minimizar os defeitos, transferências e criatividades não utilizadas através do envolvimento dos membros da equipe e das partes interessadas no preparo do produto backlog. Isso ajuda descobrir e descrever itens do backlog, evitando a entrega de requisitos sem valor para o produto do cliente. E também garante a clareza dos requisitos, reduzindo assim os defeitos, aproveitando a criatividade e os conhecimentos dos integrantes da equipe e das partes interessadas. Além de priorizar o produto backlog e assegurar que os riscos técnicos e as dependências são contabilizados.

Fonte:

“THE LEAN PRODUCT BACKLOG – ELIMINATE WASTE:”

http://www.romanpichler.com/blog/lean-and-kanban/the-lean-product-backlog-eliminate-waste/

Ta-ta for now

sábado, 11 de junho de 2011

Propriedades do Kanban

Propriedades do Kanban:

  • Físico: É um cartão físico;
  • WIP: Limita o trabalho em processo e impede a superprodução;
  • Fluxo Contínuo: Informa a necessidade de produção antes que cliente esteja sem estoque;
  • Pull: Fluxo puxado;
  • Auto-organização;
  • Visual: Mostra o estado atual do processo de forma visual;
  • Sinal: O estado visual sinaliza as ações no processo;
  • Kaizen: A visualização do fluxo do processo estimula a melhoria continua;
  • Anexado: Ele está ligado e se move com as partes físicas fornecidas.

Fonte:

“Kanban Applied to Software Development: from Agile to Lean”

by Kenji Hiranabe:

http://www.infoq.com/articles/hiranabe-lean-agile-kanban

Ta-ta for now

segunda-feira, 6 de junho de 2011

Vaga para SOFTWARE DEVELOPMENT ENGINEER IN TEST na Microsoft

A Microsoft esta contratando Software Development Engineer in Test, para o time de localização de ERP. O local de trabalho é em São Paulo, SP. Email para mais informações aos cuidados de Daniela Lemos: daniela.lemos@talengy.com.br

Job Description

SOFTWARE DEVELOPMENT ENGINEER IN TEST

Global Financials Management (GFM)

Company Description:

Microsoft

www.microsoft.com

Founded in 1975, Microsoft (Nasdaq “MSFT”) is the worldwide leader in software, services and solutions that help people and businesses realize their full potential.

Reporting Relationships:

Senior Test Lead.

Location:

São Paulo, SP - Brazil

About the Position:

Microsoft is making a huge R&D investment in Enterprise Resource Planning (ERP) applications business. Along with the functional expansion in depth and breadth of the Business Applications, Microsoft Dynamics is taking the ERP Business globally in order to compete and win in the major and strategic Markets around the globe. To succeed in this mission, we must take our testing to new levels. If you’re a highly motivated individual who is eager to make an impact on quality and how we scale our testing efforts for business applications, we have a role for you on the Dynamics AX team.

GFM LATAM team is responsible for delivering local legal requirements for Latin America and also driving Dynamics AX to become a top-notch competitor in the Region. We are looking for a motivated, customer focused, technical and accountable individual that will drive feature set testing; participate in test automation and engage with customers and partners to ship a great product.

Job Summary:

The ideal candidate will have business knowledge, programming skills, a passion for creating quality software, and solid collaboration skills to ensure that high quality processes and products are created. If you love technical challenge, like to work in an environment where managers recognize and promote potential; have tester’s skill and instinct but also want to utilize your programming skills and debugging skills, then this job is for you.

As SDET (Software Development Engineer in Test), your key responsibilities will include:

  • Define test strategies for new features
  • Write test design specifications for testing automation
  • Implement test automation seeking for the best balance between scenario priorities, coverage and test run window.
  • Implement higher level business abstraction testing API’s
  • Participate in functional specification and design documents review to influence and ensure testability and high quality features
  • Execute automated and manual tests and analyze the results
  • Analyze, debug, and report defects and then verify fixed defects by creating regression test cases

Skills & Expertise Requirements:

  • Excellent technical skills, attention to detail, strong debugging and problem solving skills;
  • Bachelor degree or higher in CS, CIS, MIS or similar field, or at least 3 years of equivalent work experience;
  • Ability to write production-quality code in either C# or C++ or similar language;
  • Strong cross-group collaboration and communication skills;
  • Self-driven and ability to work with minimal direction;
  • Show strong initiative, willingness to learn, quickly fill in personal experience gaps, and should strive to become a domain expert;
  • ERP functional knowledge and prior experience with test automation is a plus.

Ta-ta for now

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

terça-feira, 26 de abril de 2011

Felicidade no Trabalho by Julio Peres

Fatores como felicidade, generosidade, gratidão, justiça e temperança estimulam o crescimento profissional no mercado competitivo. Segundo entrevista dada pelo psicólogo e consultor Julio Peres para jornalista Patrícia Buneker.

Outro assunto da entrevista é a estratégia que a organização deve ter com a infelicidade de um funcionário, que poderá desmotivar uma equipe inteira. Pois o funcionário é uma célula deste grande organismo (a empresa), se você não cuidar da célula o organismo adoecerá.

Vale apena conferir:

Fonte:

“Felicidade no trabalho gera resultados positivos” by Julio Peres, HSMInspiringIdeas:

www.youtube.com/watch?v=_wQ6496xC8w

Ta-ta for now

domingo, 24 de abril de 2011

O que é Personal Kanban?

personalkanban

O que é Personal Kanban?

É uma maneira simples de visualizar e controlar o seu trabalho.

Apesar de nossas boas intenções, há caminhos que tornam a vida mais complicada. Pessoas, tarefas, responsabilidades, prazos e diversão competem pela nossa atenção. E o cérebro humano não responde bem ao stress da multitarefa. Uma ferramenta de produtividade pessoal aconselhável para resolver esse problema é o Personal Kanban.

O Personal Kanban é adaptável a todas as idades e situações e, acessível a todos os estilos de aprendizagem. E permite visualizar a quantidade de trabalho que temos e a maneira que o trabalho é realizado. É também escalável e adaptável, sendo que escalável significa que poderá ser usado por você, sua família ou os grupos de trabalho.

Existem apenas duas regras no Personal Kanban:

  • Visualize seu trabalho;
  • Limite seu trabalho em progresso.

Slides de como funciona o Personal Kanban, como criar e o que fazer com ele:

Personal Kanban 101 from Jim Benson.

Fonte:

http://www.personalkanban.com/pk/personal-kanban-101/

Ta-ta for now

sábado, 23 de abril de 2011

Perfil Profissional, Conhecimento, Estratégia, Inovação, Qualidade e Consumidor by Waldez Luiz Ludwig - Programa do Jô Soares

imagem

Uma Entrevista com Psicólogo e Consultor de Empresas Waldez Luiz Ludwig no programa do Jô Soares sobre perfil profissional, valorização do conhecimento, equipe, estratégia, inovação, qualidade e consumidor:

http://youtu.be/Wtnn69-oQ8E

http://youtu.be/mmWODyD6_XE

http://youtu.be/9wewvBwcsQ8

Fonte:

http://youtu.be/Wtnn69-oQ8E

http://youtu.be/mmWODyD6_XE

http://youtu.be/9wewvBwcsQ8

 

Ta-ta for now

As Cincos Coisas que Levam ao Desperdício

Todo desperdício deve ser eliminado.

Para Personal Kanban, as cincos coisas que levam ao desperdício:

  • Algo que reduz o seu desempenho;
  • Algo que alguém poderia fazer com mais eficiente;
  • Algo que leva mais tempo do que vale;
  • Algo que não é seu ponto forte;
  • Algo que você não goste ou quer fazer.

O que pode ser feito para eliminar as coisas que levam ao desperdício?

  • Identificar;
  • Entender;
  • Reorientar;
  • Terceirizar;
  • Delegar;
  • Automatizar;
  • Eliminar.

Seu tempo é sagrado. Deixe o Personal Kanban ajudá-lo a descobrir o melhor caminho para eliminar os desperdícios da sua vida.

Fonte:

“The Five Somethings of Waste” by Jim Benson:

http://www.personalkanban.com/pk/featured/the-five-somethings-of-waste/

Ta-ta for now

Um Grande Exemplo de Líder Servidor

marlimedeiros

Marli Medeiros, criadora e presidente da ONG Centro de Educação Ambiental na Vila Pinto em Porto Alegre é um grande exemplo de líder servidor. A ONG possui um Centro de Triagem da Vila Pinto, que gera trabalho e renda e, ajudou as mulheres da comunidade a saírem das mãos dos traficantes locais para serviço de reciclagem. Atualmente com 60 associadas e 300 pessoas beneficiadas indiretamente pelo Centro Cultural da Vila Pinto que é outro serviço operacional da ONG.

A líder Marli buscou conhecimento e patrocínio para concretizar o Centro de Educação Ambiental na Vila Pinto. Esse centro não trabalha somente na reciclagem, também coordena outros projetos na comunidade, como Centro Cultural da Vila Pinto que oferece oficina de costura, oficina de teatro, oficina de mosaico, telecentro, biblioteca, oficina de dança, escolinha de futebol, assistência jurídica gratuita, passeios culturais e de lazer, sala de cinema e cozinha comunitária. E irá coordenar uma creche e um centro esportivo.

É admirável o amor e a preocupação que essa líder tem pela sua comunidade e a relação de confiança. Sua garagem esta sempre aberta para qualquer emergência, seu carro serve de ambulância a carro funeral.

A líder Marli Medeiros já recebeu vários prêmios e destaques no Brasil, Suíça, Venezuela e Itália. E na Alemanha ganhou prêmio de Inovação na Área Social.

No TEDxLaçador, tive a felicidade de assistir a palestra da líder Marli Medeiros, onde fiquei conhecendo o trabalho dessa grande mulher.

Marli Medeiros é um grande exemplo de líder servidor. O Brasil precisa de mais pessoas como você.

Fonte:

http://www.youtube.com/watch?v=ejIlcZJd4cA

http://www.tedxlacador.com/blog/?p=143

Ta-ta for now

domingo, 17 de abril de 2011

Falando de Refatoração

oficina

A refatoração é o processo de simplificação do código existente, sem alterar o seu comportamento. A falta de refatoração poderá causar dependências doentias entre classes ou pacotes, código duplicado e outras confusões.

Para evitar confusões à refatoração é prioritária com aplicação de testes unitários. Quem usa a prática TDD, a refatoração e os testes unitários estão na prática. E assim elimina o código sujo.

 

tdd 

Agora imagine uma oficina mecânica que tenha cinco funcionários e, nenhum deles coloca as ferramentas no lugar certo após o uso. Nessa mesma oficina ninguém é responsável pela faxina e as peças estragadas são jogadas no quintal alimentando uma grande montanha de peças inúteis. Na administração o computador com sistema da oficina é usado para joguinho no almoço e, faz tempo que oficina voltou para velho fichário fora de ordem. E para ajudar um pouquinho mais os funcionários não se atualizam a tempo.

Uma oficina mecânica cheia de problemas como a citada, geralmente tem alto índice de defeitos e atrasa na entrega de serviços, conseqüentemente gerando insatisfação nos clientes. Mediante aos problemas citados proponho uma refatoração na oficina:

  • Limpeza da oficina diáriamente;
  • Organização das peças;
  • Fornecer as peças estragadas para um serviço de reciclagem;
  • Organização da administração;
  • Atualização dos funcionários.

O mesmo cenário da oficina mecânica acontece com código que não é refatorado. O código vai crescendo cheio de problemas e sujeiras, ou seja, um código doente.

Dica: Aproveite o recurso de refatoração das IDE’s. Esse recurso automatiza a refatoração do código.

Fonte:

“Refactoring”:

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

Ta-ta for now

quinta-feira, 14 de abril de 2011

JsUnit para Testes Unitários no JavaScript

JsUnit é um framework de testes unitários para o lado cliente, sendo responsável pelos testes no JavaScript. Frisando que JsUnit é um framework 100% escrito em JavaScript.

TDD no Javascript

tdd 

Algumas considerações sobre JsUnit:

  • Os testes unitários no JsUnit são chamados de funções de testes;
  • Funções de testes estão em uma página HTML, chamada de página de teste;
  • A página de teste é uma página HTML que tem um Javascript e deve incluir o jsUnitCore.js;
  • O jsUnitCore.js fornece as funções assertions do JsUnit;
  • JsUnit suporta setUp e tearDown;
  • Uma página suíte de teste declara uma função suite, que retorna uma JsUnitTestSuite para agrupar as páginas de testes;
  • A página testRunner.html roda páginas de testes;
  • A página testRunner.html pode ser executada no servidor de arquivos ou no servidor web.

Funções Assertions:

  • assert([comment], booleanValue)
  • assertTrue([comment], booleanValue)
  • assertFalse([comment], booleanValue)
  • assertEquals([comment], value1, value2)
  • assertNotEquals([comment], value1, value2)
  • assertNull([comment], value)
  • assertNotNull([comment], value)
  • assertUndefined([comment], value)
  • assertNotUndefined([comment], value)
  • assertNaN([comment], value)
  • assertNotNaN([comment], value)
  • fail(comment)

Obs.: Comentário é opcional.

Como instalar e usar JsUnit?

1) Fazer um download do JsUnit http://www.jsunit.net/ e extrair em uma pasta. No exemplo extrai na pasta c:\jsunit.

image

2) No navegador rodei testRunner.html, que esta na pasta c:\jsunit:

j Note que digitei no browse file:///C:/jsunit/testRunner.html

3) No meu exemplo criei um HTML calculoTest.html com testes unitários através das funções Javascript na pasta c:\jsunit\tests:

<html>

<head>

<script language="JavaScript" src="../app/jsUnitCore.js">

</script>

<script language="JavaScript">

function multiply(arg1, arg2) {

return arg1*arg2;

}

function testRetornoSeis() {

assertEquals(6, multiply(2, 3));

}

function testRetornoDez() {

assertEquals(10, multiply(2, 5));

}

function testRetornoNotNul() {

assertNotNull(multiply(2, 5));

}

</script>

</head>

<body>

Testes Unitários multiply(arg1, arg2).

</body>

</html>

4) Agora vamos rodar o calculoTest.html na página TestRunner.html:

  1. Primeiro preencher o campo file com C:/jsunit/tests/calculoTest.html;
  2. Clicar Run.

j2

Esse post mostrou um pouco sobre testes unitários no Javascript.

A documentação e exemplos sobre JsUnit estão no link http://www.jsunit.net/. Também existe uma apresentação na pasta doc do JsUnit e material na internet.

Fonte:

http://www.jsunit.net/

Ta-ta for now

terça-feira, 5 de abril de 2011

Os 7 Desperdícios da Engenharia de Software Segundo o Pensamento Lean

dinheiro

O desperdício no Pensamento Lean é uma atividade que não agrega valor ao cliente. Agora que já sabemos o que é um desperdício segundo o Pensamento Lean, vamos ver os 7 desperdícios da engenharia de software conforme o Pensamento Lean:

1) Transporte:

  • Handoffs - Movimento do produto que não agrega valor.

2) Inventário:

  • Mais informações do que o cliente necessita;
  • Código completo, mas não documentado;
  • Código não testado;
  • Código em ambiente de teste, mas não em ambiente de produção;
  • Código com excesso de comentários.

3) Movimento:

  • Movimento físico ou mental que não agrega valor, como multitarefa.

4) Esperando:

  • Tempo ocioso quando as pessoas, materiais, informações ou equipamento não estão prontos;
  • Aguardando a aprovação do projeto;
  • À espera de recursos;
  • Esperando por aprovação de um processo de mudança;
  • À espera de gerenciamento de produto ou requerimentos.

5) Overprocessing:

  • Passos extra ou esforço - Esforço que não agrega valor ao cliente;
  • Reaprender uma função, classe ou um pedaço de código;
  • Refatorar um pedaço de código que já atende aos requisitos. Mas quando um código não é limpo, os testes unitários e a refatoração serão necessários.

6) Overproduction:

  • Produzir mais do que o cliente precisa ou quer;

7) Defects:

  • Erros e retrabalho.

Fonte:

“The Seven Wastes of Software Engineering” by PETE ABILLA:

http://www.shmula.com/the-seven-wastes-of-software-engineering/2190/

Ta-ta for now

segunda-feira, 4 de abril de 2011

Dicas para Criar uma Equipe Scrum Estável

equipe scrum

Para criar uma equipe scrum estável, Roman Pichler deu as seguintes dicas em seu artigo “STABLE TEAMS”:

  • Considere cuidadosamente quem irá compor a equipe nos seguintes papéis: PO, Scrum Master e a equipe para desenvolver o produto;
  • Minimizar mudanças na equipe dentro ou entre releases;
  • Estabelecer uma parceria de longo prazo entre uma equipe e seu produto, cada produto deve ser desenvolvido por uma ou mais equipes dedicadas. Isso facilita o aprendizado e simplifica a alocação de pessoas.

O PO deve ser sempre um membro permanente da equipe. Isso permite que o indivíduo gerencie todo o ciclo de vida do produto.

Fonte:

“STABLE TEAMS” by Roman Pichler:

http://www.romanpichler.com/blog/roles/stable-teams/

Ta-ta for now

segunda-feira, 28 de março de 2011

Vídeo TED: O caminho entre o "não" e o "sim" by William Ury

William Ury, autor de "Gretting to Yes" oferece uma maneira elegante e simples (mas não fácil) de criar um acordo mesmo em as situações difíceis:

http://www.ted.com/talks/lang/por_br/william_ury.html

Fonte:

“The walk from "no" to "yes"” by William Ury:

http://www.ted.com/talks/william_ury.html

Ta-ta for now

sábado, 26 de março de 2011

História do Sistema Toyota de Produção (TPS)

Os dois vídeos são sobre a história do Sistema Toyota de Produção (TPS) e abrangem o período desde os tempos da fabricação de teares até atualidade:

 

Fonte:

http://www.aliadaconsultoria.com.br/

www.youtube.com/watch?v=c6KVeDbgRgU

www.youtube.com/watch?v=6vmdVR9dzPM

Ta-ta for now

terça-feira, 22 de março de 2011

Dez Dicas para Melhorar o Produto Backlog

fila

Trabalhar com um produto backlog pode ser desafiador e, os PO’s lutam com atrasos longos e backlogs detalhados. As seguintes dicas ajudam a manter o foco no produto backlog:

  • Derive seu produto backlog da visão do produto;
  • Certifique-se que o seu produto backlog é detalhado de forma adequada e priorizada;
  • Use uma abordagem estruturada, ou seja, um produto backlog hierárquico;
  • Deixe o seu produto backlog visível;
  • Mantenha o seu produto backlog focado e conciso;
  • Utilize as estórias de usuários para capturar os requisitos funcionais;
  • Use riscos, dependências e liberação para decidir o tempo que um item deve ser implementado;
  • Gerencie requisitos globais não-funcionais com cuidado;
  • Cuide de seu produto backlog regularmente de forma colaborativa;
  • Certifique-se que os principais itens estão prontos.

Fonte:

“Roman’s Top Ten Product Backlog Tips” by Roman Pichler:

http://www.romanpichler.com/blog/product-backlog/top-ten-product-backlog-tips/

Ta-ta for now

domingo, 20 de março de 2011

Equipes que não Gostam de Reuniões Diárias

ginastica

Algumas equipes não gostam de reuniões diárias, pelas seguintes razões:

  • Elas já se comunicam muito bem;
  • Elas colaboram com Scrum Master na resolução das questões;
  • Elas recebem toda a orientação necessária do PO;
  • Elas não precisam escrever post-it em um quadro na parede;
  • Elas não necessitam do gráfico de burndown.

Algumas questões:

Vale apena manter a reunião diária? Ou esta faltando algo nestas equipes? Ou estas equipes chegaram ao mais alto nível de auto-organização e produtividade que não precisam mais da reunião diária? O que você pensa sobre isto?

Na verdade estas equipes estão abandonando a cultura ágil (valores, princípios e práticas). E será que elas conseguirão os mesmos resultados com outra cultura?

Fonte:

“Daily Scrum Standup Meetings “ by ScoutMaster for AgileScout.com:

http://agilescout.com/daily-scrum-standup-meetings/

Ta-ta for now

domingo, 13 de março de 2011

Livro Caindo na Real by 37signals

caindo na real

O livro “Caindo na Real” foca a construção de aplicações web, mas também mostra idéias para atividades que não são de software. Há sugestões sobre equipes pequenas, prototipação rápida e muitas outras que podem servir como um guia para quem esta começando um negócio.

Aconselho o livro para empreendedores, designers, programadores ou marketeiros.

A tradução do livro em português esta no seguinte site: http://gettingreal.37signals.com/GR_por.php

Obrigado a toda equipe envolvida na organização, tradução e revisão:

Organização: Fabio Akita

Tradutores: Herval Freire, Juraci Krohling Costa, Marcello Rocha, Diogo Bispo, Adriano Mitre, Ricardo Augusto, Rodrigo Kochenburger

Revisores: Mateus Del Bianco, Diogo Bispo, Davis Zanetti Cabral, Gustavo Cardoso, Ricardo Augusto

Fonte:

gettingreal.37signals.com/GR_por.php

Ta-ta for now

domingo, 6 de março de 2011

Pessoas Ágeis

agile people

As equipes ágeis bem sucedidas são feitas por pessoas que têm as seguintes características:

  • Tem paixão pelo que fazem;
  • Tem compreensão e compromisso de equipe. Elas ganham e perdem como equipe;
  • O software é difícil e existem restrições. As pessoas da equipe reconhecem e compreendem essas limitações. E sabem como combater as mesmas;
  • Trabalham com as boas práticas da engenharia de software, tais como: testes automatizados, integração contínua, TDD, ATDD, BDD, FDD, código limpo e refatoração;
  • Adaptáveis as mudanças do projeto;
  • Valorizam a simplicidade e abominam a complexidade;
  • Elas são especialistas em alguma área, mas também conhecedoras de outras áreas;
  • Elas desenvolvem um produto de software que acrescente valor ao cliente;
  • Elas são pensadoras e questionadoras;
  • Elas preocupam-se profundamente com sua equipe e seus clientes.

Fonte:

“Agile People Are…” by Jungho Kim:

http://www.architech.ca/2010/05/agile-people-are/

Ta-ta for now

Podcast: Como motivar sua equipe by Eliana Dutra

Uma equipe dá o melhor de si quando existe confiança entre o líder e a equipe:

http://vocesa.abril.com.br/desenvolva-sua-carreira/podcast/como-motivar-sua-equipe-491903.shtml

Fonte:

“Como motivar sua equipe” by Eliana Dutra:

http://vocesa.abril.com.br/desenvolva-sua-carreira/podcast/como-motivar-sua-equipe-491903.shtml

Ta-ta for now

Criando um Mapa Mental com MindMeister

Vídeo que mostra como criar um mapa mental com MindMeister:

Fonte:

“Como criar mapas mentais - Parte 1 – MindMeister” by konfide:

http://www.videolog.tv/video.php?id=630567

Ta-ta for now

quarta-feira, 2 de março de 2011

Criatividade sem Inovação não Basta

Não basta apenas ser criativo, tem que ser inovador. Vídeo de Waldez Ludwig - Criatividade versus Inovação:

Fonte:

Vídeo Criatividade versus Inovação by Waldez Ludwig:

www.youtube.com/watch?v=gDJkbsfT55w

Ta-ta for now

terça-feira, 1 de março de 2011

Os setes desperdícios de software

desperdicio

O Desperdício é tudo que não agrega valor ao cliente. É um dos dois princípios mais importantes do Lean, o outro é respeito às pessoas.

Os setes desperdícios de software são:

  • Trabalho incompleto;
  • Excesso de processos;
  • Excesso de funcionalidades;
  • Troca de tarefas;
  • Handoffs;
  • Atrasos da equipe por causa da dependência de outra e funcionalidades desnecessárias;
  • Defeitos não encontrados em testes.

Fonte:

Desenvolvimento de Software Lean - Curso de Verão 2009 - IME/USP by Eduardo Katayama e Hugo Corbucci:

http://ccsl.ime.usp.br/agilcoop/files/AgilCoop-Verao2009-Lean.pdf

Ta-ta for now

segunda-feira, 28 de fevereiro de 2011

Vídeo: Intra-Empreendedorismo

Gladis Costa, fundadora do grupo Mulheres de Negócios no LinkedIn, explica o que é intra-empreendedorismo:

Fonte:

O que é intra-empreendedorismo by wsibrasilvideos:

www.youtube.com/watch?v=SG_QfwkhxlA

Ta-ta for now

sexta-feira, 25 de fevereiro de 2011

Vídeo: Instalação e Uso do Cliente TortoiseSVN

Tutorial sobre instalação e uso do cliente TortoiseSVN:

Fonte:

“Instalação e Uso Do TortoiseSVN ” by Sandro Múcio:

 www.youtube.com/watch?v=qvTYKHnEgd8

Ta-ta for now

sábado, 19 de fevereiro de 2011

Vídeo: Profissional independente não assusta mais as empresas

Um vídeo de José Augusto Minarelli sobre profissional independente e aceitação nas empresas:

Fonte: www.youtube.com/watch?v=StaOX0lOL0o

Ta-ta for now

quarta-feira, 16 de fevereiro de 2011

Testando ao Sabor do Mockito

mockito drink

O objeto mock simula o comportamento. Sendo que, na simulação do comportamento do CRUD Bairro, utilizarei o framework mockito que permite escrever testes limpos e simples. Segundo o site do mockito, os testes poderão ser feitos tranqüilamente, sem medo de ressaca. Então, vamos saborear o drink teste.

Interface DAO:

public interface BairroDAO {

public boolean criar(Bairro b);

public boolean deletar(Long id);

public boolean atualizar(String nome, Long id);

public Bairro load(Long id);

}

Importante: A implementação da classe DAO é feita com hibernate, como estou simulando o comportamento através do objeto mock, esta classe não realizará as transações no banco de dados.

Classe que implementa o serviço do CRUD Bairro:

public class BairroService {

private BairroDAO bairroDAO;

public void setBairroDAO(BairroDAO bairroDAO) {

this.bairroDAO = bairroDAO;

}

public boolean criar(Bairro b) {

return bairroDAO.criar(b);

}

public boolean deletar(Long id) {

return bairroDAO.deletar(id);

}

public boolean atualizar(String nome, Long id) {

return bairroDAO.atualizar(nome, id);

}

public Bairro load(Long id) {

return bairroDAO.load(id);

}

}

 

Classe de teste mock. Testando serviços como criar, deletar e load(carregar):

import junit.framework.Assert;

import junit.framework.TestCase;

import org.junit.Before;

import org.junit.Test;

import org.mockito.Mockito;

public class TestBairroMock extends TestCase {

private BairroService bairroService = new BairroService();

private BairroDAO bairroDAO;

@Before

public void setUp() throws Exception {

bairroDAO = Mockito.mock(BairroDAO.class);

bairroService.setBairroDAO(bairroDAO);

}

@Test

public void testCriar() throws Exception {

Bairro b = new Bairro();

b.setNome("Infelicidade");

//Quando for chamado o serviço criar retornará o valor booleano

Mockito.when(bairroDAO.criar(b)).thenReturn(true);

/ / chama o serviço que deseja testar

boolean result = bairroService.criar(b);

//Verifica se o serviço foi chamado

Mockito.verify(bairroDAO).criar(b);

/ / verifica se valor <true> foi devolvido como resultado

Assert.assertTrue(result);

}

@Test

public void testLoadBairroInfelicidade() throws Exception {

Bairro b = new Bairro();

b.setNome("Infelicidade");

b.setId(new Long(54));

Mockito.when(bairroDAO.load(new Long(54))).thenReturn(b);

Bairro b2 = bairroService.load(new Long(54));

Mockito.verify(bairroDAO).load(new Long(54));

Assert.assertEquals(b.getNome(), b2.getNome());

}

@Test

public void testLoadBairroCristoRedentor() throws Exception {

Bairro b = new Bairro();

b.setNome("cristo redentor");

b.setId(new Long(53));

Mockito.when(bairroDAO.load(new Long(53))).thenReturn(b);

Bairro b2 = bairroService.load(new Long(53));

Mockito.verify(bairroDAO).load(new Long(53));

Assert.assertEquals(b.getNome(), b2.getNome());

}

@Test

public void testLoadBairroCristoRedentorNull() throws Exception{

Bairro b = new Bairro();

b.setNome("cristo redentor");

b.setId(new Long(53));

Mockito.when(bairroDAO.load(new Long(53))).thenReturn(b);

Bairro b2 = bairroService.load(new Long(53));

Mockito.verify(bairroDAO).load(new Long(53));

Assert.assertNull(b2);

}

@Test

public void testAtualizar() throws Exception {

Mockito.when(bairroDAO.atualizar("Deus", new Long(53)))

.thenReturn(true);

boolean result = bairroService.atualizar("Deus", new Long(53));

Mockito.verify(bairroDAO).atualizar("Deus", new Long(53));

Assert.assertTrue(result);

}

@Test

public void testLoadBairroDeus() throws Exception {

Bairro b = new Bairro();

b.setNome("Deus");

b.setId(new Long(53));

Mockito.when(bairroDAO.load(new Long(53))).thenReturn(b);

Bairro b2 = bairroService.load(new Long(53));

Mockito.verify(bairroDAO).load(new Long(53));

Assert.assertEquals(b.getNome(), b2.getNome());

}

@Test

public void testLoadNull() throws Exception {

Bairro b = null;

Mockito.when(bairroDAO.load(new Long(1000))).thenReturn(b);

Bairro b2 = bairroService.load(new Long(1000));

Mockito.verify(bairroDAO).load(new Long(1000));

Assert.assertNull(b);

}

@Test

public void testLoadNotNull() throws Exception {

Bairro b = null;

Mockito.when(bairroDAO.load(new Long(1000))).thenReturn(b);

Bairro b2 = bairroService.load(new Long(1000));

Mockito.verify(bairroDAO).load(new Long(1000));

Assert.assertNotNull(b);

}

}

Resultado no JUnit 4.7:

mockito

Note que testLoadBairroCristoRedentorNull e testLoadNotNull quebraram. E estão marcados em azul.

A versão do mockito é a 1.8.5, baixar no site: http://mockito.org/

build

Usei o mockito com JUnit 4.7.

Fonte:

Mockito: Java Unit Testing with Mock Objects by Jacek Furmankiewicz:

http://www.developer.com/print.php/3882311 

http://mockito.org/

Ta-ta for now

quinta-feira, 10 de fevereiro de 2011

quarta-feira, 2 de fevereiro de 2011

Respeito às Pessoas

respeito

É importantíssimo tratar a todos com respeito, independente de cargo. Todos são iguais: CIO, desenvolvedor, gerente de projeto, recepcionista e secretária.

O que isso significa na prática?

Significa responder rapidamente às pessoas: escutando atentamente, ouvindo as opiniões diferentes ou iguais as suas. Isso significa incentivar as pessoas a falar. Tendo empatia com outros pontos de vista.

Mas, não significa necessariamente que deve sempre concordar com as pessoas. Então, uma das artes de respeitar as pessoas é aprender a ser assertivo e discordar de um ponto de vista. Sem a necessidade de ser agressivo ou ameaçador.

Outra forma importante de respeitar as pessoas é dar a responsabilidade para tomar decisões no trabalho. Isso é possível através do desenvolvimento de pessoas que possam pensar por si mesmas.

Fonte:

“Lean Principle #6 – Respect People” by Kelly Waters:

http://www.allaboutagile.com/lean-principle-6-respect-people/

Ta-ta for now

quinta-feira, 27 de janeiro de 2011

Aplicação dos Seis Chapéus na Retrospectiva

6hats

O pai dos seis chapéus é o medico Edward De Bono. É uma técnica que ajuda a equipe a pensar de forma colaborativa e paralela. E isso é muito útil na reunião de retrospectiva, mas deixo claro que não serve apenas para reunião de retrospectiva.

Cada chapéu tem um foco de pensamento. A idéia que a cada troca de chapéu, os integrantes da equipe trabalhem o foco. Ou seja, vistam o chapéu.

O tempo de uma reunião de retrospectiva com os seis chapéus é de uma hora. Claro que pode ultrapassar, dependendo do que esta sendo trabalhado.

Objetivos dos seis chapéus na retrospectiva:

  • A equipe discute o foco;
  • Evitar discussões inúteis e conflitos;
  • Incentivar a participação das pessoas, principalmente dos tímidos.

Neste artigo vamos trabalhar a seguinte ordem dos seis chapéus: azul, branco, amarelo, preto, verde e vermelho.

Chapéu Azul (5 minutos de duração)

Foca os objetivos.

O chapéu azul também é facilitador e condutor da reunião. Também é aconselhável que papel do facilitador ou condutor seja rotativo para estimular o ambiente democratico na equipe.

Chapéu branco (10 minutos de duração)

Foca análise dos fatos e informações. Sem emoções e julgamentos.

Chapéu amarelo (10 minutos de duração)

Foca os pontos positivos.

Chapéu preto (10 minutos de duração)

Foca as críticas, coisas ruins que aconteceram e riscos. Tudo que precisa ser melhorado.

Chapéu verde (10 minutos de duração)

Foca a criação de alternativas ou respostas para o problema.

Chapéu vermelho (5 minutos de duração)

Foca os sentimentos e emoções, sem julgamentos.

No final, retornasse ao chapéu azul. Que tem papel de condutor da reunião. Esse fará uma conclusão da retrospectiva e, através dela terá instrumentos necessários para melhorar a nova iteração.

Fonte:

“6 Thinking Hats Retrospective Plan” by rob bowley:

http://blog.robbowley.net/2009/08/29/6-thinking-hats-retrospective-plan/

“Podcast #3 – Retrospectiva dos 6 Chapéus” by  Luiz Faias Jr:

http://bluesoft.wordpress.com/2010/01/07/podcast-3-retrospectiva-dos-6-chapeus/

“Six Thinking Hats”:

http://en.wikipedia.org/wiki/Six_Thinking_Hats

Ta-ta for now