Apoio ao Manifesto do Software Artesanal

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

Os Quatros Objetivos do Manifesto Ágil

Os quatros objetivos do manifesto ágil:

1º 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.

2º 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.

3º 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.

4º 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

Algumas semelhanças entre Scrum e Kanban

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

Apoio ao Manifesto da Refatoração

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

O Papel do Analista de Negócios Ágil

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

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

Receita para o Fracasso de um Produto

 

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

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

Gerente 2.0

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