Me di cuenta que trabajar con cualquier cliente es muy similar a una aplicación web. El artículo muestra cómo puede usar este conocimiento para mejorar los procesos.
Sobre quién es el controlador y quién es el modelo bajo el corte.
Este artículo supone que el lector sabe qué es MVC .
Cuando construyo un modelo, voy a simplificaciones deliberadas.
- Todos los participantes en la relación son personas responsables y quieren lograr un único resultado.
- Considere un desarrollo personalizado típico.
Actores
Cliente : una persona que ordena un producto o proyecto. Puede ser tanto externo como interno.
Empresa (contratista) : parte de la relación contractual con el Cliente.
Gerente : una persona que interactúa con el Cliente y el ejecutor final (programador). Acepta tareas del Cliente como entrada, traduce estas tareas al Contratista y devuelve el resultado al Cliente.
El ejecutor final es un programador que implementa la tarea. Idealmente, solo se comunica con el gerente.
El proceso
El proceso de desarrollo personalizado se ve así:
- El cliente establece la tarea para la empresa.
- La compañía, actuando como un enrutador, lleva la tarea al gerente.
- El gerente aclara los detalles con el cliente.
- El gerente establece la tarea para el programador.
- El programador realiza la tarea y transfiere la tarea completada.
- El gerente identifica las deficiencias y vuelve al paso 4.
- Si no hay deficiencias, el Administrador transfiere la tarea al Cliente.
- El cliente identifica deficiencias y vuelve al párrafo 3.
- Si no hay defectos, el Cliente paga por el trabajo.
El punto más dulce para la Compañía es el párrafo 9. Pero el camino hacia él suele ser largo y espinoso.
Problema de tal proceso
A primera vista, todo en este proceso es correcto y no hay nada que mejorar. Sin embargo, esto no es así. Destacamos los problemas.
Un administrador muy malo es solo un enrutador de tareas. Espero que tengas suerte y no trabajes con tal gerentes enrutadores Tuve suerte Cuando se trabaja con un gerente real, también hay problemas.
El gerente establece la tarea al programador diciéndola en su voz o en una sala de chat. Las aclaraciones sobre el problema no se registran en ningún lado. El programador pareció entender la declaración del problema. Pero, por supuesto, lo entendí a mi manera, y no como lo explicó el gerente (desde el punto de vista del gerente). Como el enunciado del problema no es fijo, cada uno de los participantes lo interpreta a su manera.
Con este enfoque, aparecen muchas iteraciones 4-6 y 3-8. Un buen administrador se distingue de un mal administrador por la relación entre el número de estas iteraciones. Un buen gerente tiene un número unitario de intentos de entregar una tarea a un cliente. Y el intento, lo adivinó, fue inmediatamente exitoso. Al mismo tiempo, las iteraciones pueden ser mucho trabajo con el programador. El enrutador no verifica dos veces nada para el programador y simplemente pasa la tarea al cliente. Y el número de iteraciones 3-8 alcanza sus valores máximos y es igual al número de iteraciones 4-6. Y, por supuesto, el programador tiene la culpa de todo, porque desde el punto de vista del gerente hizo un mal trabajo.
Una gran cantidad de comunicaciones entre el Gerente y el Programador en el proceso de pasar la tarea conduce a un aumento de lo negativo entre ellos. Además, se interrumpen los plazos para completar la tarea, los excesos de costos, etc. Al mismo tiempo, no me importan las comunicaciones durante la especificación de requisitos y en la etapa de configuración de la tarea.
¿Qué hacer para evitar tales fenómenos indeseables?
Asociaciones
Veamos un esquema simplificado de trabajo con el Cliente:
Un desarrollador experimentado verá una coincidencia completa con MVC:
Es muy sencillo realizar una comparación de entidades.
- Cliente = Usuario
- Gerente = Controlador
- Artista = Modelo
- Resultado de trabajo = Ver
- Empresa = Aplicación completa
¿Solo una coincidencia? No lo creo Si los esquemas de interacción coinciden, puede intentar aplicar los enfoques que utilizamos en el desarrollo al proceso de gestión del desarrollo personalizado.
Primeros pasos para arreglar
¿Qué herramientas tenemos cuando estamos desarrollando?
Definimos capas de aplicación. Definimos los contratos de interacción entre las capas y dividimos la aplicación en módulos. Intentemos aplicar estas herramientas aquí.
Capas
El programador en su rol habitual no se comunica con el cliente. Puede participar en la etapa de especificación de requisitos como experto. En otros casos, solo el gerente se comunica con el cliente, aislando así la capa del modelo del impacto directo del cliente.
En el proceso de pasar la tarea al Cliente, el programador que realizó la tarea no debe participar. Nunca Nunca en absoluto.
Descomposición
Las grandes tareas deben dividirse en pequeñas. Una tarea pequeña es una tarea por un máximo de un par de días.
TK
Todos conocen la expresión: sin un claro TK, el resultado de HZ.
Al aclarar los requisitos, debe surgir un artefacto como los Términos de referencia con el Cliente. Luego la declaración del problema al programador enriquecido complementado por TK. Por ahora, aceptaremos esto como un contrato no solo entre la Compañía y el Cliente, sino también entre el gerente y el programador.
En cualquier empresa normal, los conocimientos tradicionales son un elemento indispensable para la tarea. Es cierto que esto solo se aplica a tareas grandes.
Parece que TK es bastante similar a un contrato en el contexto de la programación. Lo que veo problemas con los conocimientos tradicionales:
- Para una tarea grande, habrá un TK de páginas de 400 o más, que el programador no encajará completamente en su cabeza. Estoy empezando a quedarme dormido en la página diez.
- Para una tarea promedio, habrá un enlace a una sección o párrafo en los TdR. Entonces el programador solo leerá este elemento. Entonces, por supuesto, resulta que un pequeño punto en otra sección de los TOR cambia drásticamente toda la implementación
- Para una tarea pequeña que es parte del soporte, TK no lo será en absoluto.
- Los conocimientos tradicionales no siempre son interpretados claramente por las partes en el proceso de desarrollo. Y todo lo que pueda ser mal entendido será exactamente incorrecto e incomprendido.
Se puede ver aquí que TK claramente no es suficiente. La pregunta es qué hacer.
Criterios de aceptación.
En la práctica del desarrollo, las pruebas ocupan un lugar destacado. Las pruebas han demostrado su necesidad de un desarrollo de calidad.
¿Podemos aplicar pruebas en nuestra práctica? Sí, por lo que estamos probando todo e incluso en la descripción del proceso que es, dirá un lector atento. Si pero no. Estoy hablando un poco sobre otras pruebas.
La prueba en el proceso descrito anteriormente consiste en verificar manualmente el cumplimiento del resultado con los conocimientos tradicionales entregados. Cada participante de tales pruebas, habiéndose familiarizado con TK, de alguna manera lo interpreta en su propia imagen. El problema es que todos tienen una imagen diferente. El hombre es un intérprete imperfecto. Necesita compilar los conocimientos tradicionales en el binario una vez. No interpretes muchas veces y de diferentes maneras. Y una vez en el "papel". Como resultado, debe aparecer un cierto conjunto de artefactos. Estos pueden ser casos de prueba o criterios de aceptación.
Los criterios de aceptación deben ser desarrollados por el gerente junto con el cliente. Los criterios de aceptación no contradicen los conocimientos tradicionales, sino que solo lo explican. Los criterios de aceptación pueden o deben convertirse en un documento separado, firmado por el Cliente y la Compañía. Luego, el cliente aceptará la tarea de acuerdo con los mismos criterios de aceptación.
Con criterios de aceptación correctamente formulados, el Programador no puede tener ninguna discrepancia en TK e incluso dudar de qué debe hacer exactamente.
Para una tarea pequeña, puede que no haya TK, pero los criterios de aceptación deben estar presentes. Los criterios de aceptación son similares a las pruebas escritas antes de la implementación. ¿Esto te recuerda algo?
Para describir los criterios de aceptación, puede usar el lenguaje Gherkin que ofrece BDD . Para facilitar el inicio, puede describirlos en el idioma ruso habitual.
Objeciones
Preveo una pregunta de los gerentes:
El desarrollo de criterios de aceptación lleva tiempo extra. ¿Dónde conseguirlo?
Sin tomarse el tiempo para desarrollar criterios de aceptación, está extendiendo estos costos en todas las etapas. Y mucha gente pasa tiempo: gerente, programador, probador, cliente.
Pero aún desarrolla criterios de aceptación. Y más de una vez. En la preparación de los términos de referencia, surgen algunos criterios de aceptación en la cabeza del analista y el cliente. Al establecer el problema, sucede lo mismo. El programador les da forma en su cabeza. En el momento de la entrega de la tarea en cualquier etapa, se realiza el mismo proceso. Pero en ningún momento apareció ningún artefacto. Esa es toda la diferencia.
Si hay criterios de aceptación, el número de iteraciones antes de la aceptación de la tarea por parte del cliente se reduce significativamente. El número de comunicaciones negativas se reduce naturalmente. En consecuencia, se mejoran las relaciones con el Cliente, a lo que la Compañía pasa la tarea la primera vez.
Me atrevo a asegurarle que el desarrollo de criterios de aceptación vale la pena.
Resultado
¿Cómo cambia el proceso después de la introducción de los criterios de aceptación junto con los conocimientos tradicionales?
El programador hace su trabajo de acuerdo con los criterios de aceptación. El gerente toma el trabajo. Entonces el cliente hace lo mismo. Y no tiene ninguna razón para no pagar por esta tarea.
¿Funcionará siempre sin problemas técnicos? Supongo que no. Primero, habrá problemas con el desarrollo, la formulación de criterios de aceptación y su acuerdo con el Cliente. Y esto provocará repetidas iteraciones con el Programador y el Cliente. Pero su número se minimiza.
¿Qué opinas sobre esto?