3. La gestión del equipo técnico humano en una Startup. Francisco Javier Cervigon Ruckauer

3. La gestión del equipo técnico humano en una Startup:


Introducción

Hace ya unos años, en lo que refiere a organización de equipos técnicos, Barry Boehm enunciaba en su libro “Software Engineering Economics” (1984) los que para él eran los cinco principios a tener en cuenta a la hora de disponer de un buen equipo de desarrollo software:
    • Talento: usa el menor número de personas y que sean los mejores.
    • Ajusta: las tareas a los conocimientos y motivación de las personas.
    • Progresa: ayuda a la gente a estar al día y progresar.
    • Balancea: selecciona personas que se complementen y armonicen los unos con los otros.
    • Elimina: remplaza lo más rápido posible a los miembros problemáticos del equipo.
Simples, efectivos y muchas veces tan difíciles de ver. A lo largo de esta lección nos detendremos en cada uno de estos principios.
A modo de adelanto, la siguiente figura ilustra la diferencia entre los equipos clásicos y los equipos multifuncionales, más propios de los tiempos modernos y el desarrollo ágil.


Referencias


ENTREVISTA AEGON





























Invierte en un buen proceso de selección

Esta es otra de esas cosas que después de pasar por un montón de empresas acabas asumiendo que ya es un patrón, se repite demasiadas veces: se cuida muy poco tener un buen proceso de selección.
Un buen proceso de selección es algo que va más allá de tener una cuenta en Infojobs o similares, y que va incluso más allá de tener un buen Headhunter.
Un proceso de selección implica tener bien afinado el método por el cual finalmente se elige a un candidato para un puesto tecnológico. Método que se cuida muy poco, y que al final se acaba basando en poco más que fiarnos de referencias, conectar con la persona o encontrar frases ostentosas y cursos de nombre exótico en el currículum (mucho mejor si están en inglés).
Es curioso como hay empresas que se gastan una buena cantidad de dinero en Headhunters y que están dispuestas a invertir una buena cantidad de dinero en un puesto de tecnólogo y luego descuidan lo más importante: el proceso de selección.
Aunque en su momento nosotros hicimos un humilde procedimiento al respecto (ya antiguo y que además solo cubre métodos de desarrollo), después de haber visto cometer muchos y graves errores en procesos de selección, que tienen grandes implicaciones humanas y económicas y, además a muy largo plazo, la recomendación es encargarlo a un externo especializado en procesos de selección.
Lo sensato es que al igual que se dispone de un Headhunter, dispongas de otro profesional o empresa de referencia para que ellos te hagan el proceso de selección. Y lo más sensato es hacer esta externalización por dos razones:
  • La tecnología y los métodos para desarrollar evolucionan tan rápido que es muy difícil que tú, o internamente tu empresa, tengáis los conocimientos para evaluar a alguien, más si contratas a alguien para que desarrolle una tecnología que en tu empresa aún no desarrolláis. Si no tenéis experiencia en ello ¿cómo vais a seleccionar a un buen candidato? Dejarlo a la intuición y otros factores similares es demasiado riesgoso.
  • Si son siempre los de dentro los que seleccionan a los nuevos, las empresas se vuelven muy “endogámicas”, se acaba creando un patrón de profesionales muy parecidos, con los mismos puntos fuertes y debilidades. Busca una opinión de fuera.
