quinta-feira, 16 de dezembro de 2010

Apoio ao Manifesto do Software Artesanal

artesanato

O Cantinho do Agile assinou e esta apoiando o manifesto do software artesanal. Podemos dizer que o desenvolvimento de software é um meio termo entre arte e ciências exatas, ou seja, desenvolvimento de software é mais próximo do artesanato.

O aspirante artesão busca elevar o nível de desenvolvimento de software na prática e ajuda a comunidade aprender sobre o desenvolvimento de software artesanal.

Os valores do manifesto do software artesanal são:

“Não só o trabalho de software, mas também software bem trabalhado

Não só responder à mudança, mas também constante agregação de valor

Não somente os indivíduos e interações, mas também uma comunidade de profissionais

Não só a colaboração do cliente, mas também parcerias produtivas”

Na busca dos itens do lado esquerdo, encontramos itens indispensáveis do lado direito.

Software bem trabalhado, agregação de valor, comunidade de profissionais e parcerias produtivas buscam o melhoramento do desenvolvedor de software e do processo de desenvolvimento do produto de software. Conseqüentemente o cliente receberá um produto com mais valor e qualidade.

Sendo assim, o manifesto do software artesanal contribui para cultura ágil de desenvolvimento de software.  E se analisarmos o manifesto de software artesanal, notamos uma continuação do manifesto ágil.

Desenvolvedor, tome uma atitude para ser um desenvolvedor melhor, seja um artesão de software.

Obs.: A autora, representada por Nina Rosa Madeira, assinou o manifesto do software artesanal.

Fonte:

“Manifesto for Software Craftsmanship”:

http://scmanifesto.heroku.com/

Ta-ta for now

quarta-feira, 15 de dezembro de 2010

Os Quatros Objetivos do Manifesto Ágil

goal

Os quatros objetivos do manifesto ágil:

Objetivo: Indivíduos e interação entre eles mais que processos e ferramentas:

  • Cliente e desenvolvedores devem trabalhar juntos diariamente no projeto;
  • Conversa face a face é método mais eficaz para transmitir informações para dentro da equipe;
  • Todos envolvidos (equipe e cliente) devem manter um ritmo sustentável;
  • As melhores arquiteturas, requisitos e projetos nascem de equipes auto-organizáveis.

Objetivo: Software funcionando mais importante que documentação abrangente:

  • Maior prioridade é satisfazer o cliente com entrega antecipada e contínua de software com valor;
  • Entregar software funcionando freqüentemente em poucas semanas;
  • Software de trabalho é a medida primária de progresso;
  • Atenção contínua a excelência técnica e bom design melhoram o software;
  • Soluções simples.

Objetivo: Colaboração com o cliente mais que negociação de contratos:

  • O cliente é um membro da equipe;
  • Cliente e desenvolvedores devem trabalhar juntos diariamente ao longo do projeto.

Objetivo: Responder a mudanças mais que seguir um plano:

  • A cultura ágil se adapta a mudança;
  • Em intervalos regulares a equipe reflete sobre como se tornar mais eficaz, fazendo os ajustes necessários.

O que significa os princípios do manifesto ágil no processo de desenvolvimento?

  • Indivíduos e interação entre eles mais que processos e ferramentas: a equipe de desenvolvimento tem o controle do processo de desenvolvimento, plataformas e metodologia;
  • Software funcionando mais importante que documentação abrangente: Dar ao cliente o acesso permanente ao sistema, que é atualizado com freqüência;
  • Colaboração do cliente mais que negociação de contrato: Coloque o cliente na sua equipe. As histórias dos clientes, interações curtas com cliente e verifique se a aplicação está sempre acessível ao cliente;
  • Responder a mudanças mais que seguir um plano: Abrace a causa da mudança durante o processo de desenvolvimento de software. Ela irá ocorrer estando preparando ou não.

E como começar?

A integração contínua tem rápido ROI:

  • Inicie com controle de versão;
  • Automatização do deploy;
  • Testes automatizados.

