Acabei de começar um trabalho no Scrum e algo parece estar faltando. Eu sou novo no Scrum

O código é uma bagunça completa de uma combinação do clássico ASP / ASP.NET. O scrum consiste em consertar a grande bagunça ou fazer acréscimos a ela. Estamos muito ocupados fazendo isso para iniciar uma reescrita, então estou me perguntando ..

Onde está a parte do Scrum em que os desenvolvedores podem dizer que basta e exigir que eles tenham tempo para iniciar a grande reescrita? Parecemos um loop infinito de apenas remendar códigos antigos com 'Stories'.

Então, as coisas estão sendo executadas por pessoas não técnicas que parecem não ter vontade de reescrever porque não entendem o quão ruim a base de código ficou ..

Então, quem está encarregado de fazer essa grande mudança de reescrita acontecer? Os desenvolvedores? O Scrum Master?

A estratégia atual é apenas encontrar tempo e fazê-lo sem os superiores envolvidos, uma vez que eles são os principais responsáveis ​​pela bagunça atual em que estamos <-inseridos ->.

Não sei por que isso é tão difícil para as pessoas. Seu caso de negócios está bem aqui:

We seem in an endless loop of just patching old code with 'Stories'.

Tempo do desenvolvedor é dinheiro. Muito dinheiro. Saí de uma empresa que planejava renovar a interface do usuário há mais de um ano e esperava que a adoção do scrum os ajudasse a parar de girar. O que aconteceu? Mesmo ol 'mesmo ol'. Eles continuaram aplicando novos recursos e a "dívida técnica" não tinha nenhum caso comercial, embora metade do código que escrevemos se tornasse sem sentido a cada iteração, devido à base de código subjacente ser uma bagunça completamente desatualizada. Nada mudou no front-end desde que saí, e fui criado com o objetivo de reformulá-lo completamente. Nos dois meses em que estive lá, não toquei em CSS ou JavaScript. Eu estava apenas mexendo com HTML e algum sistema antigo de templates Java do final dos anos 90.

Minha resposta? Faça o que puder, mas se os outros desenvolvedores já desistiram e estão trabalhando até tarde para cumprir as metas do sprint em vez de cumprir prazos mais práticos e insistir que a dívida de tecnologia é de fato um problema de bloqueio, assuma o pior e comece a procurar um novo emprego agora. Seus desenvolvedores são incapazes ou não têm permissão para comunicar suas preocupações ou os negócios também são míopes para entender quanto dinheiro estão gastando.

Ignorar esses problemas SEMPRE custa mais a longo prazo. E não um pouco mais, mas muito mais. Não é apenas uma ferida no peito no que diz respeito ao tempo de desenvolvimento, mas também inevitavelmente reduzirá seus níveis de talento, pois os desenvolvedores que conhecem melhor e têm outras opções evitarão sua empresa como a praga. Meu chefe atual é desenvolvedor e proprietário da empresa. Há coisas que não vamos reescrever em favor de focar em outras prioridades, mas quando algo realmente precisa de um refator devido a ser um timeink consistente, ele recebe um refator adequado. E os resultados são óbvios. Modificar e adicionar novos itens se torna mais fácil e rápido por vários fatores. O que antes levou horas pode levar minutos com a arquitetura adequada. Os negócios não gostam de ouvir, mas vale a pena adiar as coisas para isso.

O Scrum é uma falha em ambientes em que os desenvolvedores não têm muita influência, IMO, porque é muito fácil para os tipos de negócios querer ignorar a manutenção e as atualizações em favor de pontos de referência que podem colocar em suas listas de "iniciativas bem-sucedidas" quando chega o tempo da avaliação. Eles sempre irão favorecer suas peles e potencial de promoção em favor de longo prazo, mesmo quando isso sempre os morde na bunda, para ignorar esses problemas também.

Scrum também é uma indústria motivada pelo lucro e mais ainda. As empresas pagam muito dinheiro pelo treinamento em scrum. As pessoas que desejam adotar devem olhar atentamente para quem está sendo comercializado e o quão realista será na sua cultura.

