ti-enxame.com

O Agile força os desenvolvedores a gastar mais tempo realmente trabalhando?

Observando práticas comuns do Agile, parece-me que elas (intencionalmente ou não?) Forçam os desenvolvedores a gastar mais tempo trabalhando realmente, em vez de ler blogs/artigos, bate-papos, coffee breaks e procrastinar.

Em particular:

1) Programação em pares - o maior promotor de trabalho, apenas porque é inconveniente fazer toda essa procrastinação quando houver dois de vocês sentados juntos.

2) Histórias curtas - quando você tem um enorme pedaço de trabalho que deve ser feito, por exemplo, por mês, é bastante comum relaxar nas primeiras três semanas e alternar para o modo OMG DEADLINE na última.

E com os pequenos pedaços (que devem ser feitos em um dia ou menos), é exatamente o oposto - você sente que o tempo está curto, não há espaço para manobras e você será responsabilizado pela tarefa em breve, para começar trabalhando imediatamente.

3) Comunicação e coesão da equipe - quando você tem um desempenho lento, distante e silencioso, pode parecer bom, mas quando, no final do dia, na reunião do Scrum, todos se orgulham do que realizaram e você não tem nada a dizer que pode realmente se sentir envergonhado.

4) Teste e feedback - novamente, impede que você mantenha as tarefas "99% prontas" (quando na verdade são cerca de 20%) até que o prazo ocorra repentinamente.

Você acha que no Agile você trabalha mais do que nas metodologias "convencionais"? Essa pressão é compensada pelo ambiente mais confortável e pela sensação de realmente fazer as coisas certas rapidamente?

25
Fixpoint

A principal idéia por trás dos métodos ágeis é ajudá-lo a ser produtivo - em um sentido positivo. Ninguém se importa se você passa uma hora navegando todos os dias se cumprir o prazo. Todo mundo fica bravo se você surfa meia hora todos os dias, mas perde o prazo. A solução: facilite o cumprimento do prazo.

Como você notou, a programação em pares garante que você permaneça focado (entre todas as outras vantagens, como melhorar a disseminação de habilidades/conhecimentos, melhor código, menos bugs, design uniforme etc.).

Eu descobri que a disciplina é sempre uma luta para mim. Se eu parear com alguém, é provável que um de nós queira fazer algum trabalho hoje e puxe o outro. Portanto, o "trabalho por um mês" geralmente se transforma em "trabalho em conjunto por uma semana", surpreendendo-se como essa enorme quantidade de trabalho foi resolvida no final, passando um dia ou mais se recuperando (refatorando, corrigindo TODOs no código, adicionando um dois testes, surfando com a consciência limpa) e depois pegando o próximo mês de trabalho.

Resultado líquido: estou muito mais relaxado (mais porque, apesar da supervisão constante), a coesão da equipe é muito melhor, o trabalho é feito mais rapidamente, as pessoas não ficam com problemas menores por horas ou até dias (porque alguém pode localize o problema muito mais rápido).

Quando você diz "você pode realmente sentir vergonha", isso não é uma coisa boa? Isso significa que você sente que fez algo errado e deveria. Você não está sendo pago para não fazer nada. Não fazer nada faz com que você se sinta impotente, infeliz, indigno, infeliz. Em vez de sentir vergonha, afaste-se e pense: "Por que não fiz nada hoje?" Você precisa de ajuda? Existe algo que você não entende? A tarefa atual é muito difícil? Você não gosta disso? Talvez você possa mudar a tarefa com outra pessoa. Talvez alguém possa ajudá-lo a passar. Agile significa: assuma a responsabilidade em vez de ser microgerenciado como um fantoche nas cordas. Você precisa de uma ferramenta? Vá ao seu chefe e peça. Aprenda a discutir. Aprenda a se levantar e gritar quando for necessário.

Quanto aos testes, há um ponto ideal quando seu código cai repentinamente de "Agradável" para "perfeito". Esse é o momento em que você percebe que precisa implementar o recurso X e pensou que seria um pesadelo e de repente percebeu que o código estava quase lá. Apenas uma pequena refatoração aqui e ali. Uma nova aula e pronto. Quatro semanas de trabalho de repente se tornaram um dia. Vitória! Triunfo!

