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 oposição à leitura de blogs / artigos, bate-papo, coffee breaks e procrastinação.
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 grande pedaço de trabalho que deve ser realizado em, por exemplo, um 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 é curto, não há espaço para manobras e você será responsabilizado pela tarefa em breve, então você começará trabalhando imediatamente.
3) Comunicação e coesão da equipe - quando você tem um desempenho lento, distanciado 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?
Respostas:
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. Ágil 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 repentinamente cai de "bom" para "perfeito". É 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!
fonte
Concordo.
É 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)
Sim, o Agile e, especificamente, o Scrum, são um grande impulsionador da produtividade. Quando aplicado corretamente, o turnover pode chegar a 20% (1 desenvolvedor em 5 sai da empresa).
O motivo é simples: o Scrum não fornece mais produtividade
it provides the whole company with much more visibility on what's going on(inclusive no gerenciamento, é claro).Torna impossível para um desenvolvedor fazer apenas o mínimo. 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 só piora as coisas.
fonte
Isso me faz trabalhar mais, mas acima de tudo, me faz trabalhar na coisa certa. A qualquer momento, sei o que devo fazer .
É um tipo de pressão positiva. Isso é bem diferente de alguns "externos, você já está atrasado, trabalha mais, programa horas extras!" tipo de pressão.
fonte
Na verdade, sou muito mais produtivo quando uso os métodos convencionais. Com o método convencional, crio, por exemplo, uma análise detalhada de 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 depois que a análise de impacto estiver concluída!
Ágil, tudo o que crio são alguns produtos a serem entregues.
fonte
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 rapidamente. 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 agenda 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 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.
fonte
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 você 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 você ficou 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 gerencial .
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.
fonte
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.
fonte
Discordo. Eu trabalhei com um grupo de fumantes e todos conseguiram fazer uma pausa juntos por longos períodos porque "todo mundo estava fazendo isso".
Este é um sinal de má gestão, independentemente da metodologia. Mesmo que um grande pedaço chegue em um mês, eu esperaria ver algo no final da primeira semana.
Se você estiver disposto a se masturbar por três semanas, pense em alguma besteira para dizer.
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.
fonte
O Agile não força os desenvolvedores a trabalhar mais , mas a trabalhar com mais eficiência
fonte
Fazer 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 cansado de ágil este ano, mas esse é um benefício enorme e 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.
fonte
quanto mais trabalho ainda não for semanticamente correto ou relevante para o Agile, o objetivo é ser mais produtivo . É especificamente focado em trabalhar menos na coisa errada e mais no trabalho normalmente na coisa correta ; 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.
fonte
"Armas não matam pessoas. Pessoas matam pessoas!" É o mesmo com o Agile. O Agile não faz as pessoas trabalharem mais, os gerentes fazem as pessoas trabalharem mais.
fonte