Posts Tagged ‘scrum’

h1

¿Cuál es el rol de un Scrum Master en un proyecto ágil?

07/04/2014

Wizdoc [Icon By Buuf]  Tips & Tricks.

Caminar sobre el agua y desarrollar software a partir de una especificación son fáciles… si ambos están congelados.

— Edward V. Berard, ingeniero de software y autor estadounidense.

Desde hace tiempo, he venido predicando y evangelizando acerca de las metodologías ágiles; especialmente Scrum y Extreme Programming. Ahora bien, muchos de los neófitos suelen ser muy cautelosos y hasta escépticos en cuanto a los beneficios que éstas pueden aportar. Una de las preguntas más comunes que he escuchado, consiste en qué rol debe tomar un Scrum Master (SCM) como parte del proyecto ágil; la gran mayoría cree que el SCM es un “administrador de proyectos” o “líder técnico”, quien debe asumir la responsabilidad sobre el proyecto y los integrantes del equipo, dirigiendo las tareas o asignando responsabilidades durante de la ejecución del mismo. Nada más alejado de la verdad, ya que el SCM es el guardián del proceso… y no mucho más. De hecho, si el equipo de trabajo ya cuenta con el conocimiento necesario para llevar a cabo las ceremonias y generar los artefactos de manera adecuada, en cada ciclo o iteración de desarrollo es posible que el rol de Scrum Master sea tomado por algún miembro del equipo diferente en cada ocasión; no necesariamente el responsable técnico o el más senior del grupo. Debido a esto, presento a continuación las tareas desempeñadas por un SCM como parte de un proyecto, basándome en mi propia experiencia durante estos últimos años:

Se coordina con el Product Owner (PO). Un Scrum Master debe trabajar en conjunto con el PO para facilitar las actividades requeridas y cumplir con el release. Estas actividades incluyen aportar activamente durante la priorización del backlog, rastrear actualizaciones relacionadas al sprint actual, alzar la mano cuando se detecte algún riesgo, o trabajar con el PO para seleccionar los elementos a implementar durante el siguiente sprint.

Se convierte en el enlace entre el equipo de trabajo y el Product Owner. En muchas ocasiones, el PO es una persona con un background de negocios, por lo que hablarle en bits y bytes puede convertirse en todo un reto; esto es especialmente crítico, ya que para que Scrum sea exitoso, es necesaria una interacción constante entre el Product Owner y los desarrolladores. Por ello es importante que el Scrum Master mantenga a todos en sintonía, ya sea mediante sesiones grupales para aclaración de dudas o reuniones “uno a uno” donde el Scrum Master participa como moderador. De acuerdo a mi experiencia, el equipo usualmente pregunta poco durante la sesión de planeación del sprint, dejando casi todas las dudas para sesiones de preguntas y respuestas posteriores. Entonces, es recomendable calendarizar este tipo de reuniones una vez que inicie el análisis de historias de usuario, incluso a manera de reverse knowledge transfer, en el que el desarrollador le explica al PO, en sus propias palabras, qué es lo que entendió de la historia de usuario a implementar. Así mismo, para evitar que una sesión de este tipo se convierta en una reunión maratónica, es una buena idea acordar un tiempo fijo o timebox. El SCM debe entonces evitar que la reunión se desvíe del tema principal y todos los involucrados vayan directo al grano.

Facilita la demostración del sprint y la retrospectiva. El SCM es usualmente el indicado para calendarizar y facilitar la revisión al final del sprint, en la que los miembros del equipo muestran a los stakeholders el trabajo terminado. Ya que seguramente los participantes harán preguntas y proporcionarán retroalimentación al equipo, el Scrum Master puede actuar como escriba o moderador. Para las retrospectivas, un SCM experimentado puede ayudar a que los participantes “se aflojen”, para que las preguntas ¿Qué salió bien? ¿Qué salió mal? ¿Cómo podemos mejorar para la próxima en base a nuestras lecciones aprendidas? Puedan contestarse de forma honesta y ordenada, ayudando a que el equipo se concentre en cómo mejorar, en vez de designar culpables. Para proyectos pequeños o medianos en los que existan de uno a tres equipos de desarrollo, la revisión al final del sprint así como la retrospectiva pueden realizarse de manera combinada mediante videoconferencia; cuando el staffing del proyecto sobrepase más de 30 participantes, es mucho más cómodo que el equipo líder (Scrum de Scrum Masters, Arquitecto Líder, Product Owner de Product Owners) sea la única voz de cara a los stakeholders; dejando a cada equipo hacer sus propias retrospectivas.

Protege al equipo del Product Owner. El Scrum Master debe impedir a como dé lugar que el objetivo del sprint cambie una vez que ha iniciado. Si el SCM se da cuenta que el PO está cambiando los objetivos a mitad del sprint, su labor deberá ser la de negociar con el Product Owner cómo intercambiar historias de usuario equivalentes en esfuerzo de acuerdo a la prioridad de entrega, dejando las historias removidas de vuelta en el product backlog para su posterior implementación. Esto no es ideal, pero es bastante más sano que cancelar el sprint completo. Por otro lado, si esta re-priorización se vuelve la norma, es aconsejable adoptar un modelo de Scrumban, en el que se acuerda con el PO limitar el monto de trabajo por fase (por hacer, en ejecución, terminado), permitiendo intercambiar las tareas o entregables en cualquier momento. También es recomendable aclarar con el Product Owner que este intercambio de tareas tiene un costo: el “cambio de contexto” o tiempo mínimo necesario para cambiar de la tarea A a la tarea B, puede incrementar hasta en 24% el tiempo del proyecto si se le usa de manera constante.

Representa al equipo en el Scrum de Scrums (SoS). Sólo stakeholders de alto nivel participan en esta reunión. Si el equipo tiene múltiples reuniones internas, típicamente cada SCM representará a su equipo en un SoS. El Scrum Master puede ir acompañado durante esta reunión, ya que cualquier miembro del equipo puede proporcionar estas actualizaciones. Sin embargo, el SCM es quien debería saber lo que está pasando con su equipo en todo momento, y debería estar al tanto de cualquier plan de acción que pretenda llevarse a cabo. Durante el SoS es bastante común que se discutan cuestiones de diseño técnico así como reglas de negocio e impedimentos que afecten al proyecto en su conjunto, tales como problemas de infraestructura y regulatorios. Los participantes idealmente deberán ser Scrum Masters, Product Owners, arquitectos, gerentes de proyecto, etcétera.

Facilita los daily standups. El scrum diario es una reunión en la que los miembros del equipo proporcionan actualizaciones sobre su trabajo, comentando qué hicieron ayer, que piensan hacer hoy y qué obstáculos se encuentran en su camino. El SCM debe asegurarse que los standups tengan una duración definida y que la conversación fluya correctamente – es decir, evitar concentrarse en los detalles o permanecer demasiado tiempo hablando acerca de un tema particular. Si es necesario, el Scrum Master puede tomar nota y calendarizar sesiones adicionales para tratar temas puntuales.

Ayuda a remover impedimentos que bloqueen el trabajo del equipo. Esta es de hecho, la tarea más importante que debe desempeñar el Scrum Master. Si el equipo se enfrenta a un reto que impida entregar el trabajo acordado, el SCM debe entender de qué se trata y cómo resolverlo, coordinándose con otros stakeholders para “despejar el camino”. Si el problema está “fuera de su jurisdicción”, es indispensable que el Scrum Master escale el problema lo más pronto posible.

Se convierte en un coach ágil. En caso de que algún miembro del equipo no conozca del todo el proceso ágil, es responsabilidad del Scrum Master que todos aprendan y sigan las prácticas de la metodología correctamente.

Tiene que hacer cumplir la definición de Terminado. El SCM debe asegurarse que el equipo se adhiere a la “Definición de Terminado”; es decir, una lista previamente negociada y aceptada entre los integrantes del equipo, en la que se define bajo qué criterios el trabajo es considerado como finalizado. Por ejemplo, (1) debe cumplir con los criterios de aceptación definidos en la historia de usuario, (2) las pruebas unitarias, de integración y de aceptación deben haber sido terminadas, (3) deben existir cero defectos de severidad alta y (4) la revisión de código por algún colega debe haberse completado.

