Sprint 0. Cuaderno de bitácora

Ciertamente, todos/as nos hemos encontrado en la tesitura de un proyecto basado en un lenguaje en el que habremos chapurreado código tímidamente o simplemente nos ha faltado la oportunidad de poder trabajar en la trinchera directamente.

Hace no mucho, nos llegó la oportunidad de sacar adelante un evolutivo de mejora arquitectónica. Ésto se traduce a que, la solución se liberó en su día "deprisa y corriendo", seguramente por necesidades de cliente. Quiero evitar el pensamiento de que el equipo al que se le encomendó dicho cometido se encontrase sin conocimientos previos mínimo y quiso apartar la vista al liberar la solución.

La única premisa que se impuso fue basar la solución de arquitectura en ASP.NET.

Aquí un javero de pura cepa con una certificación en tramite, receloso a cambiar de contexto, pero predispuesto a aprender y poder definir una arquitectura completa desde cero. Demasiadas eran las carencias que contenia ya el aplicativo.

¡Al meollo!

Lo primero fue buscar información específica sobre funcionamiento del lenguaje. Partiendo de la premisa de una arquitectura ASP. NET Web Forms.

Resultó ligeramente sencillo encontrar información y tutoriales sobre patrones de diseño fácilmente aplicables. Entre ellos:

• Service 
• Repository 
• Authentication Form 
• Membership 
• Command

Además de otros componentes como:

• MasterPage/UserControls 
• AjaxToolKit 
• NUnit

Una vez elegida de qué se compondrá la arquitectura, solo falta trasladar el comportamiento del aplicativo existente sobre una nueva solución más robusta y mantenible.

ja.. ja.. ja..

Nada más lejos de la verdad  si el mundo del software fuese así de sencillo. Pero la cruda realidad, suele ser "ligeramente" diferente...

Con premisas como:

• Un sistema de des-rutilización de código en las vistas. Basada en one-to-one en aspx 
• Solo una traza de log en todo el aplicativo. Conteniendo las operaciones a SQLServer que el usuario consuma. 
• Una autenticción de usuario inexistente basada en la confianza de que un sistema SSO sea invulnerable y seguro.
•  Sistema de mensajes de feedback al usuario sobre sus acciones, basada en la elevación de excepcion en las comunicaciones con el motor de Base de Datos SQLServer.
•  Vulnerabilidades de seguridad sobre la totalidad del aplicativo.

Con las anteriores premisas, debíamos de realizar un buen  trabajo de cohesión para cubrir las deficiencias existentes en el aplicativo actual.

Hay que añadir, que éste evolutivo deberá llegar a gran puerto con la metodología Scrum apoyado en Kanban (Scrumban). Según la experiencia de correctivos realizados anteriormente sobre dicha solución, parece que habría trabajo para un equipo de 3/4 personas durante un año (como poco).

Desde un punto de vista tecnológico y de cara a la visibilidad del equipo al cliente, parece una gran oportunidad (o al menos, eso pensaba yo).

Sprint 0

Con un Backlog establecido y priorizado por el product Owner. EL equipo, realizó una estimación de las historias de usuarios que se podrían asumir en el sprint backlog, teniendo en cuenta el tiempo que se destinará a implementar la arquitectura inicial.

¡The Show Starts!

Primera oportunidad de mejorar: ¿El equipo dispone de la formación necesaria sobre el lenguaje a utilizar?

Me gustaría decir que sí. Pero, por desgracia, la respuesta es la contraría. Entre los miembros que se encuentran en el equipo, solo uno contaba con experiencia previa en el contexto.

A lo largo del sprint, fueron apareciendo impedimentos perfectamente solucionables si el único requisito impuesto para la aruitectura, hubiese sido algo diferente a "utilizar ASP.NET".

Esto se ha traducido a un desvío de casi el doble del tiempo estimado por el propio equipo para la adecuada finalización de las historias de usuario.

