Publicidad

RSS Scrum

El manifiesto ágil es un documento creado en marzo del 2001 firmado por 17 desarrolladores de software entre los que se encuentran por Kent Beck, Ward Cunningham o Martin Fowler.

En este manifiesto se indican cuatro puntos que se deben valorar: Valorar más a los individuos y su interacción que a los procesos y herramientas. Valorar más al software que funciona que a una documentación exhaustiva. Colaborar más con el cliente en vez de una negociación contractual. Responder al cambio por encima de llevar un plan.

Mike Cohn, uno de los fundadores de Scrum Alliance, ha publicado en su blog unas reflexiones de cual ha sido la influencia de este manifiesto en el sector de la industria del software y como le gustaría que cambiase en los próximos 10 años.

Según el autor, en estos diez años el modo de aplicación ha ido cambiando progresivamente. Inicialmente se abarcaban procesos como Extreme Programming, Scrum, PDD, DSDM. Sin embargo, ellos mismos cuestionaron el uso de Scrum ya que, aunque habían tenido buenos resultados, la moda entonces eran el Proceso Unificado.

Cuando se estaban cuestionando esto, Ward Cunningham le envió un email con una foto de una pizarra con diferentes personas alrededor y se dieron cuenta que no estaban solos y había más gente que estaba interesada en este modo de trabajo.

Ahora las cosas han cambiado mucho. Si un equipo no es ágil se tiene la sensación de que no se están haciendo las cosas como deben ser siendo otro punto a tratar en reuniones de calidad del software como una alternativa.

Por otra parte sugiere que le gustaría que cuando se hable de procesos, las marcas desapareciesen y que no se hable de Scrum, XP, etc, si no que únicamente se diga desarrollo ágil, del mismo modo como ocurrió hace años en el que todos enfoques como Rambaugh, Booch, Meyer y Jacobson se unificó y se límitó a nombrarlo UML.

Incluso le gustaría ver es que la palabra ágil deje de utilizarse y simplemente se diga “desarrollo de software” asumiendo que las técnicas ágiles son parte de este desarrollo al igual que ahora nadie plantea “programación orientado a objetos” o “programación estructurada”, simplemente se dice “programación”.

Por ello concluye, que espera que cuando pasen 20 años de su creación, este documento pase al olvido y deje de ser un simple manifiesto para pasar a ser requisito básico del desarrollo del software.

Fuente Original | Blog de Mike Cohn

La metáfora de la “deuda técnica”

1 Comentario
La metáfora de la “deuda técnica”

La primera referencia al concepto “deuda técnica”, en el contexto del desarrollo software, viene del año 92 (aquí tienes el enlace a aquel primer documento en que se citó la idea). Otra evidencia más de que muchos temas y términos de moda hoy... llevaban ya muchos años con nosotros.

El creador del término fue Ward Cunningham, nombre poco popular en el sector, pero tras el que están, más allá del concepto deuda técnica, aportaciones como el desarrollo de la primera wiki, ser uno de los firmantes el manifiesto ágil, ser uno de los pioneros en introducir el concepto patrón, y los primeros catálogos, en el mundo del desarrollo software, las antiguas tarjetas CRC, contribuciones a eXtreme Programming, etc.

Leer más »

Retos de la agilidad en empresas grandes

4 Comentarios
Retos de la agilidad en empresas grandes

Son las 20:13, sonido en el móvil y el correspondiente mensaje de WhatsApp. Es de Marta. Ella trabaja con el rol de responsable de proyectos y, entre varios mensajes, quiere compartir conmigo que, después de meses de trabajo, el comité de dirección de su empresa, una de las que en el sector llamaríamos “grandes”, ha cancelado lo que allí llamaban la “transformación ágil” de su proyecto.

Marta me comenta que la dirección de su empresa ve demasiado grandes los cambios organizativos, estructurales, contractuales, etc., necesarios para poder acometer, realmente, el cambio que requiere trabajar de manera ágil.

Leer más »
Publicidad

Los 17 momentos por los que merece la pena ser desarrollador

21 Comentarios
Los 17 momentos por los que merece la pena ser desarrollador

Vale, tu madre no sabe explicar a tus tías a que te dedicas ("trabaja con ordenadores, internet y esas cosas"), tus amigos piensan que eres el servicio técnico de Apple y cuando se acerca una fecha de entrega, echas más horas que un reloj en el trabajo. Todo esto es cierto pero, por lo demás, ser desarrollador no está nada mal, de hecho incluso puede llegar a estar bastante bien. Como muestra, un botón en forma de 17 momentos por los que merece la pena ser desarrollador (sin demasiado orden ni concierto).

Leer más »

Large-scale Scrum, multas por no cumplir la normativa sobre cookies y hackers éticos: Pull Request #12

1 Comentario
Large-scale Scrum, multas por no cumplir la normativa sobre cookies y hackers éticos: Pull Request #12

Cerramos la semana repasando algunas de las lecturas recopiladas por los editores de Genbeta Dev. Agrupamos en este nuevo Pull Request Semanal #11 nuestras recomendaciones de artículos técnicos para desarrolladores.

Leer más »

Equipos dispersos: teletrabajo en un entorno ágil

11 Comentarios
Equipos dispersos: teletrabajo en un entorno ágil

El teletrabajo, deseado por unos, necesario para otros y del que huyen los que dicen que se aburrirían si trabajasen en casa. Pero, ¿Se puede trabajar en equipo desde casa? ¿Se puede utilizar metodologías ágiles desde casa? ¿Puedes trabajar en casa y sentirte arropado por tu equipo? ¿Puedes ser igual o más productivo desde casa? Pues bien, sí, sí, sí y sí.

