Veeam Indoor Kitchen: cómo funciona el proceso de I + D

La noche Otra entrevista de I + D está llegando a su fin, y nuestros entrevistadores están atentos a preguntas inesperadas de un futuro colega. Pero no hay sorpresas: la proporción deducida por Wilfredo Pareto también funciona aquí. En el 80% de los casos, escuchamos cuatro preguntas, aproximadamente el 20% del número total recibido. ¿Cómo se organiza su proceso? Que voy a hacer ¿Cómo convertirse en un líder senior / de equipo en un año? ¿Qué pasa con la reubicación en Europa?

En esta publicación, responderemos la primera pregunta y hablaremos sobre el proceso de desarrollo en Veeam: de equipo a equipo, esta respuesta es la que menos cambia.



Entonces el proceso. Esta es una secuencia repetible de acciones que conducen al éxito todos los días, o al menos a veces. Aprendiste a cocinar borsch y cada vez resulta igualmente sabroso: un proceso. El estacionamiento no es un golpe - dominado el proceso. El proceso le permite al cerebro no pensar en una rutina cada vez, convirtiéndola en un trabajo mecánico. El cerebro es liberado para la creatividad.

El proceso de desarrollo es una secuencia de acciones que convierten los deseos de los usuarios en productos tangibles. Estos deseos son formulados por analistas y gerentes de productos, implementados por desarrolladores, evaluados críticamente por probadores, descritos por escritores técnicos.

En Veeam estamos fabricando productos masivos para copias de seguridad y replicación de centros de datos, para que no se pierda nada. Un producto clásico en caja sin un cliente específico. A primera vista, la cosa es simple, pero hay matices, por lo que lo estamos haciendo durante la segunda década.

Actores

Cada lanzamiento es el resultado de varios grupos:

• Gerentes de producto o analistas . Priorizan su trabajo, comunicándose con el mundo exterior: clientes y socios. La asociación puede ser tecnológica. Por ejemplo, un distribuidor puede decir lo que le falta para aumentar las ventas, y el fabricante de un hipervisor puede informar sobre los planes para el futuro. Para este equipo, las "habilidades para hablar", la capacidad de captar y priorizar las tendencias en un tormentoso torrente de opiniones son importantes. Y luego defienda la posición elegida, diga no, explique por qué se hizo algo de esta manera, y no de otra manera. No importa en comunicados de prensa, en conferencias o en privado. Estas personas educan al mundo de las ventas.
  
• Soporte técnico Línea de ayuda para nuestros clientes. Los indicadores más importantes de un equipo son el tiempo de respuesta a un problema y su tiempo de resolución (SLA). Alrededor de unos pocos miles de llamadas son atendidas durante el mes. El equipo tiene varias capas, incluye grupos de interacción con los clientes y grupos de análisis de llamadas, desarrollo de soluciones alternativas, etc. Sobre la base de la información recibida por el soporte, se formula una lista de mejoras y urgencia, ya sea para implementar en una solución privada, la próxima actualización o posponer a la versión principal.
  
• Desarrolladores de I + D. Personas que materializan solicitudes en código.
  
• Probadores, o QA . Primeros probadores, un rango de prueba de tanque y un soporte de vibración al mismo tiempo. No solo verifican lo que ya se ha implementado, sino que también se conectan al trabajo en la etapa de concepción. Repitiendo las tareas de los administradores en una infraestructura cercana al combate, es más fácil entender cuán conveniente es la interfaz creada o los algoritmos seleccionados son productivos. Cuando el soporte técnico llega a la conclusión de que hay un defecto en el producto, el control de calidad reproduce los escenarios problemáticos y monitorea las soluciones.
  
• Equipo de escritores técnicos. Crean documentación para el usuario final, así como documentos específicos como "Cómo funciona" y "Guía de implementación". Obtienen material para el trabajo de desarrolladores, probadores y analistas.
  

Algunos equipos prefieren espacios abiertos, pero más a menudo - gabinetes

Los equipos están vinculados a través de un sistema de contabilidad de requisitos. Lo implementamos sobre la base del Sistema Microsoft Team Foundation, ya que históricamente lo usamos como un sistema de almacenamiento de la versión de origen. El sistema almacena requisitos (requisitos), defectos (errores) y llamadas a soporte (problemas), lo que requiere la participación de QA y desarrolladores. Cada problema involucra a cientos de participantes que trabajan en miles de tareas, requisitos y defectos. El sistema ayuda a mantener todo esto y, lo que es más importante, distribuir uniformemente la carga, priorizar a los desarrolladores.

