Agile

Documentação Leve

Documente o mínimo possível.

O propósito de você documentar é comunicar o que você fez (ou o que precisa ser feito) para alguém distante temporal ou fisicamente.

Documentação é uma das formas de se levar ao Entendimento, mas o foco deve ser o Entendimento.

Documentação é apenas um meio e, em boa parte dos casos, não é o mais eficiente.

O que importa é o Entendimento, não o documento.

É importante evitar o padrão recorrente de só se comunicar por documentos. O analista manda um .doc para o cliente que aprova (sem ler). O desenvolvedor recebe o documento e, apesar de ver erros, fica calado e faz o que está escrito. Isso é péssimo e deve ser evitado.

Comunicando a parte técnica

No caso de gente nova na equipe, crie um workshop mostrando a motivação do sistema e percorrendo as telas, se for o caso. Isso dá o contexto geral.

Também é importante mostrar a arquitetura do sistema, uma visão de alto nível.

Ler código não é a melhor forma de comunicar a arquitetura.

Usar UML, nesse caso, é uma boa. Você pode se basear no modelo 4+1 de visão arquitetural, mas usar de maneira mais leve:

  • Modelo de domínio – com as entidades importantes em termos de negócio e os relacionamentos entre elas
  • Diagrama de componentes – mostrando os principais pacotes em que o sistema está organizado
  • Diagrama de implantação – mostrando como é implantado fisicamente o sistema quando em produção

Mas é importante que estes documentos estejam atualizados. Se não estiverem, utilize a oportunidade para atualizá-los.

Comunicando com o cliente

Para novos clientes, fazer um workshop e demonstrar o sistema e casos de sucesso parece algo bem profissional e, de certa forma, um marketing ativo.

É interessante ter manuais do usuário com telas e informações relevantes, além de um FAQ. Talvez, a melhor forma de publicar essa documentação é em um site ou wiki.

É importante focar nas funcionalidades mais complexas. Não há a necessidade de colocar funcionalidades básicas nos manuais.

Dica: se o seu software precisar de muitos manuais e FAQs, pode ser que ele precise de um investimento em usabilidade.

Também pode ser interessante fazer vídeos que demonstram como utilizar as funcionalidades mais avançadas.

Para ler
Alguns pensamentos sobre “documentação ágil”, do Guilherme Chapiewski

Anúncios
Agile

Agilidade != Velocidade

Ser ágil é ter facilidade de mudar de direção.

 

Do excelente texto de Juan Bernabó:

Ser ágil não se trata de velocidade, se trata sobre ser enxuto. Ou seja imagina algo que tem muita massa, pode ganhar extrema velocidade e ser muito rápido, porem terá muita inercia e terá dificuldade de mudar de direção.

Para poder ser ágil e flexível será necessário abaixar a massa, e isto a gente faz em Scrum usando o conceito de One Piece Flow (criar um fluxo de produção de uma única peça) por exemplo se faz fluir um único requisito funcional desde o detalhamento ate o teste funcional no menor tempo possível, fazendo que toda a equipe se concentre na menor quantidade possível para abaixar o estoque de trabalho em progresso (um conceito de Lean – Toyota – Just in Time) para poder responder a mudanças sem stresse.

Daqui.

Agile

Porque XP?

No painel Agilidade no dia a dia, disponível na InfoQ BR, um dos participantes brinca:

Não entendo porque programadores sugerem XP para seus chefes. A vida deles fica mais difícil.

Foi apenas uma provocação mas é realmente surpreendente que os próprios programadores, que ficarão mais expostos com a quebra dos silos, reuniões diárias e feedback constante, em geral são os mais motivados para a adoção de um método com o XP.

Mas a resposta é simples: profissionalismo, craftsmanship, diversão, propósito no trabalho, melhoria contínua e segurança no produto do seu trabalho (TDD); tudo isso contribui para o sucesso de XP com os (bons) programadores.

Eu lembro de quando, no início da carreira, passei por uma implantação de MPS BR, do nível mais básico. Cheguei a perguntar para o colega responsável pela implantação do processo “Onde isso vai afetar o código?”. Estávamos passando do Caos para o Monumental, e não era difícil ver o quão chato e engessado iria ser trabalhar daquele jeito. E não parece resolver os problemas que eu, mero programador, enfrentava no dia-a-dia. Quando descobri sobre XP, vi que era exatamente o que eu esperava. E veio a luz!

Agile

Sobre APF e Ágil

APF e Planejamento Ágil podem trabalhar juntos no planejamento de projetos de escopo fechado.
___________

Onde trabalho rolou uma discussão sobre se há atrito entre Análise de Pontos de Função (APF) e Planejamento Ágil.

Nossa conclusão foi que para projetos de escopo fechado, pode ser interessante usar as duas técnicas.

APF

Segundo o pessoal que manja de APF, o intuito dessa técnica é estimativa de esforço. Não de tempo, como muitos acabam usando no mercado brasileiro. A idéia é descobrir quais requisitos são os mais difíceis e qual a dificuldade do projeto como um todo.

E é uma estimativa: deve ser entendido em termos estatísticos, com um coeficiente de erro para mais e para menos.

Com essa estimativa na mão e com o histórico de pontos de função da equipe, é possível ter uma idéia de quando as funcionalidades serão entregues.

Planejamento Ágil

Fast-foward para o ano 2000.

