Use A Cabeça Ágil

54 Capítulo 2

vamos ficar motivados

P: Quer dizer que profissionais

desmotivados fazem um péssimo

trabalho de propósito?

R: Não de propósito. É difícil inovar,

criar ou executar as tarefas desgastantes

que caracterizam o trabalho quando a

equipe de software atua em um ambiente

de desmotivação. Por outro lado, é muito

fácil desmotivar uma equipe: a motivação

diminui quando não há confiança no

seu trabalho, quando você recebe uma

punição séria ou constrangedora ao

cometer um erro (embora todos cometam

erros!) e quando são estabelecidos prazos

inadequados sem seu consentimento ou

fora do seu controle. Todos esses casos

já ocorreram repetidas vezes, sempre

reduzindo o ânimo das equipes de

software e diminuindo sua produtividade.

P: Calma aí. Já que falamos em

erros, vamos abordar a receptividade

a mudanças. Uma mudança não é

a alteração feita quando alguém

comete um erro?

R: É perigoso pensar em mudanças

como erros, especialmente quando usamos

a iteração. Muitas vezes, os integrantes

da equipe, usuários e stakeholders

concordam que o software deve ser

criado para executar alguma função. Mas

quando os usuários utilizam o software

em funcionamento ao final da iteração,

percebem que ele precisa de alterações,

pois agora têm informações que não

tinham no início da iteração e não porque

cometeram erros. Esse é realmente um

modo eficaz de criar softwares, mas

só funciona quando os profissionais se

sentem aptos a fazer mudanças, sem que

haja atribuição de erro ou culpa quando

alguém aponta uma alteração.

P: As especificações não

têm outras funções além da

comunicação? Podem servir como

referência no futuro? Podem ser

distribuídas para um público maior?

R: Com certeza. De fato, esses são

bons motivos para elaborar documentos

escritos. É por isso que as

equipes de

desenvolvimento ágil

valorizam

uma documentação abrangente, embora

priorizem o software em funcionamento.

Mas tenha em mente que, quando a

documentação se destina à consulta

ou distribuição a um público maior

do que a equipe de software, uma

especificação pode não ser o documento

mais adequado. A documentação é uma

ferramenta que auxilia na execução de

uma tarefa, e devemos sempre escolher

a ferramenta mais adequada ao trabalho.

Geralmente, as informações necessárias

para que as equipes criem softwares são

diferentes das informações que o usuário

ou gerente precisam para lidar com o

software em funcionamento. Logo, criar

um documento que atenda a esses dois

públicos talvez não seja uma boa ideia.

P: Ei, o capítulo está quase

acabando e você não cobriu os 12

princípios! Por quê?

R: Porque os princípios ágeis não são

um tópico isolado que as equipes devem

memorizar e partir para outra. Eles são

importantes porque ajudam a entender

como as equipes ágeis encaram seu

trabalho em grupo na criação de software.

Esse é objetivo essencial dos valores e

princípios do Manifesto Ágil.

Ainda vamos falar mais sobre a

mentalidade, valores e princípios ágeis,

mas no próximo capítulo abordaremos as

metodologias. Voltaremos a esses pontos

sempre que necessário para explicar os

tópicos (por exemplo, as equipes Scrum

são auto-organizadas e as equipes XP

valorizam a simplicidade, o que ilustra as

várias metodologias ágeis).

 O software tem qualidade quando atende às

demandas dos usuários, clientes e stakeholders.

 Para que o software tenha qualidade, as equipes

devem encaminhar uma versão preliminar aos

usuários e entregar as versões subsequentes de

forma contínua.

 As equipes de desenvolvimento ágil devem

ser receptivas às mudanças nos requisitos.

Definir essas alterações no início do processo pode

evitar a reformulação.

 A melhor forma de descobrir essas mudanças

nos estágios iniciais é entregar o software em

funcionamento para os usuários regularmente.

 Documentos são úteis, mas a forma mais eficiente

de transmitir informações é através de uma

conversa cara a cara.

 Os desenvolvedores que atuam em equipes de

desenvolvimento ágil devem trabalhar com

os colaboradores do setor comercial todos os

dias, bem como com usuários e stakeholders.

 A iteração é uma prática na qual as equipes

dividem o software em entregas frequentes com

tempo predeterminado.

 O backlog é uma prática na qual as equipes

mantêm uma lista dos recursos a serem criados nas

próximas iterações.

Mais sobre esse ponto no próximo capítulo.

As equipes Scrum mantêm dois backlogs: um para

a etapa atual e outro para o produto inteiro.