Como desenvolver um software excelente com métodos ágeis?

A resposta formal é que você entendeu mal, ágil e não dita os requisitos, os stakeholders fazem. O núcleo da agile não é esculpir suas necessidades em pedra, mas sim fazê-las emergir à medida que você for, em contato próximo com seu cliente, beneficiando-se de insights progressivos.

Mas isso é tudo teoria. O que você testemunhou é, de fato, um traço comum de muitas linhas de produção de software que adotaram uma maneira ágil de trabalhar.

O automóvel nunca teria sido inventado se os fabricantes na época fossem "ágeis" porque todos os clientes pediam um cavalo mais rápido.

Isso não dificulta a agilidade. É um pouco como o comunismo. Uma ótima idéia que dificilmente funciona bem porque as pessoas são apenas pessoas, fazendo coisas para as pessoas. E o método / ideologia / religião acalma-os na ideia de que eles estão indo bem desde que estejam passando pelos movimentos e / ou seguindo as regras.

[editar]

Slebetman:

It is ironic then that agile evolved out of the automative industry (namely Toyota).

Lembre-se da regra de ouro da automação? "Primeiro organize, depois automatize". Se você automatizar um processo quebrado, o melhor que pode acontecer é acelerar tudo o que estiver errado. As pessoas da Toyota não eram idiotas.

A razão típica para adotar qualquer nova metodologia é que as coisas não estão indo bem. A gerência reconhece isso, mas eles podem não entender os problemas principais. Então eles contratam esse guru que dá um discurso resiliente sobre o Agile e o Scrum. E todo mundo adora isso. Por suas próprias razões.

Os desenvolvedores podem pensar "Ei, isso pode funcionar. Estaríamos mais envolvidos com problemas de negócios e poderíamos fornecer dados para o preenchimento desse backlog. Isso poderia ser uma oportunidade para tornar as vendas e o atendimento ao cliente entenderem o que fazemos, por que é necessário, e nós os tiramos do nosso cabelo enquanto estamos queimando de forma transparente o que nós concordamos. " Não mais "pare o que você está fazendo, isso precisa ser feito agora" por algum cara que você não quer adiar aparecer em sua mesa.

O problema real é que a loja não foi bem organizada e isso não mudou. As pessoas receberam responsabilidades que não podem resolver, ou talvez possam, mas o Sr. Boss está constantemente interferindo e arruinando o que eles fizeram, ou (na maioria das vezes na minha experiência), responsabilidades cruciais não foram reconhecidas ou atribuídas a ninguém.

Às vezes, com o tempo, uma organização informal surgirá entre as linhas formais. Isso pode compensar parcialmente a falta de uma estrutura formal. Algumas pessoas acabam fazendo o que são boas, se têm um cartão de visita para provar isso ou não. A introdução contundente do Agile / Scrum pode arruinar isso instantaneamente. Porque agora espera-se que as pessoas sigam as regras. Eles sentem que o que costumavam fazer não é apreciado, eles recebem pequenos papéis amarelos com pequenas histórias, a mensagem será: "o que você estava fazendo, ninguém se importava". Escusado será dizer que isso não será particularmente motivador para essas pessoas. Eles vão, na melhor das hipóteses, começar a esperar por pedidos e não tomar mais nenhuma iniciativa.

Então as coisas pioram e a conclusão é que o Agile é uma droga.

O Agile não é uma droga, é ótimo para projetos de manutenção e pode até ser bom para novos desenvolvimentos se aplicado com cuidado, mas se as pessoas erradas não o entenderem ou adotarem pelas razões erradas, ele pode ser muito destrutivo.

There doesn't even seem to be a place for attractive qualities in agile.

Você está comparando maçãs e laranjas. Na cachoeira tradicional, se suas necessidades dizem que você precisa dos itens essenciais, você adquire um Fiat. Se os requisitos dizem que tem que ser de primeira qualidade, você recebe uma Ferrari.