Investir em pessoas dá maior retorno de investimento (ROI):

  • Livros;
  • Conferências;
  • Treinamentos;
  • Ambiente de trabalho bom e ritmo sustentável de trabalho.

Fonte:

http://www.manifestoagil.com.br/principios.html

e

http://www.evenamonkey.com/AgileIntroduction

Ta-ta for now

sábado, 11 de dezembro de 2010

Algumas semelhanças entre Scrum e Kanban

gemeos

Baseado no artigo “What is Best, Scrum or Kanban?” de Tomas Björkholm, relatarei algumas semelhanças entre Scrum e Kanban:

  • Priorização (opcional para Kanban);
  • Auto-organização da equipe: É quando a equipe sabe como resolver os problemas, remover obstáculos e otimizar seu processo;
  • Transparência: É mostrar o que você fez, estado atual e que fará na próxima etapa;
  • Inspecão e adaptação: É melhorar o seu produto e processo baseado em fatos;
  • Puxar o trabalho;
  • Boa comunicação e colaboração.

Fonte:

“What is Best, Scrum or Kanban?” by Tomas Björkholm:

http://www.agilejournal.com/articles/columns/column-articles/1737-what-is-best-scrum-or-kanban

Livro Kanban and Scrum - making the most of both  by Henrik Kniberg and Mattias Skarin:

http://www.crisp.se/henrik.kniberg/Kanban-vs-Scrum.pdf

Ta-ta for now

sexta-feira, 10 de dezembro de 2010

Apoio ao Manifesto da Refatoração

refactor

Pessoal, peço o apoio para o manifesto da refatoração. Pela causa de um código melhor e longa vida ao seu produto:

http://www.refactoringmanifesto.org/

Fonte:

http://www.refactoringmanifesto.org/

Ta-ta for now

segunda-feira, 6 de dezembro de 2010

O Papel do Analista de Negócios Ágil

ba

O papel do analista de negócios é facilitar a comunicação sobre o produto de software entre o cliente e a equipe. Tipicamente, o analista de negócios tem um grande conhecimento do produto de software em discussão e poderá extrair as funcionalidades exigidas pelo cliente. Sendo assim, a principal função do analista de negócios é facilitar a comunicação e a compreensão.

O analista de negócios ajudará também a traduzir as necessidades do cliente em uma linguagem mais técnica para os desenvolvedores.

A cultura ágil encoraja o analista de negócios a fazer a dissociação da amplitude da solução a partir da profundidade da solução, ou seja, usando metodologia ágil o analista escreverá requisitos dirigidos por iteração.  Isso significa que o cliente receberá valor a cada iteração (2 ou 3 semanas) e não precisará esperar meses ou anos para receber o produto de software finalizado, as vezes com vários problemas.

“The Agile Business Analyst” by Mike Cottmeyer, V. Lee Henson

http://www.infoq.com/articles/agile-business-analyst-role

Ta-ta for now

O Analista de Negócios e a Equipe Ágil

team

O analista de negócios é um membro da equipe ágil. Sendo que analista de negócios geralmente é convidado para facilitar a comunicação sobre o produto de software entre equipe e cliente. Suas principais funções são facilitação da comunicação e compreensão.

Outra função importante do analista de negócios é envolver a equipe na criação das especificações, ajudando a criar um ambiente de alta confiança e colaboração. O analista de negócios poderá ajudar a equipe: 

  • A focar nos objetivos da interação;
  • No entendimento dos requisitos em um baixo nível de detalhamento.

No caso do cliente desempenhar o papel de analista de negócios é necessário apoio de outro analista de negócios. Porque na realidade sabemos que um cliente não terá 100% do seu tempo disponível para a equipe e necessitará de um apoio na especificação das funcionalidades.

Caso o cliente não possa a participar do desenvolvimento do produto de software, o analista de negócios assume o papel de cliente proxy. Neste papel, o analista é convidado a entender as necessidades do cliente e a traduzir essas necessidades à equipe. Este modelo apresenta risco, porque o cliente não está diretamente envolvido com toda equipe. O analista de negócios poderá diminuir esse risco, através do incentivo ao cliente a participar do desenvolvimento do produto de software.

