Profesional de Ingeniería Informática y de Sistemas –UNSAAC. • Programador Java con 2 años de experiencia. • Integrante de CECI(Circulo de estudio célula informática). • Integrante de la Empresa Dev Art (Developing Art-Desarrollando Arte). • Integrante de Proyecto CANON – Microaprendizaje un nuevo enfoque de enseñanza
mundo de la fabricación y son ampliamente difundidas en el desarrollo de software, las metodologías agiles hoy en día están introduciéndose en toda clase de actividades, y no es algo casual ya que los proyectos que se alargan en el tiempo, que exceden en costes y no cumplen las expectativas no son exclusivos de la industria del software. (Alvarez Garcia, De las Heras del Dedo, & Lasa Gomez, 2012) Debido a los problemas antes descritos es que nace en el año 2001 “El manifiesto Ágil”, donde un conjuntos de autores y personas relevantes del mundo del desarrollo de software se reunieron para plasmar en unos pocos puntos lo que eran las ideas y el sentir general de la industria.
a procesos y herramientas. Aunque todas las ayudas para desarrollar un trabajo son importantes, nada sustituye a las personas, a las que hay que dar toda la importancia y poner en primer plano. Valorar más el software que funciona, que la documentación exhaustiva, ya que se llegó a un punto en el que documentar el trabajo había alcanzado tanta importancia como el producto del trabajo. Valorar más la comunicación con el cliente, ya que la forma más productiva de sacar adelante a un trabajo es establecer un marco de confianza y colaboración con quien nos lo encarga. Valorar más la respuesta a un cambio, se trata de apreciar la incertidumbre como un componente básico del trabajo, por lo que la adaptación y la flexibilidad se convierten en virtudes y no en amenazas.
soporte a la innovación basándose en equipos auto-gestionados. Con Scrum se obtiene el mínimo viable en cada iteración, estas iteraciones cortas (entre una y cuatro semanas) son llamadas Sprint” (Alvarez Garcia, De las Heras del Dedo, & Lasa Gomez, 2012)
en iteraciones llamadas Sprint, cada iteración termina con un producto entregable. Al finalizar cada iteración, este producto se muestra al cliente para que opine sobre él. El equipo se reunirá para analizar la manera de como se está trabajando unido “el que” se ha hecho y “como” se ha hecho, así de esta forma se aprenderá con la experiencia y se mejorara iteración tras iteración. (Alvarez Garcia, De las Heras del Dedo, & Lasa Gomez, 2012) Auto-organización y colaboración: El equipo se gestiona y organiza a sí mismo. Esta libertad implica asumir una responsabilidad y un gran nivel de compromiso por parte de todos. Los líderes y clientes colaboraran con el equipo de desarrollo en todo momento facilitando el trabajo, resolviendo dudas y eliminando posibles impedimentos. (Alvarez Garcia, De las Heras del Dedo, & Lasa Gomez, 2012) Priorización: Tener los requisitos perfectamente priorizados, para no perder el tiempo y dinero en algo que no interesa inmediatamente en el producto. Mantener un ritmo: Este ritmo marcara la pauta del trabajo y ayudara a los equipos a optimizar su trabajo, este ritmo aumentara hasta que el equipo llega a un punto que es su ritmo constante en cada Sprint, lo cual sirve para ver cuánto se puede hacer en cada Iteración del Back Log.
guiándolo para que cumpla las reglas y procesos de la metodología. Gestiona la reducción de impedimentos del proyecto y trabaja con el “Product owner” para maximizar la velocidad. (Softeng, 2018) Product Owner: Representante de los accionistas y clientes que usan el software. Gestiona el “Gestiona el Product BackLog” Equipo: Grupo de profesionales con los conocimientos técnicos necesarios y que desarrollan el proyecto de manera conjunta llevando a cabo “las historias de usuario” a las que se comprometen al inicio de cada Sprint.
de trabajo de git que fue popularizado por Vincent Driessen en nvie. Este concepto no agrega ningún concepto o comando nuevo adicional. En cambio asigna funciones muy especificas a diferentes ramas y define como y cuando deberían interactuar. Para poder hacer el GitFlow podemos utilizar una librería independiente que se instala llamada “git-flow” el cual lo podemos encontrar en su página web para los diferentes sistemas operativos.
solo “Master” rama, este workflow utiliza dos ramas para almacenar la historia del proyecto, la rama “Master” almacena la historia de las versiones oficiales del proyecto, y la rama “Develop” sirve como una rama de integración para las diferentes ramas “feature”. Tambien es conveniente etiquetar todas las confirmaciones en la rama “Master” con un numero deversion. El primer paso es complementar la rama por defecto “Master” con una rama “develop”. Una manera simple de hacerlo es crear una rama vacio “develop” localmente y hacer un push al servidor. Git branch develop Git push –u origin develop
característica debe residir en sus propias ramas, los cuales deben ser “pushed” subidos al repositorio central para backup o colaboración. Pero en vez de bifurcar de la rama “Master”, las ramas “feature” bifurcaran de “develop” como su rama padre. Cuando una característica es completada, esta se unira mediante “merge” con la rama “develop”. Las ramas “feature” nunca deben interactuar directamente con la rama “master”. Git checkout develop Git checkout –b feature_branch
el trabajo de desarrollo de una característica, el siguiente paso es unir “merge” la rama “feature” con la rama “develop”. Git checkout develop Git merge feature_branch
rama “develop” ha adquirido suficientes características para un lanzamiento o la fecha de lanzamiento esta cerca, tenemos que crear una nueva rama “release” que bifurcara de la rama “develop”. Al crear esta rama comienza el siguiente ciclo de lanzamiento, ninguna nueva característica puede ser agregada para este lanzamiento, solo corrección de bugs, generación de la documentación y tareas orientadas al lanzamiento deben de ir en esta rama. Una vez que ya esta listo para el lanzamiento, esta rama será unido “merge” con la rama “master” etiquetado con un numero de versión. Adicionalmente este también debe de ser unido con la rama “develop” el cual debe de tener un progreso desde que la rama “release” fue inicializado.
errores rápidamente, las ramas “HotFix” son similares a las ramas “release” y “feature” excepto que la bifurcación no se hace de la rama “develop” sino de la rama “master”. Esta es la única rama que esta basada directamente de la rama “master”. Tan pronto como se completa el HotFix, este deberá ser unido con la rama “master” y “develop”, y la rama master debería ser etiquetado con una actualización en el número de versión.
jyouryuusui
moznion
sudoakiy
takuroabe
grimoh
takonda
codmoninc
kash1064
pfn
kworkdev
akhino
prog893
notwaldorf
signer
reverentgeek
rocio
aleyda
jonoalderson
rasagy
palkan
hatefulcrawdad
tammyeverts
mongodb
wjessup