Retrospectiva Personal

Un proyecto desde cero  y una metodología ágil, ¿Es una premisa de éxito?

La realidad del día a día, es diferente a la que podamos aprender sin un pliego de experiencia previo.

Pese a todo, el Sprint 0 se consiguió finalizar con la calidad que un cliente debe esperar. Ésto me hace sentir orgulloso del equipo en el que me dieron la oportunidad de encontrarme. Muchísimas gracias por el esfuerzo y la implicación para sacar el Sprint 0 adelante.

Ya veremos si en la retrospectiva del siguiente Sprint, el equipo ha aprendido una manera de mejorar.

[IT Agile Games] Capítulo 4. La comunicación del lince

Como nueva entrada del blog, que por temas laborales se está quedando apartado... He elegido un capítulo del libro ITAgile Games.

"La comunicación del lince" es un juego de, aproximadamente, 15 minutos para demostrar al equipo la importancia de la comunicación entre miembros ágiles. 

Ésta actividad la creo apropiada como uno de los pasos de una reunión de acercamiento del equipo, se puede incluir en la dinámica del Sprint 0. El juego también permite entender conceptos que facilitan el desarrollo ágil, como conciliar a los desarrolladores de que piensen en equipo.

Materiales

• Hojas de Papel Formato A5
• Lápices

Roles

• Facilitadores/as del juego: Explican las reglas y actúan como Scrum Master.
• Desarrolladores: Equipos de 4 personas.

Actividades

1. Cada Miembro del equipo, escribe sobre una hoja de papel una frase. 10 seg.
2. Se pasa el papel al siguiente integrante del equipo.
3. El siguiente miembro realiza un dibujo representativo a la frase que viene indicada en el papel, luego se dobla el papel permitiendo solo ver el dibujo (y no la frase) y se para al siguiente compañero/a. 10 seg.
4. Se pasa el papel al siguiente integrante del equipo.
5. Los siguientes integrantes, mirarán el dibujo y deberán saber identificar una similitud con la frase inicial. 10 seg.

La mecánica se repite hasta que cada componente recupera su hoja original.

Reflexiones

Al acabar, es fácil ver el resultado final. Inicialmente no debería tener mucha relación la frase con el dibujo. Servirá para resaltar la importancia de la comunicación y de compartir una visión en común.

La experiencia personal ha sido bastante buena, los participantes se lo pasan genial, nos reímos viendo los resultados finales, creamos un contexto amigable entre todos/as y, lo más importante, empezamos a darnos cuenta de que tenemos que ser un equipo.

Saludos Ágiles

Un buchito de realidad... ¿Sub-estación, sobre-estación o equipos eficientes?

En el mundo de la informática te encuentras muchos tipos de personas con diversas habilidades de las que aprender o evitar entender.

Entre ellos: los que han sufrido un proyecto estimado de manera ajusatada, por decirlo de manera suave, y/o los que lo van sufrir. Los problemas relacionados con estimaciones así, son tan antigüos como la informática. ¿Porqué crees que aparecieron CMMI o ITIL en su día?

Los problemas, errores, malas prácticas, hábitos y demás leyendas relativas al mundo de la estimación pueden verse en sencillas búsquedas sobre la red.

Debido al dolor que aún producen las cicatrices emocionales por malas estimaciones, caen en intentar cubrirse las espaldas diciendo tiempo de más, sobrestimar.

La naturaleza humana, es exprimir la Ley de Parkinson.

Dice la ley de Parkinson: “el trabajo se expande hasta ocupar el tiempo disponible para realizarlo”. Es decir, que si una tarea se puede hacer sólo en un mes, pero dispongo de dos… Al final estaré los dos meses enredando con la tarea.

Pero, ¿Qué ocurre cuando, simplemente, el equipo ha hecho un buen trabajo?

Por que... Por suerte, todos los informáticos no son grandes followers de dicha ley.