38
Aaron Digulla

Concordo.

Programação em par

É uma maneira muito intensa e exaustiva de trabalhar, e eu nunca a aplico a menos que tenha alguns desenvolvedores que precisam ser treinados por outras pessoas (recém-chegados, por exemplo)

Histórias curtas

Comunicação e coesão da equipe

Teste e feedback

Sim Ágil e especificamente Scrum é um grande impulsionador da produtividade. Quando aplicado corretamente, o turnover pode chegar a 20% (1 desenvolvedor em 5 sai da empresa).

O motivo é simples: Scrum não fornece mais produtividade, it provides the whole company with much more visibility on what's going on (inclusive na gestão do curso).

  • Torna impossível para um desenvolvedor apenas fazer o mínimo necessário. O minium nu agora é a média da equipe!

  • Torna impossível para o gerenciamento não colaborar adequadamente.

Foi por isso que eu disse (em minhas outras respostas em perguntas semelhantes), que o Agile NÃO é para todas as organizações (e para todos).

Por exemplo, o setor público não é realmente adequado para o Agile.

Ágil sendo usado como ferramenta de pressão? Claro, eu já vi isso muitas vezes. Isso apenas piora as coisas.

20
user2567

Você acha que no Agile você trabalha mais do que nas metodologias "convencionais"? Essa pressão é compensada pelo ambiente mais confortável e pela sensação de realmente fazer as coisas certas rapidamente?

Isso me faz trabalhar mais, mas acima de tudo, me faz trabalhar na coisa certa. A qualquer momento eu sei o que devo fazer.

É um tipo de pressão positiva. Isso é bem diferente de algum externo "você já está atrasado, trabalha mais, programa horas extras!" tipo de pressão.

8
Joonas Pulakka

Na verdade, sou muito mais produtivo quando uso os métodos convencionais. Com o método convencional, crio p. uma análise detalhada dos requisitos, um estudo de viabilidade, uma especificação funcional, uma especificação técnica e muitos protocolos de atendimento, tudo em apenas alguns meses! Posso até criar algumas linhas de código assim que a análise de impacto estiver concluída!

Ágil, tudo o que crio são alguns produtos a serem entregues.

7
user281377

Em nossa empresa,

Programação em pares - Quando algo realmente complexo e exige uma análise ampla, mesmo reunimos duas pessoas excelentes e concluímos a tarefa no Quick Time. Aqui, a complexidade da tarefa decide a necessidade de programação em pares.

Histórias curtas - Depois, relaxo por 3 semanas (aproximadamente 5 a 6 horas por dia) e corro no último momento (aproximadamente 12 a 14 horas por dia) como desenvolvedor. Não gosto de ter uma oscilação na carga de trabalho. Trabalhe em torno de 8 horas por dia e mantenha sua programação estável e isso sempre parecerÁ LEGAL.

Comunicação e coesão da equipe - Na reunião do scrum, não apenas compartilhamos o status da tarefa, mas também os obstáculos. Aqui, quando alguém realmente precisa de ajuda, outros membros realmente apresentam suas idéias para ajudá-lo. Mas certamente você precisa de uma excelente equipe para isso e nós somos :)

Teste e feedback - Certamente, como desenvolvedor, não quero que eu fique sobrecarregado com os Bugs, no momento seguinte, depois que você encontrar um bug, foi para corrigi-lo e, novamente, isso me permitiria ter uma boa previsão do que deveria/pode em seguida e reagendar o prazo (se necessário) de acordo.

Então, como desenvolvedor, estou muito feliz com o tipo de tarefa que tomo e com certeza posso dizer que nunca senti a pressão REAL do prazo.

4
Gopi