No Scrum e no XP, planejamos de maneira um pouco diferente. O nosso cliente fica responsável por manter uma lista de coisas que ele gostaria de ter no sistema que está sendo construído. A equipe fica responsável por estimar o esforço de cada uma dessas coisas. As estimativas são feitas em grupo e é mais natural considerar que elas possam estar erradas.

No começo de cada interação, é negociado o que é possível de ser entregue. É levada em conta a velocidade[1] da equipe, uma medida de quanto esforço está sendo entregue pelo grupo, que é atualizada a cada iteração. E tudo é validado por todos os envolvidos.

Há algo muito positivo nas práticas de planejamento ágil: o trabalho em equipe. Trabalhar colaborativamente com um grupo de pessoas melhora as estimativas, melhora as soluções, faz com que problemas apareçam mais rápido, aumenta o entendimento de todos. E afeta positivamente algo intangível: a motivação. Trabalhar junto com outras pessoas para construir algo maior que a soma das partes é extremamente motivador. E é bom para os negócios.

Estratégico/Tático

Já trabalhei desenvolvendo softwares para ferrovias e havia uma forte distinção entre os engenheiros ferroviários dos níveis de planejamento estratégico, tático e operacional. O planejamento estratégico trata de uma visão de longo prazo. Já o planejamento tático, trata do médio prazo, levando em conta como levar adiante a estratégia definida. No nível operacional, as coisas acontecem em um período curto e as decisões tem que ser rápidas.

Para fazer um algoritmo de otimização do despacho de trens, que é um problema de planejamento, é preciso separar as soluções nesses três níveis. Há uma relação de troca entre rapidez de resposta e proximidade da solução ótima. Para o nível operacional, a resposta tem que ser rápida, o que compromete a qualidade da solução.

APF serve para um planejamento mais estratégico do projeto de software. As técnicas de Planejamento Ágil tratam do planejamento tático.

APF trabalha com um nível de abstração mais alto. Ao contrário dos algoritmos de otimização, quanto mais distante do operacional maior o erro nas estimativas geradas.

O Planejamento Ágil gera estimativas melhores mas é mais custoso: são várias pessoas envolvidas em uma tarefa supostamente não produtiva (na verdade, a arquitetura/design do sistema já começa a ser definido na reunião de planejamento da iteração).

Se houver a necessidade de comunicar com os sponsors do projeto (a galera do dinheiro) sobre se o projeto é viável ou não ou até sobre quando é provável que ele esteja finalizado, utilizar APF pode ser uma boa idéia. Agora, para forçar uma estimativa descontextualizada na equipe, como é comumente usado, não.

Quando o escopo é aberto

É preciso levar em conta que os métodos ágeis recomendam que o escopo do projeto não seja definido desde o começo. Isso muda o modelo mental do cliente, que passa a participar da evolução do sistema, se envolvendo com cada incremento depois de cada iteração e fornecendo feedback para a equipe de desenvolvimento.

Em contratos de escopo aberto, as práticas de Planejamento Ágil bastam. Talvez seja interessante usar APF logo no começo do projeto pra ver se é possível entregá-lo quando o cliente precisa (ou seja, análise de viabilidade).

Mas contratos desse tipo, de escopo aberto, são raros no mercado brasileiro porque é preciso uma relação muito forte de confiança entre o cliente e o fornecedor. Christiano Milfont, relatou no XP CE que já teve problemas com “colaboração em vez de negociação de contratos” ao prestar serviços para empresas brasileiras.

Quando o escopo é fechado

No caso de contratos de escopo fechado, o cenário é diferente. As funcionalidades e o prazo de entrega são definidos logo no início do projeto. É a maneira tradicional de trabalhar, que perde em colaboração entre quem paga e quem faz.

Nesse caso, APF é uma boa ferramenta para informar com o cliente qual é o custo do projeto, em quanto tempo será entregue e fazer uma possível negociação (antecipada) de escopo. Não é a situação ideal, mas é a mais comum no mercado brasileiro.

Fechado escopo, custo e prazo (a visão estratégica), é possível utilizar práticas de planejamento ágil para entregar iterativa e incrementalmente o software para o cliente. Aí, é definir a tática: valem as técnicas de planejamento em equipe, planning poker, etc… Além disso, é interessante usar as reuniões diárias e os incrementos produzidos para detectar se o projeto está correndo bem. Se surgir algum imprevisto, podemos comunicar ao cliente mais de maneira mais rápida.

Ao usar APF, é importante ter em mente da frase de Einsenhower, comandante dos Aliados na Segunda Guerra, que sempre é lembrada ao falar em Planejamento Ágil:

Planos não são nada, planejar é tudo

___________
1 No livro Planning Extreme Programming, os autores Martin Fowler e Kent Beck mencionam a conceito de Yesterday’s Weather ou “O Clima de Ontem”, que tem esse nome por ser baseado numa técnica de previsão de tempo. A idéia é usar o histórico da semana anterior para planejar a semana atual. Isso faz com que qualquer perda ou ganho de produtividade seja refletida na semana anterior.
___________

Outra quote que eu gosto, que ouvi numa palestra de Alistair Cockburn:

Se há discordância entre o mapa e o terreno, confie no terreno

___________
Pelo que entendi, em Kanban não há escopo e nem planejamento. Tudo é baseado na confiança e o trabalho flui. Mas deve ser uma idéia equivocada da minha parte. Preciso estudar Kanban. A palestra de Kanban do Rodrigo Yoshima no Agile Vale é muito boa. Vale a pena dar uma olhada.
___________
Agradeço ao meu amigo Sherllon pelas idéias.