O mesmo acontece no Agile. Se os seus requisitos param em must-haves, você recebe um Fiat. Se você tem histórias de excelência, você ganha uma Ferrari. Tudo o que é ágil realmente é que você faz o que é necessário primeiro . Não construa um spoiler super legal por dois anos e, então, perderá o prazo para o mecanismo.

Tão longa história: você consegue o que precisa. Se você planeja um carro esportivo, você ganha um carro esportivo. Ágil não muda nada disso. Se o seu processo ágil apresentar requisitos para um Fiat, não culpem os jogadores ágeis, apenas responsabilizem um Fiat.

However, all agile processes I know strongly favor must-be requirements. These always get the highest priority.

Como deveriam - olhe novamente para o seu modelo Kano: se os requisitos obrigatórios não forem satisfeitos, o cliente não aceitará o produto. E então seus delatores não importam.

There doesn't even seem to be a place for attractive qualities in agile.

Nada poderia estar mais longe da verdade.

Os processos ágeis geralmente enfatizam esses pontos:

• Entrega frequente de um produto em funcionamento para o qual você pode receber feedback.
• Divida recursos em pequenas partes que podem ser concluídas em pouco tempo.
• Implemente essas partes em ordem de prioridade.

Nada impede que você ofereça recursos "encantadores" de alta prioridade. Depende completamente das pessoas que estão encarregadas de determinar as prioridades.

Agora é verdade que muitas dessas pessoas preferem não assumir riscos e, portanto, podem não dar grandes prioridades aos "delatores". Mas em um projeto não ágil que ainda seria o caso.

O Agile não diz nada sobre o que deve ser feito primeiro, apenas que o código deve ser escrito incrementalmente e mantido em um estado liberável tão freqüentemente quanto possível, em vez de ser inutilizado por meses até o próximo estado libertável.

Eu tenho trabalhado tanto no Agile quanto no BDUF (Big Design Up Front), e enquanto você definitivamente consegue recursos inovadores e atraentes em ambos os processos, na BDUF, sem surpresa, você tem que planejar para eles na frente. Isso significa que as inovações geralmente têm que ser propostas ou pelo menos patrocinadas por pessoas com influência no processo de design.

Isso ocorre porque você tem seis meses (ou qualquer outro) até o próximo lançamento, e os gerentes de projeto estão estressados sobre o que está acontecendo naquele lançamento, porque se o recurso deles não entrar, serão mais seis meses até que o proximo. Portanto, há uma lista repleta de recursos em um agendamento lotado, e se o humilde rank-and-file é pego trabalhando por dois ou três dias em algo legal eles só pensam que o cliente vai gostar, e não está no lista, eles arriscam toda a programação e haverá um inferno para pagar.

Em um processo Ágil, nos esforçamos para manter o software em um estado liberável, e os gerentes de projeto ficam menos estressados porque, se o recurso deles cair, eles podem obtê-lo em apenas duas semanas. Então, se um desenvolvedor volta de uma conferência com uma idéia legal e passa alguns dias em algo, eles não estão colocando um cronograma de seis meses escrito no sangue em perigo.

Basicamente, você colhe o que planta. Se você incentivar a inovação e dar às equipes autonomia suficiente para entregar, você conseguirá. Se você exigir constantemente os cantos de corte para cumprir os prazos, você obterá software compatível, independentemente da sua metodologia.

O excelente software vem de duas coisas:

• Dando ao cliente o que eles exigem

• Sendo um profissional

Existem todos os tipos de princípios a seguir ao desenvolver software. SECO, legível, SÓLIDO, etc., que não tem nada a ver com os requisitos do cliente. O cliente pediu um carro esportivo. Se o cliente entendeu o que é preciso para tornar um carro esportivo incrível, ele não precisaria de você. Cabe a você descobrir o que mais é importante.

Parte do nosso trabalho é manter padrões que o cliente nunca experimenta, a menos que as coisas saiam terrivelmente erradas.