Quiero empezar explicando, para evitar confusiones, la diferencia entre equipos dispersos y equipos distribuidos. La diferencia es simple, los equipos distribuidos son distintos equipos que tienen que colaborar juntos y que están en ubicaciones distintas. Por su parte los equipos dispersos son integrantes de un mismo equipo que están separados geográficamente.

Leer más »

Crónica de la Conferencia Agile Spain 2011

4 Comentarios
Crónica de la Conferencia Agile Spain 2011

La semana pasada, entre el jueves y el viernes se celebró en Castellón, en la Universidad Jaume I, la conferencia Agile Spain 2011, el evento anual de la asociación Agile Spain, en el que, con el lema “Agilidad, un paso por delante”, pudimos todos los asistentes ver y compartir el estado actual de las metodologías ágiles en España.
Ante todo, mis felicitaciones a los organizadores, siempre es de agradecer el buen hacer de estas personas, voluntarias, a la hora de organizar esto.

Empezamos la conferencia de este año con la keynote de Xavier Quesada titulada, El último momento responsable, a la hora de abordar decisiones, se trata de tomarlas en el momento en que dispongamos la mayor información, pero nunca más tarde, cuando sea ya demasiado tarde. Muy orientado a los principios de las metodologías ágiles, enfrentadas totalmente al concepto de metodologías predictivas.

Leer más »
Publicidad

Test de metodologías ágiles, ¿Qué metodología es mejor: Scrum, Kanban o Scrumban?

4 Comentarios
Test de metodologías ágiles, ¿Qué metodología es mejor: Scrum, Kanban o Scrumban?

Hay quien se empeña en crear una guerra de metodologías ágiles, que si mejor Scrum, que no que mejor Kanban… Mi opinión es que hay que saber elegir la metodología adecuada según tu modelo de desarrollo y las necesidades que este tenga, no hay una mejor que otra, simplemente hay una más apropiada que otra.

Como ayuda a la hora de tomar esta decisión, propongo un pequeño test para poder escoger la metodología ágil más adecuada (10 sencillas preguntas al más puro estilo revista adolescente), ya sea porque tienes la intención de “volverte ágil” o bien porque ya estás utilizando alguna pero hay algo que chirría:

Leer más »

Ecosistema ALM en .NET. Brevísima introducción a SCRUM.

6 Comentarios
Ecosistema ALM en .NET. Brevísima introducción a SCRUM.

En el anterior artículo de esta serie he tocado por encima las metodologías de trabajo, desde su concepto más arquitectónico hasta los frameworks más utilizados como RUP, XP o SCRUM.

Ahora voy a meter las manos en la masa y, haciendo una breve descripción de la metodología y de las piezas de software que se utilizan, voy a realizar la descripción más detallada de las capacidades del ecosistema de desarrollo en .Net. La potencia de todas estas aplicaciones que tienen un nivel de comunicación y usabilidad muy alto.

Obviaré todo lo relacionado con descargas, instalaciones y configuraciones del ecosistema por dos razones fundamentales: Primero esto es un blog de desarrolladores, asique voy a la chicha que utilizo todos los días; aunque a estas alturas pueda instalar un TFS con los ojos cerrados. Y segundo, que existe una máquina virtual gratuita que ya trae todo el ecosistema montado y listo para funcionar hasta su periodo de expiración.

Leer más »

La necesidad de las pruebas en las metodologías ágiles

7 Comentarios
La necesidad de las pruebas en las metodologías ágiles

En el anterior artículo hablábamos del sentido de las iteraciones/sprints en las metodologías ágiles, y una de las cosas que resaltaba era la necesidad de la entrega de valor continúa.

Para esto hay una cosa fundamental que no debemos olvidar: que la calidad, en el sentido más amplio de la palabra, no es opcional. No me refiero sólo al típico “que no falle”, sino a ¿entrega el valor esperado? ¿Resuelve los problemas que debería? ¿Cómo se comporta esto ante condiciones anormales de negocio (p.ej.: 1000 usuarios)?

Ante esto, cuando estamos trabajando con esta mentalidad, debemos de poner la calidad como foco desde el principio. Se acabó esa forma de pensar en la que los testers son un equipo, normalmente el enemigo, de los desarrolladores. Ese típico ir y venir de descripciones de fallos (seguro que todos recordáis el mítico Pong).

Leer más »

Ser ágil es algo más que iterar

5 Comentarios
Ser ágil es algo más que iterar

Cuando hablamos de metodologías ágiles, una de las primeras cosas que primero le vienen a la gente a la cabeza, o que me dicen algunos clientes cuando les visito es, “Si, aquí trabajamos con iteraciones/sprints“, y en ciertas ocasiones la afirmación termina ahí, al final lo que se acaba teniendo es un modelo en cascada … con cascadas que duran aproximadamente cuatro semanas.

Pero, ¿por qué se hacen las iteraciones? Es una de las cosas que tenemos que preguntarnos, y una de las primeras respuestas, pero no la única, que me viene a la cabeza es, entregar valor lo antes posible y de modo continuado. Por lo que, si tras finalizar la iteración, nos hacemos la pregunta, ¿podemos darle esto a nuestros clientes?, y la respuesta es algo como “bueno, aún queda …” o “si bueno, pero hay que estabilizar el …”, hay algo que no hemos hecho bien, ya que el resultado de cada iteración, para que pueda darse por bueno, debería de ser potencialmente entregable a los clientes, aunque no vayamos a ponerlo en producción tras cada iteración.

Leer más »
Publicidad

Ver más artículos