Reflexión después de los cursos de certificación para PSM I y PSPO I


Luego de haber participado en los cursos “Professional Scrum Master I” y “Professional Scrum Product Owner I” de Scrum.Org en 3Dev Business & Consulting. decidí hacer una reflexión en referencia a los mismos.

  1. Siempre creí que Scrum era una metodología de gestión de proyectos, y aun que estaba errado, trataba de convencerme o hallar una explicación lógica, y es que definitivamente Scrum no da una forma de llevar el proceso, por el contrario, provee las herramientas necesarias para administrar el desarrollo de un producto. ¿ Acaso esto no es un proyecto?, en definitiva, no lo es. Un proyecto esta amarrado a fechas, mientras que un producto esta orientado a si mismo como tal, por tanto, Scrum no se orienta a cumplir fechas, si no, a maximizar el valor de un producto.
  2. Estaba seguro que el Scrum Master era un Jefe de Proyectos, y estaba completamente equivocado, y es que no analizaba tampoco el nombre de este rol por si mismo, es decir, el “Scrum Master” es el “Maestro de Scrum” o experto en Scrum, responsable de de asegurarse que Scrum se cumpla, facilitando el camino y brindando el soporte necesario al equipo para el éxito de Scrum, mas no de dirigir al equipo, ni menos asegurarse del éxito del producto.
  3. Asumía que el Product Owner era el cliente, esto por el nombre del rol, entendía que el dueño del producto era el cliente si mismo, ahora entiendo que esto no es del todo cierto, el Dueño del Producto es en si el responsable de que el producto consiga su éxito, si puedo hacer una analogía, diría que es el gestor del proyecto, pero sin gestionar el equipo, pero si gestionando las prioridades del producto y maximizando el valor del producto.
  4. Estaba convencido que los miembros del Equipo de Desarrollo pueden trabajar cada uno en su especialidad, lo cual no ayuda en la cohesión del equipo como tal, ya que se busca que el equipo sea cross funcional y que no haya un propietario del código. Es importante la comunicación, coordinación e interacción de cada uno de los miembros del Equipo de Desarrollo, además de su compromiso y coraje para enfrentar los retos en el camino a conseguir el mayor valor del producto.

Conclusiones

  1. Scrum es una conjunto de herramientas que nos permite desarrollar productos complejos.
  2. Cada uno de los roles de Scrum son insustituibles, y su éxito radica en el empoderamiento del equipo hacia el producto por parte de la organización.
  3. Poner en práctica lo aprendido tan pronto como sea posible.

Agradecimientos

No puedo concluir este texto sin antes agradecer a Jose Peñarrieta y César López de Inka Labs, quienes me apoyaron para concretar mi participación en estos cursos.

Anuncios

El mejor equipo


Habia ya empezado mi primier scrum, con un equipo de desarrollo, según yo optimo, aun creo en ello, el dia planificado para el demo de sprint fue el día viernes 21 de noviembre, y llegó pues el día, y no habiamos culminado. Mi equipo solicitó entre otras cosas, trabajar de noche, horas extras, retrazar la fecha, todo con tal de poder completar nuestras metas y poder finalizar el sprint.
No tuve el valor de decirles: no chicos, el sprint terminó y terminó, simplemente espere la llegada del lunes siguiente para el sprint diario, creyendo que el sprint se aplazaría, los sente al rededor de la mesa de reuniones y les expliqué el por que no podiamos extender el sprint, y debió ser asi, simplemente no culminamos lo trazado, la pregunta fue ¿Que hicimnos mal?, Scrum no sirve para nada, desechemos Scrum!!
Luego de asimilar que el sprint terminó analizamos que pasó. Conluimos que Scrum si sirvio, no fracasamos, nuestro primer Sprint, simplemente estuvo mal planificado y con muchas fallas. Nuestros roles estuvieron terribles, mal concepto de responsabilidades a nivel de roles y funciones, la falta de un arquitecto especialista, entre otras tantas fallas, leí un poco más, al menos eso hice, y junto a mi equipo analizamos todo aquello que salió mal y que retardo el proyecto. Fue una gran lección que nos trajo muchas ideas claras al final del día sobre como habíamos trabajado y como debemos intentar trabajar, a mi me sirvió para entender que encontré al equipo ideal.
Hoy planificaremos un nuevo Sprint!!.

Scrum y UML


Siempre he sido un creyente de la importancia de UML, pero hablkar de UML me lleva a pensar en metodologías predictivas, que ademas de ser pesadas y aburridas, no daan muchos resultados del todo óptimos. Pero UML, según entiendo, UML es tan solo un lenguaje de modelamiento, independiente de la metodlogía de desarrollo, entonces debe adaptarse a cualquier metodología.
Moddelar bases de datos relacionales en metodlogías orientadas a objetos, ya es un reto, pero es importante que todo el equipo sepa lo que debe hace, como y sobre que arquitectura trabajar, bueno apostaremos por ello y veré que sucede al final de este sprint.
Hoy dia tendremos nuestro segundo sprint, en el cual incluiremos el modelado de sistema y el modelado de la arquitectura de base de datos, sin descuidar la documentacion. Vaya que suena a metodología predictiva, pero si se mantiene una adecuada documentación y modelos de trabajo, pienso que no estaremos lejos de realizar algo con calidad.

Me olvidé las diapositivas