Facilita la sesión de planeación. La sesión de planeación es aquella en la que el equipo decide el objetivo del sprint y cuáles elementos del Product Backlog serán seleccionados para implementarse durante la presente iteración. Usualmente durante los primeros sprints, el Scrum Master es quien definirá o reforzará las reglas del Planning Poker usado para dimensionar las historias de usuario en términos de puntos de historia (por ejemplo: la serie de Fibonacci o “puntos perro“).

Conclusiones

Aunque la mayoría de las actividades que desempeña un SCM han sido cubiertas en este post, pueden presentarse muchas más actividades que dependen de la naturaleza del proyecto. Por ejemplo, en un equipo de desarrollo, el SCM era un excelente arquitecto en Java, por lo que además de sus funciones como Scrum Master, colaboró con el líder técnico del equipo para definir una arquitectura que fuese fácil de implementar y mantener. Por otro lado, en un caso que me tocó personalmente, en el que desempeñando la labor de Scrum de Scrum Masters, también tenía que fungir como Program Manager, llevando el tracking de varios equipos y proyectos operando simultáneamente, comunicando el avance y problemas a la alta dirección mediante presentaciones especialmente hechas para este fin – así es, de esas con portafolios, semáforos y “tiburones” listos para desayunarse al presentador si ellos ven algo que no les gusta.

h1

Una adopción ágil: retos y soluciones

02/14/2014

Wizdoc [Icon By Buuf]  Tips & Tricks.

Primero, tienes que aprender las reglas del juego. Luego, tienes que jugar mejor que nadie.

Albert Einstein (1879 – 1955). Físico judeo-alemán, nacionalizado suizo y posteriormente, estadounidense.

Desde hace poco menos de un año hemos venido trabajando con varias células de desarrollo ágil para un cliente que en aquél entonces era relativamente inexperto en esta metodología. Algunas de estas células han sido todo un éxito, compuestas por gente altamente calificada que trabaja como uña y mugre con el Product Owner (PO) perteneciente al cliente, mientras lanzan funcionalidad a producción como si fueran una fábrica de juguetes china. Otras células menos afortunadas han tenido que afrontar duros retos, incluyendo gente sin la suficiente experiencia para implementar el stack tecnológico y grado de colaboración necesarios para lidiar con proyectos y clientes complicados.

Pues bien, a partir de enero de este año, el cliente nos solicitó integrar Extreme Programming (XP) como parte de la implementación ágil, sin dejar de lado Scrum como framework de gestión de proyectos. Esto requirió un poco de flexibilidad entre ambas partes para incluir una serie de nuevos controles, tales como:

• Programación por pares, donde el trabajo es desempeñado por dos desarrolladores en vez de hacerlo de forma individual.

• El refactoring y la integración continua han tomado un rol mucho más importante durante el ciclo de desarrollo.

• Ahora existe una “propiedad colectiva del código”, en la que cualquiera puede modificar el código de otro, siempre que éste cambio sea respaldado por las mandatorias pruebas unitarias así como una correcta integración continua, evitando los así denominados cowboy coders: programadores muy buenos, pero que siempre dejan detrás de ellos un revoltijo inmantenible de código.

• La planeación ahora debe tomar en cuenta spikes de XP, los que en realidad son experimentos, análisis técnicos o pruebas de concepto que incluyen una revisión formal por parte del cliente.

• Anteriormente, la definición de “terminado” significaba tener algo listo para la demo. Ahora, ésta ha cambiado a “cuando el cliente lo haya probado satisfactoriamente”. Esto significa que durante el Sprint, el cliente realiza pruebas sobre los entregables, previo a la sesión de demostración.

• El análisis y diseño arquitectónico deben hacer uso de “metáforas”, o historias muy sencillas que explican cómo funciona el sistema. Esto se debe a que para el análisis, debemos interactuar con “embajadores” que oficialmente fungen como enlace entre las áreas de negocio y TI. Por ello la necesidad de explicarles cómo funcionan las cosas en términos “que hasta un niño pueda entender”.

Estos puntos han derivado en que el equipo tenga que reforzar la disciplina, pues si no tenemos cuidado, podemos terminar con una dinámica de grupo totalmente anárquica, en la que cada quien hace lo que quiere. Esto es más aparente si tomamos en cuenta que ahora todos trabajan en pares y pueden “tocar” cualquier parte del código. Por otro lado, el beneficio principal y la razón por la que el cliente ha considerado hacer este cambio, es que ya somos lo suficientemente maduros como para evolucionar el proceso hasta la fase de innovación:

pic: Enterprise agility adoption roadmap

Roadmap de adopción ágil. Generalmente, todo inicia con una fase de experimentación a través de un proyecto piloto con sólo un equipo de trabajo (Pasos 1 y 2). Posteriormente, corremos una fase de lanzamiento, donde varios equipos ágiles trabajan en paralelo sobre un mismo programa (Pasos 3 y 4). Después, ejecutamos un rollout general, donde establecemos ágil a nivel portafolio (Paso 4). Finalmente, viene la fase de innovación (Paso 5), en la que se implementan prácticas como colaboración remota y configuración de un ALM comercial. (Fuente de la imagen: appslog.com)

Lo que debe quedar muy claro, es que antes de llegar a esta fase, debimos haber alcanzado el punto en el que el cliente confía en nosotros lo suficiente como para sólo indicarnos cuál es el valor de negocio de la funcionalidad a entregar, dejando a nuestro criterio todo lo demás. Es decir, el momento en el que se le ha cedido el control y mando al equipo.

Los principales retos durante la adopción

Tanto la adopción ágil en general, como la implementación de XP en particular, han implicado muchísimos retos que sobre todo, tienen que ver con el lado humano. Ciertamente, desde hacía tiempo ya habíamos cubierto el tema del ciclo de desarrollo o SDLC y la calidad de los entregables; por lo que ahora debíamos lidiar con temas como “… ¿por qué debo sentarme con este tío a programar?” El cambio de algunos paradigmas, incluso entre gente “ágil”, no es cosa sencilla. A continuación, enumero los mayores retos que llegamos a enfrentar y cómo los hemos mitigado:

• El primero, y más importante de todos: ágil no significa que terminaremos un proyecto en menos tiempo. Este es un concepto erróneo que muchos usan como argumento de venta. La realidad es que el mayor beneficio de ágil, desde el punto de vista de negocio, son las liberaciones tempranas: ¿Para qué esperar seis meses a tener todo terminado, si desde el primer mes ya existe un entregable “listo para liberar a producción” que puede indicarnos si el proyecto está destinado al éxito o al fracaso? Obviamente, tendremos que esperar otros cinco meses para tener todo al 100%, pero desde el primer mes tendremos algo tangible y generando un ingreso, o podemos darnos cuenta que el caso de negocio era erróneo, teniendo la posibilidad de “tirar del enchufe” cuando apenas se ha gastado una pequeña fracción del presupuesto.

• Interdependencias entre equipos y proyectos. Aunque Scrum hace énfasis en que no existan interdependencias entre equipos, la realidad es que esto es el pan nuestro de cada día. Por ejemplo, un equipo en Java desarrolla web services que serán consumidos por una aplicación en .net desarrollada por otro equipo. En este caso, podemos echar mano de un perfil que no viene descrito en el framework original, conocido como Technical Owner (TO), que está al mismo nivel del Scrum of Scrum Masters. El TO es el responsable de la arquitectura de un programa o portafolio, definiendo interfaces y dependencias. Así mismo, debe apoyar en la definición del plan de liberación o release plan, evitando al máximo que nos pisemos los callos unos con otros, trazando una ruta crítica que tomará precedencia sobre cualquier otro ítem de los product backlogs para cada equipo involucrado:

pic: Scrum in an interdependent environment