Se você está fazendo certo, então o ágil tende para o decreto apenas quando é isso que o cliente realmente quer. Não quando é isso que eles acham que precisam se contentar.

A cachoeira é diferente porque uma vez que um mal-entendido sobre uma exigência de carro esportivo de ponta tenha se instalado, ela tende a ficar por perto. Ágil pode lidar com novas informações e adaptar-se se o que eles realmente precisam é de uma moto-bala.

A cachoeira ainda está em uso em muitas lojas até hoje. Essas lojas são bem sucedidas porque suas necessidades mudam menos de 2% em um ano.

Seu trabalho não é apenas dar ao cliente o que eles querem. É também para cuidar de coisas que você sabe que você não terá nenhum crédito em tudo. Coisas que o cliente nunca fará, a menos que você deixe as coisas darem errado. Essas coisas devem ser bem escolhidas ou você vai ter muita porcaria por perder tempo com elas.

Qualquer idiota pode criar uma ponte com um orçamento ilimitado. Um profissional constrói uma ponte que quase nunca cai.

Therefore I believe one shouldn't slavishly focus on the must-be requirements.

Claro que você deveria. Exceto quando estimar o seu tempo. Porque esses requisitos obrigatórios não são a única consideração.

Ok,

No Agile, o programador pode criar o software, mas no final é o productowner que cria o produto. (usando os desenvolvedores de software).

Então, sobre "qualidades atrativas", isso depende do proprietário do produto.

Se o productowner exigir "design sexy", isso pode ser um requisito. O desenvolvedor não deve se preocupar com essas escolhas.

Além disso, o software é tão diferente dos produtos físicos reais que eu acho que muito do modelo Kano não se aplica. Por exemplo, por que eu faço facebook? Única razão: porque meus amigos fazem. Como colocar isso no próximo sprint ........ E também, uma das qualidades mais atraentes do software, é que ele realmente faz o que deve fazer. (E é aí que o agile ajuda muito: P)

Minha experiência concorda com os comentários acima - não há nada inerente no Agile que impeça o desenvolvimento de software excelente - no entanto, há vários aspectos de como o Agile é frequentemente (mal) praticado levar a software que é apenas "bom o suficiente".

• O Agile coloca ênfase na obtenção de algo trabalhando o mais rápido possível; no entanto, isso significa fazer suposições simplificadoras e cortar cantos, principalmente na infraestrutura não visível ao usuário. Não há nada inerentemente errado nisso, se o custo de correção das hipóteses simplificadoras é baixo; no entanto, com demasiada frequência, essa "dívida técnica" não é removida antes que um produto entre em produção;
• Agile prega que, no final de um sprint, você deve sempre ter algo que seja o mais acessível possível, para que as partes interessadas e os gerentes de projeto possam decidir que "o que eles têm" é bom o suficiente para empurrar para a produção. Novamente, nada inerentemente errado com isso, se você limpou toda a sua "dívida técnica" (ou fez as pazes com o quanto você tem e onde está.) No entanto, na minha experiência, muita dívida técnica entra em produção com a promessa de um gerente de que "vamos limpá-lo assim que a pressão para embarcar for desativada", que rapidamente se transforma em "está em produção, temos que ter muito cuidado com o que mudamos agora ", que eventualmente se transforma em" Você nunca me disse que tivemos essa exposição! Temos que fazer um trabalho melhor da próxima vez! " A lição de Ben Frankin sobre "A amargura da má qualidade permanece por muito tempo depois que a doçura do preço baixo é esquecida" parece nunca ser aprendida;
• No entanto, mesmo com gerentes confiantes e desenvolvedores bem disciplinados, há o problema comum de que apenas uma análise, projeto e revisão de projeto de projeto muito insuficiente ocorre anterior ao início do sprint em que se espera que a implementação seja iniciada e completada. A falha em considerar cuidadosamente metáforas e projetos de alternativa UI é grande - geralmente é muito caro revisar isso significativamente depois que um projeto é iniciado; o fracasso das equipes juniores em estudar cuidadosamente os produtos da concorrência, ou priorizar a definição e implementação de tecnologias de infraestrutura como I18N, frameworks de notificação, registro, segurança e estratégias de versionamento de APIs (por exemplo) significa que eles terão bugs maiores menor produtividade, e acumularão mais dívida técnica, do que se tivessem passado os primeiros 2 a 5 sprints fazendo o treinamento, a análise, o design e a prototipagem necessários. Em suma, as equipes ágeis devem resistir à licença para hackear;
• Eu tive um gerente de segundo nível (de mais de 100 desenvolvedores) que desencorajou seus desenvolvedores a dedicarem tempo para escrever seus projetos planejados, mesmo no nível mais básico. Seu raciocínio - "Eu quero que as pessoas conversem umas com as outras" - o que era irônico porque elas estavam em 5 diferentes fusos horários e 3 países. Escusado será dizer que houve muitos apontamentos sobre qual equipa iria ter que trabalhar muitas noites e fins-de-semana no final do projecto, uma vez que descobriram que todos pensavam que o outro era responsável por implementar algumas funcionalidades (ou reimplementá-las porque os designs do fornecedor e do consumidor simplesmente não se mesclaram).