Anillos de los árboles: ciclos de desarrollo

El desarrollo de nuestro producto es cíclico, cada ciclo termina con el lanzamiento de la próxima versión: lanzamiento. Esto es lo que se refleja en los lanzamientos:

• Tendencias de mercado duraderas . Por ejemplo, la virtualización y la aparición de infraestructuras en la nube. Cambiar los paradigmas del trabajo de TI lleva años: en este momento, los usuarios pasan de la sospecha y la negación ("qué demonios es esto") al reconocimiento masivo ("sí, todos lo hacen"). La virtualización de los centros de datos en un momento dio lugar a Veeam, ya que bajo condiciones de virtualización, los productos antiguos para respaldar máquinas eran ineficaces.
  
• Soporte para nuevas plataformas . Érase una vez, Veeam estaba destinado solo a centros de datos virtualizados basados ​​en la plataforma VMWare. Con el creciente número y tamaño de clientes, existe la necesidad de admitir nuevas plataformas. Además de VMWare, aparecieron otros hipervisores (Hyper-V), servidores físicos, plataformas en la nube (AWS, Azure), etc.
  
• Cambios tácticos en el mercado . Se lanzan las siguientes versiones de sistemas operativos e hipervisores. Se gana experiencia usando versiones anteriores de nuestro producto. Por ejemplo, así es como obtuvimos soporte a nivel de elemento: recuperación selectiva de servidores de aplicaciones populares como Microsoft Exchange, Microsoft SQL Server, bases de datos Oracle, etc.
  
• Defectos A pesar de todos nuestros esfuerzos, la vida es no-no, y presenta sorpresas. Por supuesto, tratamos de minimizarlos.
  

Cada trimestre recibimos actualizaciones (actualizaciones), aproximadamente una vez al año: lanzamientos principales (principales). Son buenos porque minimizan la sobrecarga de crear funcionalidades volumétricas relacionadas con el soporte de nuevas plataformas y paradigmas cambiantes. Según los detalles del presupuesto, los departamentos de TI de los clientes son más activos al final del año, por lo que también lanzamos grandes lanzamientos en este momento.

Las actualizaciones trimestrales tienen principalmente dos objetivos: soporte para nuevas versiones de servidores protegidos y solución de problemas. En las actualizaciones, recopilamos todas las correcciones de defectos descubiertos por los clientes desde el lanzamiento de la versión principal. Además, con la ayuda de actualizaciones, respondemos rápidamente a los cambios en las plataformas compatibles. Bajo los términos del SLA, Veeam debe agregar soporte para la nueva versión del hipervisor en no más de tres meses .
¿Y qué pasa si el producto no funciona para un cliente en particular? En este caso, emitimos una solución privada, en otras palabras, una muleta. Dichas correcciones se publican todas las semanas y no siempre están asociadas con defectos en el producto. Por ejemplo, la configuración de seguridad del cliente puede no ser compatible con el producto. Al emitir una solución privada, analizamos la frecuencia del problema y decidimos si incluir la solución en la próxima actualización trimestral.

Del amanecer al anochecer: crónica de lanzamiento

Cada ciclo de lanzamiento comienza con la planificación, a nivel de producto en su conjunto y a nivel de un solo requisito. En el primer caso, se resuelve el problema de las prioridades comerciales y la distribución de requisitos entre los equipos. En primer lugar, se discuten los requisitos o las epopeyas más urgentes. En el buen sentido, no más del 60% del volumen total de trabajo en el lanzamiento debe asignarse a la epopeya, para que haya un colchón de tiempo. La planificación del producto se lleva a cabo a nivel de jefes de departamento: productos, probadores, desarrolladores.

Los desarrolladores y evaluadores se dividen en equipos. El número óptimo de personas en un equipo es cinco. Los equipos son funcionales y universales. En el último caso, el equipo es autosuficiente, contiene desarrolladores con experiencia en varias áreas. Los comandos funcionales se centran más estrechamente: funcionan en la interfaz de usuario, los componentes del sistema, etc. Las personas de diferentes equipos funcionales forman equipos virtuales que comienzan a implementar requisitos. Al menos los representantes del grupo PM, los equipos de desarrollo y prueba se reúnen aquí. Al líder del equipo se le asigna el líder del equipo de uno de los equipos funcionales.

El trabajo comienza en el requisito. El equipo virtual se reúne semanalmente. Los participantes hablan sobre los éxitos durante la semana pasada y planean trabajar para la próxima.
El líder del equipo responsable de la moderación modera las reuniones y registra los resultados. También resuelve problemas que no se pueden resolver dentro de un equipo virtual. Por ejemplo, si necesita mover fechas o posponer parte de las tareas.