El equipo 1 (rojo) hace Sprints de dos semanas y liberaciones cada mes; el equipo 2 (azul) ejecuta Sprints de cuatro semanas y libera cada dos meses. Sabiendo que el equipo 2 debe implementar ciertos componentes para que el equipo 1 pueda integrarlos, el Technical Owner debe apoyar a los Product Owners de ambos equipos para definir la ruta crítica y acordar quién hará qué y cuándo debe tenerlo listo. (Fuente de la imagen: cardinalsolutions.com)

Así, el TO apoyará en la generación de las especificaciones necesarias para que los equipos utilicen “mock ups” mientras tienen lista su parte. Finalmente, los POs deben considerar un Sprint o parte de éste dedicado a la integración, pruebas y refactoring entre ambos equipos.

• Dificultades para asegurar la calidad y generar los entregables de acuerdo a CMMi-L3. Desde un principio contamos con un miembro del equipo que podía fungir como “especialista técnico” (su puesto oficial es Tech Lead o TL, pero NO es el líder del equipo; tampoco tiene el rol de Scrum Master). Dicha persona colabora de forma muy estrecha con el TO para implementar adecuadamente la arquitectura definida por aquél, así como reforzar una correcta ejecución de desarrollo guiado por pruebas (TDD) e integración continua. En resumen: un TL no puede confiar en un software que no tenga un set de pruebas cuantificables que puedan ejecutarse con sólo pulsar un botón. Por otro lado, contamos con un par de Business Analysts (BA) encargados de verificar una correcta transferencia de conocimiento entre el cliente y el resto del equipo. Ya que esta transferencia está muy relacionada a la documentación requerida por CMMi, ellos son también los encargados de apoyar en esta tarea, liberando a los desarrolladores de cargas innecesarias.

• Scrum distribuido. Esta modalidad del proceso es una historia aparte, pero baste decir que en un par de células, algunos miembros del equipo pertenecen a offshore. Es decir, por un lado tenemos al Scrum Master, el tech lead, un desarrollador y un analista de negocio trabajando hombro con hombro con el cliente, mientras el resto del equipo – el tester, tres desarrolladores y otro business analyst – colabora desde literalmente, el otro lado del mundo. Desde un punto de vista táctico, el principal reto es la comunicación, confianza y respeto mutuo, así como diferencias culturales. En cuanto a estrategia de negocios, este modelo rebaja muchísimo los costos, pero también refleja una pequeña pero perceptible disminución en la productividad – en nuestra experiencia, a menos que todo el equipo este co-locado o ya se hayan resuelto diferencias culturales, los tiempos de ejecución se incrementarán hasta en un 25% debido precisamente, al overhead de comunicación.

Conclusiones

Cualquier adopción ágil y su correspondiente implementación tendrán retos a enfrentar, principalmente en las áreas de interdependencia entre equipos, manejo de recursos remotos y alineación del cliente. Sin embargo, si obtenemos el patrocinio sincero de high management – o como en nuestro caso, es una directiva que viene del cuartel general y debe adoptarse por todas sus subsidiarias alrededor del mundo – nuestros problemas serán mucho menores, limitándose a temas de madurez y alineación de procesos.

¿Dónde nos encontramos parados después de todo este ejercicio? Bastante bien, ya que después de diez meses, hemos trabajado de forma casi ininterrumpida, e incluso tenemos la oportunidad de expandir nuestras operaciones a otras unidades de negocio. Si todo sale bien, en un par de meses estaremos haciendo un copy + paste del proceso de adopción e implementación, aunque en esta ocasión, tendremos que enfrentar un área en la que personalmente no me siento tan fuerte: e-commerce.

h1

Implementando Scrum: un caso de la vida real (Parte 2)

07/14/2013

Wizdoc [Icon By Buuf]  Tips & Tricks.

La suerte no es un factor. La esperanza no es una estrategia. El miedo no es una opción.

James Cameron (n. 1954), director, guionista, productor de cine y explorador marino canadiense.

En el post pasado mostré un ejemplo de la vida real, con algunos de los tropiezos con los que podemos toparnos durante una implementación de Scrum. En resumidas cuentas, el usuario es nuevo en el paradigma ágil y por la premura de cerrar el contrato, a nosotros nos falló conseguir al personal adecuado, así como capacitarlos correctamente en las mejores prácticas de desarrollo ágil. Sin embargo, esto sólo es la punta del iceberg, ya que durante las siguientes iteraciones y para los demás equipos, tendremos que incluir una serie de medidas de control para asegurar la efectividad y eficiencia del proceso, así como de la calidad de los entregables.

Uno de los requerimientos más importantes para el cliente es una elevada productividad por cada Sprint, así que nos decidimos por un esquema de “trabajo especializado en paralelo”:

Tiempo (día) Planeación Análisis Diseño y Codificación Pruebas Despliegue
Planeación del Sprint
1 Recolectar reqs. del backlog        
2 Transf. de conocimiento de analistas hacia resto del equipo

Atomización de reqs. en tareas

Reunión de Sprint planning

     
3        
Ejecución del Sprint
4 – 13   Análisis para crear/insertar nuevos reqs. en backlog (siguiente Sprint) Diseño Ágil

Codificación

Pruebas Unitarias

Pruebas Funcionales

 
Cierre del Sprint
14         Reunión de Sprint review
15 Retro.        

Ciclo de “especialización en paralelo” con Scrum. Nótese cómo mientras una parte del equipo se enfoca a desarrollar los entregables del Sprint actual, otra parte (dos analistas) se dedica a realizar el análisis de requerimientos del siguiente Sprint.

Este modelo de tres semanas con análisis en T+1 es posible ya que cada célula incluye dos analistas de sistemas. Ciertamente esto contradice el paradigma ágil, ya que en teoría, todos los integrantes del equipo deben ser milusos o como dicen nuestros vecinos del norte, jack of all trades. Sin embargo, la misma figura literaria también dice: jack of all trades, master of none o lo que es lo mismo: quien mucho abarca, poco aprieta. Es decir, en algunas ocasiones es recomendable tener gente especializada en la célula que nos ayude a maximizar la eficiencia del equipo, pues por citar un ejemplo, un desarrollador promedio puede conocer PL/SQL y obtener buenos resultados, pero un DBA experimentado, “creará magia”.

Cabe recalcar que este esquema resultó exitoso en cuatro células pero falló catastróficamente en una de ellas. La manera más objetiva de demostrarlo es a través de números fríos: mientras la célula más productiva ha generado 819 story points durante las últimas 13 semanas, la peor ha generado tan sólo 130 que aun así, están siendo impugnados por el cliente. Esta falta de productividad fue achacada inicialmente a una falta de seguimiento en el proceso Scrum, sin embargo en términos generales, dicho proceso fue seguido al pie de la letra; el problema derivó en no implementar correctamente la construcción de los entregables. Este proceso, separado de Scrum, es conocido como el ciclo de vida de desarrollo de software (Software Development Life Cycle o SDLC).

El desarrollo de software se compone de dos procesos

Cualquier proyecto de desarrollo de software está compuesto por dos familias de procesos fuertemente ligados que atacan aspectos muy diferentes del proyecto:

• El proceso de gestión de proyectos, que de acuerdo al Project Management Body of Knowledge (PMBOK), se compone por diez áreas de conocimiento: integración, alcance, tiempo, costos, calidad, recursos humanos, comunicación, riesgo, adquisición y stakeholders.

• El proceso de desarrollo de software o SDLC, enfocado a la entrega del producto y conformado por las disciplinas ya conocidas por todos: análisis de requerimientos, diseño, construcción, pruebas, despliegue, mantenimiento y gestión de la configuración.

El problema es que los neófitos en el paradigma ágil creen que cualquier metodología define ambos procesos, algo que es tan FALSO como que el PMBOK nos indique cómo implementar un plan de pruebas. Scrum está enfocado al proceso de gestión de proyectos, dejando que el equipo decida cómo implementar a nivel operativo sus desarrollos; por el contrario, metodologías como Extreme Programming (XP) se enfocan de lleno a la ingeniería de software y por ende, a la entrega y calidad del producto. Es así como una de las metodologías híbridas más utilizadas en la industria es la mancuerna Scrum/XP, ya que ésta permite una combinación ganadora:

