Este artículo fue publicado originalmente en Medium. Visita la página de Medio de Karim aquí.
En Qumulo, construimos un sistema de archivos distribuidos altamente escalable. Ese sistema es predominantemente escrito en C y consta de varios millones de líneas de código escritas por un equipo de desarrollo de software. Es un sistema altamente complejo y de misión crítica. Los sistemas de almacenamiento empresarial, similares a la infraestructura de red, deben estar disponibles todo el tiempo y no pueden funcionar mal. Nuestros clientes suelen ser empresas con una disponibilidad extremadamente alta y requisitos de rendimiento.
Elegimos construir este sistema adhiriéndonos a algunos principios: Lanzamos nuestro software cada dos semanas. Seguimos una metodología de desarrollo de software ágil. Hacemos TDD, pruebas unitarias y somos maníacos con la calidad. Trabajamos en equipos autodirigidos y autónomos.
¿Interesado en hacer orden del caos? Echa un vistazo a las posiciones abiertas en Qumulo.
Es el último punto que quiero dedicar un tiempo a describir con un poco más de detalle.
Los miembros del equipo se auto-organizan en equipos ágiles. que varían en tamaño de 4-6 personas. A cada equipo se le asigna un propietario del producto (PO) junto con un entrenador ágil. Dentro de estos equipos no hay líder asignado. No hay gerente de desarrollo. No hay tecnología líder. Suena como una receta para el caos, pero en realidad no lo es.
Creación de equipos
Los nuevos equipos se crean en respuesta a las nuevas necesidades comerciales (creación de una nueva característica) o, más típicamente, debido al aumento en el tamaño del equipo de ingeniería. Cada vez que se forma un nuevo equipo de desarrollo de software, se galvaniza en torno a una carta o misión. Esa misión está dirigida por la característica que el equipo tiene la tarea de construir. Los objetivos de priorización de funciones, alcance y entrega son establecidos predominantemente por el equipo de PM.
Es importante tener en cuenta que el equipo selecciona su misión y no al revés. Hacemos esto para fomentar la agencia, la autonomía y el propósito, ¿Qué investigación ha demostrado una y otra vez?, fomentar empleados altamente motivados y comprometidos, lo que a su vez conduce a una mayor productividad.
Una vez que se crea un nuevo equipo de desarrollo de software, se dispusieron a crear un plan para entregar la característica que seleccionaron para implementar. Por lo general, esto implicaría trabajar con la OP (y potencialmente con los clientes) para garantizar el alcance correcto de la característica y, probablemente, un proceso de diseño, dependiendo de la complejidad de la característica. Los equipos suelen pasar de unos pocos días a semanas en esta fase, de nuevo, dependiendo de la complejidad de la función. Uno de los principales artefactos de esta fase es una estimación de alto nivel (HLE) de cuando el equipo espera entregar la característica.
El equipo es responsable del desarrollo completo de sus funciones, desde el diseño, la implementación y las pruebas. Si bien la entrega incremental es altamente recomendada, la calidad incremental es altamente desaconsejada. Nos esforzamos por mantener la punta de nuestro código base en un nivel de calidad de envío en todo momento.
Sprints de equipo
Un equipo de desarrollo de software en Qumulo trabajará en los sprints de la semana 2. Como mencioné anteriormente, lanzamos nuevas versiones de nuestro software cada 2 semanas. Cómo funciona esto, podría ser un buen artículo en sí mismo. Todos los equipos (tenemos ~ 10) se alinean con esta cadencia de lanzamiento sin excepciones.
Al comienzo de cada carrera, los equipos pasan por una fase de planificación para describir lo que esperan lograr dentro de la carrera. De manera similar, los equipos realizan una revisión (cualquiera puede asistir) al final de cada sprint durante el cual el equipo presenta lo que logró y lo evalúa en relación con lo que buscaba lograr. Esta cadencia del plan / revisión les permite a los equipos ganar confianza en su HLE y asegura que estén progresando hacia su meta de entrega.
Movimiento de Equipo
Fomentamos los movimientos de equipo a lo largo de dos ejes por así decirlo. Primero, la membresía del equipo puede cambiar. Y segundo, el estatuto del equipo cambiará, generalmente cuando un equipo haya completado su estatuto actual. Ha habido muy pocas excepciones, por las cuales un equipo tuvo que abandonar sus estatutos y trabajar en uno nuevo, que está impulsado por las necesidades del negocio.
El cambio en la membresía del equipo es impulsado por el individuo y es otra forma de fomentar la agencia y la elección. También ayuda a las personas a tratar de trabajar en diferentes partes del producto, ayudándoles a desarrollar nuevas habilidades. Sorprendentemente, el movimiento de equipo no es tan alto como te imaginas; Un puñado por trimestre.
Estructura de equipo
Como se mencionó anteriormente, un equipo de desarrollo de software no solo está compuesto por ingenieros de software / hardware, sino también por un entrenador ágil y un propietario de producto. No tenemos líderes de equipo. No hay gerentes de desarrollo ni líderes asignados por equipo. De hecho, no tenemos jerarquía dentro de la organización de ingeniería.
Equipos chárter fijos también conocidos como Equipos especiales
Algunos de nuestros equipos tienen una carta fija. Estos son típicamente para equipos que esperamos que necesiten todo el tiempo. Tenemos algunos de esos, que son:
- Rendimiento: Hace que nuestro software zoom zoom.
- Soporte: Nos adherimos a “lo rompes. Usted lo arregla ”, y como tal tenemos un equipo de soporte compuesto por ingenieros de software.
- Infraestructura de ingeniería: sistema de compilación, CI y muchas otras herramientas de las que dependemos para crear nuestro producto
- Plataformas: evalúa nuevas plataformas físicas y virtuales para que nuestro software se ejecute, así como una gran cantidad de novedades de hardware
- Certificación: este es un equipo compuesto por nuestros ingenieros de control de calidad de 3 que trabajan incansablemente para garantizar que nuestro software pueda ser entregado de forma segura a nuestros clientes.
Con la excepción del equipo de certificación, la membresía de los equipos mencionados es voluntaria. Sí, incluso nuestro equipo de soporte está basado en 100% en individuos que seleccionan unirse a ese equipo. El equipo de soporte tiene un requisito: estancia mínima de 3 meses. Y tenemos una lista de espera para ese equipo también.
Hemos estado adoptando este modelo para la estructura del equipo de desarrollo de software desde nuestros inicios (~ 5 años atrás) y ha funcionado increíblemente bien para nosotros. Hemos contratado personas inteligentes y creativas que desean contribuir al éxito de Qumulo. Al permitir que las personas seleccionen con qué grupo de personas trabajan y en qué proyectos trabajan esos equipos dentro de las limitaciones de las necesidades comerciales, podemos mantener a las personas comprometidas y hacer su mejor trabajo. Al favorecer un proceso que implica la elección para determinar los grupos de trabajo y las tareas, fomentamos la autonomía y la propiedad de los resultados.