En mi opinión, si trabajas con transparencia y te implicas en el grado que tu equipo espera, o le gustaría, y cada miembro se aplica con la motivación adecuada, es una manera de mitigar algunos de los riesgos que puedes encontrar sobre el desarrollo de una solución a cliente. Aunque siempre tendremos los típicos:

– Al equipo le falta dominio en las tecnologías.
– El equipo desconoce la lógica de negocio.
– El entorno de desarrollo debiera ser más eficiente.
– Si es un proyecto de mantenimiento, el equipo no conoce el código lo suficiente.
– Nebulosas en los requisitos funcionales.
– En los requisitos no se han tenido en cuenta cuestiones de seguridad, rendimiento o creación de marcos de trabajo(Crear: workspaces del IDE, repositorio de versiones, Base de Datos, etc).

La conclusión:

1-SUBESTIMACIÓN: El sobrecoste generalmente crece exponencialmente, cuanto más alejada esté la subestimación del tiempo real (penalizaciones por contrato, cliente cabreado, jornadas interminables, ...).

2-SOBREESTIMACIÓN: Hoy en día, la gran mayoría de clientes tiene un departamento de informática que gestiona las soluciones que necesita la infraestructura de la empresa para tratarla con los proveedores. Si nos pasamos, el cliente lo sabrá y puede decidir buscar otro proveedor.

3-UN BUEN TRABAJO: Realizar un estimación de 100/100 es prácticamente imposible. Pero si hacemos unas estimaciones coherentes y contamos con el respaldo de un equipo implicado, asertivo y motivado; podremos conseguir el win-to-win. Nos ayudará en gran medida a seguir teniendo trabajo... No olvidemos que en la empresa entra el capital por: 

A)Aportaciones de accionistas (Que a menos que sea una startup, no estarán invirtiendo dinero diariamente...).

B)Soluciones facturables (Sirven para pagar las nóminas, toners de impresión, ordenadores, la cena de empresa ...).

Con este post, quiero mostrar mi orgullo y agradecimiento por el equipo que tenemos para ayudar al cliente a obtener las soluciones que precisa.

¡Gracias!

¿Te encuentras en un proyecto un huevo de grande?

En andalucía se oscila mucho las unidades de medida propias. Vienen a ser: el pelín, la mijilla, er peazo, la jartá, la pechá y el huevo.

Muchos proyectos de software se comportan de igual manera, de repente se transforman en un huevo de tediosas (tiempos y costes se disparan, incidencias de todo tipo, incluir una nueva y simple funcionalidad conllevan una jartá de esfuerzos, etc.), e igualmente, muchas veces, nos ofrecen, o buscamos, sugerentes vías de escape que, con apenas esfuerzo, nos solucionen el problema (bastaría pasar por algunos foros de software), tecnologías que de manera casi inmediata prometen acabar con la intensidad de un proyecto de software gigante. 

El tiempo ha dado lugar a la creación de un amplio cuerpo de conocimiento en ingeniería de software que nos ha enseñado la mejor manera de trabajar, afrontar o resolver problemas asociados a la naturaleza del software, como, por ejemplo, a no utilizar el “go to”, la importancia de la ocultación de la información, el diseño orientado a objetos, las arquitecturas en capas, cómo estimar proyectos, el valor de las mejoras, economia software, patrones, etc, etc, etc. Pero éstos, en más ocasiones de las que nos gustaría, se olvidan, o desconocen, y se buscan soluciones desde lo accidental (una determinada herramienta, entorno automático o CASE, cambiar a un lenguaje de programación, utilizar otro modelo de procesos, etc.). 