Na verdade, tudo se resume a se o gerente de projeto e as partes interessadas querem fornecer um produto de alta qualidade. Se eles estiverem comprometidos em fazer isso, o Agile permitirá isso. OTOH, porque Agile coloca o cronograma de tomada de decisões apenas nas mãos do stakeholder e do gerente de projeto, o Agile torna difícil para uma equipe de desenvolvimento entregar um excelente projeto sem esse suporte. Resumindo: a responsabilidade pela qualidade do produto está quase exclusivamente nos pés do (s) gerente (s) de projeto.

TL; DR

Na verdade, o desenvolvimento ágil ajuda você a aumentar a qualidade do software, manter o cliente satisfeito e entregar um produto altamente valioso.

O desenvolvimento ágil foi introduzido por alguns profissionais inteligentes para resolver os problemas que muitos projetos de software enfrentam nos processos tradicionais.

Os valores-chave do desenvolvimento ágil, conforme definido pelo manifesto ágil (1) ,

• Indivíduos e interações sobre processos e ferramentas
• Software de trabalho sobre documentação abrangente
• Colaboração do cliente sobre negociação de contratos
• Respondendo a Mudar após seguir um plano

But do we (and the customer) really always know in advance what the must-be requirements are.

Esse é o ponto todo. Ao concentrar-se nos indivíduos, o cliente, o software em funcionamento e as mudanças no requisito de desenvolvimento ágil ajudam você a descobrir o que os clientes querem antes que o produto final seja entregue.

Essa é uma razão pela qual frameworks ágeis como o Scrum possuem ciclos de iteração curtos cujos resultados são produtos funcionais. Você já pode validar seu trabalho em um estágio inicial em relação às expectativas do cliente e ajustar as metas / requisitos sob demanda. Um desenvolvimento ágil ajuda você a ter certeza de que a qualidade deve ser de um produto.

Nos dias de hoje - ainda é verdade para hoje - muitos projetos de software desenvolvidos em abordagens tradicionais falharam, não tiveram sucesso ou causaram descontentamento a clientes porque a qualidade must-be não foi alcançada.

Além disso, o desenvolvimento ágil também ajuda você a alcançar Qualidade atrativa . Refletir o produto após cada iteração esclarece novos requisitos que não estavam preocupados com o cliente no início do projeto (qualidades atraentes). Isso mantém o cliente satisfeito.

Eu também gostaria de mencionar o Reverse Quality - atributos que levam à insatisfação - do modelo de Kano.

Em todos os projetos existem requisitos que parecem ser boas ideias no início do projeto. Depois de um tempo eles mudam para o lado oposto e causam desapontamentos.