↑ Prácticas de gestión de proyectos Gestión de Costos Gestión de adquisiciones Gestión del tiempo

Sprint

*40 Hrs./Semana

Gestión de RRHH

Scrum master

*Propiedad colectiva del código

*Cliente on-site

*Coach, no PM

  Alcance y reqs.

Product Owner

Product Backlog

*Juego de planeación

*Cliente on-site

*Historias

Gestión de la comunicación

Scrum diario

Reunión de Sprint planning

Reunión de Sprint review

*Cliente on-site

*Historias

Gestión de la integración

Sprint

Reunión de Sprint planning

Sprint backlog

*Juego de planeación

*Liberaciones cortas

Gestión del riesgo

Reunión de Sprint planning

Reunión de Sprint review

Scrum diario

*Juego de planeación

*Liberaciones cortas

*Programación orientada a pruebas

*Cliente on-site

↓ Prácticas de desarrollo de software Diseño de software

*Metáforas

*Diseño simple

Construcción de software

*Programación por pares

*Refactoring

*Propiedad colectiva del código

*Estándares de codificación

Gestión de la configuración

Build diario

*Integración continua

Gestión de la calidad

Reunión de Sprint review

*Programación orientada a pruebas

*Refactoring

*Cliente on-site

*Estándares de codificación


Combinación de metodologías de gestión de proyectos y desarrollo de software. En este caso, Scrum y Extreme Programming. Nota: las prácticas con (*) pertenecen a XP. (Fuente: just-another-blog-for-kicks @ blogspot.com)

Esta combinación incluye controles entre las disciplinas de gestión de proyectos y desarrollo de software, dejando fuera sólo la gestión de adquisición y costos, que podrían ser llevadas a cabo de forma adecuada por una Oficina de Proyectos o PMO. Como opinión personal, este ejercicio debería ayudarnos a entender que Scrum por sí solo no resolverá nuestros problemas, ya que no hay soluciones técnicas para problemas de gestión, pero puede haber soluciones administradas para problemas técnicos. Por ello la necesidad de complementarlo con mejores prácticas de otras metodologías o frameworks enfocados al nivel operativo.

Asegurando que todos hacen lo que dicen que hacen

Es así como hemos decidido verificar el seguimiento de estas prácticas a través de un checklist aplicado por un experto en la materia (Subject Matter Expert o SME) en colaboración con el resto del equipo, incluyendo el líder técnico (TL), los analistas (BA), los desarrolladores (DEV), el tester (TE) y el Scrum master (SCM):

Fase Punto de revisión Responsable Evidencia Resultado
Análisis Documentación elaborada por analistas está completada al 100% y están de acuerdo al objetivo de las historias de usuario seleccionadas para el presente Sprint. BA/TL Documento
Análisis La documentación aprobada está publicada, distribuida y disponible para todos los miembros del equipo. BA/ TL/ SCM TFS/ Sharepoint
Diseño Modelo de persistencia y modelo conceptual cumplen con alguno de los tres enfoques ORM: esquema primero, modelo primero, código primero. TL TFS/RSA
Diseño La arquitectura ya ha sido definida y comprendida por todo el equipo: cliente-servidor, N-capas, SOA. TL TFS/RSA
Construcción Los estándares de código han sido aplicados a todo artefacto de software construido de acuerdo a la filosofía de codificación adoptada. TL TFS/RSA
Construcción El ambiente de desarrollo está correctamente instalado y configurado en las instalaciones del cliente y si aplica, en las laptops de los desarrolladores. TL Ambiente verificado
Pruebas Unit tests para cada artefacto de software. TE/DEV Artefactos de software
Pruebas Matriz de pruebas actualizada con todos los casos y escenarios de prueba. TE Documento
Despliegue Obtener la documentación con los procedimientos de instalación y configuración de los entregables de software en los ambientes de QA, PERF y PROD TL Documento
Despliegue Verificar que existan procedimientos de gestión de cambios para los ambientes de QA, PERF y PROD. TL Documento

Lista de verificación para mejores prácticas del SDLC ágil.

Este es sólo un ejemplo, ya que dependiendo de la madurez del equipo o empresa que está implementando el proyecto, la lista puede tener más de 150 controles. De momento, nosotros no requerimos tantos (sólo 50-60 dependiendo de la tecnología usada), pero nuestra área de SQA ya nos adelantó la noticia que dentro de 6-8 meses certificaremos la cuenta en CMMI-5. Por ello, muy probablemente, acabaremos con una lista muy extensa, comprobada no sólo por nuestros SMEs, sino también por SQAs calificados o los appraisers que otorgan la certificación CMMI.

Conclusiones

El SDLC es el proceso que empleamos para desarrollar nuestros entregables. Y sin importar la metodología que ocupemos, si nuestro SDLC es inmaduro o deficiente, estamos en serios problemas. Sin embargo, NO existe un proceso único que pueda ser implementado por todos; incluso, debería ser lo suficientemente flexible como para cambiarlo de acuerdo a las necesidades de negocio o conforme va creciendo el alcance de nuestro proyecto. La situación es que siempre es necesario tener un proceso formal y comprendido por todos los involucrados, que pueda seguirse de forma sustentable. La alternativa es trabajar de forma desorganizada, o confiar ciegamente en que el equipo sabe lo que hace. Así que, nuestra mejor opción al adoptar ágil, consiste en adherirse al proceso de gestión, definir un SDLC formal, y hasta que estemos seguros que ambos procesos sean llevados a cabo de forma natural y repetible, es necesario introducir medidas de control para asegurarnos que todo funciona correctamente.

h1

Implementando Scrum: un caso de la vida real (Parte 1)

07/05/2013

Wizdoc [Icon By Buuf]  Tips & Tricks.

El éxito no es definitivo; el fracaso no es fatal: lo que cuenta es el coraje para continuar.

Winston Churchill (1874-1965), político y estadista británico.

Ahora que ya tenemos un par de meses implementando Scrum con un cliente relativamente inexperto en esta metodología, nos hemos llevado un par de chascos que seguramente pueden ocurrir en cualquier implementación donde no exista una definición concreta de expectativas, cuáles son sus procesos y artefactos, o aquellos que ejecutan el desarrollo no cuentan con los skills necesarios.

Pero empecemos por el principio: de entre cinco células ágiles, un equipo de desarrollo en Java “falló espectacularmente” de acuerdo al cliente. Esto provocó alerta entre nuestro “high management”, ya que el incidente puso en duda nuestra capacidad para trabajar con Scrum así como para generar los entregables de alta calidad que nos fueron solicitados. Aunque al principio esto se achacó a falta de conocimiento en los procesos ágiles, elaboramos un RCA en el que encontramos la verdadera causa del problema:

• Primero, el cliente se acercó a nuestra empresa solicitando células de desarrollo ágil. Inicialmente, pidió dos de “altísima urgencia”, advirtiéndonos que si no se conformaban e iniciaban los trabajos inmediatamente, encomendaría el proyecto a alguien más. Esto claramente fue para presionarnos, pues hasta la fecha, NO existe otro proveedor que esté ofreciendo este tipo de servicio a nuestro cliente.

• Luego, lo que el cliente solicitó fueron “células en Java y .Net”. Ni más ni menos. El requerimiento no incluyó un conjunto de tecnologías o perfiles específicos, ni en qué tipo de proyecto se estaría trabajando. Esto, aunado a la presión por iniciar de inmediato, significó que nuestra área de reclutamiento se limitó a buscar candidatos genéricos: “Hola, soy de la empresa X. ¿Sabes Java o .Net? ¿Sí? Te espero mañana para firma de contrato.” En el equipo .Net tuvimos muchísima suerte de contar con un desarrollador que ya conocía el tipo de arquitectura a implementar (Model-View-View-Model). En el equipo Java no tuvimos tanta suerte, pues el proyecto no sólo consistía en conocer el core del lenguaje, sino también en dominar una variada multitud de frameworks, herramientas y tecnologías como Spring, Hibernate, Websphere, JPA, JAX-WS o JSF.