“The Agile Business Analyst” by Mike Cottmeyer, V. Lee Henson

http://www.infoq.com/articles/agile-business-analyst-role

Ta-ta for now

domingo, 5 de dezembro de 2010

Receita para o Fracasso de um Produto

pao mofado 

A lista a seguir são erros comuns na aplicação do Scrum. Todos eles influenciam negativamente no sucesso do produto:

  • Espalhar o papel do PO para várias pessoas;
  • Construir um produto que agrade a todos e tenha uma infinidade de recursos, ou seja, um produto comercializável ao máximo;
  • Dizer sim a todas as necessidades. Você não quer decepcionar os interessados e colocar em risco o sucesso do produto;
  • Capturar e detalhar todos os requisitos do backlog antes da primeira interação. Isso diminui os riscos e proporciona um planejamento eficiente;
  • Não se incomode com a priorização;
  • Não se preocupe com o feedback do cliente sobre o produto. Afinal, você sabe o que é melhor para seu cliente;
  • Domine o mercado na calada da noite e surpreenda os concorrentes e os clientes;
  • Quando surgir alguma necessidade, adicione mais recursos e corte qualidade. Os clientes adoram produtos complexos. Não se preocupe com débito técnico. Visualize como uma oportunidade para criar um novo produto para futuro;
  • O Scrum Master deve atuar como um gerente de projeto rígido, que faça a equipe trabalhar num ritmo duro. Ritmo sustentável é para os fracos.

Não siga a lista de erros acima, pois as conseqüências serão:

  • A criação de produtos inúteis para seus clientes;
  • E a falência do seu negócio.

Fonte:

Artigo “How to Create Products that Customers Hate” by Roman Pichler:

http://www.romanpichler.com/blog/agile-product-management/how-to-create-products-that-customers-hate/

Ta-ta for now

sexta-feira, 3 de dezembro de 2010

O Guia do gestor para adoção da metodologia ágil by Mike Cottmeyer

Mostra como as equipes trabalham juntas para entregarem os projetos mais complexos e portfólios. Mike vai expandir o conceito de equipe para incluir capacidades e mostrar como os recursos podem ser organizados para melhorar toda a cadeia de valor da empresa. Em cada etapa do processo de adoção, Mike irá mostrar como escolher as políticas, práticas e métricas que criam aprendizado e conduzem a mudança organizacional sustentável:

http://www.vimeo.com/10582725

Fonte:

“The Manager's Guide to Agile Adoption” by  Mike Cottmeyer:

http://www.vimeo.com/10582725

Ta-ta for now

quinta-feira, 2 de dezembro de 2010

Gerente 2.0

bernadinho

1) Estratégia: O Gerente 2.0 terá como alvo os valores e processos, como no Lean. Assim, o gerente focará em:

  • Eliminar o desperdício;
  • Estimular a qualidade em processos e sistemas;
  • Criar uma cultura de respeito para todas as pessoas;
  • Valor do cliente;
  • Melhorar o todo.

2) Liderança: O gerente poderá assumir a responsabilidade de organizar as pessoas, os recursos(financeiros), as entrevistas, os comentários e as avaliações. Também poderá realizar as tarefas de Coach ou Scrum Master, mas terá dificuldade de manter a confiança. No caso do Coach é melhor um profissional de fora da empresa, que possa analisar organização de forma neutra. Já o Scrum Master é aconselhável alguém da equipe, que conheça a equipe.

3) Operacional: As tarefas operacionais do Gerente 2.0 não diferem dos outros gerentes. No entanto, a comunicação tem valor importantíssimo para Gerente 2.0. Sendo assim, a escolha de uma ferramenta adequada é importante.

Em geral, o Gerente 2.0 será responsável pela criação de valores que estimulem as pessoas. Ele também será responsável pela aplicação da cultura ágil, ajudando a equipe na identificação das práticas adequadas.

Apesar da equipe ágil ser auto-organizável, não exclui o gerenciamento.

Fonte:

“Manager 2.0 - part 2” by AgileCollab:

http://www.agilecollab.com/manager-20-part-2

Ta-ta for now