Dentro del desarrollo funcional o de los equipos de prueba, los puntos de control están más espaciados. Como regla general, un plan semanal se divide en tareas que no duran más de dos o tres días. Algunos equipos han echado raíces en la práctica de scrum con volátiles diarios; en algún lugar, la interacción punto a punto entre el líder del equipo y el equipo está trabajando de manera más eficiente.


Sala de reuniones típica para discutir el estado actual del proyecto.

Todo el desarrollo se divide en iteraciones semanales o quincenales. Durante las primeras iteraciones, debe crear una funcionalidad mínimamente funcional que posteriormente se convierta en carne, por ejemplo, una interfaz de usuario avanzada, API para clientes, etc. Y lo más importante, la presencia de un esqueleto ya permite a los evaluadores obtener una función.

El ciclo de lanzamiento incluye versiones alfa y beta. Con su ayuda, mostramos nuevas características al mundo exterior y recopilamos comentarios por adelantado. Si es necesario, se cambian las decisiones sobre arquitectura o funcionalidad. Los escenarios se llevan al estado de alfa y beta no de forma inmediata, sino en lotes. Como regla, hay aproximadamente dos beta en el ciclo de lanzamiento.

Después de la etapa beta, los equipos entran en modo de prueba de regresión. En esta etapa, el producto, en su conjunto, ya está funcionando, la interfaz de usuario y los scripts ya se han endurecido y cambian con menos intensidad. Entra en juego un equipo de escritores técnicos. Al mismo tiempo, se están formando equipos de soporte técnico.

Las pruebas de regresión se realizan en ciclos de dos semanas. El tiempo del ciclo está determinado por el tiempo requerido para ver todos los escenarios de productos. Cuanto más grande es el producto, más escenarios y, en consecuencia, ciclos. Se declara un bloque de código antes del último bucle. Esto significa que solo se realizarán cambios críticos en el producto, y solo después de numerosas revisiones de código. Dichos métodos draconianos son necesarios para no introducir accidentalmente nuevos defectos en el producto.

Cuanto más se acerca el momento del lanzamiento, más tiempo libre tienen los desarrolladores y menos todos los demás. Los gerentes de producto necesitan preparar comunicados de prensa, coordinar el trabajo de los servicios de marketing. Los probadores deben verificar las soluciones y realizar la prueba de regresión final. Los escritores técnicos están agregando documentación de usuario. En este momento favorable, los desarrolladores están desarrollando actividades de investigación para los requisitos de la próxima versión.

Y aquí es un momento emocionante, llamado RTM - Ready To Market. Esto significa que el producto ya está listo para su distribución a los consumidores. Dentro de dos semanas, será atormentado por periodistas, proveedores de servicios. Se mostrará en las presentaciones. Dos semanas después, el producto estará disponible para todos. En este momento, también se producen cambios internos: se están preparando nuevas ramas de desarrollo, se está depositando el código. Y, por supuesto, la infraestructura de compilación para la próxima versión aumenta. Después del lanzamiento público (GA), es un momento difícil para el soporte técnico. Y el resto ya está trabajando en la próxima versión.

Sobre las prioridades

Y finalmente, un poco de hardware. Como sabe, en la trinidad de "rápido, de alta calidad y económico" puede elegir un máximo de dos opciones. La calidad, el tiempo y la funcionalidad luchan constantemente entre ellos. En nuestro producto en caja, la calidad es lo primero. Hmm, pero ¿cuál es un área donde la calidad no importa? Por supuesto que no. Toda la cuestión es la definición de calidad.
Para nosotros, la calidad es:

• Preservación de la fiabilidad y el rendimiento en las configuraciones del zoológico . Un cliente tiene un modesto centro de datos de dos servidores desde el momento de la Batalla de Borodino, mientras que el otro tiene una infraestructura de alta gama en un hangar cercano con Amazon. El producto debería funcionar adecuadamente en ambos casos.
  
• Facilidad de uso . El usuario debe tener un mínimo de esfuerzo y, ciertamente, hacer frente sin ninguna instrucción. Pero la simplicidad similar está lejos de estar siempre oculta detrás de la simplicidad externa: intente cruzar sin problemas con un erizo.
  
• Herencia Las inversiones en las empresas son a largo plazo, y los CFO no se gastarán en TI sin una buena razón. Por lo tanto, debe mantener la compatibilidad con las versiones anteriores y los productos relacionados. A menudo, durante la reconstrucción de los centros de datos, los servidores de correo electrónico de la era de los 80 están tapiados en la pared. Y todos zumban y no piensan morir.
  