Toy Stories: Noel (Texas, USA) ~ Gabriele Galimberti


Stack Tecnológico del equipo original. Como puede apreciarse en la tabla, las habilidades prácticas de las personas tendían a medio o bajo – sólo 16% de la experiencia podía ser considerada como “alta”. Sin un liderazgo técnico adecuado, el equipo estaba condenado desde un principio. (Dar click en imagen o aquí para ver a mayor escala)

• Dos semanas después de iniciado el delivery nos dimos cuenta que los skills requeridos eran muy especializados, ya que el proyecto se trata de implementar un SOA con todo y web services, flujos de trabajo, validaciones de negocio y colaboración constante con otros proveedores. Es decir, aparte de no contar con las habilidades necesarias para realizar su tarea, la gente tampoco tenía el “colmillo” para defenderse ante los demás proveedores o el mismo cliente, pues a la primera oportunidad, culparon de cualquier retraso a nuestro equipo.

• Después de otro par de semanas, tuvimos que cambiar de líder técnico y Scrum Master. ¿La razón? No supieron hacer “click” con el responsable del lado del cliente o Product Owner (PO), quien además de ser una persona bastante difícil de tratar, también tiene altos skills técnicos y funcionales – el típico “YO lo haría en dos horas. ¿Por qué TÚ vas a tardar un día en hacerlo?” Esto acentuó los problemas con el equipo, quienes presenciaban constantes discusiones a nivel técnico y administrativo con este personaje, además que se desmoralizaron al ver cómo sus líderes dejaban el proyecto con las piernas por delante.

• En la iteración tres ocurrió el desastre. Teniendo que entregar cuatro web services, el líder técnico cometió el error de “entrar al ruedo”, programando uno de éstos, pero desatendiendo el avance de los desarrolladores. Por otro lado, el Scrum Master no tomó suficiente ownership del equipo, pues cuando preguntaba “¿Cómo vas?” todos respondían “Bien”, sin que éste indagara más al respecto. Lo triste del asunto es que en realidad no iban nada bien – de hecho, algunos jamás probaron su código. Este exceso de confianza hacia los desarrolladores significó el principio del fin, ya que como cereza del pastel, nuestro tester jamás hizo las pruebas correspondientes sobre el código “terminado”.

• Durante la demostración al final del Sprint, todo reventó en nuestras manos: algunos desarrolladores sólo probaron en sus laptops; otros jamás probaron en absoluto. Sin embargo, nadie probó en el ambiente del cliente, así que durante la revisión de la demo, nada funcionó. El cliente, enfurecido, nos dijo que a partir de ese momento, su propia gente desarrollaría estos web services. Por lo pronto, esta célula estaba cancelada.

Y es así como hemos estado la última semana y media tratando de “salvar el honor”, pues aunque sabemos que el cliente ya está desarrollando los componentes por su cuenta, nosotros tenemos que entregar algo funcional para solicitar el pago por estas semanas de trabajo. A raíz de este incidente, hemos podido generar un plan de acción con el afán de que esto no se vuelva a repetir en el resto de las células, incluyendo controles para asegurar la efectividad de todos nosotros:

• Desde un inicio, contar con los recursos adecuados. Ahora, en las células nuevas, primero se presenta un líder técnico que “mide las aguas” para obtener el stack tecnológico y los perfiles requeridos. Posteriormente, dicho líder debe estar presente durante el proceso de reclutamiento, ya que la mejor manera de asegurar un buen recurso es contestando afirmativamente la pregunta: “si esta persona va a estar bajo mi responsabilidad, ¿me conviene traerlo a bordo?”

• Por otro lado, es necesario mejorar el liderazgo, pues no se ha dado una comunicación efectiva entre en líder técnico y el Scrum Master, además de que ha faltado ownership por parte de ambos. Básicamente, evitar la práctica de estarse pasando el mono.

• El cliente tiene un conocimiento muy bajo en metodologías ágiles. Es decir, ellos sólo recibieron el curso de dos días para convertirse en Scrum Master. Por ello, es necesario crear un par de workshops: el primero dirigido hacia los POs para que conozcan cuál es la verdadera función de un Product Owner y cuáles son las expectativas y entregables que deben estar manejando con el resto del equipo; el segundo debe estar dirigido hacia los ejecutivos del cliente (gerentes y directores) para que se den cuenta que ágil no es la “bala de plata”, al mismo tiempo que mostramos cuáles son las métricas con las que nos deberían estar midiendo, pues algunos entregables que nos están solicitando como “reportes de horas” y “cartas de aceptación” son algunos esquemas de control que se contraponen a la ideología de ágil.

• Finalmente, darnos cuenta que este problema no se debió a falta de conocimiento en ágil, sino a temas más pedestres como poco ownership, un líder técnico que quiso ser héroe, exceso de confianza entre el Scrum Master, el líder y el equipo así como poca experiencia por parte del equipo, puntualmente en el proceso de desarrollo de software (SDLC), y sus disciplinas más importantes, como integración continua, refactoring y pruebas de concepto. De hecho, el cliente mismo mencionó que el problema no era Scrum, sino los skills, actitud y experiencia de la gente. Después de todo, código entregado sin haber sido probado es un tema preocupante que no tiene que ver con conocimiento en (o la falta de) Scrum. Por ello estamos reforzando el proceso SDLC a través de dos expertos, uno en Java y uno en .Net, quienes asegurarán el correcto seguimiento de las prácticas de desarrollo ágil a través de las herramientas y procesos más adecuados.

De momento, sólo hemos visto un pequeño ejemplo de lo que puede pasar durante una implementación de ágil en un ambiente inmaduro. En el próximo post veremos que Scrum “de la vida real” no sólo consiste en leer los papeles de Ken Schwaber y esperar lo mejor: la realidad es que es necesario contar con el apoyo de una buena gestión de proyectos, un governance bien estructurado y hasta que no estemos seguros que el proceso está siendo seguido por todos los involucrados, deben existir algunos puntos de control para asegurar que todo marcha sobre ruedas.

h1

Cambio de hábito

04/18/2013

Wizdoc [Icon By Buuf]  Tips & Tricks.

Durante los últimos 33 años, me he visto en el espejo cada mañana y me he preguntado: “¿Si hoy fuera el último día de mi vida, ¿querría hacer lo que voy a hacer hoy?” Y cada vez que la respuesta ha sido “No” por demasiados días consecutivos, sé que necesito cambiar algo.

Steve Jobs (1955 – 2011), empresario e inventor estadounidense, cofundador, presidente y director ejecutivo de Apple, Inc.

Estas últimas semanas han estado bastante complicadas, ya que decidí cambiar de empresa. En la anterior estaba muy a gusto, pero los proyectos, clientes y línea de trabajo se habían vuelto rutinarios pues el desarrollo de software – que es la actividad que más me llama la atención – había disminuido al mínimo mientras cada vez más de mi tiempo lo dedicaba al soporte de nuestras aplicaciones desktop y soluciones de hardware.

Ahora bien, gracias a mis conocimientos en Scrum adquiridos a lo largo de estos últimos años, aunados a una certificación como Certified Scrum Professional que obtuve este pasado 2012, pude saltar con relativa facilidad. Y digo relativa, porque la empresa donde ahora me encuentro hace unos filtros bárbaros, con background checks que incluyen una fuerte entrega de documentos oficiales así como entrevistas remotas, en inglés y a deshoras – como a las 9:30 PM, por dar un ejemplo.

Ahora formo parte de un equipo de cuatro células de desarrollo con un promedio de 9 personas cada una… y puedo confirmar que el trabajo es una verdadera joda. Más porque estaba acostumbrado a proyectos con duración y staffing pequeños – 2 a 4 personas por 3 a 6 semanas – cuando en este momento, estamos llevando a cabo seis proyectos de 6 a 8 meses de duración entre 40 personas. En este momento le estoy entrando al quite operativo, recibiendo requerimientos mientras vamos definiendo las prácticas de Scrum que estaremos implementando con los equipos – como planning poker o el formato de las historias de usuario. Ya que soy “el nuevo”, me estoy apoyando mucho en los ScrumMasters veteranos pero aun así, los días se me van como agua entre juntas, definiciones y visitas customer-face.