Independentemente disso, se você realmente se importa com o desenvolvimento, uma base de código ruim, gerenciamento com cera nos ouvidos e desenvolvedores sem espinhos é uma receita para a miséria e um ambiente que fará muito pouco para aprimorar suas habilidades em qualquer aspecto útil. Não hesite em começar a tomar medidas no GTFO antes de descobrir se seus esforços para solucionar o problema estão realmente valendo a pena.

Se você realmente executasse o Scrum, o que duvido, o Dono do Produto seria responsável por decidir sobre uma reescrita. Na maioria das vezes, uma reescrita não é uma boa idéia, porque ela não produz novas funcionalidades, apenas introduz novos bugs.

http://blog.objectmentor.com/articles/2009/01/09/the-big-redesign-in-the-sky
http://www.joelonsoftware.com/articles/fog0000000069.html

Expandir "reescrever não é uma boa ideia":

É quase sempre melhor tentar uma melhoria gradual. Como Jarrod Robertson escreveu em um comentário, encontre um módulo que precisa ser aprimorado e torne-se o especialista para esse módulo e escreva uma história para o próximo sprint para melhorar esse módulo em particular. Explique ao proprietário do produto por que esse módulo precisa funcionar.

Eu vou ser muito franco ...

• Você está encarregado dos desenvolvedores neste trabalho?
• Você é o líder do projeto?
• Quanta "aposta" os desenvolvedores mantêm no projeto?
• Qual é a justificativa da sua empresa para uma reescrita?
• O que há na base de código que a torna totalmente inútil e irrecuperável?

Você declarou que acabou de começar um trabalho e, no entanto, já parece ser o mestre da situação lá. Talvez eu tenha entendido mal a intenção da sua pergunta, mas tenho a impressão de que você entrou em um trabalho em que vê vários problemas e chegou à conclusão mais fácil em que o código é quebrado e o único caminho a seguir é. reescrever, mas você realmente considerou o custo para o seu empregador?

Com qualquer base de código existente - não importa o quão ruim é o estado -, o proprietário geralmente terá um investimento considerável nos produtos que o código representa. Existem custos diretos e indiretos associados à base de código, e uma reescrita geralmente é a última coisa que você deseja fazer como desenvolvedor de software, pois corre o risco de desvalorizar seus ativos de código e, assim, obter um retorno menor em todos os seus esforços.

Tome o sistema operacional do Windows como exemplo. Com cada nova versão criada, houve um grande pedaço de código transmitido da versão anterior. Às vezes, bibliotecas e APIs inteiras são arrastadas para a frente por várias gerações de SO. Por quê? Porque os desenvolvedores sabem que esses elementos funcionam, foram testados, foram corrigidos e corrigidos para evitar problemas de segurança e memória, e porque eles custaram muito dinheiro para entrar nesse estado. Ninguém quer jogar fora o código em funcionamento quando está ganhando dinheiro, mesmo que os custos de manutenção sejam relativamente altos, o custo para começar do zero sempre será mais alto ainda e, em uma empresa como o caso da Microsoft, eles têm bilhões no banco, permitir que eles comecem desde o início, se quiserem, mas não porque eles querem maximizar o retorno do investimento. Seu empregador não é diferente da Microsoft, exceto por ter bilhões em dinheiro para lançar em um projeto.

Portanto, o código está uma bagunça e parece que há problemas de comunicação e limites entre as várias áreas da empresa. O que você ou seus colegas podem fazer sobre isso?

Uma opção é simplesmente continuar como a equipe tem sido, e esperar um milagre no futuro. Provavelmente não é uma boa ideia e provavelmente só aumentará sua frustração e estresse.

Uma opção melhor é simplesmente simplificar e executar suas tarefas, mas como parte disso, procure oportunidades para adicionar testes para dar suporte às áreas de código que parecem ser as mais frágeis e depois refatorá-las até que se tornem mais estáveis. Você terá mais facilidade em argumentar convincentemente para melhorar o investimento da empresa em vez de argumentar para simplesmente jogar tudo fora.