El dia vieres 21 de noviembre participé en un seminario de Software Libre, organizado por los alumnos de la Escuela Profesional de Ing. de Sistemas de la Universidad Nacional de San Agustín, el tema expuesto fue “Aseguramiento de la calidad en Proyectos de Software Libre”, para ello había utilizado una presentación ya realizada por el Debian Developer Gunnar Wolf como guía, es mas solo había actualizado información tomando esta como base para una presentación más actual, usando como ejemplo al Proyecto Debian, como un caso de éxito. Este trabajo, claro esta que no demoré mucho para terminar, tan solo una noche, rebuscar información en internet, y listo!, terminé.
El día de la presentación llegue una ponencia antes de que inicie la mía, y bueno fui presentado e inicié mi presentacion.
Donde está lo diferente a otras presentaciones. Si hay algo nuevo, no lleve mi ordenador portatil donde realizé mis presentaciones, las lleve en una memoria pendrive, también llamadas memorias flash o USB, bueno al menos eso creí, Inicie mi presentación y no encontre mis diapositivas, vaya problema, pensé entonces en descargar las diapositivas originales de Gunnar y utilizarlas, pero las maquinas del auditorio de Ing. de Sistemas de La UNSA no tenían acceso a la internet, solo me quedo solicitar a un amigo que estuvo presente, miembro del Grupo de Usuarios de GNU Linux de Arequipa, que saliera a cualquier cabina y las descargará, mientras hablaba un poco de Software Libre, por suerte no demoró más de 10 minutos en darme la mano y traer dicho material.
Para no olvidar revisar donde guardo mis diapositivas la próxima vez. Si es que me vuelven a invitar a una nueva conferencia o presentación 🙂 .

Que es scrum?


Un amigo mio me habló de scrum, qué es, para qué sirve y con qué se come. Me habló sobre los beneficios y, pricipalmente, de como aplicar scrum, pero una conversación de una hora, no era suficiente para entenderlo. Revisé en internet y encontré una pagina, mejor dicho aún, un blog muy interesante:
Enseñando scrum a mi abuela
ademas un libro que lo recomiendo, lo descargue en su version gratuita, e insto a comprarlo, lo lei y esta excelente
Pagina del libro
Versión Inglés
Versión español

Importancia de la Ingenieria de Software en los procesos de desarrollo


Conversaciones con programadores expirementados y muchos que recien incursionan, toman las herramientas para el modelamiento y planificacion como algo que no sirve y solo hara demorar su trabajo, sin sentido, mas que la misma perdida de tiempo en algo que ellos consideran sin importancia, ya que la programacion, según dicen, no tiene nada que ver con Administracion.

Muchas de las empresas que he concido, y las cuales he trabajado, algunas con trayectoria, otras que recien incian, adolecen de este mal.

El resultado, trabajos planificados para dos meses, que luego de los seis meses no se terminan, debo reconocer que yo tambien padeci este mal, y cuando este software se termina, se desea revisar, es dificil reconcer que hacia cada parte del codigo, incluso para su autor; claro si es que se llego al final del desarrollo, sobre tareas que nunca se planificaron y solo se hecharon a andar, sin un norte definido.
Pero todo esto no es nuevo, es un problema que trae muchos años desde que se inicio la industria del desarrollo de software, y que pase a haber pasado ya bastante tiempo y existir herramientas para poder planificar todo esto de alguna forma, muchos de los actuales desarrolladores, aun se resiten a usar estas herramientas, excusandose en distintos argumentos, ya sea que la programacion no es administracion, o que no es documentacion, o la documentacion no sirve, en fin….

Cuando los programadores se resisten y no quieren hacer las cosas bien, existen muchos argumentos, hasta los mas pintorescos o irritrables como “Las metodologias no sirven”. Y cuando los trabajos no salen como realmente se quiere.. también existen argumentos, como: El desarrollo de software no es como uno piensa, o era mas complicado de lo que pense, en fin, yo también los use, y en realidad, suele ser asi, pero la unica rázon, la falta de estudio del problema y su posterior planificación.

Las Ingeniería de Software es la rama de la ingeniería que crea y mantiene las aplicaciones de software aplicando tecnologías y prácticas de las ciencias computacionales, manejo de proyectos, ingeniería, el ámbito de la aplicación, y otros campos.

La Ingeniería de Software entonces nos ayuda a prevenir todos estos males, pero más importante que usar la Ingeniería de Software para ayudar en los procesos de desarrollo de software, es que los programadores entiendan la importancia de esto.

Además de la importancia de esta rama, es importante saber que existen también certificaciones a la calidad de software como por ejemplo CMMI, que evalua la capacidad de madurez de los procesos de desarrollo de software, el cual hace que un producto desarrollado por empresas con esta certificacion tenga un valor mucho mayor que las que nolo tienen.

También tenemos normas que contratantes exigen antes de decidir a que empresa desarrolladora confiaran sus necesaidades de software, normas como la ISO/IEC 12207 o la ISO/IEC 15504, que hablan sobre procesos desarrollo de software, que no es mas que Ingeniería de Software.

En conclusion, si queremos ser competitivos en la industria del desarrollo de software, produciendo software de calidad, debemos valernos de la Ingeniería de Software para conseguir este objetivo, las reglas estan dadas, las normas también, entonces, no hay que ser esquivos; pero si lo unico que buscamos es desarrollar software a corto plazo que nos rinda ganancias instantaneas, sin garantias y calidad para el consumidor, entonces tomemos el camino facil, y mantengamonos en la parte de los malos programadores, pero si lo que buscamos es producir software de calidad…. ¿Será mas dificil?, no, sólo será cuestión de doctrina y buen hábito, y nuestro producto será de calidad.