Em um processo de desenvolvimento de software tradicional, você reconhecerá esses requisitos no produto final após uma execução longa do projeto. Tarde demais para evitar desapontamentos com os clientes e para mudá-los, é necessário um projeto de acompanhamento.

O desenvolvimento ágil ajuda você a identificar precocemente os requisitos que não funcionam ou que são insatisfatórios e a alterá-los durante o projeto.

Como eu disse, o desenvolvimento ágil ajuda você a aumentar a qualidade do software, manter o cliente satisfeito e entregar um produto altamente valioso.

Estou um pouco atrasado para essa festa, mas gostaria de compartilhar outro ângulo sobre esse assunto:

But how can they be applied to create delighting high quality software products and not just the bare minimum that barely fulfills the must-be requirements?

Há um aspecto temporal no desenvolvimento de software ágil que resulta da abordagem iterativa e considerando feedback do cliente , que são dois elementos importantes de a metodologia ágil. Exemplo: Recursos que são identificados como qualidade atrativa na iteração t podem se tornar qualidade must-be na próxima iteração t + 1.

A aplicação de métodos ágeis pode alterar dinamicamente a categoria de qualidade de um recurso. Se você comparar os recursos planejados da iteração t com os recursos acabados de alguma iteração posterior t + n, você experimentará exatamente o que você mencionou:

I have made the experience a few times that requirements which were given a high priority in the beginning, turned out to be much less important, if not useless, later.

Com esse aspecto temporal em mente, é plausível que os métodos ágeis possam produzir produtos de alta qualidade enquanto concentram-se em o mínimo . A abordagem iterativa emparelhada com o feedback do cliente altera as regras do jogo ao longo do tempo.

Conclusão

How to develop excellent software with agile methods?

Aplique uma abordagem iterativa e ouça o feedback do cliente . Livre-se de um desses elementos e você terá uma forma menos bem-sucedida de desenvolvimento de software ágil.

   > How to develop excellent software with agile methods?

• Ao produzir um software individual específico para o cliente:
  • encontre um cliente onde o custo não importa, porque o recurso "encantador" custa dinheiro extra e o cliente precisa decidir se deseja pagar por isso.
• Ao produzir Softwareproducts :
  As funcionalidades "deliciosas" são boas para atrair novos clientes e o custo para implementar uma funcionalidade "encantadora" não é tão importante se o produto for vendido mais de 1000 vezes.
• Em um ambiente em que "o suficiente (mais barato) é melhor", você não receberá o dinheiro para implementar recursos "deliciosos"

Em uma equipe Scrum, o Product Owner é responsável por escolher quais recursos implementar. Então cabe a ele (e até seu orçamento) definir um software "bom enought" ou "excelente"

Você levanta alguns pontos positivos. Mas não acredito que esses problemas estejam restritos a processos / metodologias ágeis.

Existem opiniões divergentes sobre o que é essencial e não essencial. Para usar o seu exemplo, alguém que compra um automóvel pode considerar a atenção como um recurso essencial e, portanto, considera que um Fiat não atende a esse requisito obrigatório. De forma mais realista, um produto de software pode precisar ter determinada funcionalidade para atender às necessidades de seus usuários finais reais ... mas também pode precisar ter outros recursos para ser vendido. Porque a pessoa que autoriza a compra frequentemente não é um usuário final.
Portanto, um recurso que é "não essencial" para o (s) usuário (s) final (is) pode ser essencial para vender o produto ... e, portanto, também essencial para a empresa que cria o produto.

Tudo isso se resume ao fato de que é crucial ter uma boa equipe de desenvolvimento de produto para definir requisitos e prioridades de forma adequada. Mas isso não é verdade apenas para lojas ágeis.

Também é importante ter o (s) proprietário (s) do produto que esteja autorizado (a) a tomar decisões. Se as decisões do proprietário do seu produto estiverem sendo constantemente anuladas por outra pessoa, eu seria o primeiro a concordar que isso é um problema, mas, novamente, não é um problema com o agile.