En fin, uno de los retos principales de este proyecto tiene que ver con que el cliente ha adoptado un Scrum personalizado, o ScrumBut. Por ejemplo, para un proyecto están requiriendo en la iteración cero, entregar un plan de trabajo para revisar fechas de liberación con el usuario de negocio; en otro equipo, no se realizan demos de la funcionalidad terminada en el sprint transcurrido porque “no hay quien los revise”. En ambos casos, estamos contradiciendo el espíritu de Scrum con customizaciones que al final, pueden llevar a resultados nefastos.

Dilbert: ScrumBut


[Jefe Pelopunta]: Vamos a intentar algo llamado programación ágil. Eso significa que ya no haremos planeación ni documentación. Sólo empiecen a codificar.
[Wally]: Me alegro que tenga un nombre.
[Jefe Pelopunta]: ESE fue su entrenamiento.


(Fuente: domin8k.com)

Sin embargo, con todo y estos temas de índole más humana que técnica, creo que vamos por buen camino. Durante las próximas semanas estaremos levantando estos múltiples proyectos, que tienen una gran variedad tecnológica: algunos son aplicaciones de escritorio en .Net; otros son aplicaciones web en Java y otros más tienen que ver con implementaciones SOA para nuestro cliente. En fin, estos días serán pesados pero muy entretenidos, pues como alguna vez me dijo un ex-jefe: si no existieran problemas, nosotros no seríamos necesarios.

h1

Sueldos IT en México 2013: Veteranos al poder

02/20/2013

Wizdoc [Icon By Buuf]  Tips & Tricks.

(Última actualización: 22/03/2015)

En este momento ya contamos con la última versión de este estudio, con cifras actualizadas para el año 2015 que incluyen entre otras cosas, desglose por entidad federativa, género, tipo de empresa contratante y nivel de inglés así como un comparativo contra el sueldo del estudio anterior (2013).

El problema con los programadores es que nunca se sabe lo que están haciendo hasta que es demasiado tarde.

Seymour Cray (1925 – 1996), ingeniero eléctrico y arquitecto de hardware estadounidense, considerado el padre de las supercomputadoras.

Desde hace ya algunos años he publicado posts relacionados a los sueldos del personal IT en México, apoyándome en los resultados de la encuesta de salarios y factores de la revista Software Guru, complementados con información de sitios como Payscale u OCCMundial. En términos generales, este 2013 no se ven demasiados cambios con respecto al reportaje anterior, sin embargo el detalle de sueldos sí presenta algunas sorpresas:

El promedio

El sueldo promedio del personal IT en México es de aproximadamente MXN 25,049 brutos (anualizado: USD 23,799 con un tipo de cambio de 12.63 pesos por dólar al 19.02.2013). Esto significa que durante los últimos dos años, el sueldo se ha mantenido a la par de la inflación y ha conservado prácticamente la misma paridad con respecto al dólar: el sueldo “dolarizado” en 2011 era de USD 23,736, por lo que ha tenido un incremento neto de 63 dólares. Aunque parece estancado en términos del billete verde, de acuerdo a la paridad de poder adquisitivo o PPP, el sueldo promedio de un sistemólogo en México equivale a ganar USD 35,975 en los Estados Unidos; aunque seguimos ganando menos de lo que ganaría un estadounidense (USD 90,279 con todo y prestaciones), de nueva cuenta los sueldos siguen convergiendo poco a poco, ya que la proporción es de 2.51 mientras hace dos años era de 2.97 (USD 70,536 vs. USD 23,736 en 2011). De seguir esta tendencia, en diez años o menos los sueldos de ambas naciones tendrán diferencias mínimas; idea que no es del todo descabellada, sobre todo para empresas que exportan servicios de consultoría hacia el exterior.

Por otro lado, vale la pena recordar que este promedio varía considerablemente. De hecho, de acuerdo a nuestra locación geográfica éste puede variar en más del 30%:

Estado Salario Promedio Mensual (MXN) Salario Promedio Anualizado (USD)
Querétaro $ 32,668.61 $ 34,383.71
Nuevo León $ 30,634.32 $ 32,242.62
Distrito Federal $ 29,025.53 $ 30,549.37
Jalisco $ 24,963.37 $ 26,273.95
Estado de México $ 24,461.17 $ 25,745.38
Promedio Nacional $ 25,049.00 $ 23,799.00
Aguascalientes $ 22,486.96 $ 23,667.53
Guanajuato $ 19,040.36 $ 20,039.98
Puebla $ 18,470.67 $ 19,440.38
Veracruz $ 14,190.00 $ 14,934.98

Sueldo bruto promedio por entidad federativa. Mensual en pesos Mexicanos, anual en dólares Americanos (Tipo de cambio al 19.02.2013)

Me parece interesante cómo han evolucionado de forma independiente lo sueldos por cada estado de la república: Querétaro se está posicionando como una Meca en el desarrollo de software, con una variación de poco más del 30% por encima del promedio nacional y un crecimiento bianual de casi el 33%. Esto no es de sorprenderse ya que dicho estado se ha esforzado en diversificar su economía: por poner un ejemplo, con la excepción de Baja California (estado tradicionalmente maquilador), Querétaro es la entidad con más empresas relacionadas a la industria aeroespacial (32) en el país.

Por otro lado, Veracruz es el mayor perdedor en esta edición, con un magro crecimiento de 3.75% anual que ni siquiera sobrepasa la inflación de estos dos años. Creo que mucho tiene que ver nuestra guerra contra las drogas, que ha hecho de éste uno de los estados más inseguros debido al conflicto; más cuando resulta que el personal IT – especialmente aquellos relacionados con las telecomunicaciones – son el objeto de secuestro por parte de los grupos criminales para crear sus propias redes de comunicaciones.

Sueldos por función

Los sueldos por función reflejan las actividades, que de acuerdo a la encuesta original, se traslapan con bastante regularidad:

pic: Mexico IT salaries by function


Sueldos por función de acuerdo a actividades desempeñadas. Cifras en pesos Mexicanos, sueldo bruto mensual.

• De nueva cuenta, el diseño gráfico resulta ser el peor pagado con un sueldo extraordinariamente bajo con respecto al promedio general.

• También me llama la atención lo bajo que es el sueldo de un DBA “genérico”; sin embargo no nos desanimemos pues cuando existe una especialización en una base de datos y/o existen certificaciones de por medio (como veremos más adelante), el panorama cambia radicalmente.

• De acuerdo a la Organización para la Cooperación y el Desarrollo Económico (OCDE), un profesor sin maestría o doctorado con 15 años de experiencia gana aproximadamente USD 25,905 anuales (con PPP incluido) en México. Esto en pesos equivale a MXN 18,037 mensuales. Así que hace mucho más sentido dedicarse a dar cursos de capacitación IT que ser maestro en nuestro pobremente pagado sistema educativo.

• El grueso de las actividades IT que va desde el análisis de datos hasta pruebas y Quality Assurance no varía demasiado (MXN 5,288 mensuales); la arquitectura de soluciones y gestión de proyectos siguen siendo las actividades operativas mejor pagadas con MXN 28,183.30 y MXN 32,018.29, respectivamente.

• Aunque en la edición pasada los habían eliminado, en esta versión volvemos a ver puestos que en realidad no nos dicen mucho del panorama IT, como ventas y dirección. Esto porque he notado que estos puestos se mueven más por conceptos ajenos a IT como ventas o desarrollo de negocios, por lo que hay gente en estas posiciones que llegan al extremo de no tener ni idea de lo que significa IT.

