SOFTENG Agile

Con el objetivo de minimizar riesgos, gestionar cambios de forma eficaz, y ofrecer un servicio de calidad que cumpla con las expectativas de nuestros clientes, SOFTENG utiliza un probado marco metodolgico orientado a procesos. Mediante el mismo, conseguimos alinear a todos los partcipes del proyecto hacia un objetivo comn y claramente definido, por lo que su ejecucin se realiza segn los plazos y costes previstos. Las fases en las que dividimos un proyecto son las siguientes:

Estudio estratgico
Se establece las bases y el alcance del proyecto, as como los recursos necesarios, timing y costes. Trabajamos para comprender el valor que quiere obtener y/o proporcionar a sus clientes, y le ayudamos a descubrir nuevas oportunidades para incrementarlo.

Diseo y arquitectura

Consiste en clarificar los objetivos del proyecto, plantear la estrategia ms adecuada para el desarrollo del mismo, as como describir la funcionalidad a implementar definiendo su alcance. Etapas:

Anlisis funcional: Definicin de los objetivos a alcanzar, y descripcin modular detallada de los requerimientos del proyecto. Anlisis tecnolgico: Seleccin de la tecnologa a aplicar, arquitectura, diagrama de objetos, modelo conceptual y lgico de la BD, y definicin de procesos. Maqueta: Definicin de la lnea

grfica de interfaz. Planificacin: Plan detallado del proyecto, asignacin de recursos y definicin de entregables.
Produccin
Consiste en el desarrollo del proyecto organizado en hitos y entregables y as facilitar a los clientes la posibilidad de revisar la aplicacin a medida que se va construyendo. Etapas: Prototipo, Diseo de interfaz, creacin de la Base de datos, Implementacin, Integracin y pruebas-testeo. Se trata de un proceso que se lleva a cabo mediante ciclos iterativos hasta que el cliente nos da su conformidad.

Control de calidad
Una vez la aplicacin ha sido desarrollada y testeada con xito, pasar por una etapa final de control de calidad previa a la aceptacin del cliente. De esta forma, el software finalizado se entrega al equipo interno de calidad para un profundo testeo, tanto funcional (comparndolo con la documentacin de requerimientos), como tcnico (especialmente de carga y stress, simulando conexiones de usuarios que la usan).

Puesta en marcha
Finalizado el control de calidad y con la aceptacin del cliente, se lleva a cabo la fase de despliegue y puesta en marcha, que a su vez se divide en cinco etapas cuyo orden y mbito depender del proyecto en cuestin: Instalacin del hardware: En caso de que sea necesario, se realizar la instalacin del servidor o clster de servidores. Instalacin del software: Se instalar y configurar el software y, en general, los requerimientos necesarios en servidor para el funcionamiento correcto de la aplicacin. Instalacin de la aplicacin: Migracin desde el servidor de pruebas al servidor definitivo. Migracin de datos: En caso necesario, se migrar la informacin desde el antiguo gestor de base de datos de la organizacin al nuevo servidor. Formacin: El responsable del proyecto prepara la documentacin necesaria, y se encarga de formar a los futuros usuarios para el uso de la aplicacin o para la gestin de contenidos en el caso de proyectos Web. Fase de cierre, inicio de la mejora continua y soporte: Se da por finalizado el proyecto al haberse alcanzado los objetivos consensuados con el cliente, y entra en vigor la garanta. Durante este periodo se pueden analizar ampliaciones funcionales que aporten ms valor aadido al proyecto, o nuevas oportunidades de negocio que desemboquen en futuras colaboraciones. Al finalizar la garanta, entrar en vigor el periodo de soporte y mejora continua.

Gestin del proyecto

Esta fase se realiza en paralelo junto a las dems, y consiste en todas la actividades de gestin necesarias para llevar a buen trmino el proyecto y lograr los objetivos marcados. Estas actividades las lleva a cabo el jefe de proyecto asignado, y consisten principalmente en el control y coordinacin de recursos, costes, tiempos, planificacin, entregables y calidad.

http://www.softeng.es/es-es/empresa/metodologias-de-trabajo/softeng-agile.html

http://www.codecompiling.net/files/slides/IS_clase_13_metodos_y_procesos.pdf