Você acha que no Agile você trabalha mais do que nas metodologias "convencionais"?

  • Se você quer dizer que me sinto mais produtivo no Agile, eu diria depende .

    Eu costumo pensar nisso em termos de Ferrari (como convencional) vs Landrover (como Scrum). Ao dirigir em uma rodovia, a Ferrari supera a Landrover.

    É off-road quando alguém precisa de jipe ​​e não de carro esportivo - quero dizer, se seus requisitos são irregulares e/ou se o trabalho em equipe e a experiência de gerenciamento não são tão bons, você terá que escolher o Scrum - simplesmente porque tentar ir convencional vai deixar você preso - como a Ferrari vai ficar fora da estrada.

Quanto a "trabalhar mais" , bem, acho que alguém que espera coisas como essa provavelmente subestima o QI do programador e sua capacidade de se adaptar a várias formas de demência de gestão.

Até o momento, participei de duas equipes do Scrum fazendo projetos bastante diferentes em diferentes empresas. Nas duas equipes, não notei nenhuma mudança nos meus hábitos em comparação com, por exemplo, cascata/iterativa.

Eu ficaria orgulhoso em afirmar que isso é porque sou tão especial e invencível, mas, francamente, também vi os hábitos de todos os outros caras do time serem invencíveis.

4
gnat

O Agile força os programadores a realizar um trabalho mais útil, porque as várias técnicas de desenvolvimento ágil eliminam trabalhos ocupados e trabalhos que simplesmente não são necessários.

2
Jay Godse

é inconveniente fazer toda essa procrastinação quando vocês dois estão sentados juntos.

Discordo. Eu trabalhei com um grupo de fumantes e todos conseguiram descansar juntos por longos períodos porque "todo mundo estava fazendo isso".

comum relaxar nas primeiras três semanas

Este é um sinal de má gestão, independentemente da metodologia. Mesmo que um grande pedaço chegue dentro de um mês, eu esperaria ver algo no final da primeira semana.

você não tem nada a dizer que pode realmente sentir vergonha.

Se você estiver disposto a se masturbar por três semanas, pense em alguma besteira para dizer.

4) Teste e feedback - novamente, impede que você mantenha as tarefas "99% prontas" (quando na verdade são cerca de 20%) até que o prazo ocorra repentinamente.

Projetos em cascata podem ter testes e compilações diárias.

Pessoalmente, eu odiaria escrever código e não faria nada com ele por um mês. Eu prefiro o loop de feedback mais curto no meu código, seja uma revisão codificada ou uma assinatura do usuário. Ter outros aprovando meu trabalho é gratificante. É como o gato que coloca um rato na sua porta apenas para que você saiba que ela está fazendo o trabalho dela.

2
JeffO

O Agile não força os desenvolvedores a trabalhar mais, mas a trabalhar mais eficientemente

1
greuze

Formular a pergunta 'forçar os desenvolvedores a trabalhar mais' é um pouco negativo, mas certamente é positivo se realmente fizermos mais e procrastinarmos menos?

Dito isto, é um bom ponto. Eu me sinto um pouco cansada de ágil este ano, mas esse é um enorme benefício não escrito que eu não reconhecia.

Concordo que o ágil pode levar os desenvolvedores a serem mais produtivos. Seus pontos de vista sobre visibilidade, responsabilidade e tendência a procrastinar menos são todos muito verdadeiros.

Mas o ágil pode e também deve levar os desenvolvedores a trabalharem mais por razões positivas - a cenoura versus a vara. Se bem feito, o ágil dará aos desenvolvedores mais interação com os usuários, menos precisão, mais controle sobre o trabalho deles, o que pode levar a obter mais da sua equipe.

0
Benjamin Wootton

mais trabalho ainda não é semanticamente correto ou relevante para o Agile, os objetivos são ser mais produtivos . É especificamente focado em trabalhar menos na coisa errada e mais no trabalho normalmente na correta coisa; o que não significa trabalhar mais, apenas mais produtivamente.

Um efeito colateral é o fato de expor preguiçosos e aqueles que são ineficientes ou não competentes muito rapidamente. O que parece mais com o que você está recebendo.

A metodologia é irrelevante para saber se um desenvolvedor é não está funcionando. O processo é que, mesmo em cascata, as análises de gerenciamento e de código também podem expor essas alterações, mas não de forma tão transparente quanto a maioria das metodologias ágeis.

0
user7519