El caso es que curiosamente hay pocos que presten buenos servicios de selección y casi nadie que recurra a ellos. Será por ello por lo que en el mundo anglosajón (Laakmann, 2011) no se deja de vender libros sobre cómo hacer y superar una entrevista de trabajo para ser programador
Es esa idea obsesiva que tienen muchos gerentes y directivos de que las importantes necesidades de cualificación profesional de algunos de los profesionales que trabajan en sus empresas se podían solucionar con formación. Solo con formación. Con un curso.
Para que te hagas una idea del problema, participé hace años en un proyecto largo y complicado, al que llegué cuando la cosa ya estaba realmente mal, y aún fue a peor. Gran parte de los problemas venían del hecho de que, ni los que dirigían el proyecto, ni gran parte de los que lo programaban en él, tenían ni formación técnica, ni conocimientos técnicos (al nivel que requería el proyecto).
Cuando el problema salía a la luz, la respuesta de la dirección era siempre la misma: eso se soluciona con formación. Hay que buscar un curso. Entiendo que decir “hace falta formación” deje tranquilas las conciencias, dé algo de tiempo, pero en ciertas situaciones, no soluciona los problemas.
Un profesional que conoce lo que es el control de versiones, y ha trabajado con SVN, puede con formación actualizarse y adaptarse rápido a trabajar con Git. Un profesional que lleva años programando en un lenguaje orientado a objetos, puede con formación adaptarse a utilizar otro lenguaje orientado a objetos, etc. Pero un gerente que tiene que gestionar proyectos de tecnología, un responsable de proyecto al frente de un proyecto tecnológico o alguien dedicado a labores técnicas sin ningún conocimiento técnico, necesita algo más que un curso de formación. O más bien, necesita muchos y de larga duración, quizá de años.
Este es un tema recurrente que ha dado lugar a muchas reflexiones sobre cómo gestionar lo que se conoce como el “peopleware” de un proyecto.
Por ejemplo, Peopleware: Productive projects and teams o Rapid Development: Taming Wild Software Schedules son libros que hablan de que el buen profesional nace, no se hace. “La gente por lo general no suele quedarse el tiempo suficiente en una empresa para cambiar de arriba abajo y un gerente simplemente no tiene suficiente influencia en la gente para cambiar su naturaleza”, decía DeMarco.
Así que la gente que trabaja en un proyecto será siempre más o menos igual durante el tiempo que estén en él. Si están muy alejados de ser adecuados para el trabajo desde el principio, probablemente nunca lo serán.
Y todo ello acaba en una moraleja de la gestión de proyectos software tan repetida como obviada: muchos de los problemas que se materializan al final de estos proyectos vienen de los orígenes del mismo, por ejemplo de no saber seleccionar bien la gente que se incorpora a un proyecto. No hay buenos ni malos profesionales en general, hay profesionales apropiados y no apropiados para un proyecto. Eso si, si llenas el proyecto de gente no apropiada para llevarlo a cabo, probablemente siempre lo serán, por muchos cursos que reciban.

Referencias

  • Laakmann, G. (2015). Cracking the Coding Interview: 189 Programming Questions and Solutions. CareerCup.



Utiliza un proceso de selección sin sentido y tendrás una empresa sin sentido

