-
Revelación
Hacer la estimación y la planeación del desarrollo de un producto puede ser una tarea desalentadora que se hace más complicada por nuestra ignorancia o mala interpretación acerca de los proyectos, como concepto y en proyectos específicos. Hace tiempo leí (enlaces al final) que un proyecto no debía ser visto sólo como una secuencia de pasos, sino que también debía ser visto como un flujo rápido que genera nuevas capacidades y nuevo conocimiento. Las nuevas capacidades se entregan como parte del nuevo producto y el nuevo conocimiento se utiliza para hacer un mejor producto (Cohn 2006). Esto es la base para el enfoque de la Planificación Agile sobre la planeación.
Al comenzar a leer sobre administración de proyectos, trabajaba como desarrollador, y esa frase (del párrafo anterior) fué una de mis primeras revelaciones serias acerca de porque trabajaba tan duro codificando para funcionalidades que al final no se utilizaban o bien en proyectos que no lograban sus objetivos plenamente. Parte de las fallas de esos proyectos fueron desde luego, a veces no planear en lo absoluto, pero también tratar de planear todo desde el principio.
Plan En un proyecto Agile utilizamos las nuevas capacidades y el nuevo conocimiento obtenido como guía para el trabajo mismo que se está realizando. El conocimiento obtenido puede ser acerca del producto o del mismo proyecto en general, lo importante es que este nuevo conocimiento nos da mejor idea de cómo debería ser el producto en el cual trabajamos o bien se convierte en mejor entendimiento sobre una tecnología, sobre el equipo, sobre los riesgos, etc.
Cuando pretendemos planear todo desde el principio (ni hablar cuando no planeamos) estamos fallando en integrar nuevo conocimiento al plan, y por lo tanto eso nos lleva a caer en suposiciones erróneas, como creer que estamos incluyendo TODO lo necesario en nuestro plan (lo que en el mundo del software rara vez sucede).
Mis amigos desarrolladores son mayormente gordos y feos (pero aún así los quiero 😃) y no les gusta correr (ejercitarse, hacer cardio, etc.) , pero a mí sí, por lo que utilizaré la siguiente analogía: Una aproximación tradicional a un proyecto puede ser como una carrera de 10km donde usted sabe exactamente dónde está la meta y trata de alcanzarla tan rápido como sea posible. Un proyecto Agile es como cuando usted se toma el tiempo y ve que tan lejos puede llegar en 60 minutos. Un equipo Agile sabe cuándo termina, pero no exactamente que entregará al final. Por lo tanto, planear se convierte en proceso en donde crean y revisan objetivos periódicamente que eventualmente llevan a una meta de más largo término.
Niveles de planificación Agile
Cuando estamos preparando los objetivos de un plan es importante reconocer que no podemos ver más allá de cierto horizonte y que la exactitud de nuestro horizonte será cada vez menor entre más lejos queramos ver. En mis cursos menciono los primeros capítulos de una serie de TV llamada Vikings en donde plantean someramente el uso regular de un compás solar, un piedra solar y cuervos para poder corregir el rumbo periódicamente y mantener un curso correcto; de esta misma manera nosotros debemos revisar el estado de nuestro proyecto y ajustar nuestro plan de acuerdo a ello. Desde este punto ya estamos hablando de la elaboración de una planeación estratégica con el enfoque Agile.
Como ya expresé, el riesgo de un plan se incrementa de acuerdo a que tan lejos en el futuro queramos planear, por ello cada cierto tiempo debemos levantar nuestra vista para ver el nuevo horizonte y ajustar el plan. Los equipos Agile hacen esto planeando en por lo menos 3 distintos horizontes (podrían ser más dependiendo de la aproximación de su organización, pero en esta entrada solo explicare estos). Los 3 horizontes son el Release (Liberación), Iteración y Diaria (actual). Puede tomar como referencia el siguiente diagrama (este no es un estándar, puede encontrar diferentes diagramas similares, pero los 3 horizontes principales no cambian):
Niveles de la Planificación Agile Planificación del Release (Liberación).
Aquí determinamos respuestas a preguntas que se relacionan con el alcance, el calendario y los recursos del proyecto. Este plan debe ser actualizado a lo largo del proyecto, usualmente al inicio de cada iteración para reflejar las expectativas actuales que serán incluidas en el Release.
Planificación de la Iteración.
Esta se lleva a cabo al inicio de cada iteración y basada en el trabajo que se hizo en la iteración anterior (si no es la primera desde luego). El cliente o sus representantes (el Product Owner) deben identificar los elementos de mayor prioridad en los cuales el equipo concentrará sus esfuerzos en la nueva iteración. Esto porque estamos en un horizonte más cercano que el del Release. En este horizonte se establecen las tareas requeridas para obtener una parte funcional y probada de nuestro producto.
Planificación Diaria.
Puede sonar muy excesivo (y quizá lo es) llamar planificación a este horizonte, esto no son más que reuniones diarias e informales (que usualmente se hacen de pie ya que solo deben durar unos minutos) en donde se sincronizan los esfuerzos diarios individualmente. Esto es, que cada miembro del equipo comparte que ha hecho el día anterior, que piensa hacer hoy y comunica los obstáculos que afronta.
Con estos tres horizontes (Release, Iteración y Diaria) los equipos ágiles se concentran sólo en lo que es visible e importante en el plan que han creado. De esta manera han adoptado el enfoque de la planificación Agile.
Condiciones de Satisfacción.
En una futura entrada dedicaré más detalle a esto (lo merece) pero no quiero dejar de mencionar el tema en esta misma entrada, por lo menos de manera breve. Todo proyecto debe comenzar con una meta, quizá de esta se deriven varios objetivos relacionados con fechas, presupuesto, recursos humanos, etc., pero típicamente solo habrá una meta. No dé por hecho que usted debe crear el mejor auto del mundo, la mejor puerta del mundo, el mejor ERP del mundo; los objetivos sólo deben alinearse con las condiciones de satisfacción del Producto Owner (la voz del cliente); esto es, los criterios que serán utilizados para evaluar y determinar el éxito del proyecto.
Lo pondré de otra forma, hace mucho tiempo, cuando estaba en la secundaria era común que a la clase entera nos asignaran escribir un artículo sobre un libro, y de inmediato aparecía la pregunta obligada al profesor, la cual era qué tan largo debía ser artículo. El respondía algo así como “cinco páginas”, entonces conociamos su primera Condición de Satisfacción. Hubo, por supuesto, una serie de condiciones adicionales de satisfacción no escritas, como que el documento estubiera bien escrito, que fuera mi propio trabajo (no plagios), sin faltas de ortografía, etc.
Al comienzo de la planificación Agile del Release o lanzamiento, el equipo y el propietario del producto exploran en colaboración las condiciones de satisfacción del propietario del producto. Estos incluyen los elementos habituales (alcance, calendario, presupuesto y calidad), aunque los equipos ágiles suelen prefieren tratar la calidad como no negociable. El equipo y el propietario del producto buscan formas de cumplir con todas las condiciones de satisfacción. El propietario del producto puede, por ejemplo, estar igualmente satisfecho con un Release en cinco meses que incluya un conjunto de historias de usuarios, que con un sólo lanzamiento de un mes que incluya historias de usuarios adicionales.
A veces, sin embargo, no se pueden cumplir todas las condiciones de satisfacción del propietario del producto. El equipo puede construir el mejor procesador de textos del mundo, pero no pueden construirlo para el próximo mes. Cuando no se puede encontrar una solución factible, las condiciones de satisfacción deben cambiar. Debido a esto, la planificación del lanzamiento y la exploración de las condiciones de satisfacción del propietario del producto son altamente iterativas
Conclusión
Los proyectos deben considerarse como una generación rápida y confiable de un flujo de nuevas capacidades útiles y nuevos conocimientos, en lugar de solo la ejecución de una serie de pasos. Los proyectos generan dos tipos de conocimiento nuevo: conocimiento sobre el producto o servicio y conocimiento sobre el proyecto. Este conocimiento debe ser validado para evitar trabajo infructuoso (waste).
La siguiente imagen muestra como la planifiación Agile existe dentro de una dinámica que busca adaptar conocimiento de manera pronta y altamente iterativa (como ya se mencionó). Hemos basado esta ilustración en la propuesta del buen @sdelbecque quien toma en cuenta la filosofía de Lean, con la cual la agilidad es altamente compatible:
Lean Agile Enlaces relacionados:
El Origen Y Los Valores De Agile
Planeación, Cono de Incertidumbre y Estimaciones en IT
Estos son alguno libros recomendables para saber más:
Emmanuel Herrera
IT professional with several years of experience in management and systems development with different goals within public and private sectors.
Emmanuel worked through development and management layers, transitioning from developer and team development leader to Project Manager, Project Coordinator, and eventually to Scrum Master, Product Owner, and Agile Coach.
Some certifications include: PSM, PSPO, SSM.
No Comment
Administración / Management / Administración de Proyectos / Project Management / Cursos / Courses / IT
Este el segundo video del curso gratuito en video de Introducción a la Administración de Proyectos desde cero. En este video se muestra la definición de gestión de proyectos como actividad y se muestran las preguntas principales que buscan responder con ella.
Las temas que se tratan en este video son:
- ¿Qué problema se está resolviendo?
- ¿Cómo va a resolver este problema?
- ¿Cuál es su plan?.
- ¿Cómo saber cuando ha terminado el proyecto?
Puede ver el primer video en la entrada anterior o bien ir directo a YouTube. El video siguiente ya está diponible en esta entrada o bien en YouTube.
Mi objetivo es mantener todo el contenido de este curso (y este blog) gratis para todos, pero también es cierto que mantener este esfuerzo vivo genera gastos y consume tiempo (que si estudias o trabajas es todo un reto), es por ello que pido su paciencia y apoyo si es que ven alguna imagen o enlace con contenido publicitario. Por otro lado, he abierto un espacio en Patreon donde la gente que así lo decida puede donar para mantener este barco a flote, desde luego las personas que donen obtendrán contenido adicional:
- Video descargable en alta definición.
- Transcripción del contenido.
- Documentos y preguntas de práctica.
La estructura del curso puede verla aquí, estoy actualizando la estructura según avanzo en la misma.
Sin más preámbulo este es el segundo video de Introducción a la Administración de Proyectos, del Capítulo 1 Explorando la Administración de Proyectos. Este segundo video se titula Definición de Gestión de Proyectos:
Algunas publicaciones recomendables para saber más:
Emmanuel Herrera
IT professional with several years of experience in management and systems development with different goals within public and private sectors.
Emmanuel worked through development and management layers, transitioning from developer and team development leader to Project Manager, Project Coordinator, and eventually to Scrum Master, Product Owner, and Agile Coach.
Some certifications include: PSM, PSPO, SSM.
No Comment
Administración / Management / Administración de Proyectos / Project Management / Agile / Cursos / Courses / IT / Scrum
En esta ocasión estoy emprendiendo algo nuevo, esto es un curso gratuito en video de Introducción a la Administración de Proyectos desde cero. En este video habla de la definición de proyecto con el fin de diferenciarlo de otro tipo de esfuerzos. Se abordan las características esenciales de un proyecto como son:
- Esfuerzo único
- Meta específica
- Fechas de inicio y fin
- Recursos
- Diferencia con operación y cadena de producción.
Como instructor de estos cursos para diferentes compañías, sé que hacerlos de manera presencial tiene una serie de ventajas y requiere cierta dinámica, sin embargo, la realidad es que estos cursos no son precisamente económicos. Debido a esto he decidido hacer una serie de videos cortos preo precisos, que tienen como objetivo compartir las bases de este conocimiento. De manera tal que pueda poner estos conocimientos en práctica o bien aquellos que resulten muy interesados pueden, posteriormente, profundizar aun más pero ya contando con los fundamentos necesarios para abordar conceptos más avanzados.
Mi objetivo es mantener todo el contenido de este curso (y este blog) gratis para todos, pero también es cierto que mantener este esfuerzo vivo es un reto (sobre todo si estudias o trabajas), es por ello que pido su paciencia y apoyo si es que ven alguna imagen o enlace con contenido publicitario. Por otro lado, he abierto un espacio en Patreon donde la gente que así lo desee pueda apoyar para mantener este barco a flote, desde luego las personas que donen obtendrán contenido adicional:
- Video descargable en alta definición.
- Transcripción del contenido.
- Documentos y preguntas de práctica.
En este enlace puede consultar el contenido del curso, puede ver su estructura y decidir el ritmo y el orden en que quiere tomarlo. Los videos que conforman este curso se irán publicando progresivamente. Puede consultar las redes sociales de internet80.com para estar al pendiente de la publicación de cada video.
Sin más preámbulo este es el primer video de Introducción a la Administración de Proyectos, del Capítulo 1 Explorando la Administración de Proyectos. Este primer video se titula Definición de Proyecto:
Algunas publicaciones recomendables para saber más:
Emmanuel Herrera
IT professional with several years of experience in management and systems development with different goals within public and private sectors.
Emmanuel worked through development and management layers, transitioning from developer and team development leader to Project Manager, Project Coordinator, and eventually to Scrum Master, Product Owner, and Agile Coach.
Some certifications include: PSM, PSPO, SSM.
No Comment
Antes de continuar
Si usted no conoce las cuatro Declaraciones de Valor Agile, lo invito a que antes de continuar le eche un vistazo a la entrada El Origen Y Los Valores De Agile, si ya lo hizo o bien ya conoce estos valores, ahora puede enfocar su atención en como es el enfoque del equipo Agile en la práctica. Las cuatro Declaraciones de Valor Agile juntas suman un proceso altamente iterativo e incremental y entregan código probado al final de cada iteración. Los siguientes puntos cubren en lo general la manera en que un equipo Agile lleva un proyecto:
- Trabaja en unidad
- Trabaja en iteraciones cortas
- Libera algo en cada iteración
- Se enfoca en las prioridades de negocio
- Inspecciona y se adapta
El equipo Agile trabaja en unidad
Desafortunadamente es común ver que analistas de negocios y de sistemas arrojan procesos o requerimientos a diseñadores y programadores cual pelota sobre la barda y sin más continúan con su vida, también hay diseñadores y arquitectos que elaboran sus atractivos diseños sin la más mínima consulta a sus compañeros programadores, o bien programadores talentosos que terminan la parte del sistema que les toca y acto seguido se sacuden las manos y desaparecen; y así podemos seguir con historias tristes. Un equipo Agile exitoso debe tener una mentalidad de “todos estamos en esto juntos”.
Me gusta mucho usar analogías de juegos online, porque son una gran manera de ilustrar lo que sucede en la vida real. Muchos juegos en línea se juegan en equipo, donde cada miembro de dicho equipo tiene un rol. En esos equipos de jugadores existen roles como el healer que cura a sus compañeros, el tank que recibe golpes haciendo de escudo para que el resto ataque más eficientemente, los DPS que se encargan de hacer daño al enemigo y la clase especial que hace algun tipo de daño. Cuando algún jugador no cumple con su rol pone al resto del equipo en desventaja considerable, a veces esto quiebra al resto del equipo por completo. ¡Todos deben trabajar como uno!
Así como sucede en estos juegos los equipo ágiles también tienen roles, y vale la pena identificarlos de manera general:
Product Owner
Las responsabilidades principales del product owner incluyen el asegurarse de que todo el equipo comparte la misma visión para el proyecto, estableciendo prioridades de manera que las funcionalidades que aportan mayor valor al negocio sean siempre en las que se trabaja. Tomar decisiones que lleven al mejor retorno de inversión del proyecto y la satisfacción de usuarios finales es la máxima prioridad.
El cliente
El cliente es la persona que tomó la decisión de financiar el proyecto, usualmente representa a un grupo o división. En estos casos es común que este rol se combine con el de product owner. En otros proyectos puede ser que el cliente sea un usuario.
Desarrollador
En el contexto de equipos agile un desarrollador se usa en un contexto amplio, esto es que un desarrollador puede ser un programador, un diseñador gráfico, un ingeniero de base de datos, expertos en experiencia de usuario, arquitectos, etc.
Project manager
Hay que tomar esto con algo de cuidado, porque un agile project manager se enfoca más en el liderazgo que en el management o (gestión tradicional del proyecto). En algunos proyectos y marcos de trabajo ágiles la persona encargada de este rol comparte las responsabilidades de un project manager tradicional con otros roles como el de product owner. También puede hacerse cargo de asesorar en la adopción y comprensión del enfoque agile. En proyectos muy pequeños puede incluso tener un rol como desarrollador, pero esta práctica no recomendable.
Un equipo Agile trabaja en iteraciones cortas
Ya lo mencionaba anteriormente, en proyectos ágiles no hay una delineación de fases demasiado marcada. No hay un establecimiento exhaustivo de requerimientos al comienzo del proyecto seguido de un análisis, no hay fase de diseño de arquitectura para todo el proyecto. Una vez que el proyecto inicia de verdad, todo el trabajo (análisis, diseño codificación, testing, etc.) ocurre junto dentro de una iteración.
Las iteraciones se hacen dentro de espacio de tiempo delimitado previamente (timeboxed). Esto significa que cada iteración se termina en el tiempo acordado sin excusas, incluso aunque las funcionalidades previstas no se terminen. Las iteraciones son a menudo muy cortas. La mayoría de los equipos ágiles utilizan iteraciones de entre una semana y cuatro semanas.
Un equipo Agile libera algo en cada iteración
Algo crucial en cada iteración es que dentro de su espacio de tiempo uno o más requerimientos se transformen en software codificado, probado y potencialmente empaquetable. En la realidad esto no significa que algo se les entregue a los usuarios finales, pero se debe estar en posibilidades de hacerlo. Las iteraciones una a una van sumando la construcción de solo algunas funcionalidades, de esta manera se va obteniendo un desarrollo incremental al ir de una iteración a la siguiente.
Debido a que una sola iteración usualmente no provee tiempo suficiente para desarrollar todas las funcionalidades que el cliente desea, se creó el concepto de release. Un release comprende una o más (casi siempre más) iteraciones. Los releases pueden ocurrir en una gran variedad de intervalos, pero es común que los releases duren entre 2 y 6 meses. Al terminar un release a este le puede seguir otro release y a su vez a este le puede seguir otro, así hasta terminar el proyecto.
Un equipo Agile se enfoca en las prioridades del negocio
Los equipos ágiles demuestran un compromiso con las prioridades comerciales de dos maneras. Primero, entregan funcionalidades en el orden especificado por el product owner, de quien se espera priorice y combine características en un release que optimiza el retorno de inversión de la organización en el proyecto. Para lograr esto, se crea un plan para el release basado en las capacidades del equipo y en una lista priorizada de las nuevas funcionalidades deseadas. Para que el product owner tenga mayor flexibilidad en la priorización, las características deben ser escritas minimizando las dependencias técnicas entre ellas.
En segundo lugar, los equipos ágiles se centran en completar y entregar funcionalidades valoradas por el usuario en lugar de completar tareas aisladas.
Un equipo Agile inspecciona y adapta
Siempre es bueno crear un plan, pero el plan creado al inicio no garantiza lo que ocurrirá en el futuro. De hecho un plan es solo una suposición en un punto del tiempo. Si usted vive perseguido por la Ley de Murphy como yo 😀, habrá muchas cosas que conspirarán contra el plan. El personal del proyecto puede ir o venir, las tecnologías funcionarán mejor o peor de lo esperado, los usuarios cambiarán de opinión, los competidores pueden obligarnos a responder de manera diferente o más rápida, y así sucesivamente. Los equipos ágiles ven que cada cambio representa tanto una oportunidad como la necesidad de actualizar el plan para mejorar y reflejar la realidad de la situación actual.
Al comienzo de cada nueva iteración, un equipo agile incorpora todo el nuevo conocimiento obtenido en la iteración anterior y se adapta en consecuencia. Si un equipo aprendió algo que probablemente afecte la precisión o el valor del plan, hay que actualizar el plan. Esto es, que quizá el quipo descubrió que han sobreestimado o subestimado su capacidad de progreso (capacity) y que un cierto tipo de trabajo consume más tiempo del que se pensó anteriormente.
De la misma forma el plan se puede ver afectado por el conocimiento que el product owner ha ganado de los usuarios. Quizá por la retroalimentación obtenida de una iteración previa el product owner ha aprendido que los usuarios quieren ver más de algún tipo de funcionalidad y ya no valoran tanto otra que havían considerado. Este tipo de situaciones pueden alterar el plan, de manera que hay que adaptar el mismo para mejorar su valor.
Enlaces relacionados:
Roles on Agile Teams: From Small to Large Teams
El Origen Y Los Valores De Agile
What Is Agile?
Planeación, Cono de Incertidumbre y Estimaciones en ITEstos son alguno libros recomendables para saber más:
¡Caulquier ayuda en bienvenida para mantener este esfuerzo vivo! PayPal Account BTC (Bech32): bc1qx6f8nczr5ram6d57svlnsfmk5mhu6lsr9q7mxw BTC: 1DDcWbphm1bKMvWruotNKLSM8ypVaHg5Nv ETH: 0x58D137fb142D946bCD815f0ded0fa3b3fE5AB3BF
Emmanuel Herrera
IT professional with several years of experience in management and systems development with different goals within public and private sectors.
Emmanuel worked through development and management layers, transitioning from developer and team development leader to Project Manager, Project Coordinator, and eventually to Scrum Master, Product Owner, and Agile Coach.
Some certifications include: PSM, PSPO, SSM.
No Comment
About This Post
Some years ago I get interested in Agile software development and I have been using the Scrum product development framework in several projects, but eventually, I decided to formalize this knowledge starting with a Scrum Master certification. When I talked about this with some friends and acquaintances I was surprised when a lot of them started to ask me about it with many doubts and confusions.
To try to shed some light, I will get into a heated territory within the Scrum community, sharing my experience while and I will try to answer several of the first questions that come to mind when you’re interested in a Scrum certification. It should be noted that nobody is paying me for my opinion (I wish….).
Why get a Scrum Master certification?
I was a developer who finds himself involved with Agile and Scrum some years ago (more by emergency than by good judgment) in order to finish projects near of collapse. Little by little and still with many setbacks but also proposing good practices to the management and in an active role, the teams which I was part of, successfully managed to get out of several quagmires, but the truth is that I never felt the need to obtain any formal validation for that knowledge. Eventually, fate, time and several fellow developers pushed me to take a more active role on the project management side, but I found that several clients and employers were asking me for certified Skills in Scrum and/or Project Management (foolish!).
Around 2013, while I was looking for a new job, I began to notice that more and more vacancies, for project managers and even developers, required Scrum knowledge. Considering that many times in the past managers, directors and even project managers asked me what was that Scrum thing, I noticed that things were changing in a remarkable way.
So, the message was clear. If I wanted to have a better chance of finding interesting (and reasonably paid) jobs, I had to certify my knowledge. But that was the easy part; I spent a good amount of time researching what my options were. In the rest of this post, I condensed what I learned about Scrum certifications under the Scrum Master role.
Scrum Master Certifications
The first thing is to clarify that there are several organizations offering Scrum Master certifications, the best known are:
- Certified Scrum Master (CSM) by Scrum Alliance.
- Professional Scrum Master (PSM) by Scrum.org.
- Scrum Master Certified (SMC) by SCRUMstudy.
- SAFe Scrum Master by Scaled Agile Framework
This post only addresses these four certifications, but there are others that probably you want to consider:
- PMI_ACP. Project Management Institute Agile Certified Practitioner is offered by the Project Management Institute.
- ICAgile Certifications. Certifications offered by the International Consortium for Agile.
*Please note that all figures presented are valid as of the date of publication of this entry and may change without prior notice.
Certified Scrum Master (CSM) from Scrum Alliance
This is the most known and long-lived certification of all. The Scrum Alliance was founded by one of the two creators of Scrum, Ken Schwaber along with other heavyweights of Agile and Scrum world such as Esther Derby and Mike Cohn.
However, today there are some criticisms for this certification because although it is the most widely recognized certification, it’s open knowledge that all certifications issued before 2012 did not require any evaluation, being the only requirement to attend an official course of the Scrum Alliance. In response, the Scrum Alliance has changed the Certified Scrum Master (CSM) certification process to the following mandatory steps:
- Familiarize yourself with the basic concepts of Scrum.
- Attend the official CSM course.
- Obtain the certificate that verifies the completion of the CSM course and passes the CSM evaluation with a minimum score of 69% (still considered a low percentage by some practitioners).
The courses can only be taught by the Certified Scrum Trainers, but as the courses are not approved, it seems that the quality of each course depends on the skills, experience, and materials that each instructor can offer independently.
The course cost includes the evaluation, can change from region to region, but ranges are between *$850 USD and *$1,300 USD. To maintain valid CSM certification, it must be renewed every two years at a cost of *$100 USD but the Scrum Alliance also introduced the Scrum Education Units, which can be used to renew its certifications. In the same vein, for those holding PMI certifications, these courses also provide PDUs.
Update 2018: The Scrum Alliance integrated new certifications to its offer, including one more as Scrum Master. Following a similar strategy to Scrum.org a certification called Advanced Certified ScrumMaster (A-CSM) have been added, which has as requirements:
- Attend to a required A-CSM course.
- Successfully complete the previous or later work to the course that the instructor may consider necessary in order to meet the learning goals.
- Validate at least one year of work experience specific to the role of ScrumMaster (within the past five years). This point is important because at least 12 months must be logged since you got your CSM certification before you can try for A-CSM.
- Hold an active Certified ScrumMaster (CSM) certification with the Scrum Alliance.
The cost of the course and the right to A-CSM exam also can vary depending on the region but according to our investigation, this is about $2500 USD.
Professional Scrum Master (PSM) from Scrum.org
The Scrum Alliance and Ken Schwaber had a separation in 2009 and this led to the latter founding of a new organization called Scrum.org, which offers courses and certifications for PSM among others. After the Scrum Alliance certification, this is the most widespread Scrum Master certification, gaining more and more recognition in the industry. Something different in Scrum.org is they don’t offer just a single certification, you can get three different levels of Scrum Master certification from them, this is the PSM I, PSM II and PSM III.
It’s important to mention that today a large part of the Scrum community address to these certifications as the most difficult to obtain, because PSM I, PSM II and PSM III require evaluations with minimum scores of 85% and since they include questions of high difficulty, being required to get the PSM I to be able to obtain the PSM II, and these two before being able to try the PSM III test. Several sources reported that there is a relatively high amount of people who, even with experience in Scrum or other certifications, fail these assessments.
In spite of how intimidating this may sound, an encouraging point is that none of these evaluations require the applicant to attend a course, so in theory, these certifications can be achieved with the appropriate time for study, revision and/or experience, in addition, these certifications do not need to be renewed.
The cost for the PSM I evaluation is *$150 USD, for the PSM II it’s *$250 USD and for the PSM III it’s *$500 USD, with the right to one single attempt.
The optional Professional Scrum Master course offered by Scrum.org can only be taught by the Professional Scrum Trainers, who have approved materials. The costs of the courses seem to go between *$1295 and *$1995 USD.
As with the Scrum Alliance courses, PMI certification holders can obtain PDUs for the PSM courses.
PSM I Exam Simulator: In order to help those who want this certification, in internet80 we have undertaken the task of developing a simulator of this test completely free. The simulator is in the testing phase but is now available to everyone. Evaluate your knowledge about the Scrum framework now here: PSM I Exam Simulator 1
Scrum Master Certified (SMC) from SCRUMstudy
This is the most controversial certification of those mentioned in this post and within the Scrum community, So far I don’t know who is/are exactly the founders of this organization, but they have the credit of having created a free book in its digital version, called the SBOK Guide or Scrum Body of Knowledge whose main author is Tridibesh Satpathy. This organization offers SCM certification.
The SCM certification bases its assessment on the SBOK Guide, which has a process approach (similar to the PMI’s PMBOK), and another concepts called principles and aspects, that is, everything is in the context of the interpretation made by the authors about Scrum in the SBOK Guide, which has caused this organization to have serious differences with many practitioners and founders of Scrum who even took part in the creation of the Agile manifesto and therefore with a large part of the Scrum community; although on the other hand, it has achieved a certain amount of acceptance from the industry.
One point against this certification, which may be eventually important for some people, is that the most popular Scrum scaling frameworks such as SAFe, LeSS or Nexus are based on the Scrum Guide and do not recognize SBOK. This may be important since being SAFe the most influential scaling framework so far, and if you want to obtain a certification as SAFe Advanced Scrum Master, the Scaled Agile organization does NOT consider relevant the SCRUMstudy certification.
Update 2017: The Scaled Agile Framework organization who provides SAFe, now offers its own Scrum Master certification, called SAFe Scrum Master (SSM), don’t get confused with SAFe Advanced Scrum Master certification, this one puts a pre-prerequisite neither CSM nor PSM anymore, but put them as highly suggested in order to take its certification course.
The minimum score in their respective evaluation to obtain this certification is of *95%, although in my research I have obtained testimonies and mixed comments on their difficulty, they do not have prerequisites although their SBOK must be strongly studied since apparently the exam attacks only the perspective of this guide.
The cost of the test is *$450 USD with *3 attempts and requires *40 re-certification units every *3 years (these units are obtained by different activities).
According to my research, the SMC course content is approved and can only be provided by the SCRUMstudy Certified Trainers whose are based mostly on the SBOK guide, the costs are around *$450 USD, but costs can change between regions and partners. The testimonials I got were quite mixed, I got good comments about the courses materials offered but one thing I was told several times is that when the trainers face questions and/or scenarios outside the context of the SBOK Guide, these instructors really struggle a lot to solve doubts from the “real world”. SCRUMstudy has several partners to offer their courses.
PDUs are also offered if you take the SMC course.
Update 2018: SCRUMstudy has followed the strategy that Scrum.org started and also Scrum Alliance followed. Now, this organization offers an advanced Scrum Master certification which is called Expert Scrum Master Certified (ESMC), and its requirements are:
- Having three years of experience in Scrum / Agile project management.
- Hold the certifications SMC, SAMC y SPOC.
- Submit 500 words write up about two Scrum / Agile projects.
- The official web page also indicates that you can attend to a 2-days ESMC face to face training, of course, provided by SCRUMstudy, however, doesn’t clearly indicate whether this is mandatory, substitute or facilitates any of the previous requirements.
The cost of the exam to obtain this certification at the time of this publication is $800 USD which may vary depending on the region. You will also have to obtain 60 RCUs every 3 years to maintain this certification.
SAFe Scrum Master
I added this certification this year (2018) because this emerged in late 2016 (months after this post), don’t get confused with the SAFe Advanced Scrum Master certification. SAFe focuses on large organizations Agile model implementation and today is the most popular escalation framework, but it’s not the only one (there are others such as Nexus, LeSS, DaD, and others). But let’s take it one step at a time because I’ve discovered out that this certification has aroused some confusion.
Previously the Scaled Agile Framework only offered the SAFe Advanced Scrum Master which is totally dedicated to this Scrum scaling framework approach, and within its prerequisites, it was required to have either CSM or PSM certifications.
Now offers its own “basic” certification which uses the Scrum Guide approach but also introduces its SAFe escalation framework approach early on, this is the SAFe Scrum Master certification. The prerequisites for this certification are knowing the agile approach and knowing the Scrum, Kanban and XP frameworks, and at the same time having first-hand experience in the software and hardware development process, and of course to take obligatorily the SAFe Scrum Master course.
According to the testimonies I’ve got, the contents of this course are homologated and are abundant, I didn’t find anything about the instructor’s qualifications who teach the courses, but apparently, both the instructors and the exam are totally oriented to the content provided during it. The first attempt for this certification test is included in the course cost (which varies between countries and regions), each additional attempt costs *$50 USD, it is a web-based test (is not clear for me if you can take the this from anywhere), to approve requires between *33 and 45 correct answers (73% of accuracy).
Something good is that just about three years ago you had to travel to the United States to take some of the SAFe courses and exams, but now these are available in several countries on all continents, which speaks of the popularity of this scaling model. Keep in mind that if you get this certification you must renew it *every year at a cost of $100 USD (which is a short-term compared with rest of the certifications).
This course offers PDUs for PMI certification holders and SEUs for those with some Scrum Alliance certifications.
Resumen
- The Certified Scrum Master (CSM) certification is more widely known than the Professional Scrum Master (PSM) and the Scrum Master Certified (SMC).
- The training costs for PSM are (on average) higher than CSM and SMC training courses and are not available in all countries. The costs of CSM are usually higher than SMC.
- The costs of acquiring and maintaining CSM certification are higher than those for SMC and PSM, the latter being the cheapest since no payment is required to maintain the certification.
- The value of CSM certification is very questioned especially if it was issued before 2012 (it was granted without evaluation).
- The materials and the quality of the courses for CSM can vary greatly since they are not approved.
- The materials provided for PSM and SMC in their training are approved (and according to several testimonies are usually good).
- The SMC certification is based on the practices described in the SBOK and not necessarily as described in the Scrum Guide (text by the creators of Scrum).
- The value of the SMC certification is questioned by many important members and organizations in the Scrum community.
- The most important scaling framework at the moment (SAFe) strongly suggests holding either the SAFe Scrum Master (SSM), Certified Scrum Master (CSM) or Professional Scrum Master (PSM) certifications in order to obtain several of its certifications including the SAFe Advanced Scrum Master (SASM).
- SAFe offers the SAFe Scrum Master (SSM) certification which is oriented to Scrum scaling in large organizations but is not the only escalation model and not every organization have or plan to use this approach.
- The SAFe Scrum Master (SSM) certification must be renewed every year for a cost, which is short-term compared with the rest of the certification.
* Correct figures at the time of publication. They can change without notice.
Sorry about my English I’m not a natural speaker (don’t be grumpy, help me to improve 🙂 ).
Related Links:
PSM I FREE Exam Simulator 1
Agile’s origins and valuesSome book that can be interesting for you:
Emmanuel Herrera
IT professional with several years of experience in management and systems development with different goals within public and private sectors.
Emmanuel worked through development and management layers, transitioning from developer and team development leader to Project Manager, Project Coordinator, and eventually to Scrum Master, Product Owner, and Agile Coach.
Some certifications include: PSM, PSPO, SSM.
14 Comments
Vientos de Cambio
Mucho se oye de Agile, de Agile project management o de la “Agile methodology” como algo propio del siglo XXI, pero en realidad el origen y los valores Agile comezaron a gestarse un poco antes. Los 90s fueron una década muy interesante, MTV tuvo su mejor momento, la música Grunge invadió la radio y la Internet llegó a la vida de las masas. Junto con todo el boom de Internet la manera de hacer software cambió por completo, las empresas comenzaron a aprender cómo hacer software a gran escala y para usuarios interconectados en todo el mundo, lo que trajo nuevas exigencias. En la búsqueda del éxito muchas de esas compañías comenzaron a importar las “buenas prácticas” de otras industrias esperando buenos resultados, los cuales al final fueron mixtos en muchos casos (vea Waterfall Model).
Muchos sistemas electromecánicos ya comenzaban a ser sustituidos por electrónica, y un tiempo después el software comenzó a tener cada vez más relevancia, pero el desarrollo y la interacción de estos elementos se vieron atrapados por modelos predictivos que intentaban saber todos elementos involucrados en un sistema de antemano, lo cual resultaba (y aún resulta) muy difícil de establecer al comienzo de un proyecto de software con altos niveles de incertidumbre, lo que causa desde entonces periodos de tiempo de desarrollo muy largos con fechas de término difíciles de predecir. Esta situación llevó a la frustración a muchos líderes, quienes a pesar de la situación fueron creando y adaptando sus propias técnicas, métodos y marcos de trabajo a los modelos tradicionalistas de desarrollo, lo que eventualmente dio pie a los primeros guiños del pensamiento Agile.
Nace Agile
Después de varias reuniones previas, en Febrero del 2001 un grupo de profesionales tuvieron una nueva y ahora famosa reunión cuyo mayor aporte fue el Manifiesto Agile (The Agile Manifesto). Este manifiesto fue escrito y firmado por diecisiete líderes del desarrollo de software (hoy conocidos como la Comunidad Agile). Su documento dio un nombre a cómo este grupo estaba desarrollando software y proporcionó una lista de declaraciones de valor Agile:
- Individuos e interacciones sobre procesos y herramientas
- Software trabajando sobre documentación completa
- Colaboración del cliente sobre la negociación del contrato
- Responder al cambio sobre seguir un plan
Y el grupo añadió:Esto es, mientras que hay valor en los elementos en la derecha, valoramos más los elementos de la izquierda.Puede ver la historia y el manifiesto original en agilemanifesto.org
En particular, estos líderes de opinión buscaron formas de construir rápidamente un software en funcionamiento y ponerlo en manos de los usuarios finales. Este enfoque de entrega rápida proporcionó un par de beneficios importantes. Primero, permitió a los usuarios obtener algunos de los beneficios comerciales del nuevo software más rápido. En segundo lugar, permitió que el equipo de software obtuviera retroalimentación rápida sobre el alcance y la dirección de los proyectos de software de forma periódica. En otros palabras el enfoque Agile había nacido.
Detrás de las Declaraciones de Valor Agile.
Ya conoce la lista de declaraciones de valor, pero veamos cuales son las razones detrás de ellas:
Valorar las personas y las interacciones sobre los procesos y herramientas. Los que tenemos un camino en recorrido en el mundo de desarrollo sabemos que un equipo con grandiosas personas funciona bien aun utilizando mediocres herramientas y que estos equipos siempre superan a otros equipos disfuncionales con personas mediocres que tienen excelentes herramientas y procesos. Si se trata a las personas como piezas desechables no habrá proceso, herramienta o metodología que salve a sus proyectos de fallar. Los buenos procesos de desarrollo reconocen las fortalezas (y debilidades) de los individuos y sacan provecho de ello en lugar de intentar que todos sean homogéneos.
Valorar el software que funciona sobre la documentación completa. Porque nos lleva a tener versiones incrementalmente mejoradas del producto al final de cada iteración. Esto hace posible recolectar temprana y frecuentemente algo de retroalimentación sobre el producto y el proceso nos permite saber si deberemos corregir el rumbo, hacer ajustes o seguir adelante con la misma visión. A medida que el software desarrollado crece con cada iteración, se puede mostrar a los usuarios probables o reales. Todo esto facilita la relación con los clientes y mejora las probabilidades de éxito.
Valorar la colaboración con el cliente sobre la negociación de contratos. Porque para crear equipos ágiles debemos buscar que todas las partes involucradas en el proyecto trabajen para lograr el mismo conjunto de metas. La negociación de contratos a veces pone en conflicto al equipo de desarrollo y al cliente desde el principio. Creo que los juegos multiplayer online battle arena son un gran ejemplo, personalmente me gustan juegos como Heroes of the Storm o League of Legends. Estos son juegos cooperativos donde se forma un equipo de 5 miembros, el objetivo es que el equipo debe destruir la base del enemigo trabajando juntos. Todos los jugadores ganan, o todos los jugadores pierden. Estos juegos son sorprendentemente divertidos, y lo que nos gustaría es que los equipos de desarrollo de software y los clientes se acercaran con esta misma actitud de colaboración y objetivos compartidos. Sí, los contratos a menudo son necesarios, pero los términos y detalles en un contrato puede ejercer una gran influencia sobre las diferentes partes involucradas, y convertir un ambiente colaborativo a uno competitivo.
Valorar responder a los cambios sobre seguir un plan. Porque el objetivo principal es aportar la mayor cantidad de valor posible al cliente del proyecto y usuarios. En proyectos grandes y/o complejos, encontrará que es muy difícil incluso para los usuarios y/o clientes, conocer cada detalle de cada característica que desean. Es inevitable que los usuarios vengan con nuevas ideas, o bien que decidan que algunas características críticas inicialmente ya no lo son tanto. Para un equipo ágil, un el plan es una visión del futuro, pero muchos puntos de vista son posibles y los factores ambientales pueden cambiar con el tiempo. A medida que un equipo gana conocimiento y experiencia sobre un proyecto, el plan debe ser actualizado de acuerdo a ello.
Con las cuatro declaraciones de valores del Manifiesto Ágil en mente creo que puede comenzar a comprender que significa tener un enfoque ágil para estimar y planificar.
Enlaces relacionados:
To agility and beyond: The history—and legacy—of agile development
What Is Agile?
Planeación, Cono de Incertidumbre y Estimaciones en ITEstos son alguno libros recomendables para saber más:
Emmanuel Herrera
IT professional with several years of experience in management and systems development with different goals within public and private sectors.
Emmanuel worked through development and management layers, transitioning from developer and team development leader to Project Manager, Project Coordinator, and eventually to Scrum Master, Product Owner, and Agile Coach.
Some certifications include: PSM, PSPO, SSM.
No Comment
The XMLHttpRequest object
The XMLHttpRequest object has been updated several times since was defined as the WHATWG’s HTML effort using Microsoft technology; then we had the original XMLHttpRequest Level 1 specification as part of W3C, we also had the XMLHttpRequest Level 2 updated specification, and now we have the last version of this object known as XMLHttpRequest Living Specification. We can summarize its advantages in the following points:
- Allows upload and download files as stream bytes, large binaries (BLOBs) or data forms
- It has event handlers for progress, errors, abortion, start, and end of operations
- Cross-domain capabilities (CORS)
- New type for JSON responses
- Is a fundamental part of the HTML5 File API specification
It’s important to emphasize that before HTML5 and the latest versions of XMLHttpRequest object it was required to resort to server-side technology in order to able to perform an uploading file operation, that is, it wasn’t possible to upload a file natively from the client side. Technologies as AJAX and Flash did their own effort but with serious limitations, so XMLHttpRequest comes to cover this old problem in a big way. There are other additional features that come with XMLHttpRequest, if you want to know more you can resort to the official specification.
Starting
The first thing we’ll do is to define the user interface for this small implementation starting with the HTML tags, the code is very simple and only includes some form elements, and some div tags that are only used to give a better presentation using CSS3. I won’t analyze in this post anything related to the used cascade style sheets since is not something really necessary for the operation of this example.
<!DOCTYPE html> <html> <head> <title>Upload File</title> <meta charset="iso-8859-1" /> </head> <body> <div id="wrap"> <div class="field"> <ul class="options"> <li><input type="file" id="myfile" name="myfile" class="rm-input" onchange="selectedFile();"/></li> <li><div id="fileSize"></div></li> <li><div id="fileType"></div></li> <li><input type="button" value="Subir Archivo" onClick="uploadFile()" class="rm-button" /></li> </ul> </div> <progress id="progressBar" value="0" max="100" class="rm-progress"></progress> <div id="percentageCalc"></div> </div> </body> </html>The previous code explains itself, but let’s summarize what is in there:- A file-type input which will be used to select the file to be uploaded
- A div which will be used to print the size of the selected file
- A div which will be used to print the MIME type of the selected file
- A button which will fire the uploading process for the selected file
- A progress bar to indicate the uploading process progress of the selected file
- Finally, a div where the progress will be shown in a percentage format
The selectedFile() function
Each time you select a file using the file element, you also trigger the onchange event which calls the selectedFile() function. In this function very interesting things happen, to start, a reference to a file array instantiated by the HTML5 object FileList is done, the objects that we get as members of FileList are File objects. In this case, we’ll get the size and type properties from the gotten File object.Using the information provided by the size property, the size of the selected file is calculated and shown in megabytes or kilobytes within the function. With the type property, the MIME type of the selected files is gotten and showed in the corresponding div.function selectedFile() { var archivoSeleccionado = document.getElementById("myfile"); var file = archivoSeleccionado.files[0]; if (file) { var fileSize = 0; if (file.size > 1048576) fileSize = (Math.round(file.size * 100 / 1048576) / 100).toString() + ' MB'; else fileSize = (Math.round(file.size * 100 / 1024) / 100).toString() + ' Kb'; var divfileSize = document.getElementById('fileSize'); var divfileType = document.getElementById('fileType'); divfileSize.innerHTML = 'Tamaño: ' + fileSize; divfileType.innerHTML = 'Tipo: ' + file.type; } }The uploadFile() function
Esta es la función que hace un mayor uso de las nuevas posibilidades de XMLHttpRequest , y es la que se encargará de disparar el proceso principal del lado cliente.
function uploadFile(){ //var url = "/ReadMoveWebServices/WSUploadFile.asmx/UploadFile"; var url = "/ReadMoveWebSite/UploadMinimal.aspx"; var archivoSeleccionado = document.getElementById("myfile"); var file = archivoSeleccionado.files[0]; var fd = new FormData(); fd.append("archivo", file); var xmlHTTP = new XMLHttpRequest(); //xmlHTTP.upload.addEventListener("loadstart", loadStartFunction, false); xmlHTTP.upload.addEventListener("progress", progressFunction, false); xmlHTTP.addEventListener("load", transferCompleteFunction, false); xmlHTTP.addEventListener("error", uploadFailed, false); xmlHTTP.addEventListener("abort", uploadCanceled, false); xmlHTTP.open("POST", url, true); //xmlHTTP.setRequestHeader('book_id','10'); xmlHTTP.send(fd); }At the beginning, we have the variable url that we’ll use to indicate where is the page o web service which is going to receive the request from this page to do the proper process on server side. Immediately like in the selectedFile() function, a reference to the gotten File object member is also done.In the fourth line, there is something new and very useful, that is the FormData object, this object allows to instantiate a web form via JavaScript, that is, is like you put an HTML form using tags, or you can refer to an already existing one assigning it to a FormData object. No doubt this is really helpful since means now you can create a web form y alter the sending values dynamically. To append values to, either instantiated or referenced web form with FormData, use the append(file, object) method, this way in the fifth line our File object is added with the file name.This is the code of the function that covers what was just stated://var url = "/ReadMoveWebServices/WSUploadFile.asmx/UploadFile"; var url = "/ReadMoveWebSite/UploadMinimal.aspx"; var archivoSeleccionado = document.getElementById("myfile"); var file = archivoSeleccionado.files[0]; var fd = new FormData(); fd.append("archivo", file);Event handlers
Continuing with the rest of the function, we can observe that the XMLHttpRequest object is finally instantiated and is assigned to the xmlHTTP variable, and then we proceed to the next novelty, I mean the possibility of creating new events which are part of XMLHttpRequest thanks to the upload object. The added events for this particular case are:- loadstart. Is triggered when the uploading file process initiates.
- progress. Is triggered each time there is an advance in the file uploading process.
- load. Is triggered when the transfer is complete successfully.
- error. Is triggered when the transfer fails
- abort. Is triggered when the user/developer interrupts the process.
These aren’t the only available events, check the official specification for more information.The event handlers are declared in the following code:var xmlHTTP= new XMLHttpRequest(); //xmlHTTP.upload.addEventListener("loadstart", loadStartFunction, false); xmlHTTP.upload.addEventListener("progress", progressFunction, false); xmlHTTP.addEventListener("load", transferCompleteFunction, false); xmlHTTP.addEventListener("error", uploadFailed, false); xmlHTTP.addEventListener("abort", uploadCanceled, false);The triggered events functions are the following:
function progressFunction(evt){ var progressBar = document.getElementById("progressBar"); var percentageDiv = document.getElementById("percentageCalc"); if (evt.lengthComputable) { progressBar.max = evt.total; progressBar.value = evt.loaded; percentageDiv.innerHTML = Math.round(evt.loaded / evt.total * 100) + "%"; } } function loadStartFunction(evt){ alert('Comenzando a subir el archivo'); } function transferCompleteFunction(evt){ alert('Transferencia completa'); var progressBar = document.getElementById("progressBar"); var percentageDiv = document.getElementById("percentageCalc"); progressBar.value = 100; percentageDiv.innerHTML = "100%"; } function uploadFailed(evt) { alert("Hubo un error al subir el archivo."); } function uploadCanceled(evt) { alert("La operación se canceló o la conexión fue interrunpida."); }ProgressFunction() updates the progress bar and percentage which indicate in a graphical and numerical way the process progress, the rest of the functions only display the proper message for each case.
Commented code
If you have observed the code you probably noticed some commented lines, this is because this is just the base code to create something a little bit more complex, but I decided to leave those lines because maybe can be useful for someone:
//var url = "/ReadMoveWebServices/WSUploadFile.asmx/UploadFile";
The previous line of code is a call to a .Net HTTP service instead of a page. Here is where you should call your own server-side implementation.
//xmlHTTP.upload.addEventListener("loadstart", loadStartFunction, false);This line calls a function that shows a message when the process starts. I commented this line after I executed the code several times because was annoying.
The completo code
This is how the complete implementation of the code looks:
<!DOCTYPE html> <html> <head> <title>Upload File</title> <meta charset="iso-8859-1" /> <link rel="stylesheet" type="text/css" href="estilosUploadFile.css" /> <script type="text/javascript"> function selectedFile() { var archivoSeleccionado = document.getElementById("myfile"); var file = archivoSeleccionado.files[0]; if (file) { var fileSize = 0; if (file.size > 1048576) fileSize = (Math.round(file.size * 100 / 1048576) / 100).toString() + ' MB'; else fileSize = (Math.round(file.size * 100 / 1024) / 100).toString() + ' Kb'; var divfileSize = document.getElementById('fileSize'); var divfileType = document.getElementById('fileType'); divfileSize.innerHTML = 'Tamaño: ' + fileSize; divfileType.innerHTML = 'Tipo: ' + file.type; } } function uploadFile(){ //var url = "http://localhost/ReadMoveWebServices/WSUploadFile.asmx?op=UploadFile"; var url = "/ReadMoveWebServices/WSUploadFile.asmx/UploadFile"; var archivoSeleccionado = document.getElementById("myfile"); var file = archivoSeleccionado.files[0]; var fd = new FormData(); fd.append("archivo", file); var xmlHTTP= new XMLHttpRequest(); //xmlHTTP.upload.addEventListener("loadstart", loadStartFunction, false); xmlHTTP.upload.addEventListener("progress", progressFunction, false); xmlHTTP.addEventListener("load", transferCompleteFunction, false); xmlHTTP.addEventListener("error", uploadFailed, false); xmlHTTP.addEventListener("abort", uploadCanceled, false); xmlHTTP.open("POST", url, true); //xmlHTTP.setRequestHeader('book_id','10'); xmlHTTP.send(fd); } function progressFunction(evt){ var progressBar = document.getElementById("progressBar"); var percentageDiv = document.getElementById("percentageCalc"); if (evt.lengthComputable) { progressBar.max = evt.total; progressBar.value = evt.loaded; percentageDiv.innerHTML = Math.round(evt.loaded / evt.total * 100) + "%"; } } function loadStartFunction(evt){ alert('Comenzando a subir el archivo'); } function transferCompleteFunction(evt){ alert('Transferencia completa'); var progressBar = document.getElementById("progressBar"); var percentageDiv = document.getElementById("percentageCalc"); progressBar.value = 100; percentageDiv.innerHTML = "100%"; } function uploadFailed(evt) { alert("Hubo un error al subir el archivo."); } function uploadCanceled(evt) { alert("La operación se canceló o la conexión fue interrunpida."); } </script> </head> <body> <div id="wrap"> <div class="field"> <ul class="options"> <li> <input type="file" id="myfile" name="myfile" class="rm-input" onchange="selectedFile();"/> </li> <li> <div id="fileSize"></div></li> <li> <div id="fileType"></div></li> <li> <input type="button" value="Subir Archivo" onClick="uploadFile()" class="rm-button" /></li> </ul> </div> <progress id="progressBar" value="0" max="100" class="rm-progress"></progress> <div id="percentageCalc"></div> </div> </body> </html>I’m not describing the CSS3 code because is irrelevant in terms of functionality, but I share an image that shows how it looks the implementation in the browser and the link to the CSS3 estilosUploadFile.zip.
I’m also sharing the original HTTP service that I used to test this example -the server-side code, backend file or any name that you prefer 😃- but this won’t be very useful for you unless you use the exact same stack that I was using at the moment- in other words, if you are the kind of person who just wants to copy and paste….hehehe well….maybe you’re not ready for this yet. Here is the file WSUploadFile.zip
Sorry about my English I’m not a natural speaker (don’t be grumpy, help me to improve).
This is all for now folks, I hope this can be useful for you.
Here some books that can help you in your HTML5 journey:
Emmanuel Herrera
IT professional with several years of experience in management and systems development with different goals within public and private sectors.
Emmanuel worked through development and management layers, transitioning from developer and team development leader to Project Manager, Project Coordinator, and eventually to Scrum Master, Product Owner, and Agile Coach.
Some certifications include: PSM, PSPO, SSM.
4 Comments
El propósito de Planear
Constantemente les digo a mis amigos y compañeros de trabajo que las ideas no son lo mismo que la planeación. Recuerde la última vez que comenzó algo que, por diversas razones, nunca terminó, o aquella ocasión que dijo mis “planes” son…, pero en la realidad nunca realizó verdaderas acciones para concretar esos “planes” o bien simplemente sigue posponiéndolos. La principal diferencia entre ideas y planes radica básicamente en que las ideas son algo vago, aspiracional y deseable; mientras que la verdadera planificación lleva más allá las ideas y establece objetivos junto con pasos previstos a seguir que finalmente ayudan a elaborar estimaciones, tomar decisiones e incluso perfeccionar o cambiar el plan.
De la misma forma que sucede en la vida, en la industria del software y de las IT en general, las estimaciones y las planificaciones son de suma importancia para lograr el éxito de cualquier proyecto. Los planes son una guía que nos indica en donde invertir nuestro tiempo, dinero y esfuerzo. Si estimamos que un proyecto nos tomará un mes en realizar y a cambio nos generará un millón de dólares, entonces quizá decidamos realizar ese proyecto. Sin embargo si el mismo proyecto nos genera ese millón de dólares en 15 años, entonces quizá sea mejor rechazarlo. Los planes nos ayudan a pensar por adelantado y a saber si estamos progresando como esperamos entre otras cosas. Sin planes estamos expuestos a cualquier cantidad de problemas.
En mi experiencia como desarrollador y project manager los equipos tienden a dos extremos: No hacen ningún plan en lo absoluto o se esfuerzan tanto en un plan que se convences a si mismos de que ese plan es correcto siempre. Los que no planean simplemente no pueden contestar a la preguntas más elementales, como ¿y cuando terminan? o ¿estará listo antes del fin de año?. Los que planean demasiado invierten tanto tiempo en su plan que caen en supuestos que no pueden confirmar, su inseguridad crece más y comienzan a creer que incluso planeando más lograrán estimaciones más precisas aunque esto en realidad no ocurra. Si usted se siente identificado con alguno de los escenario anteriores, a su favor puedo decir que planear no es fácil.
Pero que los planes fallan y que planear es complicado no es noticia. Al inicio de un proyecto muchas cosas pueden ser desconocidas, como por ejemplo los detalles específicos de los requerimientos, la naturaleza de la tecnología, detalles de la solución, el plan mismo del proyecto, miembros del equipo, contexto del negocio entre muchas otras cosas. Pero entonces ¿cómo lidiamos con estas adivinanzas? ¿cómo lidiamos con la incertidumbre?.
El Cono
Estas preguntas representan un problema que ya es bastante viejo. En 1981, Barry Boehm dibujó lo que más tarde en 1998 Steve McConnell llamó el Cono de Incertidumbre. El cono muestra que en un proyecto secuencial o en “cascada” que está en etapa de factibilidad normalmente daremos una estimación que está lejos de la realidad, en un rango de entre un 25% y un 400%. Esto es por ejemplo, que un proyecto de 40 semanas tomará entre 10 y 160 semanas. Para cuando se termine de obtener requerimientos nuestra estimación aun estará desfasada entre un -33% y un 50% . Para este punto nuestro proyecto de 40 semanas tomará entre 27 y 60 semanas. Imagine que pasa con esos proyectos que nunca tienen claros sus requerimientos.
¿Cómo lidiar con el Cono?
Buffering (margen de error)
Esto es utilizar un un porcentaje de tiempo y/o recursos para amortiguar el efecto de riesgos que se materializan. Hay que tener cuidado, una reacción común es meter el doble o el triple de tiempo a la estimación de un proyecto, esto NO es buffering, esto es hacer padding (acolchonar) lo cual NO ES una buena práctica. Dar un número demasiado grande, hará que los patrocinadores o clientes se resistan y no aprueban su proyecto. Deles un número demasiado bajo y usted correrá el riesgo de quedarse sin tiempo y dinero. Esto se vuelve doblemente arriesgado cuando usted está utilizando contratos fijos para su propuesta, donde hay aún más presión para mantener los costos bajos.
Es importante que haga uso de datos históricos para comparar su proyecto actual con otros proyecto concluidos y obtenga números razonables y justificables para margen de error o buffering. Incluya procesos de postmortem o lecciones aprendidas al terminar cada proyecto, para así sustentar sus cifras de buffering en le futuro.
Enlarge
Thanks to agilenutshell.com
Estimar en rangos
Algo que me gusta de los enfoques ágiles para gestión de proyectos es ser honesto desde el principio y nunca utilizar cifras cerradas, sino ser transparentes y siempre usar rangos, sobre todo en proyectos que buscan innovar e intentar cosas nuevas donde existe mucha incertidumbre. Esto es por ejemplo:
Mira. No sabemos cuánto tiempo se va llevar esto, sin embargo la siguiente es nuestra mejor apuesta basados en la información que tenemos hasta ahora. Pero si podemos llevar a cabo un par de iteraciones, podemos desarrollar algo, evaluar cuanto nos lleva y entonces tener una mucho mejor ideas de que tan grande es esto.
Además presente la mejor estimación al momento como un rango. Esto puede ayudar a los patrocinadores del proyecto a decidir cual es el monto de riesgo que están dispuestos a aceptar.
Estimación relativa
Han existido diversas investigaciones acerca de como hacer estimaciones de esfuerzo y se ha descubierto que las personas somos buenas estimando el tamaño de algo comparándolo con un referente (Software Development_Effort Estimation) . Por ejemplo, Alguien no puede decirle cuantos metros de alto mide el edificio en el que vive, pero sí puede decirle que es aproximadamente el doble de aquel otro. Usted puede aplicar este principio a los proyectos también
Nota. Las aproximaciones ágiles utilizan interesante conceptos como Story Points e Ideal Days para hacer estimaciones relativas.
Recursos incrementales
Esta práctica se debería aplicar más a menudo o por lo menos más inteligentemente, esto es asignar recursos de manera periódica de tal manera que no se tenga que pedir una gran bolsa de dinero al inicio del proyecto.
No es raro encontrar proyectos donde los patrocinadores proporcionan pagos por fases, sin embargo, aveces se cae en crear fases demasiado grandes o que no son periódicas. El objetivo es financiar regularmente en periodos cortos de tiempo que llamamos iteraciones y con ello hacer revisión del progreso. Al final de cada iteración ese el momento donde tenemos la oportunidad para revaluar si vamos por el camino correcto y reportar números más precisos para la actualización de estimaciones con base en el conocimiento adquirido durante el tiempo transcurrido.
Esto no es una medida infalible, aún puede estimar mal. Pero sin duda es bueno obtener un financiamiento inicial que permite construir algo al equipo y ver cuánto tiempo tarda completando este avance, mientras que simultánemente aprende más acerca de lo que hay que lograr, de tal manera que se aprovecha esta experiencia para reducir la varianza de ese número inicial estimado.
¿Por qué sucede todo esto?
Es indudable que siempre hay presión del sector financiero de las organizaciones para hacer estimaciones para todo un proyecto o para todo un año, aunque estas prácticas al final salgan contraproducentes 😀
Lo mejor que puede hacer es permear este conocimiento en su organización, y recordar y comunicar constantemente que el objetivo de estimar no es adivinar el futuro, sino determinar si los objetivos del proyecto son realistas o incluso posibles.
Algunos enlaces de interés:
El Enfoque Agile De La Planeacion
Parte de la lista de temas para este post y la idea del gráfico con el solecito 🙂 fueron parcialmente basadas en artículos de agilenutshell.com
Estos son alguno libros recomendables para saber más:
Emmanuel Herrera
IT professional with several years of experience in management and systems development with different goals within public and private sectors.
Emmanuel worked through development and management layers, transitioning from developer and team development leader to Project Manager, Project Coordinator, and eventually to Scrum Master, Product Owner, and Agile Coach.
Some certifications include: PSM, PSPO, SSM.
No Comment
Administración / Management / Administración de Proyectos / Project Management / Agile / IT / Scrum / SoftwareSobre esta entrada
Desde hace ya varios años me interesé en desarrollo Ágil de software y he venido utilizando el marco de trabajo para el desarrollo de productos Scrum en varios proyectos, pero hace unos tres años decidí comenzar a formalizar este conocimiento empezando por ser un Scrum Master certificado. Cuando comenté esto con amigos y conocidos me sorprendió que muchos de ellos me comenzaron a preguntar al respecto con muchas dudas y confusiones.
Para intentar arrojar un poco de luz, me meteré en un terreno un tanto acalorado dentro de la comunidad Scrum, compartiendo mi experiencia mientras trataré de contestar varias de las primeras preguntas que vienen a la mente cuando le interesa convertirse en un Scrum Master certificado. Cabe aclarar que nadie me ha pagado por ninguna opinión o por escribir esta entrada (ya quisiera…).
¿Por qué obtener una certificación como Scrum Master?
Yo era un desarrollador que se vio envuelto con Agile y Scrum hace ya algunos años (más por emergencia que por buen juicio) con el fin de lograr concretar proyectos que estaban al borde del colapso. Poco a poco y aún con muchos contratiempos pero proponiendo buenas prácticas a la gerencia y con un rol activo, los equipos de los cuales formé parte logramos salir exitósamente de varios atolladeros, pero la verdad es que nunca sentí la necesidad de obtener ninguna validación formal para esos conocimientos. Eventualmente el destino, el tiempo y varios compañeros desarrolladores empujaron para que tomara un rol más activo del lado de la gestión de proyectos, pero encontré que varios clientes y empleadores me estaban pidiendo habilidades certificadas en Scrum y/o Project Management (¡insensatos!).
Alrededor del 2013 mientras analizaba el mercado laboral comencé a notar que cada vez mas vacantes, para directores de proyecto e incluso desarrolladores, solicitaban conocimientos de Scrum. Considerando que muchas veces en el pasado las gerencias, los directores e incluso project managers me preguntaban con que se comía Scrum, observé que las cosas estaban cambiando de manera notable.
Entonces, el mensaje fue claro. Si quería tener una mejor oportunidad de encontrar trabajos interesantes (y razonablemente pagados) había que certificar mis conocimientos, en este caso convertime en un Scrum Master certificado. Pero eso fue la parte fácil; pasé un buen rato investigando cuales eran mis opciones. En el resto de esta entrada condenso lo que aprendí respecto a las certificaciones Scrum bajo el rol de Scrum Master.
Certificaciones Scrum Master
Lo primero es aclarar que hay varias organizaciones que ofrecen certificaciones como Scrum Master, las que se muestran como las más conocidas son:
- Certified Scrum Master (CSM) de Scrum Alliance
- Professional Scrum Master (PSM) de Scrum.org
- Scrum Master Certified (SMC) de SCRUMstudy
- SAFe Scrum Master de la Scaled Agile Framework
Esta entrada solo aborda estas cuatro certificaciones, pero hay otras que quizá quiera considerar (más las que se sumen):
- PMI_ACP. Project Management Institute Agile Certified Practitioner ofrecida por el Project Management Institute.
- ICAgile Certifications. Certificaciones ofrecidas por el International Consortium for Agile.
*Tenga en cuenta que todas la cifras presentadas son válidas a la fecha de publicación de esta entrada y pueden cambiar sin previo aviso.
Certified Scrum Master (CSM) de Scrum Alliance
Esta es la certificación más conocida de todas y la más longeva. La Scrum Alliance fue fundada por uno de los dos creadores de Scrum, Ken Schwaber junto con otros de los pesos pesados del mundo Agile y Scrum como Esther Derby y Mike Cohn.
Sin embargo, han existido muchas críticas hacia esta certificación debido a que aunque es la certificación más ámpliamente reconocida, es de conocimiento abierto el que todas las certificaciones emitidas antes del 2012 no requerían evaluación alguna, siendo el único requerimiento asistir a un curso oficial de la Scrum Alliance. Como respuesta la Scrum Alliance ha cambiado el proceso de certificación a los siguientes pasos obligatorios:
- Familiarizarse con los conceptos básicos de Scrum.
- Asistir al curso CSM oficial.
- Obtener el certificado que comprueba la finalización del curso CSM y aprobar la evaluación con una puntuación mínima de *69% (aun considerado un porcentaje bajo por algunos practicantes).
Los cursos solo pueden ser enseñados por los Certified Scrum Trainers, pero al no estar homologados, parece ser que la calidad de cada curso está sujeto a las habilidades, experiencia y materiales que cada instructor puede ofrecer de manera independiente.
El costo del curso que incluye la evaluación cambia su costo de región en región, pero oscila entre los $850 USD y los $1300 USD. Para mantener la certificación CSM válida, esta debe ser renovada cada dos años a un costo de *$100 USD, pero la Scrum Alliance también presentó las Scrum Education Units, que se pueden utilizar para renovar sus certificaciones. Del mismo modo, para aquellos que tienen certificaciones del PMI, estos cursos también proporcionan PDUs.
Update 2018: La Scrum Alliance integró nuevas certificaciones a su oferta, incluyendo una más como Scrum Master. Siguiendo una estrategia similar a la Scrum.org se ha añadido otra certficacion llamada Advanced Certified ScrumMaster (A-CSM) la cual tiene como requisitos:
- Asistir a un curso obligatorio para A-CSM.
- Completar con éxito el trabajo previo o posterior al curso que el instructor pueda considerar necesario para completar los objetivos de aprendizaje.
- Validar al menos un año de experiencia laboral específica para el rol de Scrum Master (en los últimos cinco años). Este punto es importante porque deben haber pasado por lo menos 12 meses desde que obtuvo su certificación como CSM antes de poder obtener una como A-CSM.
- Mantener una certificación activa como Scrum Master certificado con Scrum Alliance (CSM).
El costo del curso y el derecho a evaluación para la certificación como A-CSM también puede variar dependiento de la región, pero de acuerdo a lo que investigamos, esto está alrededor de los $2500 USD.
Professional Scrum Master (PSM) de Scrum.org
La Scrum Alliance y Ken Schwaber tuvieron una separación en el 2009 y ello llevó a que este último fundara una nueva organización llamada Scrum.org, donde se ofrece un curso y certificaciones para PSM entre otras. Después de la certificación de la Scrum Alliance estas son las certificaciones Scrum Master más difundidas cobrando cada vez más reconocimiento en la industria. Algo diferente en la Scrum.org es que no es una una si no tres certificaciones las que se pueden obtener como Scrum Master, la PSM I y la PSM II y la PSM III.
Es importante mencionar, que al día de hoy gran parte de la comunidad Scrum señala a estas certificaciones como las más difíciles de obtener, debido a que tanto la PSM I, la PSM II y la PSM III requieren evaluaciones con puntuaciones mínimas del *85% ya que incluyen preguntas de dificultad alta que se deben contestar en un tiempo corto, siendo requerido conseguir la PSM I para obtener la PSM II y estas dos para aspirarar a la PSM III. En diversas fuentes se reporta que hay un relativo alto índice de personas que aun con experiencia en Scrum u otras certificaciones fallan estas evaluaciones.
A pesar de lo intimidante que puede sonar lo anterior, un punto alentador es que ninguna de estas evaluaciones requieren que el postulante asista obligatoriamente a algún curso, por lo que en teoría estas certificaciones pueden ser logradas con el apropiado tiempo de estudio y revisión, además de que las certificaciones no requieren ser renovadas.
El costo de la evaluación PSM I es de $150 USD, para la PSM II es de $250 USD y para la PSM III es de $500 USD, con derecho a un un solo intento.
El curso opcional Professional Scrum Master que ofrece la Scrum.org solo puede ser impartido por los Professional Scrum Trainers, quienes tienen materiales homologados. Los costos de los cursos parecen ir entre $1295 y $1995 USD en Estados Unidos, no he encontrado cursos oficiales en México o Latinoamérica.
Al igual que sucede con la Scrum Alliance, los poseedores de certificaciones del PMI pueden obtener PDUs por el curso PSM.
PSM I Exam Simulator: Con el fin de ayudar a los que deseen esta certificación, en internet80 nos hemos dado a la terea de elaborar un simulador de esta prueba completametne gratuito. El simulador esta en fase de pruebas pero ya esta disponible para todos. Es necesario que conozca lo suficiente del idioma Inglés ya que la evaluación oficial sólo esta disponible en este idioma. Evalúe su conocimiento sobre el marco de trabajo Scrum ahora aqui: PSM I Exam Simulator 1
Scrum Master Certified (SMC) de SCRUMstudy
La certificación SCM basa su evaluación en la guía SBOK la cual tiene una aproximación por procesos (similar al PMBOK del PMI) y a lo que llama principios y aspectos, es decir, todo es bajo el contexto de la interpretación que hacen los autores de la guía SBOK sobre el marco Scrum, lo cual ha ocasionado que esta organización tenga serias diferencias con muchos practicantes y fundadores de Scrum que incluso tomaron parte en la creación del manifiesto Agile y por lo tanto con gran parte de la comunidad Scrum; aunque por otro lado ha logrado cierto grado de aceptación por parte de la industria.
Un punto en contra de esta certificación, que eventualmente puede ser importante para algunos, es que los marcos de escalamiento más populares como SAFe, LeS o Nexus están basados en la Scrum Guide y no reconocen al SBOK. Esto puede ser importante ya que siendo SAFe el marco de escalamiento más influyente hasta ahora, y si usted desea obtener una certificación como SAFe Advanced Scrum Master, la Scaled Agile NO considera relevante la certificacione de la SCRUMStudy.
Update 2017: La organización Scaled Agile Framework quien provee SAFe, ahora ofrece su propia certificación como Scrum Master, llamada SAFe Scrum Master (SSM), no confundir con su certificación SAFe Advanced Scrum Master, esta última ya NO coloca como pre-requisito las certificaciones CSM ni PSM, pero si las coloca como altamente sugeridas para tomar su curso de certificación.
La puntuación mínima en su respectiva evaluación para obtener esta certificación es del *95%, aunque en mi investigación he obtenido testimonios y comentarios mixtos sobre su dificultad, no tienen prerequisitos aunque se debe estudiar fuertemente su SBOK ya que aparentemente el examen ataca más la perspectiva de esta guía que la visión de los creadores de Scrum en la Scrum Guide .
El costo de la evaluación es de *$450 USD con 3 intentos y requiere 40 unidades de re-certificación cada 3 años (estas unidades se obtienen por diferentes actividades).
Según mi investigación, el curso SMC está homologado y solo puede ser proporcionado por los SCRUMstudy Certified Trainers que se basan mayormente en la guía SBOK, los costos están alrededor de $450 USD variando un poco entre regiones y partners. Los testimonios que obtuve fueron bastante mixtos, obtuve buenos comentarios de los materiales ofrecidos, pero una cosa que me señalaron varias veces es que cuando los capacitadores se enfrentan a preguntas y/o escenarios fuera del contexto de la guía SBOK, estos instructores batallan mucho para resolver dudas de manera contundente. SCRUMstudy tiene varios partners en México y Latinoamérica que ofrecen sus cursos.
También se ofrecen PDUs por el curso SMC.
Update 2018: SCRUMstudy ha seguido la misma estrategia que inicio Scrum.org y que su vez siguió Scrum Alliance. Ahora esta organización ofrece una certificación como Scrum Master avanzado a la cual llama Expert Scrum Master Certified (ESMC), y sus requisito son:
- Tener tres años de experiencia en la gestión de proyectos Scrum / Agile.
- Estar certificado con las certificaciones SMC, SAMC y SPOC.
- Debe enviar un ensayo de 500 palabras donde escriba sobre dos proyectos Scrum / Agile.
- La página oficicial señala que también puede asistir a una capacitación presencial ESMC de 2 días, proporcionada desde luego por SCRUMstudy, sin embargo no señala claramente si esto es obligatorio, sustituye o facilita alguno de los requerimiento previos.
El costo del examen para obtener esta certificación al momento de esta publicación de de $800 USD los cuales pueden variar dependiendo de la región. También se tendrán que obtener 60 RCUs cada 3 años para mantener la certificación.
SAFe Scrum Master de Scaled Agile Framework
Agregué esta certificación en 2018 porque surgió a fines de 2016 (meses después de la primera publicación de esta emtrada), no se confunda con la certificación SAFe Advanced Scrum Master. SAFe se enfoca en la implementación de modelos Agile de organizaciones grandes y hoy en día es el marco de escalamiento más popular, pero no es el único (hay otros como Nexus, LeSS, DaD y otros). Pero vamos a dar un paso a la vez, porque he descubierto que esta certificación ha generado cierta confusión.
Anteriormente la Scaled Agile sólo ofrecía la SAFe Advanced Scrum Master la cual está dedicada totalmente al enfoque de este framework de escalamiento Scrum, y dentro de sus prerequisitos se requería tener certificaciones CSM o PSM:
Requitments SAFe 4 0 Advanced Scrum Master 2016 (scaledagile.com) Ahora ofrece su propia certificación “básica” la cual ataca el enfoque Scrum de la Scrum Guide pero también introduce de manera temprana la aproximación de su marco de escalamiento SAFe, esta es la SAFe Scrum Master. Los pre-requisitos para esta certificación son conocer el enfoque Agile, conocer los marcos Scrum, Kanban y XP y a su vez tener experiencia de primera mano en el proceso de desarrollo de software y hardware, y desde luego tomar obligatoriametne el curso para SAFe Scrum Master.
De acuerdo a los testimonios que he obtenido, los contenidos de este curso están homologados y son abundantes, no encontré nada acerca de las calificaciones de los instructores que imparten los cursos, pero aparentemente tanto los instructores como el examen están totalmente orientados a los contenidos proporcionados durante el mismo. El primer intento para su examen de certificación está incluido en los costos del curso (el cual varía entre paises y regiones), cada intento adicional cuesta *$50 USD, el examen es vía web (no tengo claro si se puede accesar a el desde cualquier sitio), para aprobar requiere contestar *33 de 45 respuestas correctas (73% de aciertos).
Algo bueno es que hasta hace solo unos tres años usted tenía que viajar a los Estados Unidos para tomar los cursos y examenes de SAFe, pero ahora estos se ofrecen en varios paises de todos los continentes, lo cual habla de la popularidad de este modelo de escalamiento. Tenga en cuentas que si obtiene la certificación debe renovarla *cada año a un costo de $100 USD (lo cual es plazo corto comparado con el resto de las certificaciones).
Este curso afrece PDUs para los poseedores de certificaciones del PMI y SEUs para aquellos con certificaciones de la Scrum Alliance.
Resumen
- La certificación del Certified Scrum Master (CSM) es más ámpliamente conocida que la Professional Scrum Master (PSM) y la Scrum Master Certified (SMC).
- Los costos de entrenamiento para PSM son (en promedio) más altos que los de CSM y SMC y no están disponibles en todo los países. Los costos de CSM suelen ser más altos que los de SMC.
- Los costos de adquirir y mantener la certificación CSM son mayores a las de SMC y PSM, siendo esta última la más económica ya que no se requiere pagar por mantener la certificación.
- El valor de la certificación CSM es muy cuestionado sobre todo si se emitió antes del 2012 (se otorgaba sin evaluación).
- Los materiales y la calidad de los cursos para CSM pueden variar mucho al no estar homologados.
- Los materiales proporcionados para PSM y SMC en sus capacitaciones están homologados (y según varios testimonios suelen ser buenos).
- La certificación SMC se basa en la prácticas descritas en su SBOK y no necesariamente en lo descrito en la Scrum Guide (texto de los creadores de Scrum).
- El valor de la certificación SMC es cuestionada por muchos miembros y organizaciones de peso en la comunidad Scrum.
- El marco de escalamiento más popular al momento (SAFe) sugiere fuertemente las certificaiones SAFe Scrum Master (SSM), Certified Scrum Master (CSM) y a la Professional Scrum Master (PSM) para obtener varias de sus certificaciones incluyendo la SAFe Avanced Scrum Master (SASM).
- SAFe ofrece la certificación SAFe Scrum Master (SSM) la cual está orientada a Scrum y su escalamiento en organizaciones grandes, pero no es el único modelo de escalamiento y no todas las organizaciones tienen o piensan usar esta aproximación.
- La certificación SAFe Scrum Master (SSM) debe ser renovada cada año por un costo, el cual es un plazo muy corto comparado con el resto de las certificaciones.
*Cifras correctas al tiempo de la publicación de esta entrada. Pueden cambiar sin previo aviso.
Algunos enlaces de interés:
El Origen Y Los Valores De Agile
El Enfoque De La Planificación Agile
Algunos libros que pueden ser de su interés:
Emmanuel Herrera
IT professional with several years of experience in management and systems development with different goals within public and private sectors.
Emmanuel worked through development and management layers, transitioning from developer and team development leader to Project Manager, Project Coordinator, and eventually to Scrum Master, Product Owner, and Agile Coach.
Some certifications include: PSM, PSPO, SSM.
30 Comments
Desarrollo / Development / Diseño Web / Experiencia de Usuario / UX / Gamificación / Gamification / IdeasCaso de éxito con Gamification o Gamificación
Anteriormente, hablé sobre las generalidades de la gamification (ludificación, juguetización, jueguización o el término feo que prefiera), en ello expresé la definición y los objetivos que persigue, si usted NO esta familiarizado con el tema le recomiendo que lea la entrada anterior antes de continuar leyendo.
Como parte de un proyecto en que el participé recientemente, estuve analizando el uso que daban algunas organizaciones y sus sitios web al concepto de gamification, y uno de los sitios que me pareció más interesante y sobresaliente en el uso del concepto, fue LinkedIn. Como muchos ya saben, LinkedIn es una red social orientada a las relaciones profesionales, y como parte de su funcionamiento, esta red social utiliza una serie de elementos que integran la idea de gamification en su diseño. Ahora echaremos un vistazo a algunos de ellos y descubriremos cómo funcionan y cuál es el propósito de la estrategia de Gamification y LinkedIn.
Perfil
Para hacer valiosa esta red de profesionales, tanto para LinkedIn como para sus usuarios, la información de cada miembro es requerida. Entre más información sea proporcionada por el usuario mayor beneficio obtiene la red en general. Cuando un nuevo usuario se registra, tiende a proporcionar solo la información mínima, normalmente dudando acerca de cuanta información proporcionar, esto aparentemente es debido sobre todo a la desconfianza de compartir datos personales, la falta de tiempo o la pereza por parte de los usuarios de la red.
LinkedIn, echando mano de elementos de gamification y UX (User Experience), implementó una barra de progreso que apelaba al “sentido de terminar algo incompleto” para gentilmente sugerir y motivar a lograr un mejor porcentaje y así obtener más información del usuario, utilizando una estrategia en donde el aumento de porcentaje era fácil de obtener al principio, pero gradualmente se requería de mayor esfuerzo para llegar al 100% lo cual añadía un toque de diversión y reto que invitaba a proporcionar más datos.
Eventualmente y de manera muy inteligente, LinkedIn se dió cuenta de que una de las desventajas de usar una simple barra de progreso, es que otros datos que surgen como consecuencia de los cambios en la vida laboral de los usuarios, como son nuevos puestos, nuevos cargos, nuevos certificados o avances en el nivel académico, no cobraban relevancia.
Con lo anterior en mente se cambió el esquema de barra de porcentaje por una esfera que se llena cual copa con agua, la cual se conoce como eficiencia del perfil (profile strength). Dependiendo de que tanto se llena el círculo se asignan nombres a los “niveles de eficiencia”, logrando con ello ponderar TODOS los datos que se proporcionan y así mismo hacer que los miembros de LinkedIn se sientan más dispuestos a proporcionar y actualizar la información que se les solicita con un método poco invasivo y además sin dar pie a percatarse de que los usuarios están siendo “gameficados“.
Intentando mejorar aún más su interfaz, LinkedIn implementó una especie de mezcla entre su barra de progreso anterior y los niveles de eficiencia de la esfera, y actualmente está utilizando una nueva barra de progreso.
Pero incluso con los anteriores elementos de gamification, con los cuales el diseño estimula a los usuarios para que proporcionen información y así aumentar la fortaleza de sus perfiles, lo que se obtiene es una autodescripción de las cualidades del usuario, lo cual debería de poder ser verificable por otros medios. Para solucionar esto, se idearon las aptitudes y validaciones (skills and expertise), las cuales, aprovechando las ventajas inherentes de una red social, permiten a otros usuarios validar las habilidades y la experiencia, lo cual crea una visión más precisa del miembro en cuestión.
Vistas
Ningún perfil tiene mucho sentido si no está siendo visto. La red proporciona estadísticas a sus miembros acerca de cuantas veces ha sido visto su perfil en los últimos días.
También muestra quienes han sido las últimas personas en ver el perfil. Esto no solo estimula el motivador de ser el “centro de atención”, si no que además alienta a hacer clic en el perfil de esas personas para potencialmente conectar con ellas.
Actualizaciones
Los usuarios de LinkedIn no solo comparten información personal y profesional, la mecánica de la red los alienta a compartir artículos, eventos, oportunidades de trabajo y otros tipos de información relacionada con la vida laboral de sus miembros; ofreciendo con ello, el número de vistas, sus respectivos likes y la posibilidad de seguir a los usuarios o grupos de interés, lo cual son técnicas de gamification por demás experimentadas por los usuarios habituales de redes sociales.
Grupos
Pertenecer a un grupo, aportar publicaciones y respuestas puede incrementar la potencial influencia del usuario como experto dentro de una comunidad. El número de miembros es un indicador para el “dueño” del grupo acerca de que tan exitosas son las acciones derivadas de organizar a un grupo de personas alrededor de cierto tema.
Otros
Durante mi investigación de LinkedIn y sus estrategias de gamification, encontré menciones de algunas que no he podido corroborar de primera mano, pero he visto mencionadas en diferentes lugares. Aparentemente han habido envíos de correos y mensajes con felicitaciones a algunos miembros por una variedad de “logros”, como son el ser uno de los perfiles más vistos según determinados criterios de tiempo y vistas o por ser miembro destacado con cierto número de artículos compartidos y vistas obtenidas a los mismos, así como algunos otros motivadores por el estilo que pretenden ser divertidos.
¿Conoce algunas otras técnicas de gamification utilizadas en otros sitios?, ¿utiliza gamification o piensa hacerlo?, ¿cree que vale la pena el uso de gamification? compártalo con nosotros.
Otros enlaces que pueden ser de su interés:
Emmanuel Herrera
IT professional with several years of experience in management and systems development with different goals within public and private sectors.
Emmanuel worked through development and management layers, transitioning from developer and team development leader to Project Manager, Project Coordinator, and eventually to Scrum Master, Product Owner, and Agile Coach.
Some certifications include: PSM, PSPO, SSM.
No Comment
Desarrollo / Development / Diseño Web / Experiencia de Usuario / UX / Gamificación / Gamification / Ideas / Programación / ProgrammingJugando mientras trabaja, estudia, ejercita o usa la web
Aquellos que hemos sido o somos gamers (personas que gusta de los juegos y/o video juegos) sabemos que la idea o concepto de gamificaction (en sus aún más feas traducciones al español: gamificación, ludificación, juguetización o jueguización) ha andado rondando por siempre (unas 3 décadas). Recordemos frases viejísimas como: !aprende jugando!, ¡adelgace mientras se divierte!; si alguien es de México y de mis años recordará aquellos clásicos comerciales con la frase: ¡Con juguetes Mi Alegría…aprendemos…y jugamos! (sí, el tono de canción en su mente es inevitable si sabe de que hablo). Ahora, si bien el concepto es viejo, el término se acuñó gracias a un programador llamado Nick Pelling en 2002, pero en la realidad el concepto ha comenzado a atraer la atención tan solo en años recientes.
Últimamente me he encontrado con mucha gente que utiliza términos deslumbrantes como mecánica de juego, dinámica de juego o pretende establecer como algo complejo y laborioso la implementación del concepto, confundiendo la idea básica de gamification o gamificación con complejas campañas tecnológicas de marketing y big data. Lo anterior puede ser verdad y se pueden crear sofisticadas implementaciones de gamification, pero basado en mi experiencia involucrado en equipos desarrollo multimedia desde 1998, puedo decir que mucho sobre aplicar gamification es solo sentido común.
Sin ser o pretender ser un experto en gamification, a continuación le comparto algunas ideas, términos y aproximaciones que he aprendido con el tiempo:
¿Qué es gamification?
Hay montones de sitios donde puede obtener buenas definiciones sobre lo que es gamification (ludificación, juguetización o jueguización), pero para ahorrar el viaje a Wikipedia le traduzco lo que dice la misma en su sitio en inglés:
Gamification es la aplicación de elementos del diseño y principios para juegos en un contexto que no es de juego. Gamification comúnmente emplea los elementos que se utilizan en el diseño de juegos en los denominados non-game contexts en un intento de mejorar la participación de los usuarios, productividad de organización, aprendizaje, contratación y evaluación de empleados, facilidad de uso y la utilidad de sistemas, ejercicio físico, violaciónes de tráfico, apatía de votantes, entre otros. Una revisión de investigación sobre gamification muestra que la mayoría de los estudios sobre gamification encuentran efectos positivos en su implementación. Sin embargo, existen diferencias individuales y contextuales.
¿Entendió eso? Básicamente significa, hacer una tarea más interesante adoptando la lógica de un juego. La manera más simple sería otorgando alguna especie de premio por hacer alguna tarea. El premio puede ser tan obvio como un trofeo o tan vago y subjetivo como simplemente buscar ofrecer diversión mientras se hace una tarea definida. Pero desde luego hay mucho más que se puede hacer, especialmente cuando el comportamiento humano es considerado.
Pero para cumplir con el cliché, aquí mi definición personal:
Gamification es aplicar la metáfora del juego a tareas comunes u obligatorias para influenciar el comportamiento, dar mayor motivación e incrementar el involucramiento, la preferencia o la lealtad.
¿Los videojuegos sirven de algo?
Durante algunos años fui jugador de World of Warcraft, un video juego muy popular con millones de usuarios, el cual me parece que es un gran ejemplo de cómo estos juegos se pueden relacionar con el mundo real. Dentro de World of Warcraft uno de los objetivos es hacer dinero. Este dinero se puede obtener de varias maneras, pero la mayor parte es haciendo quests (misiones). Como resultado de resolver las misiones se obtiene dinero, el cual el jugador utiliza para obtener diferentes cosas como comprar ropa, armas, materiales, mejoras, información para nuevas misiones, etc. (¿le suena esto familiar?), esto es lo básico de cualquier negocio y parte importante de la vida. Día con día los jugadores de World of Warcraft se la pasan fabricando bienes, ofreciendo servicios y cumpliendo misiones. En el mundo real hacemos lo mismo, ganamos dinero por obtener determinado logro; gastamos ese dinero en comprar nuevas cosas o lo invertimos en algo que nos permita ganar más dinero o hacer algo de manera más eficiente o cómoda.
Enlarge
Blizzard Entertainment
Una pregunta válida sería ¿por qué estos jugadores están tan dispuestos a pasar tanto tiempo haciendo lo que bien podrían hacer en la vida real? La respuesta es fácil: porque es divertido.
Adoptando la idea
Es importante aclarar en este punto que no todo es acerca de video juegos, no veremos en futuro inmediato a alguien deseoso de jugar el último juego de Microsoft Project o de Word (aunque nunca se sabe 😉 ). Lo que estamos intentando hacer es tomar ideas de los juegos e insertarlos en alguna tarea de rutina, para que dicha tarea no tenga que ser aburrida hasta la muerte.
Con todo lo anterior en mente tengo que ser honesto, a pesar de la relativamente reciente popularidad de la idea de gamification, no todo el mundo sabe lo que es, no todos están interesados, pareciera que para llegar a escuchar y a comprender el término se requiere de algo de curiosidad, ganas de saber lo que está en boga o simplemente tener un poco de geekness. Todo esto hace que vender la idea en una organización no sea tan fácil como pudiera parecer (por lo menos no acá en el tercer mundo). Recientemente participé en un proyecto donde le solicitaron al equipo del cual formaba parte, proponer ideas “innovadoras” (otro término sobrevendido) para mejorar la propuesta tecnológica de una organización, como parte de esto eventualmente propuse la idea de incorporar alguna estrategia inicial y modesta de gamification dando algunos ejemplos con detalle general pero concreto, no como algo precisamente “innovador” si no como algo que únicamente pretendía poner “al día” la propuesta tecnológica implementada al momento. Sorprendentemente aunque la organización con la que trabajaba desarrolla tecnología, el 90% de los involucrados no sabía de que diablos hablaba (shame on you Infotec); tuve que explicar la idea a analistas, subdirectores, directores, consultores y desarrolladores sin demasiado éxito (nadie es profeta en su propia tierra, aunque me gusta pensar que di luz a algún alma perdida).
Tengo que agregar que la palabra gamification se escucha rara en inglés y las traducciones al español suenan aun peor, imagine decir en la reuniones todo el tiempo ludificación, juguetización o jueguización, estas palabras no ayudan mucho a la venta del concepto, como fruto de la experiencia llegué a la conclusión de que para adoptar la idea más fácilmente, hay que usar palabras como Productividad, Cambios de Comportamiento, Motivación y Preferencia (o engagement si prefiere el termino de marketing).
Puntos, Medallas, Trofeos, Tablas de Posición
Como responsable de un proyecto hace tiempo, requería hacer un aseguramiento de calidad en una serie de contenidos para cursos, con mucha información por revisar y muy poco tiempo, le dije a los miembros de mi equipo, que las 2 personas que encontraran más errores se ganaban un café grande diario durante toda la semana siguiente. Repentinamente tenía un juego en marcha.
Afortunadamente, no siempre necesitamos recurrir a premios físicos reales en todos los casos. El manejo de información que los usuarios le proporcionan a su organización, sitio web o aplicación móvil puede ser utilizado para otorgar premios en diferente forma, las más comunes son:
- Puntos
- Medallas
- Trofeos
- Niveles
- Tablas de Posición
- Retos
- Logros
En un sitio o sistema web, por ejemplo, el concepto es utilizado ampliamente para que sus usuarios hagan más dentro del sitio o estén más tiempo expuestos a determinada información. Algún sitio donde se hacen trámites, puede hacer del llenado de sus formularios algo más ameno dando alguna especie de puntaje o jerarquía relacionada con un progreso por cada paso completado. Un sitio de ventas puede dar trofeos o medallas por las reseñas que un usuario coloca acerca de algún producto.
Estos ejemplos son ciertamente algo muy simple ya que solo buscan motivar más a los usuarios a llevar a cabo una tarea, y desde luego que dejan mucho más para explotar el concepto, pero son un buen punto de inicio para explorar los beneficios de gamification.
No todo es dinero
Un argumento extraño y limitado que me topé al proponer gamification, es que bajo la suposición de alguien, gamification se trataba de dar incentivos económicos en forma de efectivo, cupones o descuentos, lo cual no necesariamente es cierto, y caer en ese supuesto usualmente crea preocupación y hasta rechazo por parte de los patrocinadores de cualquier proyecto o cadena de producción (¿qué pasa con tus directores Infotec? :D). El dinero es un buen motivador para un usuario (siempre lo es), pero hay una palabra en inglés que encontrará mucho en los blogs y libros sobre gamification y que ya mencioné, esta es engagement, esto quiere decir que el dinero siempre lo motivará a hacer alguna tarea pero no necesariamente hará que se “enganche” o que disfrute con la misma.
¿Qué más?
Si usted comienza a profundizar más en los temas de gamification, eventualmente se dará cuenta que hay mucho más que solo depender de incentivos y ciertamente mucho más que depender del dinero. Usted estará utilizando el comportamiento humano y el famoso cerebro reptiliano, es decir, usará a su favor algo que está dentro de la naturaleza humana, jugar. Usando gamification usted estará apelando a sentimientos de orgullo y necesidad de reconocimiento, con lo cual podría lograr incluso más que ofreciendo dinero.
Para concluir
Le dejo videos de algunos proyectos educativos donde apliqué gamification (algo viejos pero vigentes para entender el concepto) y algunas bibliografías que encontré útiles e interesantes:
Libros:
- Why we do what we do: understanding self-motivation
- For the Win: How Game Thinking Can Revolutionize Your Business
- A Theory of Fun for Game Design
Videos:
Interactivo Prevención de Riesgos
Interactivo Desarrollo Económico de México
Juego de cartas para ayudar a aprender inglés HTML5
Enlaces relacionados:
Mint (Empresa con aplicaciones fintech que utiliza gamification para las finanzas personales)
Emmanuel Herrera
IT professional with several years of experience in management and systems development with different goals within public and private sectors.
Emmanuel worked through development and management layers, transitioning from developer and team development leader to Project Manager, Project Coordinator, and eventually to Scrum Master, Product Owner, and Agile Coach.
Some certifications include: PSM, PSPO, SSM.
3 Comments
Historia
Hace ya 3 años inicié una serie de entradas en este blog, en donde comparaba las tecnologías Flash y la entonces emergente HTML5, en aquel entonces atestigüé acalorados debates en diferentes foros y medios sobre las bondades y retos que estas dos tecnologías tenían enfrente, sin embargo hoy en día parece que tenemos claro para donde van las cosas, y aunque Flash se niega a morir y aun se puede encontrar a uno que otro nostálgico pero aguerrido defensor de esta tecnología (yo mismo fui entusiasta de Flash durante sus años de gloria), en este primer cuarto del 2015 se han colocado algunos de los clavos más firmes en el ataúd de Flash. Las malas noticias para Flash provenientes en esta ocasión de YouTube, Mozilla y de las mismas fallas de rendimiento y seguridad del plug-in Flash Player.
Si es que alguien no lo sabe, Flash se propago ámpliamente hace más de década y media permitiendo a los desarrolladores web y multimedia crear gráficos, animación, video y otras interacciones con el usuario que eran difíciles o imposibles para el navegador. Para que las creaciones en Flash pudieran ser visualizadas en los navegadores, tanto entones como ahora, se requiere de un plug-in llamado Flash Player, y es aquí donde comienzan los problemas para Flash (¿barbas a remojar para el plug-in de Java?).
Con el poder de los navegadores incrementándose, la evolución de las capacidades de HTML5, la búsqueda del ahorro de recursos y las nuevas propuestas que se suman en el camino, tenemos que los plug-in van de salida. El primer gran golpe para Flash fue el que dio el todavía vivo Steve Jobs desterrando a Flash del ecosistema del iPhone por ahí del 2010. Pero ahora tenemos tres nuevos golpes, aunque uno de ellos es engañoso y paradójicamente quizá le ofrezca un último asidero a Flash, veamos:
Problemas de seguridad del Flash Player.
Comenzando el año 2015 el Flash Player tuvo muchos problemas de seguridad, y la verdad sea dicha es el plug-in favorito de los black hat hackers lo que ha llevado incluso a sugerir a algunos expertos el que no se instale el plug-in a menos que sea totalmente necesario, el problema es que en poco mas de dos semanas Adobe tuvo que hacer tres parches de emergencia para peligrosos bugs, lo cual ha sido en realidad un problema constante durante la vida de Flash. Esto llevó a Adobe a tener que trabajar rápidamente con sus socios distribuidores iniciando el año, dígase Google y Microsoft, para corregir el problema tanto en Chrome como en Internet Explorer de primera mano, pero al final los usuarios tenia que hacer varias actualizaciones del plug-in dependiendo de los navegadores que utilizasen; el problema fue tan grave que incluso Mozilla Firefox desactivo definitivamente el plug-in hasta que hubiera una solución final.
YouTube abandona el uso de Flash por default en sus videos.
YouTube, el mayor proveedor de videos en Flash de la historia, anunció que dejaría de servir videos utilizando el plug-in para todos los usuarios que consumen su contenido en un navegador moderno, haciendo por default el uso de HTML5 y su tag . Richard Leider en el blog de la gerencia de ingeniería de YouTube hace una interesante referencia a las razones por las cuales no habían podido hacer de HTML5 su plataforma favorita de entrega de video hasta el momento y de como las cosas han ido evolucionando para HTML5 hasta el punto de poder cerrar brechas técnicas. Esto sin duda marcará la tendencia para otros sitios de video.
Mozilla y su proyecto Shumway
En febrero Mozilla y sus programadores activaron Shumway para la reproducción de videos Flash en la plataforma Amazon SIN el uso del Flash Player. El proyecto Shumway ha estado en desarrollo desde hace algunos años y lo que intenta, en pocas palabras, es poder reproducir contenido SWF y FLV sin utilizar el Flash Player, si esto se lograra de forma completamente eficaz y eficiente significaría (desde mi punto de vista) la muerte absoluta e inmediata del Flash Player, sin embargo, el proyecto Shumway no está terminado y aun requiere mucho trabajo, pero lo que ha logrado es bastante prometedor.
Aquí es donde entra la paradoja y la esperanza para Flash, si bien algo como Shumway al final representaría la muerte inmediata del Flash Player, también significaría darle nueva vida al Flash Professional, la herramienta de creación de Adobe y probablemente a algunas otras que también crean contenido SWF y FLV. La herramienta de diseño y animación Flash Professional per se, sigue siendo bastante buena, trata de ir adaptándose a los nuevos estándares web mientras se mantiene relativamente más accesible que otras herramientas de animación y hoy por hoy aun no existe una herramienta tan buena como el Flash Professional dirigida a el HTML5 puro, el mismo Adobe lo intenta con su Adobe Edge Animate desde hace tiempo pero creo que aun no lo logran.
Enlaces a las posts previos:
Emmanuel Herrera
IT professional with several years of experience in management and systems development with different goals within public and private sectors.
Emmanuel worked through development and management layers, transitioning from developer and team development leader to Project Manager, Project Coordinator, and eventually to Scrum Master, Product Owner, and Agile Coach.
Some certifications include: PSM, PSPO, SSM.
2 Comments
En las entradas anteriores sobre la experiencias de usario (Parte 1 y Parte 2) hablé de lo interesante y ventajoso que puede ser el diseño de experiencia de usuario, pero aun siendo así, la verdad es que esta disciplina tampoco puede hacerlo todo ni es la medicina para todas los casos.
El diseño UX no viene en unitalla para todos.
El diseño de experiencia de usuario no funcionará en todos los casos para toda la gente debido a nuestra condición humana en la que todos somos diferentes. Lo que funciona para una persona probablemente funciona de manera totalmente opuesta para otra, de modo que lo que el diseño UX puede hacer es únicamente procurar alguna experiencia específica para promover cierto comportamiento, pero NO puede fabricar, imponer o predecir con total exactitud una experiencia en si misma.
El diseño de experiencia de usuario NO puede replicar de manera literal la experiencia de un sitio web o aplicación en otro sitio web o aplicación, las experiencias de un usuario siempre serán diferentes entre servicios y productos, es por eso que cuando se diseña algo, ese diseño es adaptado para buscar ciertos objetivos, valores o procesos de producción pero siempre en función de una iniciativa en particular.
No existen métricas para evaluar al UX
Desafortunadamente no hay ningún indicador que pueda señalar directamente el rendimiento o la calidad del diseño de la experiencia de usuario, esto solo lo podremos saber con la suma de múltiples factores como las clásicas estadísticas de vistas a páginas, porcentajes comparativos, tasas de conversiones de usuario, reportes ventas, colocación y otras evidencias enecdóticas, pero no existe ningún código o algoritmo que evalúe la experiencia de usuario, por lo que es importante que los diseñadores UX y los responsables de proyectos y cadenas de producción trabajen juntos con todos los indicadores al alcance bien documentados para comparar el antes y el después y así justificar la inversión en UX.UX no es usabilidad ni diseño gráfico.
Todavía encuentro blogs, videos, comentarios, etc., donde se habla de usabilidad como sinónimo de experiencia de usuario, y si bien es cierto que la usabilidad juega un papel importante, NO son lo mismo. La usabilidad se refiere a la eficiencia con la que una interface se relaciona con las acciones de un usuario, mientras que UX se refiere a lo que siente y piensa una usuario con respecto al uso de un sistema completo y como se comporta en consecuencia.Algo parecido sucede a veces con el diseño gráfico, el cual desde luego tiene un rol preponderante, pero NO es UX. Es verdad que es importante que un sitio web o aplicación resulten estéticos, con uso inteligentes de contrastes, colores y comunicación visual, pero solo por nombrar un caso ¿qué pasa si para comenzar nuestro usuario es alguien que no puede ver?, ésta es solo una razón por la que otros factores también tienen un rol importante, como lo son por ejemplo la accesibilidad, la ciencia humana, la arquitectura de información, el análisis de contexto, el análisis y ejecución de pruebas, la mercadotecnia, la psicología, la correcta gestión del proyecto entre otros.Críticas al UX como profesión.
No todo el mundo ve el valor de un diseñador de UX, la mayoría de los argumentos que he escuchado o leído giran en torno ha los costos adicionales involucrados, la redundancia con actividades de otras áreas y/o el miedo/pereza al cambio.Otra observación que algunos pueden tomar como crítica, y admito es un argumento interesante, es que los diseñadores UX no se pueden “crear de cero” como una carrera o disciplina aislada, si no que es más bien el resultado de una “especialización” de personas que han sido diseñadores web o desarrolladores quienes eventualmente deciden profundizar en los temas relacionados al UX, haciendo así indispensable un “background” en programación, desarrollo multimedia, etc. y sumarlo a conocimientos posteriores para efectuar un buen diseño UX. Usted ¿qué piensa de esta postura?
No se puede negar lo innegable.
Ya había hecho un guiño a esta situación, pero la reitero, una organización o proyecto con presupuesto realmente pequeño y personal limitado no puede invertir en un especialista UX por lo tanto el desarrollador solitario, o la compañía compuesta por dos amigos tendrían que integrar algunos (los que puedan) de los conceptos de UX como parte de sus actvidades habituales, lo cual es visto como desventaja por unos y ventaja por otros.¿Más?
Por el momento es todo lo que mi experiencia y memoria dan para mencionar, pero si a usted se le ocurre algo más no dude en comentarlo 😉Algunos enlaces de interés:
Diseño de la Experiencia de Usuario (Parte 1)
Diseño de la Experiencia de Usuario (Parte 2)
El Enfoque de la Planeación Agile
Estos son alguno libros recomendables para saber más:
Emmanuel Herrera
IT professional with several years of experience in management and systems development with different goals within public and private sectors.
Emmanuel worked through development and management layers, transitioning from developer and team development leader to Project Manager, Project Coordinator, and eventually to Scrum Master, Product Owner, and Agile Coach.
Some certifications include: PSM, PSPO, SSM.
2 Comments
Administración / Management / Desarrollo / Development / Diseño Web / Experiencia de Usuario / UX / Ideas / IT / Programación / Programming / Software¿Por qué no se utiliza el UX en su organización?
A lo largo de mi experiencia profesional trabajando en el mundo del desarrollo para Internet, me he topado con una enorme cantidad de discusiones y desacuerdos entre desarrolladores, diseñadores gráficos, project managers, clientes, jefes y un laaaargo etcetera de personas involucradas en el desarrollo de algún proyecto, de manera que muchos de ellos han sido renuentes a incluir procesos o personas explícitamente dedicadas el diseño de experiencia de usuario dentro de su organigrama de desarrollo o de personal, en otros casos, simplemente ignoran la existencia de tal disciplina (…así de triste).
El problema principal con las personas renuentes o que no conocen realmente acerca de la experiencia de usuario como disciplina, es que una vez que se les plantea la inclusión del proceso de UX, por lo general lo ven como un proceso que alarga los ya apretados tiempos de entrega (lo cual es una afirmación coja), o bien, hay gente que argumenta que el UX se “encima” con pasos de metodologías ya existententes (suspiro…esos amados procesos coporativos escritos en piedra). Con todo esto ¿porqué implementar UX en nuestros proyectos de desarrollo?.
¿Qué o quienes se benefician del diseño UX?
Si decimos en voz alta que cualquier sistema se beneficiaría de una sólida implementación de pruebas dirigidas a la experiencia de usuario, desde luego en pro de la satisfacción de este, seguramente encontraremos muy pocos o ningún argumento en contra y todos parecerán estar a favor de tan certera afirmación, pero en la práctica es ooootro cantar.
En la realidad siempre hay recursos y tiempo limitados y muchas organizaciones tienden a concentrar sus esfuerzos en el proceso de elaboración o ejecución per se, dejando descuidadas las estrategias de planeación, adaptación y mejora. Pero incluso en esta situación el diseño orientado a al experiencia de usuario puede ser beneficioso y vale la pena hacer el máximo esfuerzo por incluirlo en las tareas habituales de planeación, ejecución, monitoreo, pruebas y calidad. En mi experiencia (y no sin batallar un poco) he podido identificar algunos casos que se pueden ver particularmente beneficiados del diseño UX:
Sistemas complejos.
Entré más complejo un sistema más relevantes se vuelven la planeación adaptativa, el aprendizaje, la organización, la arquitectura progresiva y validación de condiciones de satisfacción para la correcta creación y uso de nuestro sistema. Mientras que invertir en un equipo interdiciplinario de personas que se dedicarán al UX podría ser excesivo para la elaboración de una pequeña página de presencia que solo contendrá algunos datos de contacto, en otros casos tenemos que el desarrollo de sitios, soluciones empresariales, aplicaciones web o móviles innovadoras o mucho más elaboradas, en donde se requieren de múltiples opciones, vistas y herramientas, y que además pretenden llegar a cada vez más usuarios, son las situaciones donde sin duda se verán ámpliamente los beneficios del UX.
Aquellos sitios y aplicaciones que simplemente muestran información extensa con pobre organización, que no ofrecen métodos de búsqueda efectivos, que priorizan torpemente la información, que antepone agendas propias antes de las necesidades reales del negocio y/o el usuario, que someten a sus usuarios a interminables formularios esperando que estos proporcionen información sin chistar y en una sola “sentada”, para finalmente brindar un servicio mediocre o malo, estarán proporcionando negligencia en cuanto a la experiencia de usuario y al final verán sumamente afectados el éxito, ganancias y/o longevidad de su producto o servicio. Son todos estos casos donde la UX cobra gran importancia para ayudar a prevenir o minimizar estas situaciones y lograr con ello que estos proyectos finalmente se perciban como eficientes, valiosos, exitosos y agradables tanto de ver como de utilizar.
Proyectos con presupuestos moderados y start-ups.
Sin duda las empresas pequeñas o las que apenas comienzan por lo general no cuentan con los recursos para contratar empleados dedicados 100% al la experiencia de usuario.
Otro hecho que podemos ver constantemente es que las empresas pequeñas y medianas en el afán de mantener costos bajos y priorizar entregables para obtener recursos, se concentran más en el proceso de producción o ejecución que en el de planificación, investigación y análisis para mejorar y adaptarse a nuevas condiciones, es decir, estas empresas giran alrededor del lanzamiento de un producto final.
Sin embargo, incluso estas organizaciones que pueden ser iniciativas pequeñas, pero que ya han logrado la venta de algún producto o servicio, comúnmente cuentan con una o más individualidades talentosas que son capaces de tomar diferentes roles en la organización según se necesite. Piense en ese programador, diseñador o persona entusiasta que ya está dentro de su organización y que por alguna razón parece tener cierta afinidad para crear cosas agradables y funcionales que son del gusto de clientes o usuarios. Ese tipo de talento es el que puede comenzar a entrenarse en los principios y procesos de la UX, y eventualmente comenzar a integrarlo al proceso común de desarrollo en la organización de manera incluso paulatina.
Cabe mencionar que las filosfías Lean y Agile puden potencializar mucho el correcto uso de UX gracias a sus enfoques adaptativos, iterativos, enfáticos en el aprendizaje y enfocados a la entrega de valor real más que un estricto apego a planes y procesos.
Empresas que desean reducir tiempos de entrega y costos.
Así como lo lee, a pesar de la suspicacia que despierta en algunos la implementación del diseño UX (como mencioanaba al principio de esta entrada), la integración de este puede acortar eventualmente los tiempos de desarrollo e incluso los costos del mismo.
Es verdad que con UX se deben agregar etapas adicionales a proceso de desarrollo que requieren de tiempo asignado, sin embargo en la teoría un diseñador UX realiza muchas de sus tareas paralelamente al trabajo que hacen los desarrolladores y diseñadores web, e incluso observará que mucho del trabajo que hacían estos ahora quedará en manos del mismo diseñador UX, también puede ocurrir que el trabajo que hacen un project manager, un scrum master, un product owner, un ingeniero de requerimientos, un arquitecto de información un analista de sistemas entre otros, puede verse realmente beneficiado y facilitado por el responsable del diseño UX, así potencialmente los costos causados por el bucle de revisiones y validaciones se verán reducidos y los otros miembros del equipo podrán pasar más tiempo productivo en su respectiva especialidad. Llendo incluso más lejos, la correcta y habitual implementación del diseño UX, al generar clientes más satisfechos eventualmente logrará traducirse en mayores beneficios para usted y su organización.
Enlaces de interés:
Diseño de la Experiencia de Usuario (Parte 1).
Diseño de la Experiencia de Usuario (Parte 3)
El Enfoque de la Planeación Agile
Estos son alguno libros recomendables para saber más:
Emmanuel Herrera
IT professional with several years of experience in management and systems development with different goals within public and private sectors.
Emmanuel worked through development and management layers, transitioning from developer and team development leader to Project Manager, Project Coordinator, and eventually to Scrum Master, Product Owner, and Agile Coach.
Some certifications include: PSM, PSPO, SSM.
3 Comments
Desarrollo / Development / Diseño Web / Experiencia de Usuario / UX / Ideas / Programación / Programming / SoftwareLa Experienecia de Usuario siempre ha estado ahí
La primera vez que programé fue por ahí en la década de los 90s, y entonces desarrollé muchas cosas, de las cuales algunas funcionaban y otras (la mayoría) no o por lo menos no como esperaba, así la mayor parte de lo que desarrollaba en esos años eran solo experimentos para mi deleite personal o para cumplir con alguna tarea escolar. Eventualmente algunos de estos experimentos personales se volvieron más o menos populares entre algunos de mis compañeros de clase, o para decirlo en palabras más capitalistas y emprendedoras, comencé a vender tareas (de las clases de programación y relacionadas) por encargo a algunos de mis compañeros, sin embargo, en las primeras ocasiones en que vendí tareas observé que mis “clientes” no entendían del todo (o en lo absoluto) como utilizar los pequeños programas que les entregaba y me resultaba bastante molesto tener que explicar cómo diablos se usaban, y considerando que tenía que parecer que ellos lo habían hecho, me resultaba un problema. Durante un buen tiempo me la pasé pensando en como podía lograr hacer que mis compañeros entendieran más rápido mis programas.
En esos años su servidor era un ávido lector de comics, y entonces comencé a meditar en lo hábiles que eran los dibujantes y escritores de estas historietas para dar a entender cosas complejas con tan solo algunos trazos, algunas viñetas bien colocadas o algunos “globitos” con texto, !y entonces vino la epifanía!, rápidamente comencé a observar con más atención los libros ilustrados e historietas dirigidos a niños, adolescentes y adultos, después de un rato de planificación llegué a que debía cumplir con lo siguiente:
- Distinguir mis usuarios “tontos” de los “menos tontos” para determinar el grado de esmero para los siguientes pasos (no fuí para nada políticamente correcto).
- Asegurarme que mis compañeros explicaran BIEN que era lo que querían para comprenderlo sin ninguna duda (cosa nada fácil).
- Ser los más explícito pero breve que pudiera en todos los textos que presentaba (opciones, menús avisos, etc.).
- Así como hacían los comics, los juegos y esas raras computadoras de manzana de color, tratar de auxiliarme de colores para contrastar unos elementos de otros y si era posible usar imágenes que respaldaran a los textos (este punto era mi favorito).
Palabras más palabras menos, esos fueron los pasos que diseñé para tratar que mis “encargos” salieran a la primera, mis compañeros-clientes molestaran menos y obtener un poco de dinero o alimento (tortas, churros, frutsis, .etc) en el proceso. Quisiera decir que todo fue felicidad y viento en popa, pero escribir mis pasos fue más fácil que seguirlos cabalmente, pero sí puedo decir que aunque la lata de mis clientes no desapareció, sí se redujo drásticamente. Muchos años después caí en cuenta de lo que había hecho de manera ingenua, empírica, simplona y corta de hecho tenía un nombre: Diseño de Experiencia de Usuario.
¿Pero qué es la Experiencia de Usuario?
Si usted busca en la web encontrará muchas definiciones, pero para aportar algo con la propia, la “Experiencia de Usuario“, conocida en inglés como “User Experience” y abreviada como “UX” es la manera en que una persona (un usuario) se siente acerca de su interacción con un sistema, tal sistema puede ser un programa de computadora tradicional, un sitio web, una aplicación web o una aplicación móvil entre otros, todo desde luego en un contexto de desarrollo actual.
La anécdota personal con la que inicié este post fue una feliz coincidencia basada en algo de sentido común, pero en realidad hay gente verdaderamente dedicada al estudio en profundidad del diseño de sistemas pensado en el usuario como el elemento fundamental de cualquier sistema tecnológico, la persona que probablemente ha aportado más en este campo es el Dr. Donald Arthur Norman, un investigador de ciencia cognitiva, diseño y usabilidad.
El Dr. Norman fue el primero en hablar de manera realmente científica y formal de la importancia del diseño de sistemas centrado en el usuario (user-centered design), lo cual es, en términos generales, la idea de que cualquier diseño de sistema debe estar basado en las necesidades reales del usuario (simple pero profundo cual frase de filósofo chino).
¿Porqué es importante la Experiencia de Usuario?
Usted podría pensar: ¡Pues obvio, si me la paso matándome horas programando para tener contento al #$@&% usuario! pero como diría el Dr. Andrés Roemer “no te creas todo lo que piensas“, para nadie en México (donde vivo) y en América Latina es novedad que por lo general estamos un tanto atrasados con respecto a muchas prácticas del primer mundo, donde todo este tema del desarrollo de sistemas centrado en la experiencia de usuario ya lleva un rato tomándose bastante en serio, pero en nuestra región es algo que apenas comienza a cobrar fuerza, es decir, apenas nos estamos dando cuenta de la importancia real de elaborar estrategias, alcances, estructuración, codificación y diseño enfocados realmente en el usuario.
Antes de que alguien me tire tomatazos déjeme decirle algo, para ver si le resulta familiar, aquellos que llevamos tiempo trabajando en la industria del desarrollo hemos tomado decisiones basados en dos cosas principalmente:
- Los elementos e interacciones que construimos en los sistemas son basados en lo que nosotros creemos que funciona. Basamos la estética y la funcionalidad con muy poca idea de como el usuario final usará el sistema, es decir, diseñamos para nosotros mismos (¿dónde está ese documento donde se entrevistaron, evaluaron, cuantificaron, segmentaron a los usuarios finales y sus dispositivos?).
- Todo se elabora en base a lo que el “jefe de alguien quiere ver”. Sucede que todo el trabajo que realizamos está en función del gusto de un individuo con un jerarquía mayor, ya sea de nuestra propia organización o dentro de la del cliente, sí, hablo de ese sujeto que por alguna razón cree ser experto en todo, poseer un sentido común superior y desde luego tener mejor gusto que todos (¿dónde está el documento que dice que ese stakeholder será el único usuario del sistema o si será usuario en lo absoluto?).
Sin embargo, en los últimos años la Internet y por lo tanto la web ha evolucionado y crecido más en su alcance, los sitios en web se han hecho más complejos y con características cada vez más ricas, y por si fuera poco, hoy en día la gente tiene más medios para consumir información en Internet: teléfonos inteligentes y tabletas con diferentes tamaños y capacidades, más navegadores web junto con diferentes tipos de conexiones, y todo ello nos obliga a tener que utilizar estrategias más inteligentes para lidiar con nuestros clientes y usuarios.
Otro punto importante es el tema de la accesibilidad, lo cual se refiere a el acceso universal de los servicios y productos basados en Internet para personas con necesidades diferentes (como débiles visuales por ejemplo) o bien para personas que no cuentan con buenos anchos de banda o que aún utilizan dispositivos viejos.
Tomando en cuenta todos estos cambios, hemos podido observar que todos los productos y servicios que giran alrededor de la Internet y han sobrevivido a lo largo del tiempo son solo aquellos que han logrado adaptarse para seguir siendo útiles y agradables de usar. Así, la moraleja para los que desarrollamos es: todo lo que construimos hoy se convierte en la experiencia que deseamos para con los usuarios que usan lo que hacemos.
Algunos enlaces de interés:
Diseño de la Experiencia de Usuario (Parte 2)
Diseño de la Experiencia de Usuario (Parte 3)
El Enfoque de la Planeación Agile
Estos son alguno libros recomendables para saber más:
Emmanuel Herrera
IT professional with several years of experience in management and systems development with different goals within public and private sectors.
Emmanuel worked through development and management layers, transitioning from developer and team development leader to Project Manager, Project Coordinator, and eventually to Scrum Master, Product Owner, and Agile Coach.
Some certifications include: PSM, PSPO, SSM.