Gestin de Proyectos y Metodologa de Desarrollo de Software

Publicada el 31/01/2012 por Dharma Consulting
2

Panorama General Adems de las metodologas comercialmente disponibles como Prince 2 y Rational Unified Process (RUP), existen muchas metodologas desarrolladas a la medida para organizaciones individuales. Este artculo trata de proveer un mejor entendimiento de las metodologas y cmo stas se pueden desarrollar e implementar. Metodologa de Gestin de Proyectos & Metodologa de Desarrollo de Aplicaciones Es importante diferenciar entre una metodologa de gestin de proyectos y una metodologa de desarrollo de aplicaciones o metodologa de desarrollo de software. Una metodologa

de gestin de proyectos cubre todas las cosas que un gerente de proyectos necesita hacer independientemente de si se trata de un desarrollo de software, una seleccin de paquetes, o una mudanza de su departamento de proyectos. La Gua del PMBOK (Project Management Body of Knowledge Biblia del PMI) cubre nueve reas de la gestin de proyectos, siendo stas las siguientes:

Gestin del Costo Gestin del Riesgo Gestin del Alcance Gestin de los Recursos Gestin de las Comunicaciones Gestin de la Calidad Gestin del Tiempo Gestin de las Adquisiciones Gestin de la Integracin

Como se podr ver, no se menciona nada acerca de requerimientos, pruebas, o seleccin de vendedores. Eso es parte de una metodologa de desarrollo de aplicaciones o metodologa de desarrollo de software. Diferencias entre Metodologas Una metodologa de gestin de proyectos dice que los proyectos deben descomponerse en fases y debe existir un plan definido para cada fase antes de que empiecen. Una metodologa de desarrollo de aplicaciones define que fases sern y que actividades deben de ejecutarse en cada una. Una metodologa de gestin de proyectos dice que hay que definir roles y responsabilidades. Una metodologa de desarrollo de aplicaciones define que roles y responsabilidades habrn en la fase de desarrollo. Una metodologa de gestin de proyectos dice que se debe establecer un presupuesto y que debe ser gestionado adecuadamente. Una metodologa de desarrollo de aplicaciones define cuales deberan ser los cdigos de cuenta para un desarrollo en su organizacin. La metodologa de gestin de proyectos es la estructura de trabajo. Una metodologa de desarrollo de aplicaciones es la carne que colocamos sobre los huesos.

La prueba autntica para diferenciar una metodologa de gestin de proyectos es hacer la pregunta: Podra colocar otra carne sobre los mismos huesos? Por ejemplo, podra tener una metodologa de seleccin de paquetes que podra encajar a la perfeccin en una metodologa de gestin de proyectos. La diferencia est en que contiene un conjunto diferentes de actividades, roles, responsabilidades, riesgos, etc.

Por qu es importante conocer la distincin? Es importante porque cualquier organizacin debe tener una metodologa de gestin de proyectos consistente, la cual sea de uso comn para cualquier tipo de proyecto. De esta manera, el personal puede moverse confortablemente de desarrollo de aplicaciones, a despliegue de infraestructura, a seleccin de software, o incluso mudanzas a nuevos edificios, usando la misma metodologa. Entrenar al personal en gestin de proyectos tiene prioridad antes de que aprendan a desarrollar, seleccionar software, o incluso antes de hacer algn proyecto que no tenga una metodologa definida. Las personas necesitan saber que deben administrar el alcance, y deben saber como hacerlo. Deben saber como elaborar un presupuesto y como gestionarlo. Deben saber como hacer una evaluacin de riesgos y como gestionar los riesgos. Una Metodologa no es una Plantilla

Otra rea de confusin es que las personas entreveran plantillas y metodologas. Cuando se pregunta a la gente si poseen una metodologa, responden Si, tenemos algunas plantillas. Una evolucin tpica para una organizacin que no tiene un modo definido de hacer las cosas es empezar desarrollando plantillas para ganar algo de consistencia en la manera en que se presentan las cosas. En esta fase lo que en realidad se est expresando es: Aqu tienes una lista de cosas que necesitas considerar. La siguiente fase es adicionar algunas instrucciones en la plantilla que expliquen que significa cada seccin. Alternativamente se puede crear una gua de usuario de la plantilla. Finalmente se podra desarrollar un proceso o metodologa que indique a las personas como obtener la informacin que termina en la plantilla. Existen frecuentes confusiones entre plantillas y procesos: Un proceso es un modo de hacer las cosas, ejecutando algunas actividades en una cierta secuencia. Las plantillas se usan para recolectar las salidas de los procesos.

