A equipe de desenvolvimento da qual sou membro se adaptou recentemente para trabalhar de acordo com as práticas ágeis. Isso pessoalmente destacou o fato de que eu não consigo me impedir de codificar (e documentação), e consequentemente excedo as estimativas originais, quando eu poderia ter entregue soluções que atendam aos requisitos muito antes.
Eu acho que minha ética está próxima do obsessivo, pois me apego demais ao meu código e raramente me contento em divulgar antes de refatorá-lo e aperfeiçoá-lo até o enésimo grau. Estou feliz por ter percebido isso, mas como posso mudar minha atitude / mentalidade para me contentar com meu progresso e liberar pontualmente?
agile
programming-practices
productivity
development-process
scrum
Andy Bowskill
fonte
fonte
Respostas:
O melhor é o inimigo do bom o suficiente.
Você sempre pode fazer mais testes, escrever uma documentação melhor, descobrir os casos extremos, preencher o que você acha que faltam recursos, tornar a arquitetura mais limpa. Isso nunca acaba. No entanto, tem que terminar. Há datas de vencimento que precisam ser cumpridas, restrições externas que dependem da conclusão da parte do produto. Buscar a perfeição em uma pequena parte de um produto prejudica o produto como um todo.
fonte
Primeiro, gostaria que mais desenvolvedores tivessem esse problema, não porque o software acabaria sendo lançado mais tarde do que o esperado, mas porque provavelmente seria uma versão de maior qualidade.
Se você estiver excedendo suas próprias estimativas originais, talvez precise incluir as etapas de "revestimento a ouro" como parte de suas estimativas. Se elas não são suas próprias estimativas, talvez você deva se envolver na formulação delas.
De qualquer forma, se você tiver um prazo de liberação, cumpra-o. Qualquer "revestimento de ouro" deve ser deixado como uma etapa final que não deve conter uma liberação. Se você acha que ele deve ser incluído como parte de um release, considere adicionar o "revestimento de ouro" em seu próprio tempo (ou seja, fora do horário de trabalho).
O que você deve fazer é apresentar suas etapas de "ouro" à sua equipe e / ou gerência e discutir por que você acha que elas são importantes. Se você puder convencê-los de que essas etapas são benéficas, elas devem se tornar parte de versões futuras.
fonte
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:
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.
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:
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.
fonte
Você programa por diversão também? Também fiquei aborrecido com as restrições no trabalho que tiram o máximo proveito da programação e, para compensar, às vezes inicio um novo projeto em casa e "faço o certo". A divisão me permite satisfazer tanto: minhas necessidades quanto as da empresa.
Ou então, você pode desenvolver uma nova habilidade que não seja a programação para fazer no seu tempo livre que (eventualmente) satisfaça o que o trabalho não pode oferecer. ;)
fonte