Qual metodologia de programação seria uma boa opção para nós?

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?

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.

• trabalho caindo do céu Essas histórias são colocadas na parte inferior da lista de pendências até que o proprietário e a equipe do produto possam se reunir para concordar em avançar. Sua prioridade é determinada em relação a todos os outros compromissos da sua equipe, e essa prioridade é visível para todos os interessados ​​que procuram. Deve ser extremamente raro adicionar um novo recurso no meio de um sprint, e somente os bugs de maior prioridade devem ter permissão para interromper um sprint. É incrível quantas "emergências" podem esperar até o final da próxima semana, quando isso é uma expectativa regular.
• empreendendo projetos maiores Você terá visibilidade para mostrar como as prioridades de curto prazo afetam seus projetos de longo prazo. Se as pessoas moverem continuamente histórias de usuários para seus projetos de longo prazo, tudo bem, mas para tomar essa decisão, todos saberão o impacto que isso terá no cronograma do projeto de longo prazo.
• os planos do projeto são elaborados por gerentes não técnicos As histórias de usuários devem ser escritas de um ponto de vista não técnico, mas sua equipe de scrum deve ter poderes para fazer estimativas e determinar detalhes da implementação.
• as datas são terrivelmente irreais Sua equipe lida com todas as estimativas, porque você é quem sabe o que está fazendo. Se essas estimativas não forem aceitáveis ​​para os negócios, eles deverão decidir como priorizar os recursos. Se eles precisam de mais trabalho do que você pode lidar, a necessidade de contratar mais pessoas será claramente visível.
• muitas vezes, as datas são perdidas Primeiro, suas estimativas serão mais realistas, o que deve ajudar. Além disso, você está mordendo pedaços menores e realmente finalizando- os, o que ajuda a empresa a sentir que produziu algo útil, mesmo que não esteja completo.
• reuniões repletas de momentos embaraçosos O Agile tem mais visibilidade e um ciclo de feedback muito mais rápido, com um proprietário do produto muito envolvido. Seus problemas de bloqueio e razões para atrasos não devem ser uma surpresa.
• também prestando suporte técnico Ao contrário da crença popular, o ágil não é incompatível com um cronograma dividido. Scrum fatores em suas interrupções na velocidade da sua equipe. Se você normalmente gasta metade do seu tempo prestando suporte técnico, simplesmente terá metade da velocidade.

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.

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:

• uma separação de desenvolvimento e suporte
• um processo formal de coleta de requisitos - sob controle da equipe de TI. "Histórias" etc. parecem muito vagas - mas na verdade é um método "formal" vestido para parecer informal.
• o agendamento está sob controle da equipe de TI.

Se eles não aceitarem isso, diga a eles que você não pode ser ágil.

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.

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.

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 ;-)

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!

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.

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á.

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.

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:

• Desenvolvimento de software enxuto - Mary & Tom Poppendieck
• Desenvolvimento Ágil de Software - Robert C. Martin

e por crédito extra (porque acho que é um ótimo companheiro para os outros livros que mencionei):

• Código Limpo - Robert C. Martin