martes, 26 de junio de 2012

primera entrada


Administración de proyectos de software

Nuestro equipo esta formado por los integrantes Carlos Santiago Serrano Ramírez, Ricardo Lopez Porras,  Benjamín Valdez Morales (Gerente de proyecto).

Seleccionamos  el método lean Software development para comprobar este decidimos trabajar en un proyecto llamado “mascota virtual” donde el usuario podrá interactuar con las mascota atendiendo las necesidades de la mascota como comer, tomar agua, jugar con el mascota   etc.
Para comenzar nuestro método estuvimos investigando en diferentes partes ajenas a Wikipedia donde encontramos  puntos clave para poder comenzar el proyecto.

Tomando en cuenta  el libro de “Lean Software Development: An Agile Toolkit” por Mary Poppendieck, Tom Poppendieck .  Donde  tenemos 8 capítulos para conocer los principios que debemos de seguir para utilizar LSD.

Eliminar desperdicios (Eliminate waste):
Esto se refiere a que debemos de buscar los lugares donde desperdiciamos tiempo como:
Trabajo parcialmente hecho, procesos extra, características extras, estar cambiando de tareas, esperando, movimiento, defecto. Cada de una de estas herramientas nos relata como podemos ver donde se esta desperdiciando nuestro tiempo como agregar características extras que nuestro cliente no ha solicitado ó que los programadores estén cambiando las tareas para que terminen mas “rápidamente” eso no, hace que se termine de una manera mas rápida si no seria el mismo tiempo o un poco más.

Amplificar el aprendizaje (Amplify Learning):
Este principio se refiere a que en el proceso de desarrollar software se debe dar cabida a la variabilidad para aprovechar los errores que surjan ya que aportan conocimiento sobre los límites del producto para hacer esto los autores recomiendan usar el método científico y algo que ellos llaman “inténtalo, pruébalo, arréglalo” ya que este método produce una gran cantidad de información o en otras palabras retroalimentación.

Decidir los más tarde posible (Decide as late as posible):
Este a hace referencia a que entre más tarde se haga la decisión sobre algún cambio en un proceso, o código será mejor debido a que la solución correcta a flota más claramente al final por así decirlo, aunque de igual manera es recomendable tener opciones ya sea en caso de que sea correcta la decisión y en caso de que no lo sea para tomar medidas de minimización de daños.

Entregar tan rápido como sea posible (Deliver as Fast as Possible):
Para algunos esto significa que debes de atrasar las decisiones del cliente para otros rápida gratificación para el desarrollo del software significa incrementar la flexibilidad del negocio.
Para poder aprovechar nuestro tiempo al máximo debemos de saber que están haciendo nuestras gentes, cuando los programadores terminan su trabajo ya no saben que hacer y para esto es mejor hacer un horario principal, la asociación lean recomienda hacer una junta una vez a la semana para poder ver que va haber en el horario y que otras cosas se pueden checar después de terminar el trabajo.

Construir la integridad en (build integrity in):
Vamos a ver esta parte tenemos dos conceptos integridad percibida e integridad conceptual.
Estás nos dicen respectivamente, que el total de productos alcanzados por la función, utilidad, veracidad y economía que hace deleitar al cliente, la otra definición nos dice que el concepto del sistema central  trabaja junto como un todo.

Ver la totalidad (See the whole):
Esto se refiere a tener en cuenta todas las partes del sistema o producto que estemos creando para poder producir medidas sobre como funcionara y si será de la solución que el usuario estaba buscando, además es importante este aspecto a la hora de los contratos debido a que no hay mucha confianza a la hora de firmar.


Después de entender los conceptos y tenerlos bien claros, nos vamos a basar para continuar con la 
realización del proyecto con una página la cual dejaremos la liga en las referencias.


En la metodología LSN se debe evitar caer en un proyecto tipo “big bang” , con esto se refiere a un proyecto en el que se gasta muchísimo tiempo en la recolección de requerimientos del cliente para una enorme documentación sobre estos que en realidad solo será un carga debido al ciclo de vida del software entre más complejo o extenso se haga se tardara más en terminar el software además de que se corre el riesgo de que no cumpla con las expectativas del mercado ya que como sabemos las tecnologías cambian constantemente a un ritmo muy rápido, es por eso que se conviene usar la metodología LSN, debido a que las iteraciones constantes del código junto con la retroalimentación del cliente agilizan más el proyecto obteniendo resultados más rápidos y más acordes a lo que el cliente necesita.


Utilizaremos las siguientes fases para comenzar con el proyecto.

Sprint0.- Durante esta fase, se verifican los requisitos, las opciones tecnológicas se hacen en detalle (la arquitectura, la pila), se construyen las historias de usuario (que utilizan técnicas de desarrollo ágil - historias de usuario son más o menos equivalente a los casos de uso), y la experiencia del usuario (más que un simple interfaz de , ¿cómo un usuario va a utilizar el producto) enfoque se ha desarrollado para establecer normas de interacción. El resultado de esta fase es un conjunto de especificaciones técnicas, personalidades (papeles a un grado), y las historias de los usuarios prioritarios con las estimaciones de esfuerzo de cada historia.


 Alpha versión .- Durante esta fase, el marco básico se construye y se desarrolla la funcionalidad básica para los principales usuarios finales. El punto de esta fase es verificar la visión del producto con el público clave de la aplicación - a los usuarios finales que realizan las tareas más importantes y utilizar la aplicación más. Esto significa que la versión alfa tiene que ser realmente ser juzgado por los principales usuarios finales. Por lo general, requiere que los socios de los clientes - que en el caso de un nuevo proveedor requiere salir al mercado y contratar a unos primeros adoptantes. El resultado es un menor riesgo. El costo en este momento es bajo, en comparación con la totalidad del proyecto, así que los cambios aún pueden ser absorbidos sin pérdida de grandes porciones de código desarrollado y los costos hundidos. Además, en este punto, el enfoque del equipo de desarrollo en la realización de la visión de su cliente puede ser verificado a principios - de modo que se pueden hacer ajustes y la confianza entre el cliente y el equipo de desarrollo puede crecer. Este enfoque sigue el sabio consejo articulado por Steve Blank - el punto de validación de usuario inicial es de salir de su "cuarto oscuro" y estar frente a su público a principios para que puedan informar sobre el desarrollo antes de los costosos errores se hacen.