Solo porque se tenga plantillas, no significa que la gente conozca como recolectar la informacin que va en ellas. Por ejemplo una plantilla podra tener una seccin con un encabezado llamado Seguridad. El proceso correspondiente podra ser algo como esto: Discutir el proyecto con el gerente de seguridad de aplicaciones e identificar que acciones se requerirn para satisfacer los estndares corporativos. Revisar cmo el proyecto ser afectado por los nuevos estndares de seguridad a ser introducidos por la arquitectura. Esto se debe hacer en un taller con las

siguientes personas Conversar con la administracin de redes e identificar cualquier implicacin de seguridad de la distribuido Etc. Si slo tenemos disponible una plantilla y no un proceso, la persona que llenar la plantilla quizs no sepa nada de las actividades mencionadas arriba, y al final la seccin Seguridad podra llevar slo la anotacin No aplicable a este proyecto. Esta es la diferencia entre una plantilla y un proceso o metodologa. Qu debe de cubrir una metodologa? con el red. software. Reunirse con Microsoft y discutir cualquier parche de seguridad que pueda necesitar ser

Cualquier metodologa debera cubrir los siguientes tpicos:

Usando

una

Metodologa

Una metodologa no podr ser usada por todos los proyectos que se llevarn a cabo. Habr que

hacer ajustes por muy buenas razones. Esto no significa que la metodologa variar segn el antojo de cada equipo. Se necesitar tener guas especficas sobre un enfoque pragmtico y razonable para cada proyecto. Una investigacin de Gartner Group encontr que una metodologa aplicada con holgura podra mejorar la productividad en un 30%. Aplicarla rgidamente mejorara el producto en solamente 10%. La metodologa debe ser una ayuda para el proyecto, no un obstculo. Si se desea que nuestra organizacin use una metodologa, se necesitar tener algunos expertos a quienes puedan recurrir las personas por ayuda. Objeciones para Usar una Metodologa A continuacin hay algunas objeciones comunes y la forma en que pueden ser manejadas: Reprime mi creatividad? La creatividad no significa Lo har conforme avanzo. Debe significar Poseo un mecanismo de reconocimiento de problemas y uso mi creatividad para resolverlos. En un proyecto la creatividad necesita realizarse dentro un ambiente controlado. A menos que exista una estructura establecida, los cientos de detalles y problemas no podrn ser controlados. Poseo mi propia metodologa Cualquiera de nosotros, que haya trabajado en organizaciones, posee usualmente una metodologa. La razn para usar la metodologa de la compaa es que alguien ms esta operando dentro de esa metodologa. Por lo tanto causar confusin a todos si cada uno usa sus propios procesos. Mi metodologa es mejor Una compaa debe tener un rea responsable para revisar y mejorar metodologas. Ese es el lugar donde se debe promover una nueva metodologa. La metodologa no es aplicable a mi proyecto Si no es as Porqu no? Qu componentes son aplicables, y cmo se pueden incluir otros procesos para unirse a stos. Revise la metodologa de gestin de proyectos, Qu nuevas actividades, roles, etc. necesitan ser desarrollados? La metodologa (o plantilla) tiene mucha informacin

 Trtela como un checklist. Si algo no es aplicable, justifique porqu y haga un comentario. Podra ser una situacin como el tema de seguridad mencionado anteriormente, donde la persona no entiende el proceso en forma apropiada. Existe mucho papeleo Un par de puntos: Primero, pregunt qu informacin est. A veces un pequeo rearreglo de informacin puede resultar en una solucin tipo refirase al documento X, o a un cortar y pegar prrafos. Segundo, es ms barato y fcil desechar papel que cdigo. Los programadores adoran tener sus manos en el teclado, pero es ms eficiente construir algo en papel antes de hacerlo en cdigo. Tercero, examine cada documento y vea si es realmente necesario. Hice este ejercicio con un CFO (Chief Financial Officer) quien hizo un comentario acerca de la cantidad de papel que estbamos generando. Despus de revisar cerca de diez documentos que tena sobre su escritorio, encontr al menos una razn para recibir cada uno de ellos. Todo se deba simplemente a que no estaba acostumbrado a ver agendas, actas o reportes semanales. Implementando una Metodologa

