Documente Academic
Documente Profesional
Documente Cultură
Resumen
Tradicionalmente las empresas desarrollan software aplican el enfoque de ciclo
de vida secuencial conocido normalmente como en cascada. Este enfoque
presenta un estado deficitario, respecto al cumplimiento del presupuesto y
plazo, debido a que las actuales caractersticas del software son de entorno y
convergencia hacia Internet. Hoy se debe considerar la evolucin de los
requerimientos a travs de todo el ciclo de vida. Los Procesos giles de
desarrollo de software tratan de resolver este problema. Este artculo
particularmente presenta la aplicacin de la metodologa Scrum en el
desarrollo de un sistema, aplica las procesos aborda las actividades principios
de Scrum las pautas bsicas y valida las buenas prcticas de esta metodologa.
En el desarrollo del software, los integrantes de este artculo tienen
conocimiento de previos de todo los procesos del sistema y de la metodologa
Scrum que finalmente se obtiene un software producto de la aplicacin de esta
metodologa que efectivamente se valida la metodologa.
Palabras claves
Metodologa, Software, SCRUM gil
Introduccin
Metodologas giles de desarrollo de software son una respuesta los llamados
metodologas pesados o metodologas Tradicionales. Incluso con la evolucin
de computadoras, reduccin tcnica y herramientas de ltimos aos, la
produccin de software de confianza, correcta y entregado a tiempo y costos
estipulados sigue siendo muy difcil. Datos de 1995 [2], utilizando como base
de 8.380 proyectos muestran que slo el 16,2% de los proyectos fueron
entregados respetando los plazos y los costes y todos los funcionalidades
especificadas. Aproximadamente el 31% de los proyectos fueron cancelados
antes de ser completados y el 52,7% fueron entregados, pero con mayores
plazos, costos ms altos y con menos funcionalidad especificado al principio
del proyecto. Entre los proyectos que no fueron finalizados de acuerdo con los
plazos y costos especificados, la demora media fue de 222%, y el valor
promedio fue 189% mayor de lo previsto. Teniendo en cuenta todos los
proyectos que fueron entregados fuera de plazo y costo mayor, en promedio,
slo el 61% de las funcionalidades originales fueron incluidas. Los mismos
proyectos cuya entrega se realiza respetando los lmites de plazo y costo
poseen calidad sospecha, ya que probablemente eran hecho con mucha
presin sobre los desarrolladores, que pueden cuadriplicar el nmero de
errores del software, segn el mismo investigacin. Las principales razones de
estas fallas estaban relacionadas con el proceso o metodologa de cascada. La
Metodologa
Los alumnos de la carrera de ingeniera de sistemas de la Universidad de
Nacional Tecnologa de Lima Sur (UNTELS) desarrollaron el sistema acadmico.
Todos los participantes de este proyecto del sistema acadmico asistieron a
una leccin impartida por el docente del curso ingeniera de software donde se
presentaron algunos fundamentos del desarrollo de software gil, y Scrum.
En el transcurso de duracin del curso acadmico el docente orden formar
grupos de alumnos por afinidad para asignar trabajos de las diferentes
metodologas de desarrollo de software, posteriormente se este grupo de
trabajo se form y se le asign la metodologa Scrum, de inmediato los
participantes del grupo investig y averiguo las diferentes fuentes
acadmicos libros, paper, video, artculos, revistas, publicaciones en la web, etc
respecto a la metodologa Scrum, luego estos fuentes acadmicas fueron
revisados y seleccionados previamente por el doctorado del curso,
posteriormente estos artculos son estudiados por todos los integrantes. Sin
esperar demasiado, se decidi discutir los requerimientos del sistema con una
lluvia de ideas desarrollados en clase con todos los alumnos del curso,
seguidamente todos estos requerimientos fueron clasificados por mdulos de
inmediato los integrantes del grupo de trabajo se decidi iniciar el primer
Sprint con una duracin de dos semanas, utilizando el conjunto de
requerimientos en los cuales se estaba trabajando en ese momento, para
alimentar el Product Backlog.
El primer cambio que provoc esta decisin fue eliminar al Lder de
Proyectos. Es decir, eliminar todo ese concepto de jefe del grupo, cuyo
nico inters es hacer cumplir con las fechas estipuladas en las grficas de
Gantt, sin detenerse a pensar por un momento siquiera en el bienestar del
equipo. Fue un cambio radical de mentalidad: ahora el jefe del grupo se
transform en benefactor. Dej de existir el jefe que mira a sus subalternos
desde su pedestal para convertirse ahora en un miembro efectivo del equipo,
que trabaja hombro con hombro con los dems integrantes para construir el
proyecto, ayudando a eliminar los obstculos que limitan el avance y
promoviendo un ambiente armonioso de trabajo. Ahora, cada miembro del
equipo poda expresarse de manera abierta y confiada, sin temor a
reprimendas; y, a diferencia de otras ocasiones, ahora reciba ayuda del Scrum
Master para buscar la mejor solucin al problema.
En el daily scrum, los miembros del equipo se informaban entre s en qu
haban trabajado el da anterior, en qu trabajaran el da corriente y si tenan
algn problema que les impeda avanzar en la tarea. En caso de que as fuera,
el SM ayudaba a encontrar la solucin.
El primer entregable fue desarrollado por el scrum team dirigido por Franklin,
con la finalidad de la creacin de una base de datos y una aplicacin que
actualice los datos de los estudiantes de la sistema de matrcula.
Bibliografa
(1) Una gua para el CONOCIMIENTO DE SCRUM (GUA SBOK) 2013 Edicin
(2) Standish Group, CHAOS report, 586 Olde Kings Highway, Dennis, MA
02638, USA, (1995)
(3) Cockburn, A. e Highsmith, J. "Agile Software Development: The Business
of Innovation", IEEE Computer, Sept.,(2001), pp. 120-122
(4) B. Meyer, Software Enginnering on Internet Time, IEEE Computer, Vol. 34,
N35, May 2001.