Parece que en pequeños equipos de desarrollo (más de 20 personas) no debería haber problemas de desunión, trabajar en un código común y tomar decisiones técnicas. Pero todos sabemos que esto no es así (sin mencionar equipos como el nuestro, donde hay más de 80 personas). Hace tres años, para resolverlos, comenzamos a realizar una conferencia interna semanal para desarrolladores de DevForum. Debajo del gato aprenderá cómo nos ayuda, por qué otros formatos (como reuniones semanales o Sprint Review) e instrucciones para crearlo no siempre son adecuados.
Durante tres años hemos acumulado mucho buen contenido. Por lo tanto, habrá una serie de artículos escritos basados en discursos en DevForum :
1. Gato Schrodinger sin caja: el problema del consenso en sistemas distribuidos.
2. Infraestructura como código: primer conocido.
3. Infraestructura como código: cómo superar los problemas con XP.
4. Cómo los servidores están de acuerdo entre sí: algoritmo de consenso distribuido en balsa.
5. El caballo está muerto: llora: transición de tslint a eslint.
6. Generación de contratos de mecanografiado para modelos de C #. (En progreso ...)
...
¿Qué es DevForum y qué problemas resuelve?
DevForum es nuestro evento interno semanal para desarrolladores de Dodo IS. Ha estado funcionando los jueves durante tres años. Los desarrolladores se reúnen y dedican una hora a comunicarse entre ellos.
En esta reunión, discutimos cuestiones técnicas relevantes para todo el equipo. Una hora de tiempo, dos informes de media hora, tiempo para preguntas y respuestas.
¿Qué problemas resuelve la conferencia interna?
Para avanzar hacia el logro de un objetivo común, es importante para nosotros mantener un enfoque en los problemas importantes de la empresa. Para la sincronización general de todos los Dodo, tenemos reuniones semanales los lunes. Todos los empleados, socios / franquiciados están presentes en ellos, las grabaciones de las reuniones se pueden ver
en el dominio público . Para una sincronización con empresas y socios, organizamos una
revisión de Sprint quincenal. Para un enfoque único y una sincronización regular del equipo de TI, necesita más inmersión en la "carne" técnica. Esto es lo que estamos haciendo en DevForum.
Aquí hay una lista de problemas y sus soluciones:
- Compartir conocimiento Ahora tenemos más de 80 desarrolladores en nuestro equipo. Cada uno de ellos tiene sus propios antecedentes, sus propios detalles de trabajo, su propio nivel de inmersión. Nuestros equipos están divididos por producto. Y puede suceder que dos equipos independientes necesiten pasar por la misma zona salvaje. Cuando tienen la oportunidad de compartir sus mejores prácticas, pensamientos, éxitos o viceversa, se mejora. Hay una pequeña posibilidad de no pisar el rastrillo de alguien.
Además, nuestro equipo está en constante expansión, nuevas personas vienen y obtienen una herramienta lista para actualizar y compartir conocimientos regularmente. - Entrenamiento Aquí puedes aprender si no puedes hacerlo tú mismo y enseñar si puedes. La capacitación es un punto que está estrechamente entrelazado con el intercambio de conocimientos. Nos guste o no, debemos mejorar constantemente nuestro nivel técnico.
- Sincronización técnica de comandos (no debe confundirse con la sincronización diaria de comandos) . Es fácil mantenerse al tanto de todo cuando solo son tres personas. Ahora somos mucho más. A veces nos encontramos con ese problema: los equipos trabajaron en paralelo en un producto, pero no sabían qué hace cada uno. Como resultado, surgieron conflictos, reescribiendo el código de otra persona, etc. Cuando algunos lo hacen, mientras que otros arrojan, el proceso de desarrollo puede fallar. En DevForum, también nos centramos en la sincronización técnica de los equipos y estamos luchando con la desunión.
- Herramienta para el cambio . Puedes venir aquí y cambiar el curso de la historia. Aquí tienes que decir con el ejemplo.
Un ejemplo Digamos que tenemos a Oleg. Se sienta en la infraestructura y hace el proyecto de Autonomía con los muchachos. Cuando el proyecto comienza a su máximo potencial, la vida de los desarrolladores simples será más fácil. Dejarán de tirar de la infraestructura y harán todo por sí mismos. Lo haces todo tú mismo, no dependes de nadie, está bien.
Oleg está listo para hacer cambios en la empresa. Pero él sabe que simplemente escribir sobre los cambios realizados en Slack no es suficiente. Es necesario contar en público, explicar, responder preguntas, escribir un artículo, realizar una serie de acciones, de lo contrario, nada cambiará. Oleg llega a DevForum y lo usa como una herramienta para el cambio.
- Entrenamiento antes de la actuación . Aquí puedes practicar antes de una gran actuación. Nuevamente, tome a Oleg como ejemplo.
Un ejemplo Oleg quiere hablar en grandes conferencias. Necesita honor, fama y miles de visitas en Youtube.
Él viene a nosotros y sinceramente habla de sus ambiciosos objetivos. Nosotros, a su vez, le proporcionamos una plataforma para un entrenamiento (prácticamente) indoloro. Si es necesario, le ayudamos, le pedimos guía
El umbral para ingresar a DevForum (a diferencia de un mitap o conferencia) es mínimo. Oleg necesita preparar un tema, preparar diapositivas durante media hora y llegar en el momento adecuado. Este es un gran lugar para un ensayo de prueba. Entrenamiento en gatos, es decir en nosotros Le daremos retroalimentación, revisaremos las diapositivas y podrá ver los chistes sobre nosotros.
Después de DevForuma, el informe ya se puede lanzar en un mitap local. Y lo más probable es que lo lleven.
Un poco retro: cómo surgió DevForum
¿De dónde vino este formato? Korotenechko. Hace tres años, nuestra compañía hizo su primer intento de introducir Sprint Review de forma regular.
Parecía así: todos se reunieron en una habitación, absolutamente todo y se turnaban para decirse quién había hecho qué en las últimas semanas. En ese momento, solo éramos 20, pero imagínense cómo se siente escuchar y mirar el código del representante comercial y el desarrollador para mirar los edificios de la pizzería. Rápidamente nos dimos cuenta de que las personas escuchan solo los temas que les interesan, y en otros temas están penosamente atrapados en el teléfono.
Nos enfrentamos al hecho de que una demostración de una profunda técnica para aquellas personas que están lejos de esto es tal. Llegaron a ver cómo comienza la caja, y les contamos sobre la experiencia de usar el marco de Polly para implementar retransmisiones entre servicios. Rápidamente nos dimos cuenta de que dicho formato era de poca utilidad para las personas, y Sprint Review rechazó esa forma. En algún momento, simplemente se canceló, y la reunión en el calendario se mantuvo.
Un grupo de personas de iniciativa pensó: es genial mostrar cosas técnicas a quienes están en el tema. Hay una reunión, hay gente, hay un deseo, hay temas. Así que comenzamos a reunirnos una vez por semana y seguimos haciéndolo hasta el día de hoy.
Durante tres años, el formato ha sufrido algunos cambios.- Comenzamos a grabar nuestras actuaciones. El formato en sí mismo ha estado funcionando durante tres años, tenemos registros en dos años. Todos ellos se almacenan en un solo lugar, si lo desea, puede revisar.
- Dejamos el formato de la demostración porque llegamos a la conclusión de que la preparación y la demostración en sí toman más tiempo que el formato de la presentación.
- Pasamos al formato de presentación, que es fácil de preparar, dándole literalmente 40 minutos de tiempo (aunque aquí, por supuesto, depende de la complejidad del tema y del orador).
- Al principio, cada desarrollador habló en DevForum. En algún momento, asumimos que no hablaba cada persona individual, sino un representante del equipo.
- Luego fuimos más allá y dejamos de molestar con una propuesta para hablar con aquellos equipos que ahora "no pasan nada".
- Inicialmente, encajamos cuatro temas por hora, pero llegamos a la conclusión de que no importaba lo interesantes que fueran los informes, al final de la hora solo quedaban gachas en mi cabeza. Así que ahora tomamos uno o dos temas en DevForum, 25 minutos de un informe y 5 minutos para preguntas.
- Recientemente, decidimos ampliar un poco la gama de temas y, a veces, invitar a oradores externos.
Sabemos que nuestro DevForum no es un formato súper único, muchos de nuestros colegas han intentado algo similar. Pero, desafortunadamente, a menudo estas reuniones regulares no se arraigan, se vuelven rápidamente obsoletas y se marchitan. Nuestro DevForum tiene una vida útil de tres años: es mucho tiempo para analizar, reunir experiencia y compartir con usted la experiencia de crear y mantener este formato.
Cómo organizar DevForum en su empresa
Necesitarás 6 cosas básicas:
1. Comprensión de las tareas y formatos de DevForum.
Más detallesPara comprender si es necesario ejecutar DevForum en casa, puede consultar las tareas que este formato resuelve en nuestro Dodo.
Estas son las tareas de comunicación, capacitación y autorrealización de los programadores. DevForum es un mecanismo flexible y puede, en un momento u otro, trabajar más para lograr diferentes objetivos.
Hay dos formatos de voz verificados que hemos desarrollado durante tres años. Puedes adoptar:
Informe : un desarrollador se prepara y habla, mientras que otros hacen preguntas.
Un ejemplo Una vez, el tema fue "Registro estructural", donde hablaron sobre serilog, su uso en nuestros proyectos y cómo ayuda a trabajar mejor con registros en Kibana. También abordó el tema del registro estructural a través de NLog y el uso de interfaces ILogging comunes para proyectos .NET CORE.
Después de la presentación, hubo una sesión de preguntas, y todos los participantes entendieron lo fácil que era agregar esta biblioteca a un nuevo proyecto. Nos llevó 30 minutos. Durante media hora más, discutimos los niveles de registro de ese día, como Debug, Info, Warn, Error, etc., y específicamente, qué niveles describen qué situaciones en el sistema. En la sesión de preguntas, se planteó el problema de los errores de ruido en los registros, especialmente los relacionados con las retransmisiones. Desde DevForum, todos los nuevos proyectos de microservicios utilizan exactamente Serilog, y también apareció en nuestra plantilla de servicio.
Toma de decisiones : hay un problema que de alguna manera afecta a todos. Las personas vienen con posibles soluciones para detenerse en una cosa.
Un ejemplo Reunimos DevForum para discutir la definición de hecho y queríamos estabilizar la calidad del código suministrado para la producción. Pero, ¿cómo hacer esto cuando tienes varios comandos trabajando en un código común a la vez? La solución fue hacer común a todas las definiciones de historias de usuarios realizadas. El DOD propuesto fue un punto controvertido. Nos reunimos y discutimos si lo necesitábamos o no. Se tomó una decisión general. Para implementarlo, agregamos un elemento a la lista de verificación en nuestro rastreador de tareas (Kaiten) y lo convertimos en un elemento obligatorio al cerrar las tareas. Algunos equipos fortalecieron aún más el DoD al agregar sus propios puntos importantes para ellos.
2. Organizadores potentes y cargados.
Más detallesLo que debe tenerse en cuenta es la presencia de personas que participan constantemente en el evento: los organizadores. Es importante que sean de desarrolladores o personas que entiendan la parte técnica. Tendrán que ayudar a los participantes a formular temas, buscar nuevos oradores e incluso a veces mantener una discusión haciendo buenas preguntas.
En nuestro caso, tenemos 3 organizadores de los desarrolladores, así como un equipo de marca de TI que ayuda activamente.
3. Consentimiento de la gerencia de su departamento de TI.
Más detallesAdemás de los objetivos y organizadores, un componente importante del éxito del evento es la falta de oposición desde arriba. Este proceso es una iniciativa puramente popular, podemos decir que los entusiastas lo hacen. La ayuda de la gerencia puede ser beneficiosa, y la oposición será desastrosa. Aún así, las personas se reúnen durante las horas de trabajo, usan locales y equipos de oficina. Esto, como mínimo, no debe prohibirse.
4. La disponibilidad de espacio y equipamiento para reuniones.
Más detallesEl espacio puede ser una sala de reuniones en la oficina o un lugar de reunión virtual, una llamada general en Skype o Google.
Siempre nos reunimos en una sala de reuniones reservada "para siempre en este momento" en la oficina, pero al mismo tiempo transmitimos todo en general, la reunión de Google, que también es la misma y no cambia entre reuniones.
Nuestra negociación es grande, con capacidad para 20-30 personas. Hay un proyector y un sistema de salida de sonido para llamadas remotas. Todos saben que los jueves de 4:00 p.m. a 5:00 p.m. DevForum se lleva a cabo en esta sala de reuniones.
Debido al hecho de que tenemos un desarrollo parcialmente distribuido, estamos seguros de llevar a los trabajadores remotos a una llamada común. También permite a los oradores mostrar su pantalla desde su computadora, conectándose a una reunión general. Los oradores pueden estar en la sala de reuniones generales o en cualquier otro lugar conveniente para ellos. Todos los escucharemos y también veremos su pantalla.
El espacio permanente designado hace que esta reunión sea más confiable y predecible para los participantes.
5. La presencia de una audiencia de oyentes.
Más detallesPara reunir a los participantes, tenemos un canal permanente en el #devforum slack, donde todos los desarrolladores se sientan con seguridad. Incluso incluimos este canal en la lista de canales requeridos en la lista de verificación del nuevo desarrollador. Además, los mentores novatos se aseguran de que caigan en el canal #devforum.
Hay anuncios de reuniones, discusión después, la elección de temas y discusión sobre temas.
Para que las personas participen en la vida del foro, organizamos encuestas, pedimos a los oradores que den su opinión y también publicamos una grabación de la reunión al día siguiente por la mañana.
También es importante que el evento sea voluntario y opcional. Sí, se lleva a cabo durante las horas de trabajo, pero si alguien quiere trabajar o tiene cosas más importantes que hacer en este momento, puede fallar.
Ejemplo de publicación posterior al evento:
Un ejemplo de discusión después de una reunión:
6. La presencia de oradores y temas de discusión.
Más detallesEsta es la parte más importante y más difícil de la organización. Aquí nos enfrentamos a problemas, tanto la búsqueda de oradores como la disponibilidad de temas.
Aquí hay una breve lista de actividades que los organizadores realizan para involucrar a las personas:
- Buscamos temas por adelantado, elaboramos un plan de rendimiento para más de una semana. Al principio, buscamos temas al comienzo de la semana, y el jueves tuvimos que hablar.
- Entramos en los canales de comando y preguntamos explícitamente: ¿hay algún tema para DevForum?
- Llevamos a cabo conversaciones personales con los programadores, alentándolos a actuar. Verificamos el valor para que el orador participe: una comprensión más profunda del tema, experiencia de hablar, beneficio público, material para un artículo futuro, conferencia.
- Lanzamos temas de discusión en el canal que la gente estaría interesada en escuchar. Los desarrolladores expertos pueden responder y actuar como oradores.
- Respondemos a eventos socialmente importantes, organizando de manera independiente discusiones sobre temas problemáticos de desarrollo.
- Vemos conferencias pasadas con nuestros participantes. Después de asistir a las conferencias, siempre hay algo que contar.
- Siguiendo los resultados de las conferencias que son importantes para nosotros, a las que asistieron muchas personas, estamos organizando una discusión en el formato de "3 mejores informes del último Highload ++".
- Invitamos a oradores externos.
Algo mas importante
Puede parecer que todo es simple (o viceversa, nada está claro), por lo que enumeraré algunas características más de la organización que se deben tener en cuenta y tener en cuenta.
Los organizadores necesitan trabajar con oradores. Resolvemos el miedo a hablar a través de la ayuda en la preparación del discurso. La pereza o la desorganización se detiene por una solicitud para formular el tema de antemano, incluso en forma de borrador, y con la fecha exacta del discurso.
A veces no hay ninguno. Hay momentos en que se ha encontrado tanto, a veces cuando hay poco. En este caso, no puede cancelar categóricamente el evento. Debemos tratar de encontrar temas o hablar por nosotros mismos. Los organizadores también son desarrolladores, por lo que siempre tenemos algo que contar. Puede recurrir a trucos, organizando más debates gratuitos.
Video y calidad de sonido. Es un momento puramente técnico, pero es importante para las personas que el sonido sea bueno (verifique la conexión e Internet por adelantado) y que la demostración del código en la pantalla sea legible. Incluso el tema más interesante, presentado con fallas técnicas, puede alienar a los espectadores.
Acumulamos material. Las reuniones deben ser grabadas. Tenemos un archivo de videos, con presentaciones y materiales adicionales adjuntos. Hay listas de reproducción en YouTube. Ponemos todos los registros en nuestro sistema de documentación, donde hay una búsqueda de texto completo y luego puede encontrar el tema de interés y familiarizarse.
Dedicado a los equipos de desarrollo en los que no hay gerentes en los que trabajas en un solo código, en el que los desarrolladores están interesados en saber lo que está sucediendo, para aquellas personas que quieren desarrollar y ayudar a otros a crecer, aquellos equipos para quienes la confianza es importante.
De Dodo Pizza Engineering con humanidad