• Finalmente, de nueva cuenta los ingenieros de preventa barren con los sueldos. Sin embargo, creo que esto se debe a que en muchos casos, operan con una cuota y por lo mismo, en caso de “llegar al número” tienen bonos adicionales que se ven reflejados en el sueldo mostrado.

Sueldos por género, experiencia y nivel de Inglés

Es sorprendente ver cómo nuestro nivel de Inglés o género influyen en nuestro sueldo. No tanto la experiencia, pues a mayor exposición ante diferentes tecnologías, proyectos o lenguajes, más experto se vuelve uno y por consiguiente, el sueldo se ve incrementado:

pic: Mexico IT salaries by English level, gender and experience


Sueldos por género, experiencia y nivel de Inglés. Cifras en pesos Mexicanos, sueldo bruto mensual.

• Uno de los grandes indicadores de que seguimos siendo un país en desarrollo es la inequidad de género. De acuerdo a las estadísticas, una mujer gana en promedio 30% menos de lo que hace un hombre con los mismos conocimientos y experiencia profesional. Sin embargo, esto también se debe a que esta industria ha sido tradicionalmente dominada por varones: de acuerdo a la misma OCDE, la proporción de hombres y mujeres dedicados a las matemáticas y ciencias de la computación en nuestro país es de 62% y 38% respectivamente.

• Asimismo, los años de experiencia dictan mucho qué tanto podremos percibir. Los dos extremos me llaman mucho la atención: un veterano con más de 20 años en la industria estará siempre por encima de los MXN 41,000, lo que significa que mientras encuentre trabajo, éste será muy bien recompensado. Por el contrario, me resulta doloroso ver cómo sin importar si terminó la carrera universitaria, un “becario” con menos de un año de experiencia puede ganar casi lo mismo que un “maestro albañil” que no ha terminado siquiera la escuela secundaria: MXN 11,299.38 vs MXN 10,000. Para aquellos que se encuentran en este predicamento, les doy la siguiente recomendación: certificaciones, certificaciones, certificaciones.

Sueldos por conocimientos, habilidades, tecnologías y certificaciones

A principios del 2013, éstos eran los sueldos promedio en México de acuerdo al nivel de conocimientos, tecnologías y certificaciones:

pic: Mexico IT salaries by knowledge, skill, tech, certifications (1)pic: Mexico IT salaries by knowledge, skill, tech, certifications (2)


Sueldos por conocimientos, habilidades, tecnologías y certificaciones. Cifras en pesos Mexicanos, sueldo bruto mensual. Leyenda: (P) Plataforma, (L) Lenguaje, (DB) Base de Datos, (C) Certificación/Conocimiento.

• En esta versión del estudio, Adobe AIR va de último, sin embargo es lógico ya que es prácticamente una paquetería al estilo Adobe Flash o Adobe Flex: usada generalmente por diseñadores web.

• PHP como lenguaje, MySQL como base de datos y Android como plataforma son los peores pagados en la industria; una certificación en Linux sigue siendo poco deseable debido al poco retorno de inversión (apenas 151 pesos por encima del promedio de un IT “genérico”).

• Java ha visto una pequeña mejora con respecto a años anteriores, ya que vuelve a estar por encima de Visual Basic, .Net y C#. Cuando hay certificaciones de por medio, ambas plataformas (Oracle J2EE y Microsoft .Net) permiten obtener prácticamente el mismo ingreso.

• Los sistemas legados siguen siendo los mejor pagados: Mainframe, Cobol, Informix y DB2 aseguran un sueldo por encima de los MXN 30,000 mensuales.

• Certificaciones muy recomendables incluyen la de SQA/ISTQB, UML, ScrumMaster e ITIL, ya que además de lo relativamente económicas de adquirir (no cuestan arriba de USD 300 o MXN 3,800 y los cursos de certificación no están por encima de los USD 1,200 o MXN 15,000), no requieren demasiado tiempo o esfuerzo para obtenerlas. Esto las hace muy atractivas ya que poseen un alto retorno de inversión.

• Por otro lado, las certificaciones “top” incluyen la de Project Manager certificado por el PMI o la de Enterprise Architect certificado ya sea por el Software Engineering Institute (SEI) o la IT Architect Association (IASA). Dichas certificaciones pueden ser relativamente baratas (USD 600 o MXN 7,600) pero en algunos casos requieren de 3 a 6 meses de estudio constante para pasar el examen, así como un número de horas comprobables realizando el rol a certificar. Dicho sea de paso, certificaciones no incluidas en el estudio como PMI-ACP (Agile Certified Practitioner) o CSP (Certified Scrum Professional) son equivalentes a la de PMP, pero para metodologías ágiles: de hecho, cuestan lo mismo y el tiempo requerido para estudiar y pasar el examen es muy parecido.

• Finalmente… ¿Websphere en MXN 57,000? ¡Pero si eso es un sueldo de director de operaciones! De hecho, un puesto similar en los Estados Unidos (Websphere Administrator) se paga en casi el mismo monto que la media de un ingeniero de software estándar (USD 91,450 vs. USD 91,271). Así que o tienen contratado a un gringo que está sesgando la curva, o alguien está presumiendo una certificación que del otro lado ya es considerada más bien “del montón”.

h1

Kanban: de “lean” a ágil

07/06/2011

Wizdoc [Icon By Buuf]  Tips & Tricks.

Kanban es como el lechero. Mamá no le deja un calendario al lechero. Tampoco usa un MRP. Ella simplemente deja las botellas vacías en los escalones del frente [de la casa] y el lechero las rellena. Esto es la esencia del sistema.

— Ernie Smith, facilitador del Foro Empresarial Lean en la Universidad de Tennessee

Kanban es un concepto o mejor práctica salido del Método Justo a Tiempo o Just-in-time. Literalmente, significa pizarrón o tablero (看板) en idioma Japonés y se usa en la industria automotriz para definir las etiquetas que van pegadas a los componentes intermedios antes de ser ensamblados en el producto final. Dicha práctica busca minimizar el tiempo necesario para tener un producto terminado, al ajustar o sincronizar la cantidad de “trabajo en proceso” en las estaciones de trabajo, como puede verse en el siguiente video de YouTube:

Batch and Queue - One Piece Flow

Demostración de un lote de producción vs. un flujo continuo de manufactura, minimizando el tiempo de producción (Hacer click en imagen o aquí para ver el video en YouTube)

Dicho esquema muestra las tres reglas fundamentales de Kanban:

• Visualizar el flujo de trabajo en todo momento. Se debe conocer en todo momento dónde están cada uno de los componentes individuales y en qué fase de la manufactura se encuentran; por ejemplo “por hacer”, “en ejecución” o “terminado”. Aunque en el diagrama esto es bastante explícito, en la vida real muchos gerentes de manufactura no saben en qué parte del proceso se encuentran las tareas y entregables que forman parte del producto terminado.

• Limitar el “trabajo en progreso”. Uno de los aspectos más importantes de Kanban es determinar un “trabajo en progreso” (Work In Progress – WIP) fijo. Esto permite al equipo de trabajo permanecer enfocado en un número limitado de entregables o tareas, permitiendo un flujo de ejecución continuo.

• Administrar el flujo. Llevar a cabo el flujo de trabajo de manera formal, monitoreando, midiendo y reportando el avance continuamente.

Kanban está definido de manera muy general, lo que lo hace muy flexible y fácil de adaptar a una línea de producción. Sin embargo, adaptarlo a un proceso de desarrollo de software puede no parecer tan fácil a primera vista. Empero, es muy fácil visualizar cómo funciona en un ambiente IT si lo comparamos con una metodología ágil de desarrollo de software que se le parece: Scrum.

