SILVA, Francisco Eronildo da [1]
PINTO, Aurílio Guimarães [2]
FREITAS, Caio Guimarães [3]
ALMEIDA, Cristiany Caliri de [4]
RIBEIRO, Dallas dos Santos [5]
LEITE, Francisco Canindé da Silva [6]
OLIVIERA, Geveson de Souza [7]
MORAIS, Gilvanete Melo de [8]
PERES, Paulo Júnior de Jesus [9]
SILVA, Francisco Eronildo da; et.al. Aplicabilidad de la metodología ágil de desarrollo de Software, Scrum como referencia. Revista científica multidisciplinaria base de conocimiento. Edición 07. año 02 vol. 03. PP 05-16 de octubre de 2017. ISSN: 0959-2448
Resumen
Este estudio pretende analizar la velocidad que las metodologías ágiles dan el proceso de desarrollo de software, que muestra cómo las empresas utilizan estos métodos como una manera de reducir tiempo y esfuerzo en desarrollo de software, tomando como referencia la metodología SCRUM. La metodología ágil parte de la premisa de que los resultados deben alcanzarse rápidamente sin comprometer la calidad del producto final (software), por consiguiente el SCRUM es una metodología que tiene como objetivo mejorar la planificación de proyectos de software cuya premisa es el producto se romperá en pedazos más pequeños y así entregar la funcionalidad sin cliente espera demasiado tiempo para verlas. Entre los autores de la Constitución de este trabajo ha buscado, conceptual destaca Aragón Fernandes (2014), Somerville (2007), Roger Pressman (2011), Kim Pries (2010) y Ken Schwaber (2014). Las conclusiones más importantes son que el uso de las metodologías ágiles puede dar desarrollo de software rápido, mostrando más efectividad, dinamismo y ofrecer ventajas a las empresas que adopten la metodología, estos hechos, demostradas en este trabajo.
Palabras clave: Agile, Scrum, gestión, ingeniería de Software.
1. Introducción
El ágil empezó a tener un énfasis en los años 80. El sitio DEVMEDIA afirma: "metodologías ágiles han estado alrededor por años, desde los años 80, pero cierta información va a través de la distorsión, que hace difícil en un principio el uso de metodologías. Por lo tanto, los desarrolladores han llegado a comprender la metodología ágil como algo que puede, en otras palabras, podemos desarrollar sin documentación, sin defecto y sin cuidado. Esto no es cierto, las metodologías ágiles pueden traer éxito al proyecto y se utilizan en la industria". Este trabajo demuestra que la muerte ágil basado en autores reconocida la organización y el cuidado necesario que el proyecto de software necesitan ser eficientes y eficaces, y cada día, Obtén el desarrollo de software del mercado, se utiliza en las industrias y organismos públicos que contratan fábricas subcontratados para el desarrollo de sus sistemas.
Este estudio se limita para mostrar los beneficios ágil aporta al desarrollo de software. Por ejemplo si tienes el modus operandi de las CTIS, empresa de software que opera en el mercado interno y la adopción de la metodología de desarrollo de software común, sino que depende del cliente, optando por la metodología ágil.
La Superintendencia de la zona de libre comercio de Manaus-SUFRAMA, que, a través de licitación, contrató el servicio de CTIS y optó por el traslado a metodología ágil.
SUFRAMA es una autoridad federal responsable de administrar incentivos fiscales. La mayoría de sus sistemas crítica y funciona con limitaciones, así que oferta el servicio de fábrica de software para trabajar con metodologías ágiles. La opción de métodos ágiles en razón de la entrega rápida y calidad porque la tradicional engessava la metodología del proceso.
El método ágil se distribuye con una pila de papel, se centra en la calidad del producto, porque lo que importa al cliente es el trabajo de software.
Es esto no entrar en los detalles del cambio en la metodología adoptada por la SUFRAMA y sí, ilustrar que diversos sectores y agencias gubernamentales, están optando por el cambio de su modelo de desarrollo de software para metodología ágil.
A pesar de ser una opción para el desarrollo de software, metodología ágil, que ofrece varias ventajas para el desarrollo ciertamente puede no ser conveniente para todos los proyectos. Para una mejor comprensión del tema, debería revisar algunas de la historia del desarrollo ágil.
El objetivo general de este trabajo es hacer una revisión sistemática de la metodología ágil. El método SCRUM será el objeto de este estudio, donde estarán listados los negativos y positivos.
Esta investigación se justifica por la necesidad de que la industria del software tiene para llevar a cabo las entregas de productos con el menor tiempo posible a sus clientes, sin perder de vista la calidad, economía y satisfacción.
La metodología de este estudio es la investigación descriptiva y explicativa, como la recolección de datos bibliográficos.
2. Desarrollo
Este estudio comienza por revisar el concepto de Software que originalmente fue propuesto en 1968, en una conferencia organizada para discutir lo que luego se llamó la "crisis del software". La crisis del software dio lugar indirectamente a la introducción de un nuevo hardware basada en circuitos integrados. La aplicación de los circuitos integrados de aplicaciones informáticas, considera las propuestas no es factibles y viables. El software resultante era mayor y más complejo que el anterior software de sistemas (SOMMERVILLE, 2007).
Ingeniería de software es una rama de la ingeniería, cuyo objetivo es desarrollar dentro de los sistemas de software de alta calidad coste adecuado. Ingeniería de software es una tecnología de capas, herramientas, métodos, proceso y enfoque en la calidad. (SOMERVILLE, 2007). Cualquier enfoque de ingeniería (incluyendo software) debe estar basada en un compromiso organizacional con la calidad.
Total gestión de la calidad seis Sigma1 (GYGI; DECARLO; WILLIAMS, 2008) y las filosofías similares fomentan una cultura de procesos de mejora continua y es esta cultura que, al final, conduce al desarrollo de enfoques cada vez más eficaces en la ingeniería de Software. La piedra angular que soporta la ingeniería de software es el enfoque en la calidad (PRESSMAN, 2011).
Con respecto a la historia del desarrollo ágil, la misma comenzó en 2001, con el "manifiesto para desarrollo ágil de software", que fue firmado por Kent Beck, un ingeniero de software estadounidense, creador de Extreme Programming y Test-Driven y dieciséis más célebres desarrolladores. Detalles de este hecho pueden ser verificados en la dirección https://www.agilealliance.org/agile101/the-agile-manifesto/.
El manifiesto destaca individuos e interacciones sobre procesos y herramientas; el software se ejecuta más de una completa documentación, colaboración con el cliente en lugar de las negociaciones de los contratos y las respuestas al cambio sobre seguir un plan.
Esto no quita la importancia de la documentación o procesos y de ninguna manera se relacionan con la ineficacia de las herramientas, medios, sin embargo, que la entrega del software es más valorada, como declarar Pressman:
"La ingeniería de software ágil mezcla la filosofía con un conjunto de principios de desarrollo. La filosofía promueve la satisfacción del cliente y la entrega de antes incremental; equipos de proyecto pequeños y altamente motivado; métodos informales; artefactos de ingeniería de software mínimo y, sobre todo, sencillez en el desarrollo general. Los principios de desarrollo de priorizar la entrega de más de análisis y diseño (aunque estas actividades no son recomendables); también priorizar la comunicación activa y continua entre desarrolladores y clientes ". (Pressman, 2011)
Un proyecto involucra personas y cambios, especialmente cuando se trata de entregas. De esta manera las metodologías ágiles trabajando con equipos altamente motivados, porque están relacionados directamente con el proceso involucrado en cada parte de él, sintiendo la responsabilidad sobre sí mismo el éxito del trabajo y saber que tienes la posibilidad de apoyar los cambios durante todo el proceso de desarrollo.
En el desarrollo ágil, no se puede hacer un plan completo con todo lo que debemos realizar para luego iniciar el desarrollo, sin contacto con el cliente, en cambio, desarrolló incrementalmente, es decir, el producto se hace poco a poco y constantemente luz de esta manera, cualquier cambio necesario solicitado por el cliente o visto por los miembros del proyecto, en cualquier momento durante el desarrollo, no se dañará y el cambio puede realizarse sin grandes daños, porque el proyecto está en desarrollo y no se ha completado.
Los incrementos iniciales del sistema pueden proporcionar una función de alta prioridad, para que los clientes pronto pueden obtener valor para el desarrollo de su sistema. Los clientes pueden ver los requisitos en la práctica y especificar cambios a ser incorporados en las versiones posteriores del sistema.
De esta manera, el cliente puede hacer uso de los recursos del sistema más rápidamente. Lo que llevaría meses para entregarse en semanas, verificar errores y especificar nuevos cambios o mejoras, sin necesidad de llegar hasta el final del desarrollo para ver los problemas.
Esta metodología también proporciona un mayor conocimiento del sistema para el equipo, ya que entiende el negocio a desarrollar, lo que es, con mayor velocidad y precisión, y en caso de errores, el equipo perderá menos tiempo para el análisis y puede corregir el error rápidamente.
Según Aguinaldo Aragón Fernandes (2014), inicialmente, el Scrum fue diseñado con fuerte foco en la entrega de proyectos de desarrollo de software en un entorno complejo. Sin embargo, se ha aplicado cada vez más en proyectos de desarrollo de producto de otras naturalezas ".
Aragón también afirma que:
"El Scrum consiste en el método iterativo e incremental para la gestión de proyectos complejos, cuyo objetivo es asegurar el suministro más rápido y maximizar la adherencia a los requisitos del cliente, la cooperación entre los miembros del equipo y la productividad de cada participante. Es uno de los métodos de supuesto "ágil" más extendido en la it mercado, (Aragón Fernandes 2014).
Metodologías ágiles se pueden aplicar en la resolución de problemas complejos, tales como desarrollo de software informa Schwaber:
"Proyecto complejo situaciones ocurren cuando la complejidad de las actividades intermedias no permite un proceso definido controlado, puede generar un producto de bucle en niveles aceptables de calidad. La complejidad de un proyecto es directamente proporcional a la complejidad de los requisitos de los clientes y la tecnología implicada, ale a ser depende en gran medida de las características de cada miembro del equipo, teniendo en cuenta la diversidad de aptitudes, conocimientos, actitudes etcetera, que puede encontrarse en cualquier grupo de personas ". Schwaber (2004)
En situaciones como ésta, Schwaber recomienda utilizar el concepto de control de proceso empírico, que utiliza mecanismos tales como uno mismo-organización y sentido de urgencia con los siguientes pilares:
"Visibilidad: todos los aspectos que afectan los resultados deseados deben ser visibles para el control de los procesos.
Inspección: los diversos aspectos del proceso deben pasar a través de inspecciones periódicas para detectar variaciones inaceptables.
Adaptación: el proceso o sus productos intermedios deben ajustarse después de la inspección para reducir al mínimo las desviaciones futuras más severas, caso características y los resultados están fuera de los límites aceptables y poner en peligro la aceptación del producto final. Schwaber (2004)
El Scrum está estructurado en un conjunto de prácticas realizadas por equipos en roles específicos, organizados en una secuencia de actividades o eventos de duración fija, totalmente controlados con artefactos y reglas bien definidas, cuyo objetivo es obtener productos usables a intervalos corto de tiempo.
Cada prácticas de Scrum se basan en un "esqueleto" representado por iteraciones sucesivas de las actividades de desarrollo, (cada uno generando un aumento del producto), inspeccionadas y ajustadas diariamente por los miembros de su propio personal y orientada para una lista de requerimientos iniciales.
Al principio de cada iteración, el equipo de comentarios sobre lo que debe hacerse y determina qué funcionalidad viable para ser entregado al final de la iteración. El equipo es libre de usar su mejor esfuerzo en el resto de la iteración y características a finales el producto final construido.
La siguiente figura muestra el flujo de Scrum:
En un proyecto Scrum, todas las responsabilidades se dividen entre tres funciones:
ProductOwner: persona responsable de administrar el producto (para asegurar que es visible a todos), generar y difundir los requisitos del proyecto, así como el plan de entregas sucesivas, dando prioridad a los resultados que traerán mayor valor añadido al proyecto.
Scrum Master: responsable de implementar el método Scrum, así como enseñar a todos los involucrados en los proyectos y asegurarse de que todos siguen las normas y prácticas.
Scrum team: Grupo de desarrollo colectivamente responsable por el éxito de cada iteración y el proyecto en su conjunto, debe compuesto de personas multidisciplinares capaces de auto organización y autogestión.
El proceso preconizado por Scrum cubre los siguientes elementos como se muestra a continuación:
La visión: debe ser preparado por el ProductOwner, incluyendo notas y plan de cada Sprint, los hitos de entrega de producto con el fin de maximizar el retorno de la inversión del proyecto de desarrollo de producto.
El Backlog de producto: también preparado por el ProductOwner, contiene una lista de los requisitos funcionales y no funcionales, priorizados y divide en lanzamientos (Sprints).
La reunión de planificación de Sprint: el proyecto se divide en Sprints duran treinta días naturales, a ser realizados uno tras otro, sin interrupción. La planificación se realiza en una reunión con la participación del equipo Scrum y ProductOwner, en dos periodos de 4 horas cada una:
En la primera hora es que el alcance ("qué") será tratado por Sprint, a través de la selección de los requisitos de acumulación de producto que se colocará en el Sprint Backlog.
En 4 horas de retraso, la planificación real de las tareas a realizar en el Sprint, ("cómo") y el comienzo oficial del Sprint, en que tiempo empieza a correr el plazo de 30 días.
Sprint: el producto desarrollo iteración, que tiene una duración fija. Un Sprint incluye sus reuniones de planificación, revisión y retrospectiva.
El Scrum diario: reunión diaria de quince minutos, donde cada miembro del equipo contesta las siguientes preguntas:
- ¿Lo que hice en el proyecto desde el Scrum diario pasado?
- ¿Lo que estoy planeando hacerlo hasta el próximo Scrum diario?
- ¿Es cualquier restricción o impedimento al que honro mi compromiso del Sprint actual o el proyecto?
Además, el equipo sincroniza todas las actividades y reuniones de programa necesarias para la continuación del proyecto.
Detallando un poco más vistas de partidos hasta ahora.
Reunión de revisión del Sprint: en 4 horas, el equipo Scrum presenta el ProductOwner (y otras partes interesadas) el trabajo generado en Sprint y determina entre ellos qué hacer en el siguiente Sprint.
La reunión retrospectiva de Sprint: en 3 horas, el Scrum Master anima a los miembros del equipo para revisar el desarrollo proceso de su nacimiento prácticas y modelo de proceso de Scrum, con el fin de hacerla más eficaz y gratificante para el siguiente Sprint de Scrum.
Según Schwaber (2004), el Sprint planificación reuniones Scrum diario, revisión y retrospectiva del Sprint son, juntos, las prácticas de inspección empírica y adaptación del Scrum.
Hay dos categorías de artefactos en el contexto del Scrum: la cartera de pedidos tablas y gráficos que muestran el trabajo que falta todavía hasta el final (llamado BurndownCharts).
Los retrasos son tablas: producto Backlog consiste en un documento "vivo" desarrollado y mantenido por ProductWoner que, por definición, nunca es completo (ya que siempre hay mejoras a ser implementadas en un producto hasta que finalmente se retira de circulación). Contiene una lista de todos los cambios que se harán en el producto para futuras versiones (características, funciones, tecnologías, adaptaciones, mejoras, correcciones, etcetera). tales requisitos están ordenadas por prioridad y detallados en términos de atributos de descripción, ajustes de factores complejos y cálculos (de esfuerzo y plazo) a lo largo de los Sprints futuros.
Sprint Backlog: define las tareas que debe realizar el equipo Scrum para crear incrementos de producto (de la cartera de pedidos de productos) durante la ejecución de un Sprint. El sus datos deben ser suficiente para que ser acompañado en las reuniones de la Dario de Scrum, en tareas que duran entre cuatro y 16 horas.
Cada tarea debería documentarse, al menos en términos de su responsable, el estado (no iniciado, en proceso, terminado) y la cantidad de horas de trabajo restante todos los días del Sprint.
El BurndownCharts Mostrar, gráficamente, la cantidad de trabajo total (otras actividades) con el tiempo, reflejando su correlación con los avances de los equipos de proyecto en la reducción de su trabajo. Puede ser utilizado en el contexto del producto (incluyendo todos los Sprints) la cartera o dentro de cada uno de los Sprints (Sprint Burndow).
El Scrum, como se mencionó anteriormente, fue creado originalmente para el uso en proyectos de software en entornos complejos, es decir, donde los requerimientos cambian con cierta frecuencia, que puede tener su alcance o su estructura de desglose del trabajo o WBS EAP proyecto organizado y estructuradas en paquetes de artefactos gradual, consistente y utilizables, para ser entregadas al cliente en períodos sucesivos de quince a treinta días cada uno.
Al principio este concepto es perfectamente aplicable a cualquier proyecto o programa cuyo objetivo es el desarrollo de productos o servicios de otra naturaleza, o incluso que consiste en iniciativas de mejora mediante el uso de metodologías Lean, Six Sigma, etcetera. En Resumen, el Scrum es un método recomendado, que ha demostrado la aplicabilidad fuerte, para proyectos que requieren la combinación de habilidades y conocimientos enfocados a un equipo y que implica esfuerzos de colaboración.
Segundo Pries y Quigley (2010) allí son maneras de adaptar el Scrum para su aplicación en diversos tipos de programas y proyectos complejos, tales como:
La combinación con los métodos tradicionales de gestión de proyectos: puede conectar conceptos y artefactos, como producto Backlog, ganado análisis de valor, el BurndowsCharts y el Plan de comunicación, control de reuniones y WBS (estructura de desglose de trabajo) Sprints (planificación, diario, informe, retrospectivas) etcetera.
Gestión de programas complejos: adopción de un Scrum de Scrum, donde la acumulación de producto puede dividirse en los retrasos, cada uno que se consume por su respectivos Scrum Team.
Conocimientos en áreas funcionales que sirven varios proyectos (por ejemplo, equipos de prueba o garantía de calidad): en el producto Baclog, puede venir en varios diseños y tareas en la cartera de pedidos en un Spint, esas tareas que caben dentro de los treinta días.
Combinado con la tecnología en forma de "cascada": se puede dividir el programa en modelo de duración fija, con el fin de sincronizar, por ejemplo, una secuencia de Sprint con un jalón (jalón) prevista en el proyecto, así como tuvieron las actividades de verificación y validación de la forma evolución en cada Sprint.
La combinación con el enfoque de Six Sigma: usted puede envolver cada una de las fases de la metodología DMAIC (definir, medir, analizar, mejorar, controlar) en un Sprint corriendo uno tras otro.
Schwaber (2004) menciona la posibilidad de utilizar el Scrum en un contexto de precio y contrato de duración prefijado. En estos casos, el Backlog de producto puede utilizarse no sólo para demostrar a los clientes que eran entendidos los requisitos, pero también entendió la prioridad de cada uno para la generación de valor. Los requisitos más relevantes pueden ser seleccionado para los primera pocos Sprints y los incrementos en la funcionalidad fiable cada reunión de seguimiento.
Es importante subrayar que la adopción de Scrum en una organización debe hacerse con criterio y que hay muchos desafíos que afrontar.
Vamos a conectar algunos de los puntos que, si no son bien administrados, pueden poner en peligro la efectividad de la metodología Scrum:
Es imprescindible contar con un equipo eficiente grupo de trabajo ya que el éxito del trabajo depende de un esfuerzo intensivo en las habilidades que cada uno tiene como un diferencial;
Es importante que cada miembro del Scrum tiene un fuerte sentido de autogestión.
Asegúrese de que los miembros del equipo son asignados a un único proyecto.
Debe asegurarse el compromiso de todos los involucrados (especialmente de aquellos que representan al cliente).
Debe asegurarse de que los retrasos están bien documentados, por lo que hay no hay malentendidos entre las personas involucradas.
Puede haber algunas dificultades para "atomizar" las tareas en cada línea de la sobrecarga de trabajo, así como establecer las dependencias entre ellos, que pueden afectar la planificación y el buen progreso en la implementación de los Sprints.
Debe asegurarse de que todas las reuniones (planificación, diario, informe, retrospectivo) de las carreras se llevan hacia fuera y que el fijo veces efectivamente se cumplan, a riesgo de dañar el sentido de la disciplina, que es crucial para el éxito del método.
Conclusión
Antes de las citas de diversos autores, es notorio para agilidad y velocidad que las metodologías ágiles, en particular el SCRUM, elegido para ilustrar en esta obra, dan empresas que contratan fábricas de software.
Entre las ventajas, podemos destacar: mayor agilidad en el control y manejo de los avances de obra, énfasis en el trabajo en equipo y enfoque en resultados rápidos, responsabilidad compartida con el grupo que causa un mayor sentido de compromiso, entregas más rápidas y eficiencia, acortar retroalimentación haciendo hincapié en la comunicación y aumentar la satisfacción del cliente por tener el tiempo de entrega de software reducido, sin perder la calidad y mayor beneficio de la empresa.
Referencias
FERNANDES, A. A.; ABREU, V.F.: Implementación de la gobernanza, 4to ed., São Paulo, SP: Brasport libros y publicación multimedia empresa Ltd. de 2014.
PRESSMAN, enfoque profesional de r. 2011 A ingeniería de Software. Traducción Ariovaldo Griesi, Mario Moro Fecchio. 7 º ed.-São Paulo, SP: MGH Editora Ltda, 2011.
PRIES, H. Kim, QUIGLEI, Jon M. Scrum gestión de proyectos. CRC Press, 2010
SOMMERVILLE, i. Ingeniería de Software. 8. Ed. São Paulo, Pearson Addison Wesley, 2007.
SCHWABER, Ken. Gestión de proyectos ágiles con Scrum. Microsoft Press, 2014.
El manifiesto ágil. Disponible en: <https: www.agilealliance.org/agile101/the-agile-manifesto/="">. Consultado el 21 de octubre de 2016.</https:>
Manifiesto para desarrollo ágil de Software. Disponible en: <http: www.manifestoagil.com.br/="">.</http:> Consultado el 21 de octubre de 2016.
Un resumen de la metodología ágil. Disponible en: <http: www.devmedia.com.br/uma="" visao-geral-sobre-metodologia-agil/27944/="">.</http:> Consultado el 21 de octubre de 2016.
[1] Licenciado en Ciencias de la computación, actúa como un servidor público de la SUFRAMA, como analista administrativo-te.
[2] Licenciado en Ciencias de la computación, actúa como un servidor público de la SUFRAMA, como analista administrativo-te.
[3] Licenciado en Ciencias de la computación, actúa como un servidor público de la SUFRAMA, como analista administrativo-te.
[4] Se graduó en administración de empresas, actúa como servidor público de la SUFRAMA, como administrador.
[5] Licenciado en Ciencias de la computación, actúa como un servidor público de la SUFRAMA, como analista administrativo-te.
[6] Licenciado en Ciencias de la computación, actúa como un servidor público de la SUFRAMA, como analista administrativo-te.
[7] Licenciado en Ciencias de la computación, actúa como servidor de la SUFRAMA, analista administrativo-te.
[8] Licenciado en economía, actúa como servidor público de la SUFRAMA, como economista.
[9] Licenciado en Ciencias de la computación, actúa como un servidor público de la SUFRAMA, como analista administrativo-te.
