Durante más de un año, en MyStore, hemos estado creando funcionalidades que ayudan a nuestros usuarios a comprar y vender productos etiquetados. Las noticias sobre el etiquetado se han deslizado muchas veces en Habré, así que brevemente: desde 2019, los productos están marcados necesariamente. No todo a la vez, pero ahora debe etiquetar cigarrillos, zapatos, perfumes y neumáticos para automóviles. Al mismo tiempo, estamos trabajando en una situación de incertidumbre cuando la API de los sistemas gubernamentales cambia constantemente.
Por lo tanto, solo tenemos dos formas de integrarnos con las agencias gubernamentales: esperar hasta que todo se estabilice y perder el liderazgo del mercado o desarrollar un sistema en un mundo de requisitos cambiantes.
Elegimos el segundo, solo en el espíritu de metodologías flexibles. Creo que Agile realmente puede ayudar a resolver problemas aplicados. Y la vida en un mundo de demandas siempre cambiantes es el campo en el que puedes cambiar.
Mi nombre es Maxim Sukharenko, soy el jefe de equipo de la plataforma de servicio MySklad. Y hoy les diré cómo trabajamos con los requisitos cambiantes.
Del clásico al scrum
La fecha límite inicial para el desarrollo del sistema por parte de las autoridades reguladoras fue planeada para abril de 2019, pero lo comprende todo. Como resultado, los plazos se trasladaron a octubre. Y donde hay nuevos plazos, hay nuevos requisitos y nuevos formatos. No podíamos esperar a que se arreglara la API, entonces no tendríamos tiempo para implementar la integración. Por lo tanto, decidieron "dudar con la línea del partido".
Pensamos en el enfoque clásico que nos ofrece hacer un adaptador para un sistema externo. Compleméntelo con un enchufe con un interruptor y, de vez en cuando, levante la funcionalidad del enchufe y el adaptador al estado actual del sistema externo.
La lógica sugiere que para desarrollar un sistema con una interfaz en constante cambio, debe corregir los requisitos en algún momento. ¿Pero solo en qué? ¿Hasta que desarrollemos alguna parte de la funcionalidad?
Debe admitir que es desagradable dejar una funcionalidad inacabada en la que no pasan las pruebas, y también comenzar a romperla en una nueva. Puede corregir los requisitos para el período de desarrollo de características. Pero, ¿qué hacer con las grandes características que pueden vivir en desarrollo durante varios meses? Es simplemente imposible fijar requisitos para un período tan largo.
Entonces recurrimos a Scrum. Nos dice que al final del sprint, debemos proporcionar un producto que funcione con una nueva funcionalidad. Pero, ¿cómo lucha esto con la fijación de requisitos y grandes características? Hay un buen chiste sobre este tema:
"Doctor, cuando lo hago así, me duele".
"Y simplemente no lo haces así".
Quien no entiende, no hace grandes características . Puede corregir los requisitos durante una o dos semanas para que coincidan con el sprint y establecer la implementación de la funcionalidad de acuerdo con los requisitos para el sprint. Y la funcionalidad debe batirse en tales piezas para que encajen en uno o dos sprints. ¿Piensas demasiado complicado? Y luego! Simplemente no sabes cómo cortar los boletos. Vio, Shura, vio, son dorados.
Por supuesto, esto no es tan simple, tenemos que avanzar a propósito hacia esto: para dejar el desarrollo de "lo haremos durante seis meses, luego lanzaremos una nueva versión para la prueba".
El secreto es tener una versión estable al final de cada sprint . Por supuesto, puede parecer que esto aumentará el tiempo de desarrollo debido al aumento de los costos generales para la estabilización de la sucursal y que el desarrollo será subóptimo. Pero aquí la situación es casi la misma que con las pruebas, hablemos de ello a continuación.
Para combatir misiones
Y ahora para situaciones reales. Nuestra tarea era configurar el cifrado entre nuestro sistema y la API para que el usuario firme todas las solicitudes con una clave. Creo que muchos de ustedes se han encontrado con CryptoPro, así que tuvimos que hacerlo.
Si utiliza el enfoque estándar, se formará una tarea aislada: configurar la criptografía para el servicio. Lo colgaremos de una persona y durante un mes eliminaremos el estado y volveremos a enviar por qué no terminará de ninguna manera. Y el desarrollador se convertirá gradualmente en una criatura salvaje del otro mundo, con espuma en la boca y ojos salvajes.
Lo dividimos en pequeñas tareas y dispersas por todo el equipo. Comparo la criptografía con el alcohol: en compañía y en una dosis moderada, es mucho mejor que mucho y solo.
Como estamos desarrollando un servicio en la nube, nos fue más fácil usar el complemento del navegador CryptoPro EDS (esto no es publicidad, esto es desesperanza). Permite que CryptoPro CSP extienda claves y métodos de cifrado a una página web.
Primero, el usuario elige qué clave usará para trabajar con el servicio, luego se lleva a cabo la autenticación para obtener un token. Y solo entonces con la ayuda de cifrado y token se realizan llamadas API. Parece que todo es simple (no).
En primer lugar, hicimos MVP de forma aislada de nuestro servicio, para configurar la interacción del complemento con la API. ¿Sabes cuánta documentación hay sobre el complemento del navegador cryptoPro del fabricante? ¡Para nada! Solo ejemplos de ingeniería inversa, solo hardcore. Noches de insomnio e intentos de determinar en qué influyen estos u otros parámetros.
Y solo entonces pudimos intentar incorporarlo a nuestro ecosistema. Una persona trae la apariencia del componente prototipo a una visión humana, el segundo lo conecta con la lógica de negocios, el tercero escribe instrucciones para la posteridad para configurarlo. Cada tarea tiene un objetivo específico y está relativamente aislada de las demás. Y las personas tienen algo que discutir y con quién compartir el dolor.
Entonces la situación se ha vuelto bastante estable. En pequeñas iteraciones, agregamos nuevas funciones, de vez en cuando actualizamos la interfaz externa y difundimos los cambios en nuestro sistema. Pero surge la pregunta: ¿vivir en una rama separada hasta el final, o tratar de mantener constantemente pequeñas características en el maestro?
Prueba de funcionalidad
Propongo averiguar qué hacer con las pruebas y qué hacer si agregamos integración a un proyecto en vivo.
Comencemos con las pruebas. Para comenzar, determinaremos qué podemos llamar la funcionalidad probada. Propongo nombrar el funcional que pasó las pruebas de aceptación, incluidas las de regresión. Solo aceptaremos que no recurriremos al truco de vida "sin pruebas, eso significa que todo está probado". Necesitamos mantener nuestro código en el producto, y cuanto más cobertura de prueba, mejor. Cuanto mayor es el porcentaje de automatización de tales pruebas, más barata es cada iteración de prueba de la funcionalidad y con mayor frecuencia se puede hacer.
Tenemos un cierto conjunto de pruebas de aceptación y regresión, algunas de ellas automatizadas y otras realizadas a mano.
Si nos acercamos formalmente, deberíamos realizar pruebas después de cada cambio de código. Por ejemplo, dividieron su función en seis tickets y durante el proceso de prueba encontraron diez errores. Y deje que cada prueba tome cuatro horas: el automático no cuenta, pero el manual toma solo cuatro horas. Resulta que con la forma básica y formal de trabajar, pasaremos 64 horas.
Ahora intentemos probar no después de cada cambio de código, sino después de uno. La lógica sugiere que gastemos solo 32 horas. Y si realiza pruebas solo después de desarrollar la funcionalidad y después de corregir todos los defectos. Pero esto se establece que todos los defectos están aislados unos de otros, lo que en la vida no sucede.
En la vida, resulta que después del desarrollo de la funcionalidad, se realizan pruebas y se lleva a cabo la primera ola de errores. Luego se reparan los errores, se rompe la funcionalidad, se prueban con el error de error. Realizan una segunda prueba global y aparece una nueva ola de errores. Estos errores estaban ocultos y aparecieron cuando corrigieron la primera ola y cambiaron la funcionalidad. Y así varias veces.
Por lo general, obtienes de tres a cinco carreras completas de pruebas, dependiendo de la complejidad de la funcionalidad y la orientación de las manos. Pero el proceso se puede acelerar aún más, si superas las características pequeñas.
Por ejemplo, si divide una característica con la prueba a las cuatro horas en dos con la prueba a las tres horas y media y media, obtendrá cinco horas en lugar de cuatro. Parece que no hay ganancias. Pero se manifiesta en una disminución en la complejidad de la funcionalidad liberada y una disminución en la probabilidad de cadenas de defectos relacionados. Como resultado, las iteraciones de las pruebas completas se vuelven menos.
Agregar al proyecto
Ahora analizaremos la situación cuando realice una función en un proyecto en el que los desarrolladores todavía estén trabajando. Supongamos que usamos el concepto de código fuente de Branch Per Feature (Branch Per Ticket) relativamente estándar.
Obviamente, la cantidad de costo para mantener la relevancia del brunch es proporcional a su vida útil. Cuantas menos intersecciones de código en los tickets actuales, menos problemas hay en su fusión. Esto depende indirectamente de la vida útil: cuanto más tiempo haya pasado, mayores serán las posibilidades de que aparezcan tickets relacionados. En consecuencia, cuanto menos brunch vive, menos esfuerzo dedicamos a su relevancia.
Queda por comprender cómo implementar una funcionalidad parcialmente funcional en el producto. La respuesta es bastante simple: no debe ser accesible para el usuario. Si desea preguntar por qué debería hacer esto, puede devolver algunos párrafos anteriores.
Parece que mantener el código muerto en el asistente no es muy bueno. Así es, pero no está muerto. Puede hacer una página secreta con bolígrafos que incluirá dicha funcionalidad. O una secuencia especial de acciones que, como los huevos de Pascua en los juegos, lo llevarán a esta funcionalidad. Además, puede probarlo de inmediato.
Por supuesto, hay otras formas de lidiar con la variabilidad de los requisitos. Y este enfoque tiene sus limitaciones y condiciones de uso. Como saben, todavía no hay una bala de plata.