Hola Mi nombre es Dasha, estoy probando una aplicación móvil 2GIS en iOS. Quiero compartir nuestro proceso de realización de funciones, que ayuda no solo a ahorrar tiempo, sino también a mejorar mis habilidades personales. Lea el artículo para descubrir cómo logramos mantener los productos, los diseñadores y el desarrollo en el mismo contexto. Creemos que la revisión del primer ensamblaje de prueba por todas las personas interesadas realmente facilita la vida. Y la comunicación es la clave para administrar una función.
Nuestro dolor
Cuando me comunico con probadores de otras compañías, a menudo noto que probar sus características es de alguna manera desordenado, desestructurado. Debido a esto, se pierde tiempo, la fuerza de las personas involucradas en el desarrollo. La gente se enoja, comienza a odiar a sus colegas, los espera en los porches.
Anteriormente, también teníamos algo similar: cuando planificamos un sprint, una tarea voló, al comienzo del sprint se puso en desarrollo, ya resolvimos la tarea en el proceso. Si hubo preguntas sobre la interacción con otros equipos, nos dirigimos al producto. A menudo sucedía que en algunos equipos el trabajo ya estaba en su apogeo: todos esperaban el lanzamiento, alguien ya había soñado con la característica en la batalla; y en el otro equipo ni siquiera sabían sobre su existencia. Tal proceso fue ineficaz, pasó mucho tiempo / esfuerzo, trajo el caos.
Como resultado, se dieron cuenta de que era imposible vivir así y comenzaron a construir un nuevo proceso. Él ya ha ayudado a salvar los nervios de alguien, y posiblemente la vida.
Acerca del equipo
Nuestro equipo consta de: 9 desarrolladores, 6 probadores, un producto y un diseñador. Al planificar una iteración (lo que haremos durante los próximos 4 meses), se compilan características que desea lanzar en el período de tiempo actual. Cuando se compila la lista, se asigna una característica para cada característica del equipo desde el desarrollo y las pruebas, que será con características de principio a fin.
Para nosotros, aparece una persona que vive con características de TK para lanzar. Tiene información actualizada sobre lo que sucede con la función en su conjunto y sirve como punto de entrada para preguntas sobre cómo trabajar en funciones para personas de otros equipos. Puede obtener más información sobre las características al final del
informe de Sasha Kartavtsev . Recuerde este término, entonces se encontrará más de una vez.
Lanzamiento en 9 etapas
Todo el proceso de traer características a la versión se puede dividir en 9 etapas principales. Para mayor claridad, tomamos la función recientemente lanzada de las "Recompensas" y contamos cómo la llevamos a cabo en las nueve etapas.
Los premios son una recompensa para los usuarios por su contribución al producto. Los usuarios los obtienen para escribir reseñas, subir fotos y agregar nuevas empresas al directorio. Se pueden ver en la pestaña "My 2GIS".
Etapa 1: proceso de desarrollo de conocimientos tradicionales
Antes de comenzar a resolver las características, creamos una sala de chat en holgura y llamamos a todas las personas involucradas allí. Acordamos que en él discutiremos todos los problemas sobre características y eventos en la vida de los participantes del chat que pueden afectar el curso del lanzamiento. No es necesario decir que fui a tomar leche, pero necesito hablar sobre vacaciones / baja por enfermedad, de lo contrario, corre el riesgo de odiarse por no responder.
En primer lugar, las características del desarrollo y las pruebas analizaron TK / diseños, preguntas formuladas, mejoras propuestas, basadas en la experiencia de otras características. La función se supervisó para que las preguntas se respondieran en un día. Si se retrasaron los plazos, entonces estos mismos muchachos insinuaron a la gente responsable / producto que el tiempo está corriendo y que sería bueno responder ya.
El proceso de desarrollo de TK se considera completado cuando se cierran todos los problemas principales, hay diseños finales, el desarrollo no tiene preguntas sobre la implementación de características.
En la primera etapa, es muy bueno hacer un prototipo de una característica y usarla en el desarrollo de TK: ayudará a sentir la característica en el dispositivo e identificar imperfecciones en una etapa temprana, proponer casos para probar. Los productos podrán realizar cambios en la lógica incluso antes de que comience el desarrollo en la plataforma.
Etapa 2 - Elaboración de la lista de verificación
En el proceso de elaboración de los Términos de Referencia, I, como aparece para las pruebas, compilé casos de prueba para la función en TestRail, según los cuales la función se verificó posteriormente. Casos priorizados para su mayor automatización. Como hay un backend en la función, agregué un cheque al plan de prueba: qué campos enviamos, cuáles recibimos y qué sucederá si hay algunas tonterías incomprensibles aquí. Démosle la lista de verificación terminada al desarrollo y los productos para sincronizar las expectativas de la función, de modo que no ocurra que las pruebas piensen en una cosa, el producto espera otra y el desarrollador hizo otra cosa.
Etapa 3 - Desarrollo
Después del desarrollo de los Términos de Referencia, comenzó el desarrollo de la función. Las pruebas en ese momento cerraron / debatieron temas abiertos en el ToR y la sala de chat, informaron el desarrollo de todos los cambios, si aparecieron: nuevos requisitos, nuevos diseños, nuevos textos, cualquier otra cosa: el desarrollo debe ser consciente de todo, de lo contrario no hay forma de evitar una pelea.
Etapa 4: revisión del primer conjunto de características
Después de recibir el primer ensamblaje, lo lanzamos a un chat de características, donde solicitamos una revisión de los productos y diseñadores. Las pruebas controlaron que el ensamblaje fuera visto y recibiera retroalimentación: cuanto más rápido, mejor. Esto se hace en las primeras etapas, de modo que las situaciones desagradables posteriores no sucedan.
Un ejemplo de una situación desagradable.Te sientas en silencio por la noche en casa, no toques a nadie. Crees que todo está atrás, mañana la función irá a la batalla. Pero a la una de la mañana, un producto maligno irrumpe en su hogar (esto es real, porque ella vive tres pisos por encima de mí) o el diseñador (esto ya es menos real, vive lejos de mí, pero tiene un automóvil) con los requisitos para arreglar urgentemente la fuente / color / relleno, de lo contrario "¡no se libere! no puedes salir así ", y por la mañana la compañía de relaciones públicas ya estaba descrita, y eso es todo, todo está en el desagüe. Y ahora te sientas a las dos de la mañana, llama al desarrollador, comienza las entradas. En general, los comentarios recibidos a tiempo de las personas adecuadas son valiosos. Conseguirlo desde el principio no te permitirá apretar la liberación de este flanco.
Etapa 5 - Prueba de plataforma
Paralelamente a la revisión del primer ensamblaje, las pruebas comenzaron en la plataforma utilizando casos de prueba compilados anteriormente. Durante el proceso de prueba, si encuentra problemas que amenazan con interrumpir el lanzamiento, o se da cuenta de que algo se puede hacer mejor, agregarán funciones al chat o dejarán un comentario en los TOR. Nos aseguramos de que la pregunta no permaneciera abierta.
En la misma etapa, hubo cambios en la lógica de las características (UI, por ejemplo); también entregaron el ensamblaje al producto y al diseñador para su revisión para asegurarse de que las expectativas coincidieran con la realidad.
Etapa 6 - Pruebas de integración
Este elemento es necesario si otros equipos que no sean teléfonos móviles participan en el desarrollo de la función. Por ejemplo, teléfonos móviles + backend. Si reemplazamos la fuente o el color del icono, entonces, por supuesto, no se realiza ninguna integración. Sin embargo, en nuestro ejemplo con Rewards, hay un backend involucrado: la integración era indispensable.
Lo primero que debía hacer era atracar en Confluence. Como regla, al principio una persona hace esto.
El documento prescribe:
- fechas de realización;
- participantes - para que el equipo conozca a los héroes de vista y los héroes no puedan refutar este hecho;
- lista de cheques;
- lista de casos - verificación de escenarios con condiciones específicas.
Después de compilar un dock, lo lancé al chat de funciones y llamé a todos los participantes de la integración para que revisen / complementen los casos.
El día X, los participantes de la integración se reunieron en una oficina y verificaron todos los escenarios desde los muelles de integración. Es genial llevar a cabo integraciones conjuntas con el equipo de back-end: inmediatamente resuelve todos los problemas en el acto y aclara todas las rarezas.
Etapa 7 - Resumen de soporte
Antes del lanzamiento, informaron al soporte técnico que una característica se lanzará pronto, es hora de prepararse. Dali leyó TK, empuja la asamblea. Informaron qué chats escribir y a quién contactar si reciben comentarios de los usuarios.
Etapa 8 - Lanzamiento
Comenzamos a implementar la función, notificamos al chat al respecto y, en paralelo, vimos Crashlytics, comentarios en la tienda y soporte. Esperábamos lo mejor, bebimos valeriana. Todo salió bien con las Recompensas, pero estábamos listos para hacer una revisión inmediata e informar a todos en el chat de características si durante el lanzamiento se encontró un error crítico en el lado de la plataforma.
Etapa 9: compatibilidad con funciones después del lanzamiento
Después de que la función ingresó a la batalla, nuestro rol se volvió informativo: respondieron las preguntas entrantes, lo solicitaron, resolvieron algunos problemas de la plataforma o, si entendieron que el problema estaba en el backend, los pasaron. Después del lanzamiento, también vertí las cajas en el cheque de Recompensas en el almacenamiento de la caja principal en el recorrido de prueba para que pudieran reutilizarse en el futuro.
Y si brevemente
- Siempre mantenga a todos en el mismo contexto. Informar cambios importantes.
- Tan pronto como aparezca un conjunto con características, organice una revisión del primer conjunto por todas las partes interesadas.
- Si se producen cambios en la lógica de una característica en cualquier etapa, también organice una revisión.
- Obtén la respuesta: escribe, llama, patea, hasta que respondas.
- Prepare el soporte para una nueva característica y ayúdelo después del lanzamiento.
El conocimiento y la experiencia que obtuve en el proceso me ayudan tanto en el trabajo como en la vida. Bombeé comunicación, independencia, responsabilidad, me sumergí en el producto más allá del trabajo de nuestro equipo. El equipo, por cierto, también está contento: en el caso de un fakap, ahora bebe vino, no valeriana.