Convencer é melhor do que impor

Em tempos de agile, tem algumas coisas que são um pouco difíceis de algumas pessoas/times adorarem como prática. Por exemplo: como fazer com que desenvolvedores façam testes automatizados, de preferência usando a abordagem TDD? Pode parecer fácil, mas só quem já tentou sabe como é difícil e como existe resistência na quebra do paradigma.

Pra resolver o problema temos basicamente 2 opções: (1) Alguém obriga todos do time a fazer os testes automatizados e ponto final, ou (2) utilizar-se de algum método que os convença que essa prática trás ganhos significativos.

Continue reading

O nosso Sistema Kanban – Uma experiência Lean para equipes de sustentação

A Motivação

Há cerca de um ano, iniciei um desafiador trabalho de coaching em Agile para uma instituição financeira/bancária. De forma que como é uma empresa relativamente grande, têm nos permitido usar ferramentas diferentes para resolver problemas específicos, um exemplo disso é que usamos Scrum para projetos desenvolvimento de software e algumas práticas da FDD(Feature Driven Development) para engenharia e gestão de requisitos.

Um das áreas com qual eu atuo, é uma equipe de sustentação de produtos (suporte) que atende a vários clientes internos diferentes, com demandas (novas funcionalidades e correções) totalmente diferentes e principalmente numa necessidade de ritmo totalmente independentes da outra.

Continue reading

Rails + Agile na DDWorks

Uma das maiores convicções que tenho sobre desenvolvimento de software é que não existem fórmulas mágicas, nem processos mágicos e nem certificações mágicas… O máximo de “mágico” que pode existir em desenvolvimento de software são alguns profissionais mágicos (infelizmente alguns são adeptos de magia negra). Além disso, “Processo Padrão” é uma coisa que não existe.

O projeto da DDWorks começou de maneira interessante. Numa dessas quintas-feiras de verão, um dos sócios me ligou e disse: “- Quero colocar um e-commerce no ar na semana que vêm”. (nem sei se ainda se usa a palavra e-commerce, mas ele disse assim!) As condições são:

1. Nós não temos tempo de negociar, não temos tempo de firmar contrato, não temos tempo nem de “planejar” o projeto

2. Tem que estar no ar e vendendo até sexta-feira da semana que vem

3. Tem que ter integração com e-payment ainda a ser definido (no fim optamos pelo PagSeguro)

4. O desenvolvedor tem que estar aqui presente. Vamos dar todos os subsídios e decisões em tempo hábil

5. Já falei que tem que estar no ar na semana que vem?

Qualquer pessoa poderia falar que isso é impossível, porém, o cliente estava disposto a fazer o que fosse necessário para atingir esse objetivo, e nenhum outro fornecedor deu atenção a esse projeto. Eles acharam isso “impossível”. Eu até imagino aqueles vendedores acompanhados de gerentes de projeto (ambos de gravata) dizendo “- Vamos com calma!”, “- Precisamos planejar direitinho.”, “- Vamos detalhar mais…”. O mercado está cansado dessas ladainhas! Como seria um desafio interessante topei na hora. Traçamos alguns objetivos juntos e marcamos uma reunião de planejamento na segunda-feira às 9:00.

Leia o restante do artigo e comente no blog “Débito Técnico”:
http://blog.aspercom.com.br/2009/03/03/rails_agile_ddworks/

Artigo Projetos Ágeis – Levantamento Inicial

Felipe Rodrigues, Arquiteto com larga experiência em desenvolvimento de aplicações críticas, juntamente com Flávia Oliveira Gestora de Negócio e Editora da InfoQ Brasil, escreveram no blog da Fratech IT, um excelente e breve relato de uma experiência em Gestão Ágil de Requisitos num projeto de desenvolvimento de software da sua companhia (localizada em SP).

O artigo através dos temas Definição do objetivo do projeto, Definição das áreas e operações do sistema e Construção de protótipos de telas, mostra com clareza e maestria, o processo ágil de concepção em alto nível de um produto (usando FBS da FDD com conceitos de áreas e atividades).

Outra dimensão muito interessante que artigo aborda, é o uso da Modelagem com Mapas Mentais (M3), para facilitar o processo de aprendizagem acerca do escopo do produto e também afim fomentar a descoberta iterativa e incremental dos detalhes de implementação do produto.

O link para o artigo é: http://www.fratech.net/comunidade/exibir/46

Boa leitura.