Software Industry Coach

Te han mentido. No existe tal cosa como “la metodología ágil” porque la agilidad no se puede prescribir. No es una píldora que tomas una vez y resuelve tus problemas de un día para otro. Pero muchos siguen convencidos que sí lo es.

En esta nueva serie de artículos quiero hablarte de muchos de los conceptos que se entienden mal sobre la agilidad y, por lo tanto, se aplican erróneamente en las formas de trabajo (por ejemplo, que “Agile” es una metodología y se adopta como tal). Quiero hablarte de cómo es que esto ocurre y cómo lo podemos arreglar para que cambiemos los resultados en nuestros desarrollos.

Una estrategia de aseguramiento de la calidad mal diseñada entorpecerá el flujo de trabajo y generará retrasos. Veamos algunas maneras de optimizar el flujo del equipo, asegurando una alta calidad.

Esta es la historia de un conflicto ríspido entre Testers y Devs, y de cómo lo podemos eliminar

Es común creer que empezar a probar antes garantiza la calidad y ocurre lo opuesto ¿Por qué? Vamos a encontrar la respuesta a esta cuestión

Más allá aún: ser capaz de predecir la cantidad de defectos y fallas que tendrá el software antes de iniciar testing

En el primer episodio de esta serie, te compartí que hubo un cambio en mi forma de trabajo y mi actitud al desarrollar software, que me hizo un mejor desarrollador

En el desarrollo iterativo, suele pensarse que parte de iterar sobre el MVP incluye arreglar los bugs y fallas. No es lo más adecuado, porque si tu MVP ya es suficiente para ir a producción, no lo podrías enviar inmediatamente porque tiene fallas, lo cual impide la agilidad. La calidad debe ser una cultura, un conjunto de actividades continuas a lo largo del desarrollo y no ser solamente momentos en el tiempo donde decimos “ahora nos concentraremos en la calidad”. Hacer el producto correcto y hacerlo bien.

Un tema que tuvo un alto impacto profesional en mí fue el de Gestión de la Calidad en el desarrollo de software. Literalmente cambió mi vida para bien y para siempre. Hoy, es algo que difundo y comparto (a nivel de evangelizador) a donde voy, pues lo considero fundamental para el desarrollo de software. Te comparto la experiencia con la que lo comprendí.

La mala gestión ocurre en software. Una serie de decisiones y acciones conducen a esta situación. A lo largo del tiempo, he identificado cinco que siempre están presentes y te las describo

Medir es un proceso disciplinado, el cual es utilizado para comprender las razones de un desempeño actual y emprender acciones de mejora asertivas

Los procesos de gestión de la configuración son críticos y muchos equipos suelen ignorar definirlos, pero si nombramos a un responsable, el Líder de Gestión de Configuración correremos menos riesgos.

Dos de los roles, que hemos mencionado en esta serie, son responsables directos del aseguramiento de la calidad en el desarrollo del software: el Líder de Calidad y el Líder de Pruebas.

Es más fácil gestionar un trabajo que conoces bien. Si tú lo definiste, entonces eliminamos la curva de aprendizaje de un proceso organizacional.

Un equipo tradicional tiene un solo tomador de decisiones, mientras que uno autodirigido decide todo en consenso y en comité

Hacer software es un trabajo complejo. Involucra múltiples tareas y habilidades diferentes. Lo mejor es que la gestión del trabajo se haga por varios roles en el equipo

El concepto de “proyecto” en software ha dejado de usarse, para centrarse en “desarrollo de producto”. Así se ha difundido la idea de prescindir de los Project Managers en el desarrollo de software

¿Qué debo hacer, en el contexto del desarrollo de software, para poder lograr empatía con mis usuarios? Debes fijarte en cuatro cosas. Acompáñame a conocerlas.

Las habilidades de análisis de negocio y de sistemas son importantes para todo ingeniero de software y debes trabajar en ellas. Abordemos lo que es esta disciplina

La mejor solución de software se consigue haciendo algo muy simple, que te describo a continuación.

No existe un solo ciclo de vida que sea efectivo para todos los productos y todos los desarrollos de software. En este artículo te hablo de cómo elegir el ciclo adecuado para tu próximo desarrollo

El ciclo de vida del software es una de las decisiones importantes que toma todo equipo de desarrollo, pues una mala elección entorpece la obtención de los objetivos del producto