Jim: ¡Por fin, ya tenemos Scrum implementado!
Fred: ¿Cómo les va?
Jim: Bueno, es mucho mejor que lo que teníamos antes…
Fred: … ¿pero?
Jim: … pero verás, somos un equipo de soporte y mantenimiento.
Fred: ¿Y?
Jim: Bueno, nos encanta todo eso de clasificar las prioridades en un backlog de producto, equipos auto-organizados, Scrums diarios, retrospectivas, etcétera…
Fred: Entonces, ¿cuál es el problema?
Jim: Seguimos fallando en nuestros Sprints.
Fred: ¿Por qué?
Jim: Porque encontramos difícil comprometernos a un plan de dos semanas. Las iteraciones no tienen mucho sentido para nosotros, ya que trabajamos de acuerdo a lo que es más prioritario para ese día. ¿Será que necesitamos iteraciones de una semana?
Fred: ¿Podrían comprometerse a una semana de trabajo? ¿Crees que podrían permitirles enfocarse y trabajar en paz por una semana?
Jim: No en realidad, pues surgen problemas a diario. Tal vez si hiciéramos Sprints de un día…
Fred: ¿Los problemas toman menos de un día para resolver?
Jim: No, algunas veces toman varios días.
Fred: Así que Sprints de un día tampoco funcionarían. ¿Han pensado en deshacerse de los Sprints por completo?
Jim: Francamente, sí nos gustaría. Pero, ¿no va eso en contra de Scrum?
Fred: Scrum es sólo una herramienta. Tú escoges cuándo y cómo usarla. ¡No seas un esclavo de la metodología!
Jim: Entonces, ¿qué deberíamos hacer?
Fred: ¿Haz escuchado hablar de Kanban?

Kanban vs Scrum: a practical guide by Henrik Kniberg. Crisp AB. 2009.

Kanban vs. Scrum

La principal diferencia entre Scrum y Kanban es que Scrum limita el “trabajo en progreso” o WIP por cada iteración o Sprint, mientras Kanban lo limita por fase de ejecución. Es decir, en Scrum se selecciona desde un principio el trabajo a desarrollar durante el presente Sprint, luego se “congela” cualquier cambio en las tareas a realizar por la duración del Sprint y después de dos a cuatro semanas se tiene todo el trabajo terminado, como se muestra en el siguiente diagrama:

Scrum Sprint

Ciertamente, un Sprint utiliza una manera de trabajar muy parecida al proceso por lotes mostrado más arriba (Fuente: outsystems.com)

Por el contrario, en Kanban lo único que se limita es el monto de trabajo a realizar en cada cola o fase de desarrollo (por hacer, en ejecución, terminado). Esto significa que pueden cambiarse las tareas o entregables en cualquier momento y no existe un “Sprint”, permitiendo que el trabajo continúe fluyendo de manera constante:

Kanban Flow

Un flujo Kanban, con un límite de WIP para 3 actividades en las tareas “por hacer” (Todo) y un límite de 2 actividades para las tareas “en ejecución” (Ongoing). (Fuente: outsystems.com)

La posibilidad de cambiar prioridades o agregar y quitar actividades al vuelo permite una mayor flexibilidad que la encontrada en Scrum; pues mientras en aquella metodología es necesario esperar al final del Sprint por resultados, en Kanban es posible determinar día con día el avance de las tareas por realizar. Sin embargo, es necesario tener en mente dos pequeños detalles:

• En Scrum se ha definido el Sprint con la finalidad de permitir a los desarrolladores “trabajar en paz” durante un tiempo determinado, para evitar el overhead o tiempo perdido que resulta cuando hacemos un cambio de tareas (llamado cambio de contexto en multithreading). Es decir, es un hecho que los seres humanos NO somos multitarea: si estamos muy enfocados en realizar la tarea A, al cambiar nuestro contexto para realizar la tarea B requerimos un tiempo para reorganizarnos. Por otro lado, si más tarde tenemos que volver a terminar la tarea A, acabaremos con el famoso “¡Ahh! ¿en donde me quedé?” y nuevamente requeriremos un tiempo para retomar dicha actividad.

• Kanban permite reorganizar las tareas en todo momento, sin embargo es indispensable llevar un buen control de cambios y tener en cuenta que dependiendo de la tarea se darán en mayor o menor medida tiempos perdidos debido al cambio de contexto por parte de los desarrolladores. Este overhead puede ser excesivo en algunos casos – por ejemplo, pasar de programar algunos componentes en Ajax a configurar un servidor LDAP y de regreso puede tomar horas o días para reorganizarse – y en todo caso, dependerá de cada programador sin importar su experiencia o conocimientos.

Considerando estos puntos, Scrum está mejor adaptado para proyectos de desarrollo, mientras Kanban es mucho mejor para mantenimientos o proyectos de sistemas donde con frecuencia se detectan errores o se introducen historias de usuario de forma constante.

Scrum-ban

Finalmente, existe un mashup entre Scrum y Kanban, denominado Scrumban o Scrum-ban. En éste, se sigue el flujo de trabajo continuo como lo define Kanban, pero se incluyen elementos de Scrum como el backlog, las reuniones diarias de 15 minutos y pequeñas retrospectivas con el afán de mejorar el proceso. De acuerdo a algunos autores, es de hecho recomendable utilizar primero Scrumban para introducir a los equipos de desarrollo al mundo de las metodologías ágiles. Esto permite tener un periodo de transición, con el afán de que los desarrolladores y demás stakeholders se sientan cómodos con la nueva metodología. Una interesante muestra de cómo puede llevarse Scrumban se puede ver en el artículo Scrumban multiproyecto y multiperfil, del blog de Carlos Iglesias, socio y consultor tecnológico en Runroom, una pequeña consultoría de desarrollo web en Barcelona, España. Para efectos de completitud, incluyo un pequeño extracto del artículo, donde el autor menciona cómo priorizan las tareas y llevan el seguimiento del Task board:


Scrumban, por definición, se compone de un panel Scrum y un panel Kanban.

En el panel Scrum, metemos las historias priorizadas por el Product Owner (un servidor). Dichas historias se subdividen en tareas y se estiman en puntos de historia en la reunión de planificación de sprint. Además, en nuestro caso, las separamos por colores en función del proyecto, con lo que nos queda un panel ordenado verticalmente por prioridad y horizontalmente por proyecto. Las columnas, como es habitual, trazan el flujo de las tareas.

Scrumban Task board

En el panel Kanban, por contra, entran directamente las tareas sin estimar. ¿Cómo que sin estimar? Pues eso, las tareas de este panel no se estiman al inicio, sino que se cuantifican en horas al final. Eso sí, el Dueño de Producto las prioriza teniendo en cuenta las 3 filas de urgencia:

  • FIRE: Una tarea en esta fila significa “Deja todo lo que estés haciendo y atiende esta tarea!”. A esto le llamamos bala de plata, y está establecida la limitación de que sólo puede haber una a la vez. Una bala de plata es una cosa seria y por tanto en el momento de la retrospectiva se auditará.
  • PRIO: “Tan pronto como acabes lo que estás haciendo, por favor ponte a hacer esta tarea”
  • ASAP: “Deberías hacer esta tarea, pero solo si no se compromete el objetivo del sprint”

Por último, la autoasignación de tareas se ve reflejada con un avatar personalizado… :))

Cabe destacar que en aquella consultoría tienen al mismo tiempo proyectos de desarrollo así como mantenimientos que requieren atender bomberazos.

Conclusiones

En nuestra propia organización usamos Scrum en los proyectos, sin embargo de un tiempo para acá se han venido realizando pruebas piloto con Kanban para tareas de sustaining con nuestra contraparte de la India; posiblemente aquí mismo podamos hacerlo también. Especialmente interesante me pareció la combinación de Kanban y Scrum, pues de esta manera podemos saber quién está haciendo qué en todo momento, sobre todo cuando aparecen bomberazos y alguno de los desarrolladores tiene que entrarle al quite, con el posible impacto en el backlog comprometido.

De momento, estaré empezando mis propias pruebas piloto, viendo qué tanto pega el estar cambiando prioridades tan rápido como lo demanda Kanban. Me he empezado a organizar con la product owner y los desarrolladores para que hagan las cosas de tal forma que si tienen que switchearse sólo necesiten poco tiempo, al mismo tiempo que lo que dejen hecho esté listo (ready to ship) para ser revisado en forma de pruebas beta con el cliente, en lo que vuelven a retomar el proyecto.