Uma opção ainda melhor é organizar-se como uma equipe e garantir que alguém esteja do lado com antiguidade suficiente para que eles possam ser um bom argumento para permitir à equipe mais flexibilidade para agendar um horário para melhorar a base de código. Não me importo com o quão ocupada é uma empresa, ou com a rigidez do cronograma, sempre há algumas "interrupções" ocasionais nas atividades que podem ser usadas para pressionar uma melhoria ou duas. É ainda melhor, no entanto, se as melhorias puderem ser feitas durante a conclusão de outras tarefas. Se fosse eu, estaria informando um gerente e apresentando-os a conceitos em alguns dos livros canônicos que os desenvolvedores de software lêem. Código Limpoé provavelmente o que sua equipe mais precisa. Plante algumas sementes sobre como melhorar o código e forneça alguns exemplos do que você quer dizer. Um bom gerente verá o valor de adicionar melhorias incrementais ao código, especialmente se você conseguir descrever o conceito de Dívida técnica . Ajude seu líder ou gerente de equipe a fazer um bom argumento comercial para melhorar o código, e eles terão uma motivação melhor para agir de acordo com ele.

Também não basta dizer "o código está desarrumado". Você precisa incentivar seus colegas a praticar a codificação limpa o tempo todo e a usar a técnica de codificação limpa para incentivar um pouco de organização. Tenho um pequeno pôster que imprimo e penduro da parede do escritório toda vez que assumo um novo emprego. Ele diz "Sempre se esforce para deixar o código um pouco mais bonito do que você o encontrou". Bem ao lado, adiciono outro que diz "Os lírios não precisam ser dourados". Ambos servem para me lembrar que eu deveria sempre tentar melhorar o que encontro, mas evitar simplesmente colocar um problema em outro. Reescrições maciças são geralmente o pior tipo de "revestimento de ouro", porque geralmente são feitas pelas razões erradas. Certamente, uma versão totalmente nova do produto pode ser justificável em algum momento,

Aqui está a definição oficial da equipe de desenvolvimento do Scrum no Guia oficial do Scrum . Coloco ênfase nas partes que lhe dizem respeito diretamente:

A equipe de desenvolvimento é composta por profissionais que realizam o trabalho de fornecer um incremento potencialmente liberável do produto "Concluído" no final de cada Sprint. Somente membros da equipe de desenvolvimento criam o incremento. As equipes de desenvolvimento são estruturadas e capacitadas pela organização para organizar e gerenciar seu próprio trabalho . A sinergia resultante otimiza a eficiência e a eficácia gerais da equipe de desenvolvimento. As equipes de desenvolvimento têm as seguintes características:

• Eles são auto-organizados. Ninguém (nem mesmo o Scrum Master) diz à equipe de desenvolvimento como transformar o Backlog do produto em incrementos de funcionalidade potencialmente liberável;

• As equipes de desenvolvimento são multifuncionais, com todas as habilidades necessárias como equipe para criar um incremento de produto;

• O Scrum não reconhece títulos para os membros da equipe de desenvolvimento além do desenvolvedor, independentemente do trabalho que está sendo realizado pela pessoa; não há exceções a esta regra;

• Os membros da equipe de desenvolvimento individual podem ter habilidades e áreas de foco especializadas, mas a responsabilidade pertence à equipe de desenvolvimento como um todo; e,

• As equipes de desenvolvimento não contêm sub-equipes dedicadas a domínios específicos, como teste ou análise de negócios.

A equipe de desenvolvimento é, portanto, responsável por sua própria bagunça e deve resolver a questão sozinha, sem precisar perguntar a ninguém de fora da equipe.

Inclua um tempo de fixação da dívida técnica em cada estimativa futura e garanta que a qualidade do software que você entrega seja de primeira qualidade.

Se você realmente precisar fazer uma reescrita completa, deverá resolver o problema na Restritiva de Scrum. O Dono do produto pode eventualmente cancelar o projeto e iniciar um novo. O Dono do Produto também é o único capaz de cancelar um sprint.