Hasta hace poco, no comprendía por qué la mayoría de la gente en el mundo del software es renuente a practicar la Ingeniería del Software. Hablando con algunas personas lo entendí

Puedo decir, con seguridad, que el saber recibir y manejar la retroalimentación es más relevante que saber emitirla. Podemos aprender y convertirnos en mejores receptores de esta información

En general, el entrenamiento se enfoca en enseñar cómo dar la retroalimentación. Pero esto solo es la mitad del proceso. La otra, es la recepción y manejo, que suele ser algo que pocos saben hacer.

Los Ingenieros de Software debemos ser conscientes de que esta actividad es importante y no debemos omitirla. Tres ideas clave: por qué documentar, lo que no es documentación y cómo hacerlo

Esto es algo que escucho con frecuencia: yo no hago documentación en el software que desarrollo. Aquí te digo por qué esta idea es errónea y dañina

¿Cómo ordenarías estos criterios para priorizar el trabajo? - Urgencia del cliente / usuario - Riesgo potencial y Valor para el cliente / usuario - Valor para el cliente / usuario - Estabilidad del requerimiento Te comparto mi lista y mis razones

La Ingeniería de Software es mucho más que “un montón de páginas y diagramas”. Es el camino que conduce a producir un resultado que deleita a los usuarios lo más rápido. Como decía Watts Humphrey: la forma más rápida de hacer el software, es hacerlo bien a la primera. Eso solo se logra con la Discilina de la Ingeniería.

Parece que la calidad es un tabú en el gremio o algo que se puede postergar e incluir después; basta ver la lista de actualizaciones de apps en tu teléfono móvil para darnos cuenta que, en su mayoría, se trata de “soluciones de errores (bug fixes)”. Esto tiene varias causas; las que yo veo, como principales, son: que los desarrolladores creen que todo se soluciona con tecnología solamente y que la mayoría hacen a un lado la Ingeniería (se llama Ingeniería de Software, ¿recuerdan?). ¿Por qué ocurre así, qué es lo que ocasiona y qué podemos hacer? Vamos a explorar un poco.

Muchos desarrolladores de software padecemos el “God Complex”: creemos que todas nuestras decisiones son acertadas y sabemos más que todos. También, que podemos resolver los problemas con poca o nada de ayuda. Ágil parte de un hecho: empezamos a implementar la solución sobre un problema que ya comprendimos en su mayoría y lo que se descubre es el cómo resolverlo mejor. Por eso, aquí te dejo tres recomendaciones de lo que debes entender bien antes de comenzar el desarrollo de un producto de software.

En nuestras observaciones, hemos encontrado que dan mejores resultados si los equipos se concentran en uno o dos temas a la vez y los atienden respondiendo cinco preguntas.

La retrospectiva es una práctica que aporta valor en la mejora continua, sin embargo he visto que muchos equipos evitan la práctica, los ingenieros prefieren ausentarse a la reunión porque la ven como pérdida de tiempo o, simplemente, le temen. Esto ocurre porque la actividad se ha distorsionado y ya no sirve para su propósito. Esto es lo que nunca debes hacer en una retrospectiva.

Mi respuesta, desde hace algunos años, ha sido esta: todos y ninguno. Aunque escuches y leas de los casos de éxito que ha tenido Scrum, de lo fantásticas que son los métodos de Netflix y Spotify, de lo terrible que es Waterfall (cascada) y de que solo Ágil puede funcionar, es una mala idea intentar copiar la forma de trabajo definida por otros y aplicarla así en nuestro equipo.

En esta ocasión te hablaré de lo que ocurre cuando los miembros del equipo colaboran activamente en establecer acuerdos, que les permiten obtener buenos resultados consistentemente. Recuerda que el trabajo de software depende, en gran medida, de las interacciones entre las personas. Cuando los integrantes del grupo trabajan, saludablemente, en crear acuerdos, observarás que ocurre lo siguiente.

El Driver de la agilidad "Organización del equipo" procura la autonomía y la autodirección de los equipos de software. Es decir, que los equipos acuerden una forma de trabajo que les sirva. Si esto no se realiza adecuadamente, veremos algunos síntomas de un mal trabajo de desarrollo, aquí te hablo de algunos.

