XP vs SCRUM

XP vs SCRUM

Introdución:
Extreme Programming (XP) y Scrum están definitivamente muy ligados entre sí. Es un hecho que si perteneces a un equipo que lleva una de estas dos metodologías vas a tener un tiempo difícil encontrando diferencias entre una y otra. Las diferencias son mínimas, pero muy importantes. Personalmente creo que existen 4 principales diferencias entre Scrum y XP.

Desarrollo:
Los Equipos de Scrum normalmente trabajan en iteraciones (llamadas sprints) con una duración de 2 semanas a un mes. Los Equipos de XP normalmente trabajan con iteraciones muy cortas (1 o 2 semanas).
Los equipos de Scrum no permiten cambios en sus sprints. Una vez que el sprint planning meeting ha concluido y se llegó a una acuerdo para elegir los product backlog items, estos no pueden recibir cambios, por lo menos hasta el final del sprint. Los equipos XP aceptan los cambios con más facilidad en sus iteraciones. Siempre y cuando el equipo no haya empezado ya a trabajar en un requerimiento en particular , un nuevo requerimiento de un tamaño similar puede ser cambiado por otro equivalente en la iteración.
Los  equipos de XP trabajan en un orden estricto. Los requerimientos que serán desarrollados son priorizados por el cliente (Product Owner en Scrum) y el equipo debe desarrollar los requerimientos en ese orden específico. En contraste, el product owner de Scrum prioriza los product backlog pero el equipo determina el orden en el que serán desarrollados.

Scrum no recomienda ninguna buena práctica de desarrollo. XP si lo hace. Personalmente amo las buenas prácticas de XP , particularmente cosas como el test-driven development, desarrollo basado en pruebas, pair programing, diseño simple, entre otros. Pienso que es un error de los equipos el pensar en “auto-organización, confiamos en ti , pero debes hacer estan buenas prácticas en específico”. Esto envía un mensaje confuso al equipo. Las buenas practicas de XP no es necesarios obligar a los equipos a realizarlas pues descubren sus virtudes por cuenta propia.

SCRUM	XP
Es una metodología de desarrollo ágil basada en la administración del proyecto.	Es una metodología de desarrollo que está más centrada en la programación o creación del producto.
Cada miembro de del equipo trabaja de forma indivisual.	Los miembro del equipo programan en parejas.
Las ietraciones de entrega son de 1 a 4 semanas.	Las ietraciones de entrega son de 1 a 3 semanas
Al finalizar un Sprint, las tareas del Sprint Backlog que se hayan realizado y que el Product Owner (propietario del producto) haya mostrado su conformidad ya no se retoca. Si funciona y está bién, se aparta y a otra cosa.	Las tareas se van terminando aunque son susceptibles de ser modificadas durante el transcurso de proyecto, incluso, después de que funcionen correctamente.
Trata de seguir el orden de prioridades que marca el Product Owneren el Sprint Backlog pero puede cambiarlo si es mejor para el desarrollo de la tareas.	El equipo de desarrollo sigue estrictamente el orden de prioridad de las tareas definido por el cliente.

Conclusión:
Puedo notar que estas son pequeñas diferencias, pero importantes entre XP y Scrum. De cualquier manera, pueden tener un gran impacto en el equipo. Las buenas prácticas de XP son demasiado buenas y prácticas, pero pueden no funcionar bien para todos los equipos, es mejor que vean por si mismos cuales son las que más se adaptan a todo el equipo. Scrum es tambien muy bueno puesto que trae por muchas mejoras a la forma en que trabajan los equipos y parte de un buen punto para añadir las mejoras de XP.

Bibliografia:
https://es.slideshare.net/edgarespinoza/programacion-extrema
http://ingenieriadesoftware.mex.tl/52753_XP---Extreme-Programing.html
https://manifesto.co.uk/kanban-vs-scrum-vs-xp-an-agile-comparison/
http://www.islavisual.com/articulos/desarrollo_web/diferencias-entre-scrum-y-xp.php
"Una historia de guerra ágil".Henrik Kniberg.© 2007 C4Media Inc
http://ingenieriadesoftware.mex.tl/52812_Scrum.html
http://www.islavisual.com/articulos/desarrollo_web/diferencias-entre-scrum-y-xp.php
http://ingenieriadesoftware.mex.tl/52753_XP---Extreme-Programing.html

Leyes de Lehman

Tipos de Mantenimiento de Software:

Mantenimiento Preventivo

Un claro ejemplo de este mantenimiento es la plataforma de videojuegos llamada Steam ya que prevee la saturación de los servidores al momento de que se lanza una oferta o cualquier juego se da gratis en un periodo de 24 hrs.