Enquanto você descreve isso, devo dizer que não vejo nada que tenha a ver com o SCRUM, ou que sua equipe de desenvolvimento de produtos está sendo um problema atualmente .

Isto é normal

O que você descreve é ​​a entropia normal de uma base de código. No seu caso, a equipe provavelmente começou mais longe do ideal, mas ainda assim toda base de código acaba se tornando um Big Ball of Mud .

Em um cenário greenfield completamente perfeito , tudo o que você pode fazer é começar mais longe da entropia absoluta e avançar mais lentamente.

Concordo com os outros, a bagunça da base de código é por causa dos desenvolvedores. Estou certo de que antecede a adoção do SCRUM por muitos anos.

Esta não é uma decisão técnica ou de desenvolvedor para reescrever, é uma decisão comercial.

Você não conhece o motivo pelo qual os proprietários do produto não desejam reescrever. Você, como desenvolvedor, pensa que é necessário, mas há realmente algum caso comercial para isso?

Se houver um caso de negócios real , não apenas uma mão acenando; "o código é uma bagunça legada, eu quero começar o greenfield porque é isso que eu quero" , então a gerência entraria na despesa de uma reescrita, considerando o retorno do investimento.

Você não apresentou um argumento comercial sólido para uma reescrita, apenas um discurso retórico sobre sua opinião sobre como todos os outros causaram essa bagunça e você não quer lidar com isso.

Prova - o lucro leva as decisões de negócios a jogar fora o software em funcionamento, e não o TOC precisa de uma base de código limpa

Se você realmente pode mostrar provas , não apenas a teoria, mas a prova concreta de que gastar Xdólares em uma reescrita greenfield garantirá X * N dólares para os negócios no Yperíodo de tempo (onde Né alto e Ycurto), você pode obter alguma tração da gerência . Este é um caso altamente improvável que você pode apresentar e provar.

Caso contrário, você só precisa lidar com isso, isso é realidade. Ao contrário de suas afirmações inflexíveis de que não há absolutamente nenhum caminho a seguir sem essa imensa reescrita imaculada, eu apostaria que em cinco anos ou mais a partir de agora a base de código da qual você está reclamando ainda estará funcionando e funcionando em algum lugar, fornecendo funcionalidade e valor a alguém por muito tempo depois você deixou a empresa.

Eu geralmente sou cético quando as pessoas pressionam por "grandes reescritas". Há alguns casos em que definitivamente faz sentido, mas na maioria das vezes, esse código legado tem valor (já está em produção e sendo usado para os fins que inspiraram sua criação). Realizar uma grande reescrita é, em muitos casos, o oposto de ágil. Quanto tempo levaria para levar a nova versão do aplicativo a um ponto em que ele pudesse substituir o aplicativo existente.

A abordagem que eu prefiro é o que Martin Fowler chama de videira estranguladora . Implemente uma nova funcionalidade (incluindo alterações na funcionalidade existente) usando a nova abordagem, mas use o aplicativo existente como uma grade em que a nova funcionalidade possa crescer. Isso oferece o melhor dos dois mundos, você não precisa parar tudo enquanto a grande reescrita está sendo preparada para o snuff, mas você obtém o benefício de escrever um novo código que tira proveito das estruturas atualizadas. É definitivamente uma abordagem mais difícil do que começar limpo e pode não ser tão sexy, mas oferece mais valor aos negócios do que despejar tudo o que está lá porque está desatualizado.

Onde estou e como trabalhamos é o que faríamos: escreva uma nova história e entregue-a ao proprietário do produto, que decidirá como priorizá-la. Um exemplo seria: "Como desenvolvedor do produto X, gostaria de reescrever o código nessa área para que o desenvolvimento futuro seja mais eficiente" Os critérios de aceitação precisariam seguir as seguintes linhas: Reescrever / refatorar x para que seja melhor assim.

Eu não sei sobre a situação em que você está, mas aqui, se quiséssemos recomeçar do zero, seria um caso de sentar com o proprietário do produto e convencê-lo do porquê e depois escrever uma pilha de histórias para recriar os existentes. funcionalidade.