¿Qué es más importante para un ingeniero de software, programar bien en el lenguaje de programación o saber ortografía y redacción en su idioma? Aquí te comparto algunos de los aprendizajes que he obtenido al respecto a lo largo de mi carrera, que te ayudarán a conseguir equilibrio. No aprendas a usar el framework haciendo el sistema No apliques religiosamente una metodología No elijas la tecnología antes de entender el problema a resolver Asume roles activamente dentro del equipo

La influencia en los resultados proviene de cinco aspectos y en la capacidad de desempeñarlos bien o la ausencia de estos. Los llamamos "Drivers para el alto desempeño" y te cuento cuáles son.

Un equipo de trabajo con el que colaboré, estaba conformado por 7 personas (6 desarrolladores y 1 líder). El equipo comentaba que estaban muy ocupados y no podían iniciar trabajo con clientes nuevos con rapidez. También, se quejaban de que no les autorizaban contratar más personas, que pudiesen ayudarles a crecer su capacidad de producción. El equipo, en los tres meses que colaboramos, perdió un integrante que se fue a otro empleo y no fue reemplazado. Muchas organizaciones entrarían en una crisis en ese escenario con los proyectos actuales. Sin embargo, el equipo del que les hablo tuvo un mejor resultado: incrementó su capacidad de atender nuevos clientes en 53% en un año, con 6 personas solamente. El equipo creció sin aumentar la cantidad de integrantes. Otros equipos, en otras organizaciones, crecen en personal, pero no en capacidad en la misma proporción; incluso, algunos la reducen conforme más personas llegan. Hay varias razones para esto, aquí te expongo algunas.

Una vez, un director de empresa me dijo que su producto de software estrella se estaba quedando rezagado: Tenía varias funciones, pero estaban especializadas en un nicho del mercado. No podía ofrecerlo a nuevos clientes u otros giros. No tenían a un encargado, que pudiese identificar nuevas tendencias y necesidades para incorporarlas. Además, estaban retrasados en el mantenimiento correctivo de varias cosas. Entre otras dificultades de gestión de la configuración, de las que no hablaré el día de hoy. Varias organizaciones, que desarrollan software para terceros o internamente, enfrentan esta dificultad: la brecha tecnológica (aprovechar al máximo la tecnología) se ensancha en lugar de cerrarse. Por esta razón, todas pierden oportunidades de negocio, pues no pueden vender un producto nuevo o sus operaciones internas se ralentizan porque la tecnología no está ahí para apoyarlas. A continuación te presento algunas de las razones por las que las organizaciones de software pierden oportunidades de negocio.

Existen dos frases, que he escuchado decir a muchos Líderes de equipo y Gerentes, quizás las has escuchado también: - "Quiero un equipo con la camiseta bien puesta" - "Todos los miembros del equipo deben ser más comprometidos" Son una arenga, que busca motivar al equipo para que obtenga resultados extraordinarios o sea capaz de solucionar problemas activa y rápidamente. A veces, cuando existe la urgencia de liberar una función o un fix, la escucho en esta forma: "comprométete más con la empresa". Sin embargo, solemos ver un efecto opuesto al que buscan estas frases: un equipo desmoralizado y resultados alejados de las expectativas de los líderes. Los miembros del equipo están comprometidos; dice Watts Humphrey: "todos los participantes quieren hacer un gran trabajo y dar lo mejor de sí, siempre", y es verdad; no conozco un solo desarrollador de software que se levante en las mañanas pensando "hoy haré el peor trabajo que pueda"; es solo que, en su estado actual, tiene poco margen para participar.