Mantenimiento Correctivo

El ejemplo perfecto para este tipo de mantenimiento es la aplicación de Facebook en ciertas ocasiones se queda congelada la lista de contactos y no muestra quien esta conectado y quien desconectado realmente, otro punto en contra es que los mensajes a veces no se actualizan.

Mantenimiento Adaptativo

La plataforma de lanzamiento del juego conocido como “League of legends” la compatibilidad y jugabilidad en diferentes sistemas operativos que no sea Windows es bastante mala.

Mantenimiento Perfectivo

El emulador de juegos llamado Dolphin lo que se podría implementar para mejorar su rendimiento es corregir los bugs y parchar los juegos los cuales corre, además de que emule juegos de wii y de wii u.

Leyes de Lehman

Cambio continuo:  Un programa que se usa en un entorno real necesariamente debe cambiar o se volverá progresivamente menos útil y menos satisfactorio para el usuario.

Las Redes Sociales Son un claro ejemplodel cambio continuo, ya que si no son atractivas y funcionales, entonces los usuarios dejarán de usarlas. Por lo tanto deben estar actualizandose constantemente.

Complejidad creciente: A medida que un programa en evolución cambia, su estructura tiende a ser cada vez más compleja. Se deben dedicar recursos extras para preservar y simplificar su estructura.

Facebook y las versiones de Android en especifico están en evolución están en conste cambio y es por ello que su estructura debe ser cambiada debido a su complejidad.

Autoregulación:  La evolución de los programas es un proceso autoregulado. Los atributos de los sistemas, tales como tamaño, tiempo entre entregas y la cantidad de errores documentados son aproximadamente invariantes para cada entrega del sistema.

Podemos relacionar esta Ley con el virus de la influenza AH1N1, que ha estado autoregulandose para cambiar conforme avanza el tiempo desde que fue descubierta, ya que ha sido muy dificil encontrar una cura y el virus muta mas rápido, entonces concluimos que el virus se autoregula para cambiar.

Estabilidad organizacional:  Durante el tiempo de vida de un programa, su velocidad de desarrollo es aproximadamente constante e independiente de los recursos dedicados al desarrollo del sistema.

Conservación de la familiaridad: A medida que un sistema evoluciona todo lo que está asociado con ello, como los desarrolladores, personal de ventas, y usuarios por ejemplo, deben mantener un conocimiento total de su contenido y su comportamiento para lograr una evolución satisfactoria. Un crecimiento exagerado disminuye esta capacidad. Por tanto este incremento promedio debe mantenerse.

Multitasking en iOS: Para muchos quienes desconocían el mutitasking de iOS esta nueva funcionalidad fue problemática, ya que a falta de conocimiento de esta varias aplicaciones se mantenían funcionando en segundo plano, provocando que la memoria libre del dispositivo se redujera y por lo tanto su eficiencia fuera menor.
Está relacionada con la familiaridad, ya que para los usuarios perdían rendimiento de sus dispositivos a causa de una nueva funcionalidad que hasta entonces no conocían.

Crecimiento continuado:  La funcionalidad ofrecida por los sistemas tiene que crecer continuamente para mantener la satisfacción de los usuarios.

Decremento de la calidad: La calidad de los sistemas software comenzará a disminuir a menos que dichos sistemas se adapten a los cambios de su entorno de funcionamiento.

Yahoo rediseño su pagina en México donde muestra que están en constante cambio para que sus usuarios tenga una mejor experiencia. Además de que no es un cambio radical ya que solo cambia algunos aspectos para que la experiencia de del usuario sea mas intuitivo, conservando la estructura básica de su sitio pero agregando nuevas funciones a éste.

Bibliografia:
Lehman, M. M., & J. F. Ramil, P. D. (1997). Metrics and laws of software evolution—the nineties view.

Gestión de Proyectos. "Leyes de Lehman".Febrero 2014

http://alexistorreblanca.blogspot.mx/2014/02/tipos-de-mantenimiento-de-software-y.html

http://gcp5im6.blogspot.mx/2014/02/leyes-de-lehman.html

Leyes de Lehman. Primitivo López García
http://ronuor.blogspot.mx/2014/02/leyes-de-lehman.html
https://www.lifewire.com/use-multitasking-on-iphone-2000763

Modelos de desarrollo de Software

INTRODUCCIÓN:

      Dentro de estos modelos de software se sigue un proceso de producción de Software y un ciclo de vida de los modelos estructurados.

      La meta de meta de un modelo es determinar el orden de las etapas que componen el desarrollo y evolución del software. Y están hechos para contestar las siguientes preguntas:

        ¿Qué debemos hacer a continuación?
        ¿Cuánto tiempo debemos continuar haciéndolo?

     Según Sommerville (2005), para muchas personas el software son solo programas de computadora, sin embargo nos comenta que son todos aquellos documentos asociados a la configuración de datos que se necesitan para hacer que estos programas operen de manera adecuada.