Há outras coisas que você quer no (s) proprietário (s) do seu produto ... uma descrição que ouvi é "C.R.A.C.K." (colaborativo, representante, autorizado, comprometido e conhecedor). Um proprietário de produto que não tem em nenhuma dessas áreas pode causar problemas para um projeto. Mas eu ouvi essa sigla pela primeira vez em um ambiente de cascata, então claramente a dor de clientes / donos de produtos ruins não está restrita a lojas ágeis.

O que a agilidade pode (ajudar) é trazer alguns desses problemas para a superfície.

Por exemplo, a literatura sobre o XP é bastante explícita sobre o fato de o "cliente" ser conhecedor, acessível à equipe e autorizado a tomar decisões. O termo "product owner" implica algum nível de conhecimento, compromisso e autoridade.

Se você se encontrar em uma situação em que a maior parte da funcionalidade entregue consiste em delatores em vez de recursos obrigatórios, é muito mais fácil levantar esse problema (e muito mais fácil determinar a causa) quando você está entregando trabalho ou próximo trabalhando software a cada 2-3 semanas do que quando as entregas são meses ou anos de intervalo.

Se você estiver trabalhando em pequenas iterações - e revisando o backlog com frequência (incluindo revisitando a priorização) - isso dará à equipe uma oportunidade de aprender com os erros anteriores. "Parece que isso é realmente importante agora, mas lembre-se da navegação dinâmica que nós tínhamos certeza de que precisávamos que não acabássemos usando?" Como outros apontaram, essas discussões são muito menos prováveis se tudo tiver sido planejado antecipadamente.

Por outro lado, a metodologia de design inicial pressupõe (por padrão) que a compreensão do produto e dos recursos é estática. Essa não tem sido minha experiência: ter algo tangível para trabalhar quase sempre muda a compreensão do problema por parte dos empresários. Daí a ênfase no feedback rápido. (A compreensão dos desenvolvedores também muda, mas isso não afetará as prioridades.)

Adiar parte do planejamento também permite que você responda às mudanças nas necessidades de negócios. "Você sabe que o site que você está construindo? Nós realmente precisamos que seja um aplicativo móvel, capaz de operação desconectada." Isso não é algo que foi perguntado especificamente ... mas você não gostaria que seu processo respondesse a mudanças no cenário de negócios (pelo menos em teoria)?

O Agile não diz "não crie recursos não essenciais". Ele diz "permitir que o negócio decida quais recursos (não) construir". ... e (igualmente importante) "permite que os técnicos lhe digam quanto tempo um recurso que você quer vai levar para construir".

1. Must-be qualities são muitas vezes difíceis de determinar. As pessoas as têm no subconsciente. As iterações ágeis e a participação do cliente ajudam a encontrar a maioria dos que devem ser. Esse é o poder da agilidade e é tolice ignorá-la .
2. One-dimensional qualities que significa promessas que devem ser cumpridas, são suportadas pela cachoeira OK, até que elas não estejam mudando. Aqui, ser ágil só ajuda, mas não tão poderosamente.
3. Attractive qualities são recursos legais. Eles podem se tornar must-be na próxima geração. Mas na geração atual eles nem estão no acordo - ou então seriam qualidades unidimensionais. Esses métodos ágeis que pressupõem a participação representativa do cliente apóiam muito bem essas qualidades. Para nós podemos mudar o escopo levemente durante o trabalho. Nós podemos negociar em melhoria um lugar para alguma compensação em outro. Na cachoeira é praticamente impossível. Sem um grande atraso organizacional, poderíamos apenas adicionar recursos gratuitamente. É possível, se algum tempo extra for previamente colocado no orçamento.

Assim, os processos ágeis podem suportar o modelo Kano, alguns deles o fazem muito e definitivamente muito melhor do que os melhores projetos em cascata.

Para fazer isso em sua compreensão, você deve definir processos ágeis com um participante representante do cliente responsável.