A lo largo de mi carrera profesional he escuchado lo siguiente en diferentes ámbitos: “Es normal que el software tenga defectos” o su variante “El software siempre tendrá defectos” No es normal. Ustedes no andarían por un puente vehicular, del que saben que tiene defectos. No aceptarían un coche defectuoso o aceptarían una casa con múltiples defectos. Sin embargo, como decía mi profesor Carlos Montes de Oca “el software es tan necesario que le perdonamos que sea malo”. Se vuelve el cuento de nunca acabar. En general, las organizaciones con este problema dedican entre 65% y 85% del tiempo solo a esta actividad en lugar de producir funciones nuevas, o dedican equipos completos solamente a esto. Algunas organizaciones, con algo de cinismo, la incluyen en los contratos como “fase de estabilización”, que solo es trasladarle el costo al cliente por la mala calidad del desarrollo. A continuación te presento razones por las que se presenta este comportamiento en organizaciones de software. No hay cultura de la calidad Cuando pregunto “¿Quién es responsable de la calidad del software en la organizacion?” suelen responder: El equipo de QA La fase de Testing Es decir, asumen que la calidad es “algo que sucede en un momento del tiempo” o es una actividad concreta, en lugar de ser un trabajo continuo. Esto genera una forma de trabajo donde la responsabilidad se diluye. El equipo de desarrollo espera que QA sea quienes encuentren los defectos, y QA espera que desarrollo esté atento a los ciclos de pruebas para reparar cuanto antes. Además, genera conflicto y fricción, sobre todo si ambos grupos solo se involucran en su fase y no colaboran en el resto del ciclo. Presiones para entregar a Testing rápido Esto es consecuencia de la pobre cultura de la calidad. Project Managers, Gerentes y Líderes saben, por la experiencia anterior, que la fase con más costo será testing. Por lo tanto, concluyen que una forma de acortarla es iniciarla rápidamente. Presionan para entregar y empezar a probar, en lugar de promover que se aseguren de que lo que entregan aprobará las pruebas rápidamente. El resultado siempre es el opuesto al que esperan: mientras más defectos encuentran, más defectos hay por arreglar. Watts Humphrey lo dice en su libro “A discipline for software engineering”: “Al llegar a testing, la calidad ya se encuentra dentro del producto”. William Lewis lo remata así: “No se puede agregar calidad a un producto ya terminado” Imagen: pch.vector para Freepiki La forma de trabajo es inadecuada En el punto anterior menciono: mientras más defectos encuentran en testing, más defectos hay por arreglar. Si la forma de trabajo usada para arreglar los bugs es la misma que se usó para crear el código la primera vez, la consecuencia es que inserte más defectos. Puedes observar cosas como: El equipo de desarrollo quiere regresar el código a QA lo más rápido posible (como la primera vez), y no verifica exhaustivamente que ya no hay defectos. Los equipos no comparten información, que puede ayudar a prevenir defectos. Un caso común es que un equipo no comparte cuáles son las ideas de prueba que tiene, o qué cosas le gustaría probar. Cualquier actividad de aseguramiento de calidad como peer review, inspecciones, walkthroughs, etc. es suprimida porque se ve como pérdida de tiempo y lo que urge es entregar a QA. Deuda técnica Productos y sistemas que están en desarrollo constante (mejoras y mantenimiento) suelen presentar el problema de la deuda técnica, la cual “se cobra” con el tiempo en forma de fallas y defectos. La deuda técnica es una implementación inadecuada, que se hizo apresuradamente para resolver algo en un momento, pero nunca se reemplazó por la solución correcta. Esto, a la larga, va manifestándose con problemas que son costosos para los equipos, en términos de tiempo. Aunado a esto, los sistemas están pobre o nulamente documentados. Cuando un ingeniero quiere arreglar un problem...