DESARROLLO:

¿Qué es un modelo de desarrollo?

Un modelo de desarrollo es una representación abstracta de un proceso de software, cada modelo representa el proceso de desarrollo de software de una manera en particular. A pesar de estar definidos claramente, no representan necesariamente la realidad de cómo se debe desarrollar el software, sino que establece un enfoque común. Un modelo puede ser modificado y adaptado de acuerdo a las necesidades del software en desarrollo.
En forma general podemos clasificar los modelos de desarrollo en 3 grupos:

El modelo en cascada

 Considera las actividades fundamentales del proceso de especificación, desarrollo, validación y evolución, y los representa como fases separadas del proceso, tales como la especificación de requerimientos, el diseño del software, la implementación, las pruebas, etcétera.

Desarrollo Evolutivo

El desarrollo evolutivo consta del desarrollo de una versión inicial que luego de exponerse se va refinando de acuerdo de los comentarios o nuevos requerimientos por parte del cliente o del usuario final. Las fases de especificación, desarrollo y validación se entrelazan en vez de separarse. Este enfoque entrelaza las actividades de especificación, desarrollo y validación. Un sistema inicial se desarrolla rápidamente a partir de especificaciones abstractas. Éste se refina basándose en las peticiones del cliente para producir un sistema que satisfaga sus necesidades.

Existen dos tipos de desarrollo evolutivo:

Desarrollo exploratorio

Donde el objetivo del proceso es trabajar con el cliente para explorar sus requerimientos y entregar un sistema final. El desarrollo empieza con las partes del sistema que se comprenden mejor. El sistema evoluciona agregando nuevos atributos propuestos por el cliente.

Prototipos desechables

Donde el objetivo del proceso de desarrollo evolutivo es comprender los requerimientos del cliente y entonces desarrollar una definición mejorada de los requerimientos para el sistema. El prototipo se centra en experimentar con los requerimientos del cliente que no se comprenden del todo.

Modelo Espiral

Es un modelo de desarrollo evolutivo propuesto por Barry Boehm, que utiliza prototipos como apoyo. La forma de espiral representa una iteración (repetición) de procesos que, a medida que se van entregando prototipos y éstos son revisados por los clientes o usuarios finales, el tiempo empleado para desarrollar la próxima versión es cada vez mayor. Cada división recibe el nombre de región de tareas.

Aunque el modelo espiral representa ventajas por sobre el desarrollo lineal, el cálculo de los riesgos puede ser muy complicado y no es tan usado en la realidad.

Modelo Incremental

El modelo incremental es una unión de las mejores funcionalidades del modelo de cascada y del modelo de prototipos. A medida que se presenta un prototipo se produce un “incremento”, que es una iteración del proceso anterior pero aplicando las experiencias aprendidas del proceso anterior. A diferencia del modelo de prototipos, los prototipos de este modelo están orientados a ser operacionales en cada incremento y no ser solo una “previa” de cómo sería el sistema en su versión final.

CONCLUSIÓN:

Desde el punto de vista de desarrollo de sistema el enfoque evolutivo suele traer más ventajas en comparación con un enfoque en cascada ya que el sistema se va ajustando a las necesidades del cliente, a la vez que él mismo entiende mejor sus propios requerimientos. Sin embargo el enfoque evolutivo desde una perspectiva de ingeniería y gestión suele tener grandes problemas.

Pienso que el desarrollo de software es uno de los pilares fundamentales al cual se dedican muchas horas de esfuerzo, y conforme la tecnología va avanzando, se van apareciendo nuevas soluciones, nuevas formas de programación, nuevos lenguajes, y un sin fin de herramientas que intentan realizar el trabajo del desarrollador un poco mas fácil. Es importante conocer bien estos modelos, para tener un esquema mental que nos permita gestionar proyectos y organizar equipos que sean productivos.

BIBLIOGRAFÍA:

http://www.eumed.net/tesis-doctorales/2014/jlcv/software.htm
Carvajal Jose Carlos. Metodologías Ágiles. Septiembre 2008.
http://tema3isoftware.blogspot.mx/p/modelos-de-desarrollo-tecnicas-y.html

https://es.wikiversity.org/wiki/Procesos_de_desarrollo_software

http://www.monografias.com/trabajos39/desarrollo-del-software/desarrollo-del-software2.shtml

Soporte de Software

Soporte de Software:

Es dar mantenimiento al software realizando actividades de soporte técnico.