Como experiencia personal, la mayoría de los problemas del software parten de obviar los principios esenciales, y se incrementan al intentar solucionarlos exclusivamente desde la vía accidental. Como profesional deberíamos cuidar más el conocimiento esencial, la educación y formación en el mismo. El conocimiento accidental es necesario para poder trabajar, pero el esencial es necesario para además hacer un buen trabajo. El difundir y aprender el cómo trabajar correctamente con la parte esencial del software, esa jartá de conocimiento que existe y se ha ido creando a lo largo de la cronología del software, es quizás uno de los principales retos de nuestra profesión y muchos deberían aprender a apreciarlo en su justa medida. Muchos han sido los  partífices en estableces esas bases.

Al Liquindoi... ¿Reconocerías a un Knowmads?

El término knowmad combina las palabaras know (conocer) y nomad (nómada) nos informa del perfil de un trabajador capaz de ser un "nómada del conocimiento y la innovación", es valorado por sus conocimiento personales, lo que nos proporciona una ventaja competitiva coon respecto a otros trabajadores/compañeros.

Algunas de las características sobre éste tipo de perfiles:

• No está limitado a una edad determinada.
• Adaptativoa diferentes contextos y entornos.
• Creativo, innovador, colaborativo y motivado.
• Consciente de liberar el acceso a la información (sin límites geográficos).
• Entiende cómo y porqué funcionan las tecnologías digitales.
• Aprendizaje permanente.
• No teme al fracaso.

En la sociedad TIC los trabajadores de la sociedad de la información y del conocimiento se han vuelto mucho menos específicas en términos de ubicación y de las tareas a desempeñar, lo cual se ve favorecido por las tecnologías que permiten efectuar buena parte del trabajo de manera virtual. Los knowmads tienen la capacidad de volver a configurar y contextualizar su espacio de trabajo en cualquier momento, intercambiando información e ideas con otros profesionales, lo que genera ideas, productos y servicios muy diferentes a lo que haría cada uno por su parte.

Cualquier persona, desde CEO o empresario hasta el empleado de primera línea, puede ser knowmad.Y no es moda pasajera porque va a ser el tipo de profesional que más crezca y se desarrolle en el futuro cercano, básicamente porque es el que reúne todas las condiciones para trabajar con las exigencias que piden los nuevos tiempos, y que por lo tanto también será el que requieran las empresas.

Foto: Obtenida de "ENJI - Encuentro Nacional de Jóvenes Innovadores"

Motivación modo OFF

Uno de los mayores retos a los que nos enfrentamos es el largo tiempo de desarrollo de algunos proyectos. Meses y meses donde todo es trabajo y más trabajo que nos permite avanzar, por supuesto, pero en los que hay muchos días donde cuesta seguir el camino que creamos siendo ingenieros o técnicos.

La desmotivación es uno de los principales enemigos que tenemos que vencer. No la falta de inversión externa, no la falta de medios humanos o materiales  en el proyecto sino los días en los que todo parece ir cuesta arriba y nos faltaba chispa, energía y empuje... motivación.

No hace falta estar en un gran o largo proyecto para sufrirla. Puede asaltar —de hecho lo hace— en cualquier momento, en cualquier actividad y la sufre cualquier persona. Hay muchas formas de combatir la desmotivación pero te voy a dar algunas de las claves que mejor me han funcionado a mí.

• Recuerda el porqué

Detrás de cada tarea, de cada golpe de click, de cada tecleo hay un porqué... Puede ser el inicio del proyecto de tu vida, estudios que te permitirán acceder a tu primer empleo, un trabajo que te facilitará saltar a otro mejor, el aprendizaje que te formará como profesional, etc. 

Vivir sobre railes es lo peor que podemos hacer y hacer las cosas “porque sí” suele ser pasaporte directo a la desmotivación y la frustración. ¿Por qué estás ahí? ¿Por qué vas a hacer eso? Dicho de otro modo: dale un sentido a la tarea, a la actividad o a ese día “tan jodido” que parece no acabar nunca.

