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.
