Software banhado a ouro
A primeira vez que vi chapeamento de ouro usado como descrição para software foi em um artigo de Barry Boehm, onde ele deu a seguinte causa raiz:
Folheado a ouro. As especificações de requisitos fixos antes do design tendiam a incentivar o revestimento de ouro do software. Os usuários perguntados sobre seus requisitos frequentemente raciocinam: "Não sei se vou precisar desse recurso ou não, mas é melhor especificar apenas por precaução".
Em sua descrição, ele recomenda usar os métodos descritos em sua pesquisa, incluindo o modelo de ciclo de vida do software em espiral no qual os projetos foram projetados para produzir uma série de protótipos um por ciclo e, à medida que as espirais aumentavam, um produto completo. O Spiral teve ampla influência nos pesquisadores de software e foi uma ponte importante entre o Waterfall e o Agile. Uma limitação crítica da espiral é que, a cada volta da espiral, os ciclos ficam mais longos e mais caros.
Assim como no Agile, a espiral tenta evitar o revestimento de ouro com um escopo mais restrito e agendando a entrega do projeto por tempo suficiente para que as equipes possam concluir os requisitos, ao mesmo tempo em que é curta o suficiente para permitir o foco no objetivo desde o primeiro dia até o dia da entrega. Uma maneira que os métodos Agile como Scrum são superiores é que o Scrum corra por um período de tempo que não fica mais longo com as iterações. Pelo artigo, o gerenciamento de projetos parece ter mais influência no revestimento do que nos desenvolvedores individuais.
Talento para Time Boxe
Ser capaz de cronometrar a caixa é muito importante, mas não é uma habilidade binária. Você não tem ou não tem. Você é melhor ou menos bom com isso. Seja do seu chefe ou de você, eu preferiria que ninguém dissesse que você não pode parar o ouro. Isso parece pessoal, difundido e permanente.
Uma análise de causa raiz pode ajudar a identificar vários problemas. Tenho certeza de que nem todos estarão apontando para você e que, a menos que você trabalhe com psicopatas, outras pessoas em sua equipe terão necessidades semelhantes para melhorar o conjunto de habilidades Agile. Se você conhece alguém sem problemas, não o conhece muito bem. Se você conhece alguém que pensa que não precisa melhorar, ele não se conhece muito bem.
Espero que as melhorias identificadas sejam coisas que você possa resolver com sua própria consciência e com a ajuda da equipe. No entanto, acho que não é aí que isso acaba. Minha expectativa do supervisor ou gerente que escreve seus comentários é que eles também possam treinar seus subordinados para que sejam bem-sucedidos. Isso é particularmente crítico quando a organização está passando por uma mudança revolucionária, como mudar do planejado para o Agile (ou ad-hoc para o Agile).
Protótipo rápido e sujo ou gerenciado por risco?
Eu tinha um gerente que costumava solicitar que as tarefas fossem executadas de certa maneira.
Rápido e sujo, mas uma coisa de beleza.
Ele conhecia a tolice disso, e fazia parte de seu senso de humor irônico. Muitas pessoas dizem coisas assim e estão falando sério. Em algum lugar, existe um compromisso ou uma oportunidade para aliviar o problema com uma tecnologia ou abordagem aprimorada.
O que podemos sacrificar para caber em nossa caixa de tempo?
No capítulo um do Extreme Programming Explained , segunda edição, Kent Beck fala sobre o que é preciso para avançar rapidamente. A resposta dele é que "você faz apenas o que precisa para criar valor para o cliente".
Risco
Na primeira edição do mesmo livro, Beck identifica um pouco mais de perto as visões de Boehm sobre o controle de riscos como críticas à sua metodologia, dizendo:
"Risco é o problema básico do desenvolvimento de software"
Nas duas edições, Beck lista e descreve oito riscos comuns, seguidos de uma afirmação de que o XP (ou talvez por extensão, o Agile) trata cada um de uma maneira específica. Para mim, a maior parte de sua explicação se resume ao uso de incrementos menores e iterações mais rápidas, permitindo que as coisas voltem ao rumo antes que os riscos cresçam demais para lidar.
Mentalidade de Suficiência
Beck discute recursos no contexto de uma história sobre o Povo da Montanha e o Povo da Floresta e introduz um conceito chamado "Mentalidade de Suficiência". No contexto da sua situação, ele pergunta: "Como você faria se tivesse tempo suficiente?" Apenas este primeiro capítulo, disponível como uma prévia do livro, pode fornecer muita reflexão sobre como o XP (e outros métodos Agile) pensa em restrições como o tempo.
A compulsão pode ser o sintoma, não a doença
Anos atrás, vi um livro sobre procrastinação que afirmava que muita procrastinação se origina no medo. Se você não começar, não cometerá um erro e talvez não seja criticado. Compulsão e perfeccionismo dão algo que nosso senso moral diz que é melhor que a procrastinação, mas provavelmente tem o mesmo resultado. Considere que talvez você esteja tendo um problema com a procrastinação de outra forma?
Críticas e Concorrência
Nas metodologias ágeis como Scrum, as oportunidades de serem criticadas ou punidas por procrastinação nunca foram maiores. Esse é um ciclo vicioso. Procrastino porque sou criticado, sou criticado porque procrastino. Nas reuniões diárias do scrum, estamos sempre em alerta, porque estamos sempre um dia ou menos informando à equipe o que realizamos.
Em uma equipe ideal, o Scrum oferece uma oportunidade diária para corrigir a procrastinação. Os erros não devem ter tempo para crescer antes que a ajuda chegue. As equipes nem sempre são onde deveriam confiar; portanto, os líderes da equipe podem precisar abordar proativamente as críticas ou o medo de críticas para permitir que as coisas avancem.
No nosso mundo de trabalho, cada pessoa em uma equipe também deve competir com os outros. É um pouco esquizofrênico acreditar em ter uma equipe que compartilhe o trabalho e a glória por realizações, mas depois use um processo anual de gerenciamento de desempenho que recompensa 20% de seus membros, pune ou expulsa 10% ou mais dos membros, e finge que a maioria de 70% contribui da melhor forma sem incentivos. Eu acho que este é um grande elefante na sala WRT que promove o trabalho em equipe e, para referenciar a história de Kent Beck, mostra profundos laços culturais em ser Pessoas da Montanha.
O caminho a seguir
Como membro de uma equipe Agile, seria bom estudar e dialogar com outras pessoas sobre o que funciona. Se sua equipe estiver usando o TDD para automatizar seus testes de unidade com uma ferramenta, peça à pessoa que faz o melhor para treiná-lo. Se o seu supervisor ou gerente tiver um problema com a sua abordagem de documentação, descubra o que ele gosta ou quem está fazendo do jeito que ele gosta e siga a abordagem deles. Se tudo se resumir à velocidade de codificação bruta, investigue o que é necessário para codificar mais rapidamente.
Os líderes podem dar passos na direção certa, modelando os comportamentos desejados, como conversas sinceras sobre seus próprios problemas (não os de outra pessoa), oferecendo e acompanhando com ajuda, tendo um diálogo sobre como a equipe pode mudar para o estilo Agile Marine (ou seja, nenhum homem deixado para trás). Nem todo mundo na equipe tem as mesmas habilidades. Pode ser apropriado explorar emparelhar membros da equipe ou atribuir tarefas e funções que possam enfatizar pontos fortes complementares das pessoas envolvidas. Planejar o crescimento ou a remediação de habilidades deve ser uma parte gratificante do trabalho, tanto para o supervisor quanto para o subordinado, mas deve acontecer cedo e com frequência para ser eficaz.