Beta versión.- Esta fase produce el primer corte de la versión de mercado de un producto. Es importante entender que el alcance de esta versión es intencionadamente limitada a sólo lo necesario para entregar valor a los usuarios finales. En otras palabras - ofrecer exactamente lo que pagará. Se trata de una evaluación crítica de que se informa tanto por la visión de los expertos en la materia y los comentarios de la versión Alpha. El problema es, sin embargo, no importa lo bueno que la visión y la retroalimentación son, no habrá información adicional cuando el producto llegue a los muchos contextos diferentes de los reales destinatarios a los usuarios finales en el mercado. El lanzamiento de la versión beta también ofrece el "kick off" de las operaciones internas para el proveedor - y en el caso de la mayoría de los productos - de apoyo, ventas y marketing. Las lecciones aprendidas de la versión beta a continuación, informar a la siguiente fase para que los adoptantes beta son recompensados ​​(y conservado) y las operaciones de entrega el mensaje y los servicios necesarios para atraer clientes nuevos y la adopción del usuario. Debido a la naturaleza progresiva de los ciclos de liberación de Agile, el punto real en que las ventas se realizan durante esta fase varía mucho entre los productos -, pero el desarrollo no se detiene. Lo que cambia es que el desarrollo es ahora más directamente informado de los nuevos clientes que ven y participar en la beta. Algunas compañías de precio a las pruebas y la comercialización más agresiva en este punto que otros - pero la recomendación general es establecer principios de fijación de precios y poner a prueba contra el valor percibido de los usuarios. El resultado no se espera que sea un ajuste de precios directamente, sino más bien un ajuste de las características o envases para alinear mejor con el valor percibido.


Market release.- Esta fase marca el lanzamiento del producto total del mercado y el inicio de las mejoras "normales" de productos para seguir creciendo en consonancia con la funcionalidad de comentarios de los usuarios. A veces añade una fase de desarrollo hasta el mercado de liberar a sí mismo que es independiente de beta -, pero para fines generales - el desarrollo ha caído en un modo de enriquecimiento, en lugar de desarrollo a partir completa a menos que exista una diferencia significativa de lo que se planea para el lanzamiento de los clientes beta y el mercado general. El resultado de esta fase es un producto informado por la retroalimentación del usuario de destino, a prueba las operaciones de negocio y un cambio de enfoque de conseguir el producto "por la puerta" para conseguir clientes y continua para mejorar las características y la funcionalidad. No es un punto final - es sólo el comienzo de la evolución natural y el "tirón" de un "en objeto de consumo" de productos en línea.
Los resultados de las fases son las siguientes cosas.

los resultado de los procesos son:

la libertad anticipada y la retroalimentacion de la gente que cuenta como los usuarios en el campo.
Si el ciclo de desarrollo es largo, los clientes existentes pueden abandonar el barco antes de la versión completa está disponible en línea.
Soporte y mantenimiento del producto ya existente puede abrumar a los miembros clave del equipo de producto que deben estar disponibles para dar forma al nuevo producto. Encontrar un punto en que la transición puede comenzar de una manera ordenada, sin canibalizar las ventas existentes es fundamental.
La nueva dirección ofrece una oportunidad para desarrollar nuevos mercados, adoptar nuevos niveles de precios y la transición a un modelo de función de arrastre impulsada por (en lugar del empuje de lanzamientos de productos tradicionales), pero el tiempo es clave. Para que un producto complejo de satisfacer las necesidades de la parte superior de un mercado vertical esto se convierte en un ejercicio enorme y es francamente muy difícil de romper en pedazos manejables.


Para lidiar con eso tenemos un modelo general que tiene la plantilla de nuevos productos por encima y lo convierte en un desarrollo progresivo de un conjunto de productos



Sprint .-El punto de todo este proyecto es como antes, conseguir productos antes de tiempo, tengan un flujo de información y dinero en efectivo tan pronto como sea posible. Esto también incluye un análisis más detallado en el primer producto de la suite.


Mejoras en la Web.- Esta parte de la liberación primer producto es opcional, pero vale la pena considerar como una forma de asegurar que los clientes existentes a bordo para permanecer a largo plazo y puede ver la visión a largo temprana.

Versión Mercado Amplio.- Para permitir retroalimentación temprana y para entrar en el mercado tan pronto como sea posible, el primer producto tiene que estar centrado en un subconjunto de la experiencia expresada en el producto legado que se dirigió a la parte superior del mercado con anterioridad.

Versión Profesional - Basándose en el mismo código base que las versiones del mercado amplio, la versión profesional se centra en los elementos que satisfacen el 80% de su base instalada. 

Versión Enterprise - Una vez más, en la misma base de código, la funcionalidad de la empresa, se añade, y ahora todo el "paquete de productos" ha llegado a niveles nunca alcanzados de funcionalidad en la versión legado.


referencias 
-Libro- Lean Software Development: An Agile Toolkit.










1 comentario:

  1. Ahí va. No me quedó claro cuándo van a ocurrir las actividades y cuánto estiman tardar en cada una. La ortografía (acentos y puntuación) parece ser un punto débil. Van 9 pts por el primer reporte.

    ResponderEliminar