En las cinco red flags de las organizaciones de software, que les detiene para lograr resultados de élite, tenemos el tiempo de desarrollo muy largo; esto es, la incapacidad del equipo para entregar software funcionando en intervalos cortos, regulares y frecuentes. Algunas empresas se distinguen por su innovación, la cual notamos porque brindan funciones nuevas en sus productos constantemente. Hablamos de compañías como Amazon, Netflix o Facebook (ahora, Meta), quienes crearon una forma de trabajo capaz de hacer varios deploys al día, completamente funcionales. Amazon lo hace a una tasa de 30,000 al día; Netflix, 500 y Facebook 2 veces diariamente. ¿La tuya es capaz de hacer esto? Tal vez te encuentras en la circunstancia normal de muchas organizaciones: solo hacen una o dos entregas (deploys funcionales) AL AÑO. ¿Cuáles son las razones de esto? Te presento las más importantes. Pasan muchos días entre el fin de un ciclo (sprint) y el inicio del siguiente Los frameworks de la filosofía ágil, basados en ciclos, son muy populares. Estos recomiendan dividir el trabajo en ciclos cortos (sprints), en los que se produce un MVP listo para ser utilizado. La idea es que, después de cerrar uno, inmediatamente comenzar el siguiente, incorporando las nuevas User Stories y la retroalimentación del anterior. Muchos equipos dejan pasar días, o semanas, entre el fin de un ciclo y el inicio del siguiente. Las causas suelen ser: Realmente no entregaron un MVP sino un producto a testing; el equipo de QA ha regresado la entrega con muchos reportes de defectos para reparar. No hay autonomía en el equipo para tomar decisiones. Si el responsable de autorizar o dar visto bueno a la planificación está ausente, el trabajo se detiene. Proceso burocrático. Se requieren muchos pasos para lograr el visto bueno de inicio; por ejemplo, que los requerimientos sean definidos, priorizados y aprobados por varias personas. Tiempos muertos entre silos funcionales Si tu equipo está organizado en grupos especialistas (analistas, desarrolladores, testers, etc.), verás que las personas tienen picos de ocupación y desocupación. Esto es porque el trabajo está avanzando linealmente, pero necesita de que todo esté terminado para poder pasar al siguiente grupo; éste tiene que esperar, hacer su parte y enviarla al siguiente, que también está a la expectativa. Mientras están desocupados, quizás están haciendo otras labores (capacitarse, arreglar defectos, entre otros), pero el progreso del sprint no está avanzando más rápidamente. Burnout Imagen: Macrovector para Freepik Un equipo cansado es improductivo. Algunos señalan que una noche sin dormir (o poco sueño) reduce la efectividad de un Ingeniero en 20%; dos consecutivas la reducen 80%. La creencia de que trabajar más horas hará que el resultado sea más rápido es contraproducente. Muchos Project Managers y Gerentes insistirán en prolongar las jornadas de trabajo para acelerar el desarrollo, pero con esto solamente lograrán que el equipo se queme. En esta circunstancia, por más horas que acumulen, no podrán producir un buen resultado y la cantidad de defectos y problemas crecerá exponencialmente.  Pobres técnicas de ingeniería para validar la solución A lo largo de mi carrera, he observado que una limitante para las entregas continuas es la carencia de técnicas ingenieriles: Los desarrolladores no saben cómo probar un módulo si otro, u otros, no están terminados. Por esto, deciden usar un enfoque en Cascada para completar todas las partes y poder probar. El equipo no sabe cómo automatizar las pruebas. Los procesos son manuales y replicar una prueba toma mucho tiempo, sobre todo si falla. El proceso de instalación de cualquier cambio, actualización o ambiente es completamente manual. Literalmente, copian y pegan archivos de una computadora a otra en lugar de tener scripts o software que haga el deploy por ellos.