Una metodologa no es una serie de plantillas. Es un proceso que necesita ser adaptado a la medida de cada situacin. Para esto se necesita de alguien con quien el equipo se pueda comunicar, el cual ser el mentor de los equipos en el uso de la metodologa. Una de las implantaciones ms exitosas de una metodologa en la cual he participado, fue la de un departamento de gobierno. Ellos tienen un coordinador de la metodologa a tiempo completo, quien entrena, trabajaba con los equipos, e integra la retroalimentacin dentro de la metodologa. La retroalimentacin es muy importante. La metodologa no permanecer inmvil. Evolucionar volvindose ms aplicable en la organizacin. En este sentido se necesitar un mecanismo establecido que se ocupe del aprendizaje a partir de la experiencia. Proceda de manera gradual. Un cambio radical en el modo en que la gente trabaja no tendr probablemente tanto xito como un cambio progresivo. Si la meta es tener personas elaborando un plan para cada fase, lo mejor ser que empiecen por un solo plan estndar para todo el proyecto. Si decide introducir tres puntos de control para la aprobacin de recursos, introdzcalos uno a la vez. Probablemente encontrar, despus de haber establecido el primer punto de control, que tendr que cambiar tan slo ligeramente su proceso para establecer los otros dos puntos de control.

La disponibilidad es otro asunto a tratar. Pedir a las personas que lean 400 hojas de un manual, no funciona. Proporcionarles un entrenamiento de alto nivel, y presentndoles la informacin en un formato donde puedan encontrar fcilmente la parte que es relevante para la labor que estn realizando, tiene muchas ms probabilidades de xito. Una bien estructurada presentacin va Web, es una condicin indispensable. Las personas necesitan ser capaces de profundizar rpidamente a travs de unos cuantos clicks, para encontrar lo que es relevante para ellos en ese momento. Entrenarlos en el layout del website de la metodologa probablemente tendr mayor impacto que entrenarlos en el detalle de la metodologa. Resumen Colocar algunas plantillas es un buen primer paso, pero no es una metodologa. Asegrese de entender la diferencia entre las plantillas y los procesos. Tambin entienda la diferencia entre una metodologa de gestin de proyectos y otras metodologas. Para muchas personas la metodologa es una palabra sucia. Significa burocracia, papeleo, y restricciones. Se necesita superar esto proveyendo soporte y flexibilidad en la manera de aplicar la metodologa. Todava no he visto una metodologa que tenga xito con tan solo presentar a las personas una serie de libros y plantillas. Finalmente, aprenda a caminar antes de correr. Primero implante pasos simples en la metodologa, dejando lo ms complicado para el final. Comprenda que est tratando de cambiar el modo de pensar y trabajar de las personas. Hay una resistencia al cambio. Aborde el asunto lentamente o se encontrar obteniendo pocos resultados o ninguno. Neville Turbit tiene ms de 15 aos de experiencia como Consultor TI y casi el mismo tiempo en Negocios. Es el director principal de Project Perfect. Project Perfect es una organizacin de consultora y entrenamiento localizada en Sydney, Australia. Su foco es proveer soluciones creativas aunque pragmticas para los problemas dela Gestinde Proyectos. Project Perfect vende el software Project Administrator, el cual es una herramienta que ayuda a las organizaciones a gestionar mejor los riesgos del proyecto, problemas, presupuestos, alcance, documentacin del planeamiento, y programacin de actividades. Tambin ha creado una tcnica para levantar informacin llamada Method H, y vende software para soportar dicha tcnica. Para mayor informacin sobre Herramientas para Proyectos o Gestin de Proyectos visite www.projectperfect.com.au

http://blog.dharmacon.net/articulos/gestion-proyectos-metodologia-desarrollo-software/