Piensa por encima de todo que no es algo que tienes que hacer por narices, porque toca o porque te lo han mandado… es algo que quieres hacer porque te acercará a un objetivo que seguramente un día te marcaste. Recuérdalo de forma frecuente para:

    a) inspirarte e ilusionarte cada nuevo día

    b) para motivarte en los días en que todo se ponga cuesta arriba.

• Disfruta del camino

Hemos aprendido a “celebrar los éxitos y aprender de los errores” pero nadie nos ha enseñado a “disfrutar del camino”. En mi experiencia personal, ésto es una de las claves de la Productividad y una de las cosas que te fomento a practicar con devoción.

Hay que ir celebrando las pequeñas victorias y las pequeñas conquistas diarias. No sólo hay que motivarse con el gran objetivo en mente, sino también con los pequeños regalos que obtenemos cada día gracias a nuestro trabajo, talento e intensidad.

“Hoy he trabajado duro, ha costado mucho PERO he conseguido esto, esto y esto. Y ahora es el momento de celebrarlo. ¿Unas cañas?”.

Eso tiene que ser motivo de alegría y de celebración. Que esto no le suene ridículo a nadie. Un atleta corre para ganar una medalla pero por encima de todo corre porque le gusta. La propia carrera y cada zancada, aunque le cueste esfuerzo y dolor, es lo que le hacen decir: “hago esto porque me gusta”.

No esperes a celebrar el éxito final de ese proyecto o te estimules con ese gran objetivo en mente. Cada día es una dura etapa que hay que cubrir y cuando lo haces bien, creo que hay que utilizarlo como incentivo personal. Hay que reconocerlo, saborearlo y aprovecharlo para recargar la motivación que necesitas ese día y al día siguiente y al siguiente…

• Las pequeñas cosas son importantes

Muchas veces no hay que recurrir a los grandes objetivos para motivarnos. En no pocas ocasiones la ilusión, y hasta la pasión, está en las pequeñas y hasta minúsculas cosas que te rodean o que rodean a ese proyecto. En esos días en que “todo te da igual” es necesario que miremos y nos fijemos en esas pequeñas cosas que tanto nos gustan

Cambia el orden de trabajo, empieza por esa pequeña tarea que te estimula más o haz esa sencilla actividad que siempre te gusta hacer. Utiliza a tu favor esas pequeñas cosas como detonante y estímulo. A veces hay que recurrir a algo pequeño y “tirar de él” para desencadenar la motivación

En los días en los que ni tienes ganas de trabajar divide tus grandes tareas en pequeñas tareas y luego éstas en minitareas o microtareas. Empieza con la que de verdad te ilusione y empieza a caminar. 

A veces la desmotivación es una ficticia ilusión que genera tu mente. Verte que vas avanzando te animará y te empujará a continuar.

• El ahora es importante

En muchas más ocasiones de las que pensamos nos falta motivación porque nuestra cabeza no está en lo que hacemos, no estamos presentes. En esos momentos está presa de pensamientos o en cosas mucho más agradables generalmente relacionadas con nuestro ocio o tiempo libre.

Un concierto, un viaje, una cena, una reunión, etc. Vuelve al momento, sé consciente del ahora y de lo que tienes delante y utiliza ese pensamiento “de ocio” como arma motivadora. Interprétalo como una recompensa o un premio al trabajo que tienes que hacer y para el que te cuesta encontrar un porqué.

• Toma un kitkat (Date un respiro)

Yo miro alrededor y no veo a ningún superhéroe. No sé tú pero yo ni soy una cadena de montaje ni me han fabricado en "Informáticas Paco" (sin ser peyorativo). Todos pasamos por días muy productivos y días muy complicados. Ambos forman parte de nuestra vida y tarde o temprano llegan. Los días difíciles son absolutamente necesarios para disfrutar todavía más de los días productivos.