As outras coisas que fizemos para tentar lidar com códigos ruins e / ou legados foram incluir tarefas para retrabalho ao descobrir as histórias dos usuários.

Decidir grandes reescritas é uma decisão comercial. Você pode tentar influenciar as decisões de negócios vendendo, do seu ponto de vista, às pessoas responsáveis ​​pela parte comercial das coisas.

Contudo; a mudança na qualidade do código de uma iteração para a próxima é uma decisão do desenvolvedor. Se você permitir que a qualidade do código diminua, você está adicionando uma dívida técnica para atender às expectativas do proprietário do produto agora. O que você pode fazer é começar a assumir a responsabilidade pelo código que você escreve e garantir que ele melhore a base de código, e não o contrário. Agora, isso significa que você perderá velocidade, pois está diminuindo continuamente o valor da dívida técnica e o proprietário do produto certamente ficará desapontado. Você pode tentar explicar que, por sua vontade, por favor, deixou a qualidade do código diminuir e agora está tomando medidas para corrigir esse problema.

Agora, percebo que é um passo aterrador, e pode ser tentador adiá-lo apenas mais um sprint para que você possa usar o recurso X antes de um prazo importante. Infelizmente, ficará mais difícil quanto mais você esperar.

A propósito, isso não é estritamente um problema do Scrum, nem estou sugerindo uma solução específica para o Scrum. Trata-se de desenvolvedores que se apropriam do código.

Os desenvolvedores são responsáveis ​​por alertar o mundo sobre o estado atual da base de código. Isso pode acontecer durante um scrum diário, uma retrospectiva ou apenas informalmente. Pode parecer óbvio, mas se você não expressar claramente que confusão é essa e quanto tempo você perde por causa disso, ninguém nunca notará. O Scrum Master normalmente será responsável por passar as informações para a OP e as pessoas encarregadas do projeto e convencê-las de que algo precisa ser feito, além de facilitar a implementação de uma solução pela equipe.

Como uma observação lateral, uma reescrita do big bang não é necessariamente a resposta certa para esse tipo de problema. Por mais fartos que os desenvolvedores estejam com a base de código atual, executar pequenas etapas mensuráveis ​​em direção a uma arquitetura mais limpa geralmente é uma idéia melhor, pois você pode ver o progresso, justificar seu trabalho mostrando regularmente ao PO as realizações e continuar o fluxo de implementação de novos usuários. histórias em paralelo, em vez de se perder em uma reforma interminável e monopolizadora de recursos.

Você perguntou:

Onde está a parte do Scrum em que os desenvolvedores podem dizer que basta e exigir que eles tenham tempo para iniciar a grande reescrita? Parecemos um loop infinito de apenas remendar códigos antigos com 'Stories'. Então, as coisas estão sendo executadas por pessoas não técnicas que parecem não querer pressionar por uma reescrita, porque não entendem o quão ruim a base de código ficou ..

Como alguém que é gerente e desenvolvedor, a resposta mais simples para sua pergunta é que não há parte no Scrum, ou qualquer outra metodologia ou cenário de negócios, em que o desenvolvedor tenha o poder de dizer o suficiente e exigir um reescrever. Muitas pessoas aqui apresentaram argumentos bons e válidos para explicar por que as reescritas são freqüentemente más idéias e para explicar como as mudanças podem e devem ser realizadas de maneira ágil e incremental. E eu concordo com todos eles.

Mas a linha inferior é ainda mais simples. Você não toma essa decisão, NUNCA. Você é o funcionário, e a única decisão que você realmente toma é "continuarei trabalhando para esses asshats ou encontrarei um novo emprego que tema a minha louca habilidade". Seu novo emprego também não permitirá que você tome essa decisão, mas pelo menos você sentirá que está no controle de seu destino, ao passar de emprego em emprego.

Sinto sua dor, mas não tenho certeza do que isso tem a ver com Scrum. A decisão de reescrever o código não depende do processo de desenvolvimento.

Espere o que?

Você está remendando ? Você deveria estar refatorando . Atenha-se a valores ágeis. Use TDD e práticas apropriadas e a situação acabará se tornando melhor.