Para ilustrar la importancia de seleccionar adecuadamente al equipo técnico de tu empresa y, sobre todo, para mostrarte cómo NO deberías hacerlo, a continuación queremos transcribir aquí uno de los posts del Blog de Javier:
Cuando en Julio terminé el último curso de la carrera, ingeniería informática, tenía claro que hasta septiembre no tenía mucho sentido buscar trabajo, dado lo próximo que estaba el periodo vacacional y el consiguiente parón en las empresas.
Mientras esperaba la fecha de ponerme a enviar currículums, dedique aquel verano a preparar las futuras entrevistas. Y para ello, cree un plan de lectura, que ejecuté concienzudamente durante julio y agosto.
Aquel plan de lectura, a veces de re-lectura, y de preparación para el futuro laboral, y las entrevistas previas, incluyó principalmente libros como aquel enorme Object-Oriented Software Construction de Meyer, Extreme programming explainedde Beck, el Rapid Development: Taming Wild Software Schedules de McConnell, el Use case driven object modelin with UML: A practical approach (object tecnology series) de Rosenberg & Scott), etc.
La tarea fue dura, más aún al ejecutarse bajo en arduo verano Manchego.
Pero prácticamente completé al 100% los objetivos establecidos, destacando superar varios libros de metodologías, los que había de agilidad en aquellos entonces (algo de Kent Beck y Cockburn), terminar (ufff) el Meyer y complementar la lectura del Design pattrns: Elements of reusable object-oriented software with applyng uml and patterns: An introduction to object-oriented analysis... analysis and design and iterative development de Gamma, E., Helm, R., Johnson, R., Larman, C. & Vlissides, implementaciones de aquellos patrones en Java (el libro estaba en C++) que pude descargar por aquel entonces de la web, la impresión de aquellos códigos en papel y el “traceo” e implementación de los mismos.
Al final, como siempre, septiembre llegó. Y con él, los periódicos de color salmón se llenaron, por fin, de ofertas de empleo tecnológico.
Ofertas a las que correspondí enviando el correspondiente currículum. Y las empresas, casi todas, correspondieron a su vez conmigo proponiéndome la correspondiente entrevista de trabajo, en Madrid.
La primera entrevista fue en una multinacional tecnológica. Acudí con confianza, la de haberme preparado concienzudamente durante el verano. Pero, para mi sorpresa, ninguna de las pruebas o preguntas tuvo relación alguna con algo técnico. Ninguna.
Aquella situación para mi sorprendente fue dejando de serlo, al repetirse la situación una y otra vez: ninguna de las pruebas o preguntas tenía relación alguna con algo técnico. Ninguna. Ninguna, en ninguna de aquellas entrevistas en despachos de impresionantes edificios, ni en pruebas grupales, allí en un auditórium rodeado de multitud de candidatos, entre los que tenía la sensación de ser el único con formación técnica.
Y, sí, sí, los puestos ofertados eran para “programador software”, “informático”, “analista de sistemas” o similares.
Aquellas pruebas de selección eran psicotécnicas o eran test de inglés. Y si había entrevista personal, las preguntas eran del tipo “tus mejores cinco cualidades”, “tus aficiones”, “te gusta trabajar en grupo”, etc.
Pero ninguna de las pruebas o preguntas tenía relación alguna con algo técnico. Ninguna. Pero ya no te hablo de un tema de patrones de diseño o similar, es que ni mirar una línea de código. Y te aseguro que, para mi desgracia, asombro y decepción, hice bastantes entrevistas. Pero es que ni siquiera la carrera que habías estudiado, en mi caso informática, era un tema a tratar en los procesos de selección, por aquel entonces bastaba con tener carrera.
“De poco había valido, de nada, aquel verano de lectura, de nada había valido lo que me enseñó Meyer, Beck, Cockburn, McConnel, etc.” Pensaba yo.
“Me he equivocado”. Aunque aquellos procesos de selección parecían absurdos, “¿cómo no seleccionaban a la gente para un puesto técnico en función de sus conocimientos técnicos?”. Yo estaba seguro de que me había equivocado: “si todas esas grandes empresas tecnológicas, multinacionales con miles de empleados, no preguntan nada técnico para los puestos técnicos, quién era yo para pensar lo contrario. Me había equivocado, alguna razón tendrían.
Es lo que tiene el tiempo, él pone a prueba tu confianza en ti mismo, y para ello pon tiempo de por medio entre lo que tú crees hoy ciegamente y las pruebas que te demostrarán estar en lo cierto (o falso), pruebas que llegaran tiempo después, entre tanto tienes que hacer el camino solo.
Finalmente, superé una de esas entrevistas en una multinacional. Sin necesidad de demostrar ningún conocimiento técnico, por supuesto.
Ya dentro, como trabajador, el tiempo pasaba y yo seguía sin ver donde estaba el truco de seleccionar personas sin evaluación de criterios técnicos, seguía sin verlo porque en una gran mayoría los conocimiento técnicos brillaban por su ausencia.
Y fue entonces cuando me di cuenta de que aquel verano de lectura y preparación no había sido un error.
No en vano, yo ahora era, prácticamente (y desgraciadamente), el único que en toda la empresa sabía de la existencia de unos tal Meyer, Beck, Cockburn, McConnel, etc. Y el ser el único tiene de bueno algunas cosas, que puedes elegir entrar en los, para ti, mejores proyectos, ya que si en ellos se pide saber de cosas que cuentan en los libros de Meyer, Beck, Cockburn o McConnel, tú eres el único que los conoces.

Referencias

  • Beck, K. (2000). Extreme programming explained: Embrace change. Addison-Wesley Professional.
  • Gamma, E., Helm, R., Johnson, R., Larman, C., & Vlissides, J. (2005). Design pattrns: Elements of reusable object-oriented software.Addison-Wesley.
  • McConnell, S. (2010). Rapid Development: Taming Wild Software Schedules. Microsoft Press.
  • Meyer, B. (1997). Object-Oriented Software Construction. Prentice Hall PTR (ECS Professional).
  • Rosenberg, D., & Scott, K. (1999). Use case driven object modelin with UML: A practical approach (object tecnology series). Addison-Wesley.



Qué se pide en las ofertas de empleo tecnológicas. Tendencias

