 |
| Imagen de: cartoonstock.com |
En las dos entregas anteriores de esta serie de pmoinformatica.com, nos dedicados a describir 10 razones para aplicar metodologías ágiles (Primera y segunda parte). Justo cuando pensábamos que habíamos descrito todas las razones y nos preparábamos para escribir de otro tema, nos topamos con un interesantísimo artículo en Scrum Alliance, escrito por Robert Karlsson titulado “Key arguments to sell Scrum to your boss” ó argumentos clave para vender Scrum a tu jefe.
Pmoinformatica.com dedica esta entrega a presentar estos argumentos muy buenos para convencer a tu jefe y la organización sobre la adopción de metodologías ágiles, tales como que En dos semanas se obtendrá algo que ya está probado, permite hablar menos y hacer más, hace que los cambios sean bienvenidos y no una carga, permite manejar una sola lista de prioridades, mejor uso de las habilidades de la gente y por ende mayor espíritu de equipo, entre otros.
A continuación el artículo:
Fuente del artículo: Key Arguments to Sell Scrum to Your Boss. Scrum Alliance.
Karlsson comienza su artículo diciendo que siempre es difícil para los desarrolladores responder rápidamente a los cambios. Los mercaderistas, áreas de negocio, ventas y producción por lo general necesitan que las cosas se hagan “Ahora”, porque, bien, “ahora es ahora” y “mañana es mañana”.
Karlsson escribe para Scrum Alliance. Más información sobre Scrum Alliance.
¿Cómo convencer a nuestros jefes que existe una forma de responder a las áreas de negocio más rápido?, una forma de hacer “usuarios felices” más rápido, adoptar los cambios que solicitan más rápido y que los cambios “son buenos y no malos”.
Más información en: >> ¿Cuando aplicar y no aplicar el desarrollo ágil?
Lo primordial es que necesitamos argumentos, no podemos simplemente decirle a nuestros jefes que “necesitamos que dejen en paz al equipo de desarrollo durante dos semanas” (la duración de una iteración). Tenemos que venderles las ventajas de este concepto de forma clara y con significado.
8 argumentos para convencer a tu jefe de adoptar Scrum
Una forma de lograr esto, es describir los aspectos claves del proceso Scrum de la siguiente forma:
1.- En dos semanas se obtendrá algo que ha sido probado, está funcionando, puede ser enviado a producción y corresponde con lo que solicitó el usuario, ¿puede imaginarse los beneficios?.
6.- Mejor espíritu de equipo: El involucrar a los desarrolladores en el proceso de planificación (denominado Sprint Planning en Scrum), les compromete con el plan y las metas. Y crea sentido de equipo en función de la meta común y dejándoles decidir cómo resolver el problema.
Más información sobre >> Test Driven Development (TDD): Como llevarlo a la práctica. TDD es una de las prácticas de la programación extrema de software (XP).
7.- No es una bala de plata: No debemos cambiar el proceso y adaptar la metodología antes, primero probémoslo, aprendamos y modifiquemos la organización basados en ese aprendizaje.
Pmoinformatica.com dedica esta entrega a presentar estos argumentos muy buenos para convencer a tu jefe y la organización sobre la adopción de metodologías ágiles, tales como que En dos semanas se obtendrá algo que ya está probado, permite hablar menos y hacer más, hace que los cambios sean bienvenidos y no una carga, permite manejar una sola lista de prioridades, mejor uso de las habilidades de la gente y por ende mayor espíritu de equipo, entre otros.
A continuación el artículo:
Fuente del artículo: Key Arguments to Sell Scrum to Your Boss. Scrum Alliance.
Karlsson comienza su artículo diciendo que siempre es difícil para los desarrolladores responder rápidamente a los cambios. Los mercaderistas, áreas de negocio, ventas y producción por lo general necesitan que las cosas se hagan “Ahora”, porque, bien, “ahora es ahora” y “mañana es mañana”.
Karlsson escribe para Scrum Alliance. Más información sobre Scrum Alliance.
¿Cómo convencer a nuestros jefes que existe una forma de responder a las áreas de negocio más rápido?, una forma de hacer “usuarios felices” más rápido, adoptar los cambios que solicitan más rápido y que los cambios “son buenos y no malos”.
Más información en: >> ¿Cuando aplicar y no aplicar el desarrollo ágil?
Lo primordial es que necesitamos argumentos, no podemos simplemente decirle a nuestros jefes que “necesitamos que dejen en paz al equipo de desarrollo durante dos semanas” (la duración de una iteración). Tenemos que venderles las ventajas de este concepto de forma clara y con significado.
8 argumentos para convencer a tu jefe de adoptar Scrum
Una forma de lograr esto, es describir los aspectos claves del proceso Scrum de la siguiente forma:
1.- En dos semanas se obtendrá algo que ha sido probado, está funcionando, puede ser enviado a producción y corresponde con lo que solicitó el usuario, ¿puede imaginarse los beneficios?.
2.- Hablar menos y hacer más: En lugar de invertir tiempo escribiendo especificaciones funcionales, en las cuales un los desarrolladores senior ya han formulado la idea y se la especifican al equipo, se va directo al desarrollo y se pueden hacer prototipos de las ideas directamente.
>> Plantillas Scrum: historias de usuario y criterios de aceptación
3.- Los cambios son buenos, no una carga para el proyecto: Que tal si dijéramos que todas esas cosas fastidiosas, imposibles prever con antelación, las podemos incluir en un prototipo, y que luego si lo necesitamos podemos cambiar el prototipo. Aquí entra en juego la ejecución en iteraciones (Sprints), todas esas cosas que no pudieron completarse en la iteración debido a que necesitan especificarse más o que cuando las vimos las pensamos mejor, pues las dejamos para la siguiente iteración. Cierto, tendrá que esperar dos semanas más, pero luego de esperar si funcionar. Scrum significa hacer cambios incrementales a un producto en funcionamiento.
Más sobre cómo manejar cambios de alcance en proyectos de informática.
4.- Una sola lista de prioridades: El día a día de un proyecto de informática suele involucrar personas distintas, de distintas áreas, con distintos intereses, solicitando cosas. Cada día distintas personas, evaden la red de seguridad (el proceso de control de cambios), contactan a los desarrolladores directamente, cargándoles de decisiones de priorización.
La solución, es tener una sola lista y solo una sola lista, la única persona que puede añadir cosas a la lista es el dueño de producto, cada solicitud debe pasar por esta persona y ser priorizadas. Esto también se hacía antes (con los métodos tradicionales), pero ahora sabemos que está allí y tenemos un sistema para manejarlo.
Más información: >> El Desarrollo ágil en un entorno de fechas y presupuestos predefinidos
5.- Mejor uso de las habilidades de los programadores: La premisa de los métodos tradicionales es que los programadores sólo saben programar y necesitan especificaciones detalladas de lo que se necesita hacer. Pero no es verdad, los programadores saben hacer mucho más que programar y la única forma de descubrir sus habilidades es involucrándolos. Lo mejor, es dejar que piensen por sí solos, proporcionándoles una historia a desarrollar en lugar de una especificación detallada.
Más información en: >> Los 5 valores de la programación extrema (XP).
>> Plantillas Scrum: historias de usuario y criterios de aceptación
3.- Los cambios son buenos, no una carga para el proyecto: Que tal si dijéramos que todas esas cosas fastidiosas, imposibles prever con antelación, las podemos incluir en un prototipo, y que luego si lo necesitamos podemos cambiar el prototipo. Aquí entra en juego la ejecución en iteraciones (Sprints), todas esas cosas que no pudieron completarse en la iteración debido a que necesitan especificarse más o que cuando las vimos las pensamos mejor, pues las dejamos para la siguiente iteración. Cierto, tendrá que esperar dos semanas más, pero luego de esperar si funcionar. Scrum significa hacer cambios incrementales a un producto en funcionamiento.
Más sobre cómo manejar cambios de alcance en proyectos de informática.
4.- Una sola lista de prioridades: El día a día de un proyecto de informática suele involucrar personas distintas, de distintas áreas, con distintos intereses, solicitando cosas. Cada día distintas personas, evaden la red de seguridad (el proceso de control de cambios), contactan a los desarrolladores directamente, cargándoles de decisiones de priorización.
La solución, es tener una sola lista y solo una sola lista, la única persona que puede añadir cosas a la lista es el dueño de producto, cada solicitud debe pasar por esta persona y ser priorizadas. Esto también se hacía antes (con los métodos tradicionales), pero ahora sabemos que está allí y tenemos un sistema para manejarlo.
Más información: >> El Desarrollo ágil en un entorno de fechas y presupuestos predefinidos
5.- Mejor uso de las habilidades de los programadores: La premisa de los métodos tradicionales es que los programadores sólo saben programar y necesitan especificaciones detalladas de lo que se necesita hacer. Pero no es verdad, los programadores saben hacer mucho más que programar y la única forma de descubrir sus habilidades es involucrándolos. Lo mejor, es dejar que piensen por sí solos, proporcionándoles una historia a desarrollar en lugar de una especificación detallada.
Más información en: >> Los 5 valores de la programación extrema (XP).
6.- Mejor espíritu de equipo: El involucrar a los desarrolladores en el proceso de planificación (denominado Sprint Planning en Scrum), les compromete con el plan y las metas. Y crea sentido de equipo en función de la meta común y dejándoles decidir cómo resolver el problema.
Más información sobre >> Test Driven Development (TDD): Como llevarlo a la práctica. TDD es una de las prácticas de la programación extrema de software (XP).
7.- No es una bala de plata: No debemos cambiar el proceso y adaptar la metodología antes, primero probémoslo, aprendamos y modifiquemos la organización basados en ese aprendizaje.
Hay que tener cuidado con vender Scrum y las metodologías ágiles como la panacea para resolver todos los problemas, aún aplicando los enfoques ágiles, pues todavía tenemos que desarrollarlo, todavía tenemos que probar, y si lo hacemos mal, pues el enfoque ágil no nos ayudará.
Más información desarrollo bajo enfoques ágiles: >> Refactorización: 6 preguntas y respuestas
8.- Enfoquémonos en entregar con calidad: A pesar de todo lo dicho anteriormente, lo que realmente le importa a su jefe son los resultados, enfóquese en entregar y hacerlo con calidad y rápido, esto realmente es lo que cambia las actitudes de resistencia a enfoques como Scrum.
>> 5 métricas de desempeño para proyectos de desarrollo ágil y Scrum
>> Herramientas de software para gestión de proyectos de desarrollo ágil
¿y qué opina usted?
¿Qué opina usted?, ¿Cuáles son los principales puntos a favor que utilizaría para recomendar un enfoque ágil a una organización?, ¿lo recomendaría en todas las situaciones?, ¿En cuales situaciones y en cuales no?. Le invitamos a dejar sus comentarios en la Web de La Oficina de Proyectos de Informática (pmoinformatica) y a suscribirse por los distintos canales, incluyendo lista de correo electrónico, al Twitter @PMOInformatica, a nuestra página de Facebook o al feed RSS.
<< Artículo anterior: 10 razones para aplicar el desarrollo ágil - 2da Parte
Referencia
Key Arguments to Sell Scrum to Your Boss. Scrum Alliance.
¿Quieres conocer otros productos y últimas novedades sobre desarrollo ágil y gestión de proyectos en amazon.es y amazon.com?.
>> Visita nuestra sección de productos amazon
Otros artículos sobre Desarrollo ágil, Scrum y Test Driven Development
>> 10 razones para aplicar el desarrollo ágil - 1era Parte
>> TDD: Componentes difíciles de probar
>> Test Driven Development (TDD): Pruebas del desarrollador
>> Test Driven Development (TDD): Ventajas y desventajas
>> Test Driven Development (TDD): 9 retos para su implementación y cómo hacerles frente
>> 5 Preguntas y respuestas sobre el Feature Driven Development (FDD)
>> Scrum de Scrum: Desarrollo ágil para grandes proyectos
>> Los Programas de Certificación del Scrum Alliance
>> Gestión de Proyectos PMI y el Desarrollo Ágil: ¿Que tienen en común?
>> Metodologías de desarrollo ágil
Más información desarrollo bajo enfoques ágiles: >> Refactorización: 6 preguntas y respuestas
8.- Enfoquémonos en entregar con calidad: A pesar de todo lo dicho anteriormente, lo que realmente le importa a su jefe son los resultados, enfóquese en entregar y hacerlo con calidad y rápido, esto realmente es lo que cambia las actitudes de resistencia a enfoques como Scrum.
>> 5 métricas de desempeño para proyectos de desarrollo ágil y Scrum
>> Herramientas de software para gestión de proyectos de desarrollo ágil
¿y qué opina usted?
¿Qué opina usted?, ¿Cuáles son los principales puntos a favor que utilizaría para recomendar un enfoque ágil a una organización?, ¿lo recomendaría en todas las situaciones?, ¿En cuales situaciones y en cuales no?. Le invitamos a dejar sus comentarios en la Web de La Oficina de Proyectos de Informática (pmoinformatica) y a suscribirse por los distintos canales, incluyendo lista de correo electrónico, al Twitter @PMOInformatica, a nuestra página de Facebook o al feed RSS.
<< Artículo anterior: 10 razones para aplicar el desarrollo ágil - 2da Parte
Referencia
Key Arguments to Sell Scrum to Your Boss. Scrum Alliance.
¿Interesado en libros sobre Desarrollo ágil de Software?
 |  |  |  | ||