Con este conjunto de prioridades para preservar la calidad, siempre debe combinar algo, tanto para desarrolladores como para evaluadores. Pequeños cambios en el comportamiento de las funciones pueden llevar a pruebas de integración forzadas de la mayor parte del producto. Intente agregar soporte regional asiático al producto y entienda de qué se trata. Por lo tanto, el tema de las prioridades es una cuestión de discusión conjunta de los PM, evaluadores y desarrolladores.

La segunda prioridad, casi indestructible, es el tiempo. En el caso de actualizaciones, las fechas de lanzamiento son establecidas por el SLA, en el caso de lanzamientos grandes, por el calendario comercial. Según las estadísticas, en cada ciclo de lanzamiento, casi el 50% del tiempo se dedica al desarrollo, el 50% a recordar el producto (etapa de corrección de errores).

Lo que puede cambiar es la funcionalidad de la próxima versión. Una lista priorizada de requisitos, o trabajo atrasado, ayuda aquí. Teóricamente, todo es simple: elija la siguiente función de prioridad de la cartera de pedidos, mire el tiempo restante. Cuando el tiempo esté cerca del final, deténgase y lance la próxima versión del producto. El diablo está escondido en los matices:

• Incertidumbre de los requisitos . Por ejemplo, el requisito "para admitir copias de seguridad de máquinas físicas en el sistema operativo Linux" se puede refinar aún más. ¿Qué núcleos deberían ser compatibles? ¿Qué distribuciones? ¿Qué sistemas de archivos? Se puede implementar uno y el mismo requisito de alto nivel en un mes o un año. La pregunta está completa.
  
• Los equipos tienen especializaciones . No todos los requisitos pueden ser asumidos por ningún equipo. El desarrollador de C # no escribirá controladores; el desarrollador de componentes del sistema no siempre se encargará del desarrollo web.
  
• Los requisitos dependen unos de otros . Esto no siempre es visible a nivel de escenarios de usuario, pero existen tales relaciones dentro. Desde el punto de vista del mundo exterior, el soporte de respaldo de los sistemas de archivos NTFS y ExtFS puede ser un requisito con diferentes prioridades, pero dentro tendrá que escribir primero un motor común.
  
• Los requisitos se dividen en diferidos y no diferibles . Si el mercado está esperando en la próxima versión alguna función, y se anunció, entonces no funcionará posponerla.
  
• Parte de los requisitos implica investigación . Sin los resultados de la investigación, es imposible planificar la complejidad de la tarea (tal vez sea imposible en absoluto), y puede ser difícil predecir estos resultados.
  

Aquí es donde entra en juego el desarrollo ágil. Para nosotros, el desarrollo ágil significa la necesidad de una reurbanización periódica. Se conocieron nuevas circunstancias: planes cambiados. Se agregaron nuevos requisitos de prioridad a la cartera de pedidos: se cambiaron los planes. No tenemos tiempo con requisitos no demorados: cortamos parte de las tareas o cambiamos los requisitos. En la teoría del control técnico, esto se llama un sistema de retroalimentación. Recuerda cómo funciona el piloto automático.

Cualquier planificación en las condiciones anteriores se basa en el juicio de expertos. Una evaluación experta del líder del equipo es el elemento que hace que todo el proceso posterior sea claro y estructurado. Otro nombre para la evaluación experta es "el método de estrabismo leninista", como le gusta repetir a Alexander Orlov de Stratoplan. Esto es cuando tomas una decisión basada en la experiencia previa y la intuición. A pesar de las posibles críticas, esto funciona. Funciona como todos nuestros procesos descritos anteriormente. Si aún tiene preguntas sobre ellos, lo invitamos a comentar.

Que sigue

La tecnología de proceso actual es cómoda y acogedora como las zapatillas de casa. El único problema es que en Veeam algún punzón invisible siempre te impulsa: más rápido, más, más, más.
Más recientemente, se construyeron oficinas piloto en Finlandia y la República Checa, y este año nos estamos preparando para la gran inauguración del centro de I + D de Praga para varios cientos de personas.


El vestíbulo de nuestra oficina de Praga.

Recientemente ha aparecido una oficina de desarrollo en Israel; los equipos en Canadá y Alemania están creciendo. El número de proyectos de desarrollo conjunto con HP, NetApp, Nutanix, EMC está aumentando.
La fábrica se convierte en un transportador geográficamente distribuido y, al mismo tiempo, se cristalizan nuevos procesos. Sin embargo, este es un tema para un artículo separado.
Mantente conectado