Metodologías Ágiles: (Ensayo y Mapa conceptual)

INTRODUCCIÓN:

Se puede destacar que en el pasado existía un estándar en el cual se definía para garantizar la calidad del software mediante métodos de análisis y diseño soportados por herramientas CASE (Ingeniería de Software Asistida por Computador), sin embargo estas metodologías tenían una carga pesada en la planificación, diseño y documentación dedicándole menos tiempo al desarrollo del sistema.

Sin embargo a finales de los años 80's y principios de los años 90's se proponen nuevos métodos ágiles de programación, los cuales se enfocan en el software y le dedican menos tiempo al diseño y documentación, entre algunos métodos de programación ágil se encuentran: XP (extreme programming), LSD (Lean Software Development), Scrum, entre otros, destacando estos por ser los más utilizados.

DESARROLLO

Una metodología es una colección de procedimientos, técnicas, herramientas y documentos auxiliares que ayudan a los desarrolladores de software en sus esfuerzos por implementar nuevos sistemas de información. Una metodología está formada por fases, cada una de las cuales se puede dividir en sub-fases, que guiarán a los desarrolladores de sistemas a elegir las técnicas más apropiadas en cada momento del proyecto y también a planificarlo, gestionarlo, controlarlo y evaluarlo.
Las metodologías comunes en el desarrollo de software son muy rígidas, muy resistente a los cambios a lo largo del proyecto y todo debe ser definido desde el inicio, y la gran mayoría de las veces eso no es posible seguir todo al pie de la letra, de aquí surge la necesidad de crear nuevas metodologías que puedan atacar los problemas que tienen las antes mencionadas, surgen cosas como la programación extrema, metodologías de cristal,  entre otros, explicaremos algunos.

Programación Extrema

Fué formulada por  Kent Beck en 1999,  siendo este el más destacado de los procesos ágiles de programación, pone énfasis en la adaptación del software en el proceso de desarrollo, es mas realista en muchos sentidos en especial en los requerimientos ya que aveces ponemos cosas que si bien son muy difíciles, algunas son ciencia ficción, es común que en esta metodología el cliente se involucre con el equipo de desarrollo o bien pertenezca a este, en lo personal, me gusta mucho este.

Crystal Clear

Mas que una metodología, son una familia de estas, fueron descritas por Alistair Cockburn, e ideal para equipos de 6 a 8 personas, se centra en las personas, no en los procesos, y la seguridad es una de sus mayores preocupaciones.

DSDM

El método de desarrollo de sistemas dinámicos (Dynamic Systems Development Method) desarrollado en el reino unido en la época de los 90's provee un framework de desarrollo y es increíblemente flexible a los cambios en los requerimientos, es ideal para proyectos que deben sacarse en poco tiempo.

SCRUM

Consiste en un modelo de asignación de tareas diarias basado en reuniones rápidas y control de la evolución de los procesos.

LEARN PROGRAMMING

Consiste en ciclos de evolución de software incrementales en los que se posponen las decisiones lo más posible hasta haber obtenido una retro alimentación del cliente y así reaccionar lo más rápido y eficazmente posible a sus necesidades.

Conclusiones:

Después de conocer lo que son las metodologías ágiles, se podría decir que éste tipo de planificación será la más utilizada por programadores, ya que son aplicables a una mayor cantidad de sistemas en el mercado y a miparecer, su filosofía es más confortable para los clientes porque le presta una mejor participación en el proyecto, también otorga mayor confianza al trabajo del programador por la constante comunicación y la entrega parcial de los avances funcionales del sistema, lo que lo hace un método favorable, y debido a que los proyectos que llevamos ahora suelen ser muy grandes y deben entregarse en tan solo algunos meses, me parece que estas metodologías son ideales, y aunque desde el inicio se siguió la metodología tradicional, me parece que hubiera sido mas acertado que hubiésemos seguidos alguna de estas metodologías, ya que habría sido mucho mas ameno, y la verdad es que al menos en los equipos en los que he estado, en buena parte hemos seguido estas metodologías en algunos aspectos y sin saber que o como se definían.

Bibliografía:
http://danielgrifol.es/metodologias-agiles-de-desarrollo-de-software/
http://blog.leanmonitor.com/es/que-son-las-metodologias-agiles/

http://carlosreynoso.com.ar/archivos/arquitectura/Metodos-Agiles.PDF

http://www.agilemanifesto.org/iso/es/principles.html

http://www.i2btech.com/blog-i2b/tech-deployment/5-beneficios-de-aplicar-metodologias-agiles-en-el-desarrollo-de-software/

http://www.agilemanifesto.org/iso/es/manifesto.html