Una organización de software es una persona o grupo, que tiene como fin crear y entregar soluciones basadas en software, las cuales deleitan a sus usuarios y dan valor financiero a los patrocinadores de su desarrollo. Estas organizaciones pueden ser vendedoras del servicio de software a clientes finales o estar dentro de otra empresa, creando el software que se usa en las operaciones diarias. Mientras más rápido consigan la entrega, más rápido se obtienen también los beneficios e inician más oportunidades de desarrollo. Es lo que, hoy en día, se llama Agilidad y es un resultado que todas las organizaciones deben procurar. Sin embargo, muchas de ellas descuidan factores importantes, que les impiden obtener los mejores resultados. Estas carencias se observan en sus prácticas de Ingeniería de Software. A continuación te presento cinco red flags en los grupos de desarrollo de software y las razones por las que detienen al equipo para lograr los resultados de elite: El tiempo de desarrollo es muy largo La mayor parte del tiempo se dedica a apagar fuegos y arreglar defectos Moral de equipo baja Pérdida de oportunidades para aprovechar tendencias tecnológicas y crear nuevos productos, servicios y negocios No pueden crecer El tiempo de desarrollo es muy largo Un requerimiento solamente aporta valor a los usuarios si éste se encuentra en sus manos, implementado sin defectos, y listo para ser utilizado. Guardado en el backlog o en la lista de requerimientos no les es útil, por lo tanto, debe pasar poco tiempo entre la espera y la entrega. Ese poco tiempo es un día o unos pocos días. Los equipos que tienen esta red flag tardan meses entre una entrega y la siguiente, porque el proceso de desarrollo establece esta forma de trabajo o bien porque hay un período largo de inactividad entre el fin de un ciclo de desarrollo y el inicio del siguiente. Los gerentes y directores suelen presionar en este aspecto; aunque la presión aumenta, la práctica y el resultado siguen iguales: el tiempo de entrega es de meses. Peor aún, cuando las jornadas de trabajo se extienden, tratando de acortar el calendario de entregas, y frecuentemente se pierden fines de semana o se trabaja desde la mañana hasta la madrugada. La mayor parte del tiempo se dedica a apagar fuegos y arreglar defectos El valor que entrega el software solamente puede aumentar si agregamos funciones nuevas o mejoramos mucho las existentes. No hay valor si una función falla o los defectos hacen imposible el uso del software. Las organizaciones deberían pasar la mayor parte del tiempo implementado nuevas funciones y mejoras. Los equipos que tienen esta red flag dedican entre el 65% y el 85% de su tiempo arreglando defectos y apagando fuegos (problemas causados por la operación del software). Terminan con una crisis y al poco tiempo están atendiendo otra, o varias a la vez. Los problemas parecen inacabables porque los equipos utilizan las mismas prácticas para arreglar los defectos, que fueron las que los pusieron en el software en primer lugar. El ciclo es interminable por esta razón. Moral del equipo baja Los grandes resultados son obtenidos por equipos cohesivos y altamente motivados. Las organizaciones que tienen esta red flag cuentan con individuos desmotivados y la moral baja; esto puede observarse porque los miembros de equipo solo se limitan a cumplir con las funciones que les encomendaron en su puesto y no se involucran en otras actividades, opinan poco o nada y no comparten información relevante, sobre todo cuando puede prevenir problemas.  Los directores y gerentes llaman a esto "falta de compromiso", ¿te suena? Cuando los problemas ocurren, inevitablemente, todos intentarán culpar a otros y no asumir la responsabilidad por el resultado completo, pues ellos habrán cumplido con lo que les correspondía, pero no asumirán nada más. Imagen: jcomp para freepik Pérdida de oportunidades para aprovechar tendencias tecnológicas y crear nuevos producto...

Muchas veces ocurre que no comprendimos bien los requerimientos de un sistema y ponemos el producto incorrecto en las manos del cliente. Esto, si ya ha pasado mucho tiempo y se haLeer

Hablemos de la Especificación de Requerimientos Es imposible que el equipo de desarrollo memorice toda la información del producto. A lo largo del proyecto, los miembros del equipo tendrán preguntas, habrá suposicionesLeer

La información que obtienes durante el levantamiento de requerimientos es un conjunto de datos muy grande, que en su estado natural es poco útil. Debemos analizarla para entender cuatro cosas respecto aLeer

Los ingenieros de software solemos cometer el error de esperar que los usuarios nos den sus requerimientos; ellos nunca lo podrán hacer, porque no están entrenados en desarrollo de software, pero insistimos en hacer preguntas como “¿Qué es lo que quieres?”, “¿Usamos tal herramienta o tal otra?”, “¿Será en plataformaLeer

Hay tres cosas que debes entender para tener buenas prácticas en tus requerimientos: Qué son los Stakeholders Los niveles de requerimientos Los tipos de requerimientos Comprender bien esto, te permitirá responder fácilmente a la pregunta: ¿Cuáles son las siguientes user stories a desarrollar?  Identifica a tus Stakeholders Un sistema deLeer

¡Hola! Bienvenido a la serie “Cómo deleitar a tus usuarios”. En ésta hablaremos de Ingeniería de Requerimientos, un conjunto de actividades muy importantes, que nos permiten construir soluciones que deleitan a nuestros usuarios.  Esta es una serie de siete artículos. En éste primero te hablaré de qué son y enLeer

En esta ocasión te presento las razones por qué hablo de lo que hablo en este canal. Visita mi web: https://www.edgarfernandez.com https://www.aprend-is.net Aprende a estimar proyectos de software: http://bit.ly/estimacionpromo Videos mencionados: Mi experiencia con Rambo: https://www.youtube.com/watch?v=qllc56_uR6c ¿Qué hace un Ing. de Software?: https://www.youtube.com/watch?v=uRiXseiYOUQ ¿Cómo quebré mi empresa? https://www.youtube.com/watch?v=LjZYZbVKJMQ Música De fondo: "Hard Boiled", por Kevin MacLeod (https://incompetech.com) Intro: Virus, por Dzynek