| Kanban Autor: David J Anderson >> España (amazon.es)  >> Latinoámerica (amazon.com)  |
| Gestión Ágil de Proyectos Autor: Pablo Lledó >> España(amazon.es)  >> Latinoámerica (amazon.com)  | Diseño ágil con TDD Autor: Carlos Ble Jurado >> España(amazon.es)  >> Latinoámerica (amazon.com)  |
¿Quieres conocer otros productos y últimas novedades sobre desarrollo ágil y gestión de proyectos en amazon.es y amazon.com?.
>> Visita nuestra sección de productos amazon
Otros artículos sobre Desarrollo ágil, Scrum y Test Driven Development
>> 10 razones para aplicar el desarrollo ágil - 1era Parte
>> TDD: Componentes difíciles de probar
>> Test Driven Development (TDD): Pruebas del desarrollador
>> Test Driven Development (TDD): Ventajas y desventajas
>> Test Driven Development (TDD): 9 retos para su implementación y cómo hacerles frente
>> 5 Preguntas y respuestas sobre el Feature Driven Development (FDD)
>> Scrum de Scrum: Desarrollo ágil para grandes proyectos
>> Los Programas de Certificación del Scrum Alliance
>> Gestión de Proyectos PMI y el Desarrollo Ágil: ¿Que tienen en común?
>> Metodologías de desarrollo ágil
No hay comentarios :
Publicar un comentario