Hace unos meses estábamos metidos en un proyecto formativo para el ámbito profesional, bastante ambicioso, en el que la agilidad, Scrum y la calidad software iban a ser pilar clave.
Para dicho proyecto pidieron una justificación de “qué papel juega hoy la agilidad en el mundo laboral”. Y la mejor forma de responder a esta petición pasaba por utilizar una herramienta que ya veníamos utilizando y que permite identificar tendencias entre las ofertas laborales publicadas (http://www.indeed.com/jobtrends).
Por si no lo conoces, Indeed.com es un meta-buscador de ofertas de empleo, que rastrea la Web en busca de ofertas en periódicos, páginas de empleo, asociaciones, etc. Gracias a la cantidad de datos que maneja, el buscador muestra cómo evoluciona en el tiempo la demanda de una tecnología o disciplina en las ofertas de empleo. Nosotros la utilizamos mucho para ver tendencias en tecnología.
Después de jugar un rato con el buscador de tendencias, os dejamos algunos gráficos de evolución interesantes (ojo, son del ámbito de los EEUU, por lo que aplicarán algún tiempo después en otras zonas del globo.




















ENTREVISTA BEEVA





























Las dependencias al agilizar los equipos 

Como en el bloque anterior, te dejamos aquí otro relato de Javier contando una de sus experiencias para ilustrar algunos de los conceptos que acabamos de presentar y el problema de las dependencias.
Cuando llegué por primera vez a la empresa ACME era lunes a primera hora de la mañana, mientras esperaba en la recepción, lo primero que vi fue un montón de gente reunida en una sala haciendo lo que ellos llamaban “daily meeting”.
Allí, en aquella reunión, había veintitantas personas. Cuando ACME inició su “transformación ágil”, una de las primeras cosas que abordó fue el problema de los equipos multitudinarios.
Como ya es bien sabido, un equipo que busca la máxima productividad debería controlar su “peso”, peso medido en número de personas que lo forman, donde la cifra que sirve de referencia es que no sean más de 10, por aquello de que los equipos con mucha gente (más de 7) son menos productivos, unido a lograr que los equipos fueran multifuncionales.
Pero a la hora de dividir ese gran equipo apareció un problema aún mayor que el de haberlo dejado como estaba: lasdependencias. Las dependencias suele ser el problema número uno cuando cuando una organización quiere estructurarse, digamos, de manera ágil. Las dependencias suelen venir de dos sitios, de las personas o de aspectos tecnológicos. Las dependencias de personas aparecen cuando hay héroes, personas que concentran exclusivamente todo el conocimiento sobre algo, que se convierten en el único que puede desarrollar una tarea.
Cuando por ejemplo un equipo de 20 personas se quiere dividir en dos de 10, si hay un héroe (un Rambo), éste irá a parar sólo a uno de esos dos nuevos equipos, y aquel equipo en el que no esté el héroe, dependerá siempre del primero para completar sus tareas.
En ACME hicimos uso de aquella técnica de escribir en las columnas de una tabla las principales competencias necesarias para completar el trabajo y en las filas de esa misma tabla los nombres de las personas del equipo. Pusimos un asterisco en aquella casilla donde una persona es experta en una competencia, detectando las columnas con un solo asterisco.
Así aparecieron los héroes que dificultaban la intención de escalar la agilidad. De hecho, las dependencias son tan importantes que en algunos “frameworks” para escalar agilidad, las dependencias son uno de los puntos clave. Por ejemplo, en Nexus, un marco para escalar Scrum (es decir para llevarlo a empresas grandes), las dependencias son una de las tareas claves del “Nexus Integration Team”. Aunque hagas uso de un framework para escalar la agilidad, las dependencias entre grupos debería ser una de tus primeras prioridades. 
Si, es posible evitar que solo unas pocas personas tengan el 100% del conocimiento de un proyecto o tarea, pero hay que ponerse manos a la obra, hay muchas técnicas que tratan sobre ello, ninguna seria se basa en cosas meramente burocráticas, como “documentar” todo lo posible para que el conocimiento no esté sólo en la mente del héroes. No existe la magia y lleva tiempo implantarlas.



Vídeo explicativo de un equipo auto-organizado

A continuación, se va a mostrar un vídeo explicativo del tamaño ideal de un equipo técnico.


























Lo que une a los equipos son las causas, no las empresas ni los proyectos



No, no. Que no, que lo que une a los equipos son las causas, no las empresas ni los proyectos. Las empresas y los proyectos no unen a los equipos… los juntan. Los reúnen bajo un mismo techo (y a veces ni eso), bajo un mismo nombre de empresa (el cual muchas veces a pocos les importa) y/o bajo una misma nómina (que nunca contenta a nadie).
Lo que une a los miembros de un equipo son las causas y el luchar por ellas, si éstas existen.
De todos nuestros trabajos, proyectos y dedicaciones, solo podemos recordar verdaderas situaciones de unión con los miembros del equipo cuando hubo alguna causa común por la que luchar.
Y lo curioso del asunto no es, desgraciadamente, lo poco que esto importa a las empresas. Tampoco es que la mayoría ni lo conozcan ni les interese. No, lo realmente curioso es que las empresas o no propician una causa de unión o propician una mala causa (mala también para ellas mismas, obviamente).
Recordemos a modo de ejemplo causas en las que yo he participado y que realmente vi que unieron, que no juntaron, a un equipo para “luchar hasta la muerte”:
    • Luchar contra el injusto trato de gerentes Troglodita Management que vendían proyectos en tiempos irrealizables, se despedían de aquellos que harían el proyecto y les dejaban el marrón a los que nos tocaba hacerlo.
    • Luchar contra ese ERE que cada fin de mes despedía a 20 compañeros (al menos antes era con indemnización, ahora ya ni eso).
    • Luchar contra el frío, contra programar con el abrigo puesto, contra programar en lugares inundados, etc.
Es suficiente, no hace falta seguir enumerando.
Esas causas sí que unen a un equipo hasta la muerte, a trabajar sin descanso por ellas. Por desgracia.
Esas sí, y no el ir diciendo lo grande que es tu empresa, los países en los que está, los clientes que tiene y los millones que factura.
Y espera que ahora viene lo importante… además de las causas que luchan contra la desigualdad y el maltrato hay otras causas que unen a un equipo. Causas que son hasta buenas causas. Sí, sí.
Y como la anterior, todo aquel grupo, empresa, etc., que ha creado algo grande ha tenido una causa por la cual hacerlo. Más allá de empresas piensa en la causa que unió a aquellos que dedicaron su tiempo libre para crear algún software libre o piensa en las causas que defendieron las principales y referentes empresas de tecnología.


Reglas para el buen uso de recompensas a la hora de motivar

Este tema lo tratan muchos libros, y vamos a compartir aquí algunas buenas prácticas para orientar las recompensas.
Os dejamos 6 buenas prácticas para recompensar a los miembros de los equipos, concretamente las que expone el libroManagement 3.0 de Jurgen Appelo, que quizá sea el más popular sobre el tema:
  • 1. No prometas todas las recompensas por adelantado. Recompensa en momentos inesperados.
  • 2. Pequeñas recompensas anticipadas. Pequeñas recompensas son más efectivas para fomentar las ganas de trabajar y pueden ser más frecuentes.


  • 3. Recompensas de forma continua, no solo una vez. No busques una recompensa puntual… cada día puede ser un buen día para celebrar algo.
  • 4. Recompensas en público, no en privado. El objetivo de dar recompensas es reconocer buenas prácticas y que la gente disfrute de su trabajo y de manera pública puede funcionar mejor que de manera privada.


  • 5. Recompensar el comportamiento, no el resultado. Recompensa la buena conducta, si solo te centras en los resultados… puedes generar una cultura peligrosa.
  • 6. Recompensa también a compañeros, no solo a subordinados. Los compañeros se conocen mejor entre ellos que los superiores y también merecen un cumplido.


Seguir estas reglas para recompensar, da la oportunidad de aumentar el rendimiento de las personas y el disfrute del trabajo fomentando la motivación interna. Por ejemplo, un “¡buen trabajo!” O un “¡bien hecho!”, puede aumentar la autoestima y animar al equipo a seguir haciendo su trabajo como hasta el momento, con ganas y motivación, dando como resultado proyectos con la mejor calidad, que es lo que busca una organización, el éxito de sus proyectos. Recuerda que las personas son lo más importante para el éxito o el fracaso de un proyecto, por ello es una buena práctica recompensar cuando es merecido.

Referencias

  • Appelo, J. (2011). Management 3.0: Leading Agile Developers, Developing Agile Leaders. Pearson Education.




El método de Kudo Box

Kudo Box es un método para recompensar, sencillo pero eficaz, que cumple con las 6 reglas para dar recompensas (que hemos visto anteriormente). Este método consiste en instalar una caja (como por ejemplo la que vemos figura de más abajo), Kudo Box, que permite a los miembros del grupo dejar en la misma una pequeña recompensa, ya sean pequeños obsequios, notas de agradecimiento o de reconocimiento del esfuerzo y el trabajo… Puedes leer una descripción más completa del mismo en el libro Management 3.0 de Jurgen Appelo.
El nombre de este método viene de Paul Klipo, el ex presidente de Lunar Lógica Polska en Polonia. En ella, sus empleados podían dar a sus compañeros un regalo por valor de 20€. Lo llamaron Kudos y consistiría en una caja en la que pudieran dejar esa recompensa cuando alguien en la compañía sentía que otro merecía una recompensa.
De esta manera, serían recompensas públicas (una de las 6 reglas que vimos). Todos los miembros de la organización participan en esta iniciativa y puede usarse de forma anónima o no. Todo esto, dio como resultado un sistema de recompensas de bajo costo.
Un sistema similar, llamado “LoveMachine” (hacer a los empleados felices), fue implantado por Philip Rosedale, ex director ejecutivo de Linen Lab. Este sistema permitía a los miembros del grupo enviar notas de agradecimiento a sus compañeros, de forma muy similar al sistema Kudo Box.
Hay otros nombres para este sistema como “HERO awards” en Zappos y que funciona de manera similar a los anteriores, pero no importa el nombre, todos ellos son un sistema que permite a la gente darse entre ellos pequeños obsequios inesperados de agradecimiento por un trabajo y además también permite a la persona apreciar el cumplido, y eso, también tiene valor.






Vídeo explicativo de la técnica Kudo Box

A continuación, se va a mostrar un vídeo explicativo de la técnica del Kudo Box


























El calendario Niko-Niko

Hay equipos que utilizan el llamado calendario Niko-Niko (en japonés significa sonreír), también conocido como calendario de la felicidad o índice de la felicidad.
Hay empresas que van más allá, por ejemplo, la de Kniberg, y consideran el índice de la felicidad como un parámetro más importante que los índices financieros.
En la empresa de Henrik Kniberg (te dejamos la entrevista que le hicimos) lo miden continuamente a través de una hoja de cálculo de Google, que la gente actualiza aproximadamente una vez al mes y que tiene las siguientes columnas:
  • Nombre
  • ¿Cómo de feliz eres en la empresa? (escala 1-5)
  • Última actualización
  • ¿Qué es lo mejor?
  • ¿Qué es lo peor?
  • ¿Qué haría aumentar tu índice de felicidad?
  • Otros comentarios
Además, trazan la historia y cómo se correlaciona con eventos. Según comenta, “Si vemos un 1 o 2 en cualquier fila, esto actúa como una llamada de ayuda”.
Consiste en poner en filas los miembros del equipo, en columnas los días y animar a que cada uno dibuje una carita al final del día indicando cuál ha sido su estado de ánimo. Las caras pueden ser felices, indiferentes o tristes. Para que sea más visual, se suele asociar un color distinto a cada carita, como verde para feliz y rojo para triste.
Después a intervalos regulares de tiempo (por ejemplo, en la retrospectiva del sprint, o incluso antes), se echa un vistazo al calendario y se analizan los datos. Así podremos detectar más rápidamente posibles problemas que puedan ocurrir.
Nosotros, usamos la técnica Niko-Niko para medir la felicidad. A parte de problemas relacionados con el trabajo, nosotros también consideramos problemas ajenos que pueden causar una baja productividad, y no solo cuestiones internas como distracciones, muchas tareas abiertas, que se produzca slack (saturación de trabajo) ...
En primer lugar, cada uno de los miembros del equipo ha elegido un dibujo o avatar; por otro lado, tenemos tres colores, rojo para cuando la productividad ha sido baja o se ha tenido algún problema, verde cuando ha ido todo bien, no se ha tenido ningún problema y azul algo intermedio.
Nuestro calendario es diario, es decir, cada uno de los miembros del equipo, al final de la jornada laboral diaria, coge el rotulador de color que crean oportuno según el día que hayan pasado y dibujarán su avatar en el calendario, en el día correspondiente y del color elegido, de esta manera es más fácil saber cómo estamos, y si ha habido algún problema, en un rato o en alguna reunión las hablamos y las solucionamos.
La siguiente imagen es nuestro calendario Niko-Niko. Como se puede ver por cada uno de los días hay un avatar dibujado, los días que no hay es porque no se podido ir (por viajes de trabajo, cosas personales, etc.) y los días que los avatares no son de color verde, son a causa de los problemas que se hayan podido tener.































Vídeo explicativo del calendario Niko-Niko

A continuación, se va a mostrar un vídeo explicativo del calendario Niko-Niko


























Referencias:

Libro: McConnell, S. (2010). Rapid Development: Taming Wild Software Schedules. Microsoft Press.
Francisco Javier Cervigon Ruckauer

No hay comentarios:

Publicar un comentario