Infelizmente, alguém ensinou à nossa alta administração a palavra "Ágil" e agora quer que avancemos nessa direção. Eu tenho uma compreensão periférica do ágil (em princípio), mas nunca o usei na prática. Pelo que sei, não será uma boa opção para a nossa organização. No momento, as coisas são bem grunge. Aqui está como é;
Somos uma equipe muito pequena - dois desenvolvedores, um DBA, um designer. A empresa em que trabalho gera uma quantia desproporcionalmente grande de dinheiro em relação ao seu tamanho, e quase 95% disso é pura venda on-line.
Do ponto de vista do desenvolvimento, estamos sujeitos a muitas invasões de mesa durante um dia típico (somos suporte técnico e desenvolvedor), o trabalho pode cair do céu regularmente em um instante, se um membro da equipe de vendas promete algo a alguém . Também realizamos projetos maiores, e eles são um pesadelo com as constantes interrupções. Alguns de nós estão começando a arrancar os cabelos! Os planos do projeto são elaborados por gerentes não técnicos em planilhas do Excel, onde eles tentam dividir a tarefa em frases pequenas que eles podem entender e colocar uma data ao lado de cada uma. Essas datas são sempre terrivelmente irreais e muitas vezes perdidas, e nossas reuniões (que realizamos semanalmente) são regularmente preenchidas com momentos estranhos com pessoas perguntando "por que isso ainda não foi feito".
Tenho certeza de que o Agile não é o único para nós. Agora, considerando que (e eu tentei) esta empresa não mudará de maneira , e apenas a equipe de desenvolvimento está disposta a mudar, existe uma metodologia de desenvolvimento que possamos adotar que seja adequada para nos salvar um pouco de sanidade?
fonte
Respostas:
O Agile foi realmente projetado para resolver muitos dos problemas exatos que você está tendo. Se a gerência realmente se interessou e não perverter o processo, você poderá ver uma grande melhoria. Deixe-me abordar seus problemas ponto a ponto. Minha experiência é com scrum, então vou falar desse ponto de vista, mas tenho certeza que outras implementações têm benefícios semelhantes.
O que a gerência e as vendas precisam entender é que o agile não é uma maneira de exercer um controle mais rígido sobre a equipe de desenvolvimento, dando à equipe mais autonomia para fazer o que é bom, ajudando os negócios a considerar realisticamente todas as suas prioridades ao atribuir trabalho a eles. O time.
fonte
Eu diria que tire proveito dos caprichos da sua gerência! Parece que eles estão lhe fazendo um favor e dando-lhe alguma influência para melhorar seus métodos de trabalho.
Diga a eles que tudo bem, vamos agilizar entre outras coisas:
Se eles não aceitarem isso, diga a eles que você não pode ser ágil.
fonte
Agile não é uma metodologia de programação, Agile é uma metodologia de gerenciamento de projetos. Se o gerenciamento superior realmente deseja que você experimente essa nova palavra da moda, eles precisam entender que o método Agile começa do topo e envolve o gerenciamento em todas as etapas do processo. Se você precisar dar a eles uma dose dura de realidade, talvez organize uma apresentação do Powerpoint de 30 minutos sobre o Agile para dar a eles um pouco de educação. Os gerentes adoram o Powerpoint.
No entanto, se, como você diz, a equipe de desenvolvimento é a única pessoa disposta a mudar, nenhuma metodologia de desenvolvimento poderá ajudá-lo. Sem o alívio de suas obrigações, as interrupções continuarão ocorrendo e você será solicitado a cumprir prazos que simplesmente não pode cumprir.
Meu conselho nesse cenário é educar, e não repreender, a gerência sobre como ela realmente está nas linhas de frente.
fonte
Nenhuma metodologia de desenvolvimento de software e gerenciamento de projetos pode ajudar em uma organização onde o pessoal de vendas determina o cronograma diário. Como você deve gerenciar um projeto em meio a uma semana de trabalho tão caótica e distraída?
Muitos gerentes de nível superior veem o valor do Agile e desejam seus benefícios, mas quase nunca são capazes de fazer as alterações internas necessárias para garantir que a mudança seja bem-sucedida. As únicas lojas bem-sucedidas do Agile que eu conhecia começaram assim. Não me lembro de uma única instância da minha experiência profissional de uma loja de desenvolvimento de software gerenciada por vendas ou em cascata que está se movendo porque exige uma mudança fundamental na cultura.
Essa mudança de cultura é possível? Sim, mas no seu caso quase certamente não.
Uma mudança na cultura é geralmente necessária por um concorrente que ameaça a existência da empresa ou uma situação de fabricação ou quebra ou alguma outra situação similarmente envolvida para justificar uma reorganização. Na sua situação, sua empresa está no outro extremo do espectro, onde o dinheiro agora é fácil e todo mundo está engordando.
As empresas NUNCA mudam de dentro quando o dinheiro é fácil. Por que deveriam, eles são bem-sucedidos, apesar das falhas no desenvolvimento de software, não por causa do sucesso no desenvolvimento de software.
Meu conselho final é que, se eu fosse você, procuraria algo melhor. As pessoas aqui têm ótimos conselhos, mas eu já vi essa música e dança antes e simplesmente não funciona na sua situação.
fonte
veja extremeprogramming.org - XP é uma forma de Agile com aspectos de fácil compreensão que você pode escolher e escolher a la cart; um bom lugar para começar
o compromisso do cliente de não mudar de idéia durante uma interação seria um bom ponto de partida para o seu ambiente, pelo que parece ;-)
fonte
Se considerarmos o cenário das metodologias, tradicionais e contemporâneas, perceberíamos que "Agile" é mais uma "antimetodologia" do que uma metodologia. Os padrões visam retratar a melhor solução para um determinado problema dentro de um contexto específico. As tentativas de violar diretamente essa solução ou padrão são geralmente chamadas de "antipadrões" ou práticas de pior caso. Da mesma forma, enquanto as verdadeiras metodologias de desenvolvimento de software tentam prescrever as melhores práticas para o desenvolvimento de soluções, o "Agile" (Scrum, XP, etc.) tenta violar diretamente toda e qualquer estrutura dentro do processo de desenvolvimento de software, em favor de um acaso, caótico. abordagem - que (ultimamente), também parece exigir aplausos dos (ingênuos) espectadores.
Com isso dito, é adequado ter em mente o contexto em que a filosofia Agile surgiu. Embora existissem metodologias iterativas sofisticadas (por exemplo, Processo Unificado), a metodologia principal ainda era a antiga abordagem em cascata, que prescrevia uma "melhor prática" de análise completa de requisitos, projeto completo, desenvolvimento / codificação da solução e implementação. a solução. Claramente, essa abordagem de engenharia para o desenvolvimento de software foi mal recomendada - e resultou em muitos papéis antes (e às vezes sem nunca) de ver uma solução executável.
No entanto, ele ainda não garante a expulsão do bebê com a água do banho, como foi o caso dos conjuradores do Agile. A abordagem Agile quase impõe uma negação direta de qualquer coisa que foi usada antes dela - exceto talvez a codificação real da solução. Claramente, isso é uma indicação de insight limitado por parte de seus autores, ou talvez seja simplesmente um caso de "não há ninguém tão cego, como aqueles que não querem ver".
No entanto, o mérito do ágil é que ele encoraja processos simplificados e se concentra no código executável - que é inevitavelmente o seu produto final.
AGORA, para responder sua pergunta mais diretamente:
Dada a sua visão geral do seu ambiente, sugiro que você primeiro selecione uma implementação Agile (por exemplo, Scrum, XP, etc.). Em seguida, personalize a abordagem para adequar seu ambiente, delineando um processo claro de como sua equipe estará trabalhando, por exemplo:
Receber solicitação do (s) usuário (s);
Priorizar solicitações de usuário;
Avalie o impacto do aprimoramento no sistema existente (talvez durante suas reuniões diárias / semanais);
Estime o tempo de desenvolvimento de cada aprimoramento - e comunique-o novamente a vários usuários solicitantes;
Realize aprimoramentos reais no sistema existente (ou seja, codificação).
Realize testes do usuário - e obtenha o comprometimento dos usuários (por exemplo, por email) de que as alterações solicitadas foram implementadas com sucesso.
Isso deve fornecer alguma estrutura (e ordem), além de manter alguma aparência de uma abordagem Agile.
Com o que foi dito acima, lembre-se de que a antiga figura inglesa do discurso, "Tão ágil quanto um macaco", não foi inventada sem razão!
fonte
Eu diria que você precisa de uma metodologia como o Agile é essencial para sua equipe. Como sua empresa é tão desorganizada, você precisa estar mais organizado dentro de sua própria equipe de desenvolvimento. No entanto, acho que seus gerentes não técnicos devem ter algo a ver com isso.
Se você vai pressionar seu pessoal de vendas e exigir prazos realistas, você precisa justificar isso com planos organizados.
Também em uma nota separada, se eles chegarem a você com estimativas sem consultar o técnico, basta recusá-las à queima-roupa.
fonte
Talvez focar nos aspectos incrementais / iterativos seja o que sua equipe e as partes interessadas do céu precisam ser capazes de oferecer com regularidade e consistência. Com o tempo, a equipe de vendas e a gerência acreditarão que, quando fizerem uma nova solicitação de recurso, poderão ter certeza de que sua equipe cumprirá um prazo adequado.
Obviamente, você precisa investir em testes de unidade / sistema / regressão, construções automatizadas, dogfooding, etc., para chegar lá, se você ainda não estiver lá.
fonte
Primeiro, sugiro reunir alguns dados. Sente-se em um momento tranquilo e descubra qual é realmente o status quo - como as coisas são feitas. Se a gerência está decidida a implementar algo que eles podem chamar de ágil, então descubra algo que funcionaria para sua equipe, elabore um documento, dê um tapa em "Agile" no nome e você estará pronto. Lembre-se de que a única coisa que eles realmente sabem sobre ágil é a palavra e alguma associação vaga com rapidez por sua definição usual em inglês. Portanto, o que estou defendendo é que sua equipe se destaque da questão, encontre um sabor que funcione para você e apresente isso ao seu gerenciamento da maneira Agile (tm). Caso contrário, alguns PHB vão pegar um livro e tentar encaixar a estaca quadrada no buraco redondo e ninguém ficará feliz.
Se você adota uma forma "pura" de agilidade, pode ser difícil que sua equipe também cumpra a função de suporte. Vamos ser sinceros, seu chefe pode achar difícil aceitar membros da sua equipe respondendo às solicitações do suporte técnico dizendo "deixe-me criar um item de lista de pendências, chegarei a isso em (no final do sprint) semanas".
O maior obstáculo é o dinheiro. Se tudo é molho verde, é muito mais difícil dizer que algo está errado e precisa mudar.
Boa sorte.
fonte
Pelo contrário, parece-me que um método Agile é exatamente o que você precisa para lidar com prazos perdidos, expectativas irreais e projetos mal planejados.
Sua gerência indicou que está interessado nesta nova palavra do Google Buzz. Muito provavelmente eles vão querer usá-lo para exagerar na comercialização de seus produtos. isso não é necessariamente uma coisa ruim, mas precisará ser gerenciado com muito cuidado se você quiser fazer um método Agile funcionar para você.
Metade da batalha está recebendo apoio da administração. Tê-los receptivos à própria idéia do Agile é a maior parte da batalha. O resto é garantir que as expectativas deles sejam gerenciadas para que eles continuem desejando que você seja ágil e evitar que eles fiquem desencantados quando e se seus gerentes sentirem que o controle sobre o gerenciamento de projetos está escorregando em seus dedos.
Antes de sua empresa decidir alguma coisa, eu recomendaria entrar em um coach Agile para fazer um seminário e um workshop de meio dia. Faça com que todos pensem como equipe - gerentes e desenvolvedores - sobre o que é Agile que você acha que funcionará para você e o que você sente que não. Se, por outro lado, a gerência confiar em seu julgamento, será necessário familiarizar-se com várias práticas e métodos ágeis e criar um seminário próprio. Pessoalmente, eu recomendaria um treinador experiente, para que você não perca muito tempo e mantenha o ritmo. Enquanto isso, pegue uma cópia de alguns bons livros Agile como referências, leia-os completamente, mas também deixe-os pendurados em sua mesa, onde a gerência pode vê-los. A psicologia subliminar pode fazer maravilhas em uma situação como a que você descreveu.
Eu recomendo, no mínimo, ler o seguinte:
e por crédito extra (porque acho que é um ótimo companheiro para os outros livros que mencionei):
fonte