Eu notei. que trabalhar com qualquer cliente é muito semelhante a um aplicativo da web. O artigo mostra como você pode usar esse conhecimento para melhorar processos.
Sobre quem é o controlador e quem é o modelo sob o corte.
Este artigo pressupõe que o leitor saiba o que é MVC .
Ao construir um modelo, vou para simplificações deliberadas.
- Todos os participantes do relacionamento são pessoas responsáveis e desejam alcançar um único resultado.
- Considere um desenvolvimento personalizado típico.
Atores
Cliente - uma pessoa que solicita um produto ou projeto. Pode ser externo e interno.
Empresa (contratada) - parte no relacionamento contratual com o Cliente.
Gerente - uma pessoa que interage com o Cliente e o executor final (programador). Ele aceita tarefas do Cliente como uma entrada, converte essas tarefas no Empreiteiro e retorna o resultado ao Cliente.
O executor final é um programador que implementa a tarefa. Idealmente, apenas se comunica com o gerente.
O processo
O processo de desenvolvimento personalizado é mais ou menos assim:
- O cliente define a tarefa para a empresa.
- A empresa, atuando como roteador, leva a tarefa ao gerente.
- O gerente esclarece os detalhes com o cliente.
- O gerente define a tarefa para o programador.
- O programador executa a tarefa e transfere a tarefa concluída.
- O gerente identifica deficiências e retorna à etapa 4.
- Se não houver falhas, o gerente transferirá a tarefa para o cliente.
- O cliente identifica deficiências e retorna ao parágrafo 3.
- Se não houver falhas, o Cliente pagará pelo trabalho.
O ponto mais agradável para a Companhia é o parágrafo 9. Mas o caminho para isso é geralmente longo e espinhoso.
Problema de tal processo
À primeira vista, tudo nesse processo está correto e não há nada a melhorar. No entanto, isso não é verdade. Destacamos os problemas.
Um gerente muito ruim é apenas um roteador de tarefas. Espero que você tenha sorte e não trabalhe com tais gerentes roteadores. Eu tive sorte. Ao trabalhar com um gerente real, também existem problemas.
O gerente define a tarefa para o programador falando em sua voz ou em uma sala de bate-papo. Os esclarecimentos sobre o problema não são registrados em nenhum lugar. O programador pareceu entender a afirmação do problema. Mas é claro que eu entendi do meu jeito, e não como o gerente explicou (do ponto de vista do gerente). Como a declaração do problema não foi corrigida, cada um dos participantes a interpreta à sua maneira.
Com essa abordagem, muitas iterações 4-6 e 3-8 aparecem. Um bom gerente se diferencia de um gerente ruim pela razão entre o número dessas iterações. Um bom gerente tem um número unitário de tentativas para entregar uma tarefa a um cliente. E a tentativa, você adivinhou, foi imediatamente bem-sucedida. Ao mesmo tempo, as iterações podem ser muito trabalhosas com o programador. O roteador não verifica nada para o programador e simplesmente passa a tarefa ao cliente. E o número de iterações 3-8 atinge seus valores máximos e é igual ao número de iterações 4-6. E, é claro, o programador é o responsável por tudo, porque, do ponto de vista do gerente, ele fez um mau trabalho.
Um grande número de comunicações entre o Gerente e o Programador no processo de aprovação da tarefa leva a um aumento do negativo entre eles. Além disso, os prazos para a conclusão da tarefa, os custos excedentes e assim por diante são interrompidos. Ao mesmo tempo, não me importo com as comunicações durante a especificação de requisitos e no estágio de definição da tarefa.
O que fazer para evitar esses fenômenos indesejáveis?
Associações
Vejamos um esquema simplificado de trabalho com o Cliente:
Um desenvolvedor experiente verá uma correspondência completa com o MVC:
É muito simples realizar uma comparação de entidades.
- Cliente = Usuário
- Manager = Controller
- Artista = Modelo
- Resultado do Trabalho = Visualizar
- Empresa = Aplicativo inteiro
Apenas uma coincidência? Eu acho que não. Se os esquemas de interação coincidirem, você poderá tentar aplicar as abordagens que usamos no desenvolvimento ao processo de gerenciamento do desenvolvimento personalizado.
Primeiros passos para corrigir
Quais ferramentas temos quando estamos desenvolvendo?
Definimos camadas de aplicação. Definimos os contratos de interação entre as camadas e dividimos o aplicativo em módulos. Vamos tentar aplicar essas ferramentas aqui.
Camadas
O programador em sua função usual não se comunica com o cliente. Ele pode estar envolvido no estágio de especificação de requisitos como especialista. Em outros casos, apenas o gerente se comunica com o cliente, isolando a camada do modelo do impacto direto do cliente.
No processo de passar a tarefa para o Cliente, o programador que executou a tarefa não deve estar envolvido. Nunca. Nunca mesmo.
Decomposição
Grandes tarefas precisam ser divididas em pequenas. Uma tarefa pequena é uma tarefa por no máximo dois dias.
TK
Todo mundo conhece a expressão: sem um TK claro - o resultado do HZ.
Ao esclarecer os requisitos, um artefato como os Termos de Referência deve surgir com o Cliente. Em seguida, a declaração do problema para o programador enriquecido complementado por TK. Por enquanto, aceitaremos isso como um contrato, não apenas entre a Empresa e o Cliente, mas também entre o gerente e o programador.
Em qualquer empresa normal, a TK é um elemento indispensável à tarefa. Verdade, isso se aplica apenas a grandes tarefas.
Parece que o TK é bastante semelhante a um contrato no contexto da programação. O que vejo problemas com o TK:
- Para uma tarefa grande, haverá TK de páginas de 400 ou mais, que o programador não caberá inteiramente em sua cabeça. Estou começando a adormecer na página dez.
- Para uma tarefa média, haverá um link para uma seção ou parágrafo no ToR. Em seguida, o programador lerá apenas este item. Então, é claro que acontece que um pequeno ponto em outra seção do TOR altera drasticamente toda a implementação
- Para uma pequena tarefa que faz parte do suporte, o TK não será de todo.
- Nem sempre a TK é claramente interpretada pelas partes no processo de desenvolvimento. E tudo o que pode ser mal interpretado será exatamente errado e mal compreendido.
Pode-se ver aqui que o TK claramente não é suficiente. A questão é o que fazer?
Critérios de aceitação
Na prática de desenvolvimento, o teste ocupa um lugar de destaque. Os testes provaram sua necessidade de desenvolvimento de qualidade.
Podemos aplicar testes em nossa prática? Sim, e por isso estamos testando tudo e, mesmo na descrição do processo, um leitor atento dirá. Sim mas não Estou falando um pouco sobre outros testes.
O teste no processo descrito acima consiste em verificar manualmente a conformidade do resultado com o TK entregue. Cada participante desse teste, familiarizado com o TK, de alguma forma o interpreta em sua própria imagem. O problema é que todo mundo tem uma imagem diferente. O homem é um intérprete imperfeito. Você precisa compilar o TK no binário uma vez. Não interprete muitas vezes e de maneiras diferentes. E uma vez no "papel". Como resultado, um determinado conjunto de artefatos deve aparecer. Podem ser casos de teste ou critérios de aceitação.
Os critérios de aceitação devem ser desenvolvidos pelo gerente em conjunto com o cliente. Os critérios de aceitação não contradizem o TK, mas apenas o explicam. Os critérios de aceitação podem ou devem se tornar um documento separado, assinado pelo Cliente e pela Empresa. Em seguida, o cliente aceitará a tarefa de acordo com os mesmos critérios de aceitação.
Com critérios de aceitação formulados corretamente, o Programador não pode ter discrepâncias no TdR e até mesmo duvidar do que exatamente ele deve fazer.
Para uma tarefa pequena, pode não haver TK, mas os critérios de aceitação devem estar presentes. Os critérios de aceitação são semelhantes aos testes escritos antes da implementação. Isso lembra alguma coisa?
Para descrever os critérios de aceitação, você pode usar a linguagem Gherkin que o BDD oferece. Para facilitar o início, você pode descrevê-los no idioma russo habitual.
Objeções
Prevejo uma pergunta dos gerentes:
O desenvolvimento de critérios de aceitação leva mais tempo. Onde conseguir?
Sem dedicar tempo para desenvolver critérios de aceitação, você está distribuindo esses custos em todas as etapas. E muitas pessoas gastam tempo: gerente, programador, testador, cliente.
Mas você ainda desenvolve critérios de aceitação. E mais de uma vez. Na preparação do ToR, alguns critérios de aceitação surgem na cabeça do analista e do cliente. Ao definir o problema, acontece o mesmo. O programador os molda em sua cabeça. No momento da entrega da tarefa em qualquer estágio, o mesmo processo é executado. Mas em nenhum momento nenhum artefato apareceu. Essa é toda a diferença.
Se houver critérios de aceitação, o número de iterações antes da aceitação da tarefa pelo cliente é reduzido significativamente. O número de comunicações negativas é naturalmente reduzido. Da mesma forma, as relações com o Cliente são aprimoradas, para as quais a Empresa passa a tarefa pela primeira vez.
Atrevo-me a garantir que o desenvolvimento de critérios de aceitação compensa generosamente.
Resultado
Como o processo muda após a introdução dos critérios de aceitação junto com o TK?
O programador faz seu trabalho de acordo com os critérios de aceitação. O gerente aceita o trabalho. Então o cliente faz o mesmo. E ele não tem motivos para não pagar por essa tarefa.
Funcionará sempre sem falhas? Acho que não. Primeiro, haverá problemas com o desenvolvimento, a formulação de critérios de aceitação e seu acordo com o Cliente. E isso causará repetidas iterações com o Programador e o Cliente. Mas seu número é minimizado.
O que você acha disso?