Si lo intentas todo y aún así no eres capaz de motivarte… ¡no pasa nada! No te desesperes ni te tortures con frases como “vaya desastre, hoy no estoy rindiendo nada” o “puff, un día tirado a la basura”. Ese día no tomes decisiones drásticas, trata de concentrarte en hacer lo mínimo e imprescindible y dedícate a labores mecánicas o más rutinarias que exijan poca creatividad e intensidad (ordenar, clasificar, limpiar, buscar, etc.). Cierto es que en ciertas tesituras del día a día, es complicado desviar los esfuerzos desde un trabajo tipo "Tiene que estar para ayer" pero debemos intentar desfatigar nuestra mente.

Sencillamente deja correr las horas del día. El día terminará... Mañana será otro día, tu motivación regresará. Las tareas y tu proyecto te estarán esperando de igual modo para que des lo mejor de ti.

IInca, Maya, Azteca, Arapahoes... ¿Qué tipo de ingeniero eres?

En la profesión de ingeniería o técnico informático en España, el 90% de aquellos a los que no les gusta programar, se pasan toda la vida haciéndolo. Y el 90% de los puestos relacionados con la informática que no son de programador los acaban ocupando personas que no estudiaron informática (Administración de empresas, por ejemplo). Así son las cosas en ésta profesión.

De ésta manera, se suelen encontrar el mismo organigrama sobre la jerarquia que contienen las empresas de TIC:

• Incas: Los que llegan a las 8 de la mañana e hincan el codo hasta que se van. En algunos proyectos, ni se van a la hora correspondiente...
• Mayas: Llegan a partir de las 10:00 horas y dicen “¿Mallamado alguien?”
• Aztecas: Acuden a su puesto de trabajo a partir de las 12:00 horas y siempre dicen “tú, hazte cargo de esto. Tú, hazte cargo de lo otro”.
• Arapahoes: No pisan la oficina en toda la semana, pero el viernes aparecen y dicen “Ahora pa’ joe, una reunión”.

Sinceramente, es muy complicado llegar a Arapahoe. Hágase constar que la programación es una actividad muy muy respetable y una de las actividades más importantes a las que se puede dedicar un ingeniero o técnico en informática (o cómo nos acabemos llamando con los grados que sacan cada año). Pero aún siendo una gran dedicación, hay otras muchas dedicaciones profesionales donde un ingeniero o técnico en informática es perfectamente apto. A veces, incluso más cualificado que la persona que tienes dirigiendo el cotarro en el proyecto. Dichas dedicaciones para las que hay que reconocer que, por desgracia, pocas instituciones formativas preparan a sus futuros ingenieros y/o técnicos.

Los siguientes consejos no-técnicos no son una garantía, no aseguran el moverte a tribus Mayas-Aztecas-Arapahoes, pero sí que, en mi corta experiencia profesional, aquellos que he tenido la oportunidad de conocer que han dejado la tribu de los Incas, cumplieron con varias de las siguientes aptitudes:

• Aprende Inglés: A nivel conversación y documentación.
• Especialízate en un área: Para destacar en la misma. Lee, estudia, webinar, formaciones con coste adicional, certificaciones, etc.
• Selecciona bien dónde quieres trabajar: No tires tu carrera profesional por cobrar más, por ejemplo.
• Viaja: Siempre que puedas metete en un proyecto en que sea necesario desplazarte de la oficina.
• Relaciónate: Lee y participa en los grupos de gente que se dedica a lo que a ti te gustaría dedicarte. Hoy en día es relativamente fácil (foros, linkedin groups, twitter, etc).
• Desarrolla aptitudes no técnicas: Aprende a realizar presentaciones, hablar en público, resumir ideas, etc. Saber transmitir adecuadamente es fundamental.
• Hazte visible: Desde crearte un perfil de Linkedin hasta hacerte una website propia, lo que quieras y/o veas apropiado. Pero mantenlo en contína actualización.

Son algunas de las cosas que te pueden ayudar a inclinar la balanza para cambiar de tribu, si es lo que realmente quieres en tu carrera profesional.