Check List para PLANIFICAR  proyectos de Software

.

Planificar es el proceso de organizar y proyectar acciones futuras para alcanzar objetivos específicos, mediante la definición de pasos, recursos, tiempos y estrategias

"Si no sabes donde vas , no sabrás que has llegado"

"La gente que no planifica , siempre lleva ropa sucia en sus valijas"

"Desarrollar software es un viaje excitante y costoso"

Planificar es una etapa del proceso de gerencia:

El proceso de la gerencia

1-Determinar objetivos

2-Organizar los recursos

3-Planificar la acción

4-Dirigir la acción

5-Controlar los resultados

Es BASICO reconocer que la producción de soft es diferente de  la  clásica  producción de fabrica o taller.

Sin embargo, para dirigir exitosamente la producción de soft tendremos que cumplir con las expectativas de cualquier proyecto.

Por ejemplo BASICO son las preguntas:

    - Cuando estiman que estará completado?

    - Que equipo profesional se utilizara?

    - Cual es el MONTO estimado de la inversión requerida?

    - Que fechas se estima para entregar cada componente o sub-sistema?

    .

    .

    -... etc 

Recordemos que: el soft es percibido como material adaptable a los cambios , los programadores son optimistas , los usuarios harán usos inesperados del soft , los usuarios trataran de introducir cambios para su beneficio antes de que el proyecto este terminado ... y así

Por otro lado , hay lemas clásicos de la disciplina de planificación que son de aplicación a todo proyecto

."Si no sabes donde vas , no sabrás que has llegado"

."los planes se hacen para no cumplirlos"

."el mapa no es el camino"

."al equipo hay que llenarle los bolsillos de batallas ganadas"

."un proceso es una serie de pasos pequeños , todos demostrables y cumplibles"

."la calidad se construye y se demuestra satisfaciendo especificaciones solicitadas"

."El costo de un recurso se mide primero por su magnitud , después por el precio"

."Para ponerle precio a algo , es ético saber su costo"

."una estimación requiere saber el esfuerzo optimista , el pesimista y el normal o promedio"

."minimizamos el riesgo y administramos la incertidumbre"

."todo sucede con algún grado de incertidumbre"

.El método PERT de planificación fue inventado para manejar proyectos con incertidumbre

Esta nota esta basada en experiencias con muchos proyectos de soft y en la bibliografía fundamental de la ingeniería del software. No intento ser polémico ni critico ni clásico. 

COMENCEMOS ...

þ hay que adquirir las especificaciones

    þ determinar los requerimientos

    þ determinar restricciones y preferencias

þ hay que diseñar una resolución

    ¨  Se trata de determinar factibilidad?

    ¨  Se trata de identificar alternativas construibles?

    ¨  Se trata de implementar una solución a lo requerido?

 

þ hay que estructurar el esfuerzo de construcción

    þ  Selección de un modelo de ciclo de desarrollo

    þ Adopción de una arquitectura

    þ  Identificación de entregables

þ Selección de actividades requeridas (estimación del esfuerzos)

Los tiempos estimados son: Optimistas,Pesimistas y Promedio (los 3 para cada actividad)

    þ  Identificación de dependencias de actividades

    þ  Organización de una secuencia de ejecución de actividades

    þ  Identificación de particiones factibles y selección de una alternativa

    þ Adaptación de la estructura particionada a la arquitectura elegida

    þ  Adaptación a los recursos disponibles

    þ  Generación del primer grafo de planificación del proyecto

    þ Análisis de criticidad , riesgos , adaptabilidad  , hitos , metas , linea de base

    þ  Generación del primer CRONOGRAMA / HOJA DE RUTA  de actividades 

         (primer estimado)

 Proyectos de Software (capitulo 2)

   Costos a tener en cuenta y flujos de fondos

__________________________________________________________________________ 

Un proyecto de software generara básicamente 3 cosas: código ,  datos y COSTOS 

La documentación habitual de un proyecto requiere información sobre los costos del proyecto  a través del tiempo (para una evaluación económica-financiera)

Revisaremos un tema fundamental , generalmente extraño para un desarrollador centrado en codificar , también para desarrolladores con formación preminente en la programación. 

Ì   - Costo de producción o desarrollo es el esfuerzo requerido para la generación, instalación e institución de un software . Costos concretos que pueden ser  expresados en su valor monetario.  

Por la naturaleza de la producción de software , no es útil asimilar a la producción continua de una fabrica , es mas parecido a una producción por ordenes en talleres o a la construcción de obras civiles.

En la producción por ordenes y en las obras civiles el ‘producto’ es a pedido no se repite y los recursos y su organización se adecuan a cada pedido

Ì - Costo de operación es el esfuerzo requerido para mantener el producto de soft en funcionamiento cumpliendo con los objetivos especificados (hasta que sea retirado  )

 

Tener en cuenta que los costos de  producción de un soft son diferentes  para una unidad interna de un empresa cuyo producto no es el software que para el caso de una empresa productora de soft o consultora o contratista de servicios de software

Los sistemas de costeo de una empresa pueden ser muy diferentes , tenemos costeo de absorción , costeo variable , costeo standard , etc. Estos sistemas de costeo brindan diferentes caminos para determinar aspectos fundamentales como: el precio de un contrato por la producción de un software o el costo de mantenimiento.

La clásica clasificación de los costos es: directos o  generales (indirectos) , variables o fijos

En un enfoque de costeo  variable , los salarios de los desarrolladores son inevitables e independientes de la producción del desarrollador  (la empresa los incurrirá aunque no haga nada y el monto es fruto de un contrato pactado ). En un enfoque de absorción el gerente deberá estimar las horas dedicadas a cada producto y eso dará lugar al costo por la actividad de los desarrolladores.

En general independientemente del proceso de desarrollo elegido , se incurrirá en costos para adquisición de requerimientos , adquisición de equipamiento y servicios , diseño , codificación , verificación   , en las diferentes fases o etapas  

Ì  Las fuentes de costos , en general son los costos generados por:

-Gerenciadores

-Diseñadores

-Desarrolladores

-Auxiliares del desarrollo

-Consultores

-Capacitación

-Adquisiciones o licencias de herramientas de software facilitadoras o catalizadores (ides, compiladores , frameworks , librerías , componentes, debuggers , documentadores , control de versión, etc.)    

-Equipamiento de hardware

-Instalaciones

-Repositorios del desarrollo

-Repositorio para los datos…

-certificaciones

-instalación

-institución (curva de aprendizaje)

-documentacion

-Costos ocultos

-Mantenimiento o soporte inesperado

-Hardware especializado

-Servicios especializados

-Obsolescencia planeada

-deuda tecnica

 

El costo estimado o registrado dependerá también del modelo de proceso de desarrollo (o ciclo de vida) adoptado

El capital a invertir y el tiempo hasta su puesta en marcha , son los factores comunes que se requieren conocer para evaluar si es conveniente utilizar recursos de la empresa  en una u otra alternativa

Entonces los evaluadores requerirían saber

1- Duración estimada del tiempo de formulación y desarrollo

2- Monto estimado de la inversión inicial

3- Capacidad de dividir la inversión inicial

4- Periodo estimado de repago

5- Horizonte de vida

6- Flujos de fondos generados durante la vida útil

Algunos aspectos relevantes en la determinación de flujo de fondos

Impuestos: las sumas pagadas por impuestos deben tener igual tratamiento que cualquier otra erogación

Amortizaciones: Son un 'costo' para cualquier sistema de costos operativos  , per NO deben computarse al calcular los flujos de fondos.

SI debe tenerse en cuenta cuando afectan los importes netos a pagar por impuestos

Intereses: Generalmente no se incluyen como egresos computados en la determinación de un flujo de fondos

Capital de trabajo:  todos los componentes del capital de trabajo requerido para la operacion normal  de un proyecto generaran egresos que se incluyen en el flujo de fondos , menos los intereses por deudas

No se incluirán los flujos que ocurrirán con independencia de la aprobación del proyecto.

Pero SI en el caso que : existan flujos causados si el proyecto  NO llega a desarrollarse 

Primeros Proyectos 

(primeras experiencias)

No fueron en el área del software , pero aprendí mucho de ellos

-La primera  vez que me pidieron formalmente que hiciera un "proyecto" fue cuando era estudiante en la catedra "estructuras metálicas" , el profesor me pidió hacer un "proyecto" para galpón de acopio y expedición de cereales a granel , en una zona rural ,donde también había una procesadora de la cosecha de granos.

Fui a Reunión donde me informaron algo mas: el tipo de grano acopiado , las dimensiones esperadas , la circulación esperada de vehículos , las alturas mínimas , el clima de la zona .

Tenia que presentar un plano de estructura , con memoria de calculo.

Yo estudiaba ingeniería industrial , era el único "colado" en esa materia común con ingeniería civil. Así que consultando con mis compañeros me entere que los cálculos de los materiales a utilizar no se hacían con la clásica teoría estudiada de resistencia de materiales . las solicitudes se calculaban en base a los conceptos estudiados , pero la propuesta de implementación (perfiles y uniones)  se hacia en base a una NORMA  standard que se aceptaba en la regíon.

Resumiendo , ese "proyecto" era un conjunto de documentos (normalizados) que permitían al solicitante evaluar si lo que yo proponía era aceptable , construible y : una solución beneficiosa para la situación planteada  .

-Mas adelante en la catedra de "proyectos industriales"  me pidieron que propusiera una planta industrial para la obtención de gas carbónico.

Eso fue mucho mas interesante , me pedían un volumen de producción mínima y dejaban a mi elección la materia prima , la localización , y el equipamiento de planta.

En realidad era un anteproyecto , porque el objetivo era: decidir si era factible y rentable: una fabrica

Esperaban que mi proyecto supere los problemas básicos de adquisición  de la materia prima y que los procesos elegidos consigan el producto a un costo que justifique la inversión

La evaluación no era parte del trabajo

Tenia que entregar una justificación de la elección de la materia prima , un esquema de la línea  de producción con las capacidades seleccionadas para cada proceso y su posible equipamiento. Una memoria de calculo de cada proceso y un calculo estimado de costo de producción

Tenia un profesor como tutor , la biblioteca de la universidad , manuales de presentación de proyectos , y promesas de contactos para satisfacer todas mis dudas

Fue un trabajo que me entusiasmo mucho. No me atraían tanto los procesos productivos , pero me volaba la cabeza el proceso de elaboración del proyecto

- En condición de pasante en empresas mineras ; en una boratera , presente un proyecto de "decantador "  de el material extraído "in situ"  . Justificado con mediciones de laboratorio. 

- En una empresa de extracción de mineral de hierro ,mi proyecto fue: alternativas para la formación de colas de camiones transportadores de mineral desde la extracción hasta planta de clasificación . Para justificar mi propuesta hice un estudio de movimientos y tiempos de camiones en el trayecto : bocamina- planta de clasificación . 

Estos 2 últimos , eran anteproyectos para un análisis de factibilidad y oportunidad.  La boratera estaba en plena producción desde hace años y la extractora de hierro estaba en etapa de preparación para explotación de la mina.

- Apenas recibido generamos con otros profesores de la universidad un proyecto para implementar modelos econométricos computarizados de auxilio para las cátedras de ingeniería i administración de empresas (eran los primeros años de las microcomputadoras) . Entonces hubo un concurso regional para financiar proyectos y hubo que llenar formularios para contar lo que pensábamos hacer ... Pero no con nuestra idiosincrasia o lenguaje. Se trataba de una intimidante cantidad de formularios a rellenar para que un evaluador decidiera apoyar o no la inversión del estado en nuestro proyecto.

Proyectos de Software (capitulo 1)

Conceptos básicos

Ì   CONCEPTO DE PROYECTO: Como ya vimos el termino “proyecto” tiene 2 significados habituales

1- Conjunto de antecedentes que permiten estimar las ventajas y desventajas de aplicar ciertos recursos a la solución de necesidades en forma de productos o servicios

2-  Actividad de cualquier naturaleza que requiere para su realización,  del uso o concurso de algunos recursos escasos (o limitados) , con la esperanza de obtener beneficios superiores a los que se obtienen con el empleo actual de dichos recursos    

    Proyecto de un automóvil , de una carretera , de un puente , de una computadora ,de una nueva maquina industrial ,de producción de automóviles , de construcción de un edificio , de mejora de la producción ,etc  tienen en común que el objeto del proyecto es algo concreto y que para su elaboración se recurre a disciplinas con métodos  y  estándares establecidos 

Y que sucede con el software?  ...   resulta que no se trata de algo concreto . mas bien se caracteriza por (segun F. Brooks) :

 Ì CARACTERISTICAS ESCENCIALES :

Complejidad: La complejidad del software es una propiedad esencial no una accidental

Muchos de los problemas clásicos del desarrollo de productos de soft derivan de su esencia compleja y su crecimiento no lineal … 

Conformidad: Mucha de la complejidad que debemos manejar es "complejidad arbitraria" forzada por instituciones y sistemas creados por humanos , a cuyas interfaces el soft debe conformar...

Cambiabilidad (posibilidad de cambio) La entidad de software está constantemente sujeta a presiones de cambio. Por supuesto, también lo son los edificios, coches, ordenadores. Pero las cosas manufacturadas rara vez se modifican después de su fabricación; Son reemplazados por modelos posteriores, o se incorporan cambios esenciales en modelos que son el mismo diseño básico pero con numero de serie nuevos.  Las evoluciones de  automóviles son realmente bastante infrecuente; los cambios  de las computadoras lo son un poco menos. Ambos son mucho menos frecuentes que modificaciones al software .  En parte, esto se debe a que el software de un sistema resuelve su función, y la función es la parte que más siente las presiones del cambio. En parte se debe a que el software puede ser cambiado  más fácilmente ( es pura materia de pensamiento, infinitamente maleable. )                         De hecho, los edificios pueden cambiar , pero los altos costos del cambio, entendidos por todos, sirven para amortiguar los caprichos de los cambiadores. Recordar que:Todo el software exitoso se cambia. 

Hay dos procesos en juego:     Como el producto de software resulta útil, la gente lo prueba en casos nuevos que se encuentran en el límite o más allá del  dominio original. Las presiones para ampliar la función provienen principalmente de usuarios a quienes les gustan las funciones básicas e inventan nuevos usos para el soft.          En segundo lugar, el software exitoso también sobrevive más allá de la vida normal de la máquina para la  que se escribio por primera vez. Si no son computadoras nuevas, al menos discos nuevos, pantallas nuevas. Cambian  las impresoras; y el software debe adaptarse a sus nuevos vehículos de oportunidad. 

En resumen, el producto de software está integrado en una matriz cultural de aplicaciones, usuarios, leyes y vehículos mecánicos. Todos ellos cambian continuamente, y sus cambios inexorablemente fuerzan el cambio en el producto de software

esta caraceristica sera un aspecto central en un proyecto moderno de software de pequeño y mediano tamaño

Invisibilidad: El soft es invisible e imperceptible. No puede ser explicitado en un espacio , como la geometría (no en uno sino en muchos gráficos superpuestos)

El  proyecto de software tiene algo de  carácter intimidante (al menos tal como lo ve un gerente que no es  del área), generalmente inocente y directo, pero capaz de convertirse en un monstruo de cronogramas incumplidos , presupuestos arruinados y productos defectuosos. 

A pesar de todas estas precauciones , un proyecto de  software en una empresa , sera evaluado como cualquier otro. Es decir: un proyecto sera analizado como una alternativa  de aplicacion de los recursos de una empresa. (alternativa limite: el proyecto o no hacer nada)

Ì INVERSION:                                                                                                                                                                                Definición clásica : Asignación de recursos efectuado con la esperanza de obtener beneficios futuros  que permitan recuperar los fondos invertidos y lograr ganancias económicas , satisfacción de una necesidad o el aprovechamiento de una oportunidad

Ì FLUJO DE FONDOS:

Cuando se haga una análisis económico de un proyecto, se evaluara su posible impacto sobre los objetivos seleccionados comparando las diversas maneras como se podrían utilizar los recursos que el proyecto requiere.El impacto es analizado técnicamente y económicamente. El análisis económico debe fundar toda decisión en criterios aplicables a todas las alternativas .  El movimiento de efectivo constituye un hecho concreto claramente definido , no susceptible de interpretación ni tratamiento discrecional.                                                                                                                                                                           NO confundir con costos y beneficios

Hay que considerar los proyectos que no generan flujo de fondos (los llamados ahorradores) que tienen mucho que ver con la productividad y los métodos de trabajo , son casos comunes en el software. Hay que analizar cuidadosamente y no buscar ciegamente calcular la ROI

Los costos seran analizados contra los costos de las alternativas , generalmente la de no hacer el proyecto . 

información  para la dirección de un proyecto bajo PERT

Generada por el modelo PERT para  una fecha (T)

-probabilidad de completar el proyecto en fecha (F)  establecida 

 -sucesos alcanzados y actividades terminadas

-actividades que deberían haber empezado

-actividades que deberian haber terminado

-actividades que deberían empezar y terminar en el próximo periodo

-actividades anticipadas con relación al tiempo de comienzo o de terminación previstos

-duración total estimada para una actividad

-duración restante o tiempo de la fracción de actividad que queda por realizar a la fecha del informe

-cantidad o porcentaje de proyecto realizada hasta la fecha o en el periodo de informe,  si se establecieron estos parámetros en el programa

-fecha en que debería terminar la actividad si se altero la fecha de comienzo

-tiempo que puede desplazarse el comienzo o la terminación de la tarea si se produjo cambio en el margen total.

-actividades añadidas o suprimidas desde el informe anterior

-cambios en las previsiones de tiempos de los anteriores informes

-márgenes negativos en relación con la fecha impuesta para la terminación del proyecto

Breve resumen de la evolución de métodos de desarrollo 

de soft     "agile"

( hasta 2013)

El desarrollo ágil es un marco conceptual que reconoce las distintas interacciones y cambios que ocurren en todo desarrollo de software. Evolucionó a partir de varios métodos. El Término "Ágil" fue definido por el "Manifiesto Ágil" en 2001. A continuación presentamos una línea de tiempo con los principales eventos en la historia del movimiento ágil:

1930 - Ciclo PDCA

Walter Shewhart propone el ciclo de "Planear", "Hacer", "Estudiar" y "Actuar", un concepto que luego fue difundido por Deming.

1940 - Kanban, Sistemas de Producción de Toyota y el Lean Manufacturing  (Manufactura esbelta)

Taiichi Ohno inventa el método Kanban en Toyota. El Lean Manufacturing es una fuente de inspiración y precursor del movimiento ágil.

1974 - El Proceso de Desarrollo de Software Adaptativo

Un Paper de E.A. Edmonds presenta el concepto de "Proceso de Desarrollo de Software Adaptativo" en 1974. Asimismo, también durante los 70, Tom Gild publica conceptos sobre la Gestión de Proyectos Evolutiva (EVO).

1992 - Crystal

Alistair Cockbur presenta los Métodos Crystal, el punto de inicio de la evolución de las metodologías de desarrollo de software que eventualmente resultaron en lo que hoy se conoce como el movimiento ágil.

Crystal puede ser aplicada en equipos de trabajo de entre 6 y 8 desarrolladores localizados en la misma área, trabajando en sistemas no críticos para la vida (es decir los fallos son tolerables).

1993 - Refactorización

Bill Opdyke presenta el concepto de "Refactorización" en su paper titulado "Creando Superclases Abstractas por medio dela Refactorización".

La Refactorización de código es una técnica para la reestructuración de piezas de código existente, alterando su estructura interna sin afectar su comportamiento con el exterior, que se ejecuta para mejorar los atributos no funcionales de un software.

995 - Programación en Pares (Pair Programming)

Es un concepto que fue simultáneamente ideado, pero de forma independiente por varios autores. Por una parte JimCoplien publicó un Paper , que definió la "Programación en Pares" como un patrón de desarrollo de software. Por otraparte Larry Constantine definió los "duos dinámicos" en su libro "Constantine on Peopleware" del mismo año.

Este concepto se convirtió en una parte integral de la Programación Extrema.

Se han realizado muchas investigaciones que han demostrado la efectividad de la programación en pares. Sin embargo, lafilosofía no está reflejada en el Manifiesto Ágil.

1995 - Scrum

El método Scrum  fue ideado por Ken Schwaber y Jeff Sutherland, quienes lo presentaron en la conferencia OOPSLA95 (Object-Oriented Programming, Systems, Languages & Applications) en Austin Texas. Jeff Sutherland es el Presidente(CEO) de Scrum, Inc y Ken Schawaber es el fundador de Scrum.org.

Mike Beedle fue uno de los pioneros en adoptar Scrum y colaboró con su adopción en muchas organizaciones. Como se sabe, Scrum es prácticamente el estándar de facto para el desarrollo ágil.

1997 - Desarrollo guiado por funcionalidades / Feature Driven Development (FDD)

El método FDD fue inicialmente ideado por Jeff De Luca. En él se definen mejores prácticas como son: Modelado de objetos de dominio, Desarrollo por funcionalidades, Propiedad individual de las clases (Código), Equipos de trabajo por funcionalidad, Inspecciones, Gestión de Configuración, Compilaciones regulares (periódicas) y visibilidad del avance y resultados.

El Proceso FDD fue explicado por medio de la publicación del libro "Modelado Java a Colores con UML: Componentes yProcesos Empresariales", cuyos coautores son Jeff De Luca y Peter Coad.

1999 Desarrollo de Software Adaptativo

Jim Highsmith formalizó el concepto de Desarrollo de Software Adaptativo y público su libro del mismo nombre. La ideacreció y evolucionó hacia las metodologías de Desarrollo Rápido de Aplicaciones (RAD). La metodología propone un ciclode vida de 3 fases: Especulación, Colaboración y Aprendizaje.

1999 - Programación Extrema / Extreme Programming (XP)

Mientras trabajaba en Chrysler, Kent Beck desarrolla el concepto de Programación Extrema

, publicando el método en1999 en un libro titulado "Extreme Programming Explained". Como parte de la Programación Extrema, también formuló los conceptos de  Historias de Usuario y Planificación de Releases. La metodología especifica buenas prácticas para la planificación, gestión, diseño, codificación y pruebas.

Ward Cunningham y Ron Jeffries colaboraron con Beck al escribir el libro sobre XP, a los tres se les considera losfundadores de la Programación Extrema.

1999 - Integración Continua

Kent Beck definió este concepto también, pero fue un paper de Martin Fowler el que lo popularizó.

2001 - El Manifiesto Ágil

Bob Martin, reúne a otros 16 líderes del movimiento ágil, para escribir el "Manifiesto Ágil", que engloba las metodologíasque hasta ese momento se les conocía como "Metodologías de Desarrollo de Software de peso liviano".

2002 - Desarrollo guiado por pruebas / Test Driven Development (TDD)

El concepto se originó el enfoque de "Probar primero" asociado a la Programación Extrema (XP). Luego tomo mayor conla publicación del libro "Desarrollo guiado por pruebas: Por ejemplos" (Test Driven Development: By Example), escrito porKent Beck.

Luego Kent Beck escribe otros libros sobre el tema como "Rediscovering Test-Driven Development".

2002 - Planning Poker

También en 2002 nace la técnica de Planning Poker, ideada por James Greening y escrita en un Paper.

2003 - Desarrollo de Software Esbelto / Lean Software Development

Mary y Tom Poppendieck presentan su obra "Lean Software Development".

El Lean Software Development es una adaptación de los principios de la manufactura esbelta y de los del desarrollo de software. Presenta 7 principios: Eliminar desperdicio, amplificar el aprendizaje, Decidir tan tarde como sea posible, entregar lo más rápido posible, dar poder al equipo (empowerment), construir integridad y ver la totalidad. Como se puede ver estos principios están alineados con la filosofía ágil.

¿Es el Lean Software Development una metodología ágil?, o es algo distinto, muchos la consideran como el próximo eslabon en la evolución del desarrollo ágil.

2006 - Desarrollo guiado por comportamiento / Behavior Driven Development

Dan North presenta su obra "Behavior Driven Development", un método que combina las principales ideas y técnicas delTDD con las ideas del Diseño guiado por dominio y el Análisis y Diseño orientado a objetivos. El método se enfoca en proporcionar herramientas y procesos colaborativos entre desarrolladores de software y analistas funcionales, buscando acercar a los técnicos de software con las necesidades que impulsan al área de negocio.

2007 - Retrospectivas

Esther Derby y Diana Larsen escriben su obra "Agile Retrospectives", estableciendo las reuniones retrospectivas como práctica ágil estándar.

2007 - Kanban para el Desarrollo de Software

David Anderson presenta su obra "Kanban", adaptando el Kanban para el desarrollo de software. El método se enfoca en la entrega "justo a tiempo" y en no sobrecargar a los desarrolladores de software, tal como su precursor el Kanban para manufactura perfeccionado por Toyota. Bajo este enfoque, todas las tareas necesarias para entregar una funcionalidad al cliente se le muestran a los desarrolladores, quienes toman la tarea a realizar de una cola, de forma similar al backlog definido en Scrum.

El Kanban no prescribe una serie de pasos o métodos, no existe algo como "el método de Gestión de Proyectos Kanban",en su lugar, la intención es iniciar con los roles y procesos que se tienen actualmente y partir de allí estimular cambios continuos, incrementales y evolucionarios sobre el método de trabajo.

2009 - Manifiesto de la Artesanía de Software (Software Craftmanship)

Los asistentes a la primera conferencia internacional de Artesanía de Software escriben sus conclusiones y promulgan el "Manifiesto de Artesanía de Software". La artesanía de software no solamente se trata de prácticas de programación sino también de formar a la siguiente generación.

2009 - Lean Startup

Eric Ries escribe su obra "Lean Startup". Es una metodología mayormente teórica para el desarrollo de empresas yproductos. Basado en las experiencias de Ries trabajando con varios emprendimientos (startups), el método se basa enque los ciclos de desarrollo de productos pueden reducirse en duración por medio de ciclos continuos deexperimentaciones, iteraciones y lanzamientos de producto.

Ries establece que si las Compañías construyen sus productos o servicios de forma iterativa, buscando lanzarlos al cliente lo antes posible y adquirir aprendizaje a partir de allí, pueden evitarse los costosos proyectos y lanzamientos de nuevos productos.

tomado de: www.pmoinformatica.com/2013/06/una-breve-historia-de-las-metodologias.html

EL CONTROL EN LOS SISTEMAS DE PRODUCCION

Efecto en las aplicaciones que no formalizan su manejo

    Un diseñador (ingeniero,arquitecto,analista) que desarrolle su actividad profesional en el ambito de sistemas para empresas habra observado que siempre existe alguna unidad o rol identificado con el rotulo "control".

    En las empresas industriales de procesos químicos es muy notable su existencia

    Sucede ... que todo esfuerzo de producción (transformación de insumos en productos)  requiere (para generar los resultados esperados) procesos estabilizados , es decir que para conseguir los objetivos elegidos por los dueños/administradores todo sucede bajo control.

    Acomodando el diccionario: En toda industria existen parametros de operacion y de resultados .Ademas los administradores pueden introducir sus criterios de exito asignando valores deseables de variables de los procesos

    Bajando a la programación , en los casos de uso esenciales (critical use cases) , los del núcleo de una arquitectura se implementan para cumplir con las exigencias de estabilidad y control.

    Porque el diseñador sabe que un sistema concreto   funcionara con inestabilidad a mens que se controle (recordar el ultimo paso del proceso de la gerencia)

    En este contexto hay 2 conceptos fundamentales: control adaptativo y servosistemas 

    De los antecedentes y preparación de un ingeniero deriva su capacidad para resolver problemas en un campo , estableciendo una analogía con otro

    Uno de los aspectos de la analogía es la posibilidad de producir modelos reducidos y de bajo costo 

    Aplicando analogias a : control , se ha clasificado sus modelos baicos en 3

-Modelo estático

-Modelo dinámico

- modelo de servosistema

    Se trata de un sistema ce control con 2 características: Amplificación , Realimentación

    Los resultados de un modelo se valoran comparándola con un cierto valor standard (objetivo) eso motiva las acciones correctivas y respuestas de retroalimentación

CONTROL ADAPTATIVO 

    Este tipo de control procura que el sistema de control automático se adapte a circunstancias variantes de comportamiento en la dinámica de un sistema y a sus perturbaciones

    Su diseño refleja el esfuerzo por controlar las interrelaciones de las componentes del sistema , con el fin de regular el resultado final

    El esquema mas simple (y menos beneficioso) de control adaptativo es el de :

Bucle Abierto

    ej: -la tostadora que tiene un temporizador que la apaga cuando se alcanza un valor de tiempo

         - El clasico punto de pedido basado en la cantidad minima predeterminada en stock

Bucle Cerrado    

    El esquema básico es un bucle principal que incluye un regulador y otro secundario en el que se miden las variables , se determina un índice de actuación , se compara con  el índice deseado y se disparan los mecanismos de adaptación que afectan al regulador y/o actúa directamente sobre la señal de control  

    La característica principal de un sistema de control adaptativo cerrado,  es la presencia de un bucle de control donde se compara los índices de funcionamiento (o actuación)

Servosistemas

    También identificado como servomecanismo , es un sistema de control automatizado capaz de ajustar la salida en función de la retroalimentación que recibe , logrando asi gran  precisión .

    Un servomecanismo es fundamentalmente un sistema de control retroalimentado que incluye sensores , un controlador y actuadores

    Los sensores miden y envían esa información al controlador , que la procesa determina los ajustes necesarios.

    A continuación los actuadores a menudo en forma de servomotores ejecutan esos ajustes para alinear la salida real con la deseada.

    La belleza de un servomecanismo reside en su capacidad para corregir errores en tiempo real. Esto se consigue mediante la retroalimentación negativa . Este proceso de ajuste continuo es lo que permite a los servomecanismos mantener un control preciso sobre los mecanismos que gobiernan.

    Para superar la inercia al cambio , los sobre impulsos y las oscilaciones , las estrategias básicas han sido: 

- ajustes de los parámetros de control 

- tecnicas de amortiguacion (analogias de amortiguacion mecanica o electronica) para absorber la energia excesiva y estabilizar el sistema

-algoritmos de control que anticipan y compensan los posibles rebasamientos y oscilaciones 

 (Advanced Motion Control , blog: what is servomechanism )

    Algunas de las  ideas relatadas en los parrafos previos DEBEN existir en forma de un proceso debidamente segregado (empresas grandes o procesos estandarizados) pero ... la mas de las veces se presentan como procesos embebidos que un progrador bien formado sabra manejar como "business rules" El desconocimiento de esta funcion y la manera de tratarla hace que el programador "reparta control" a su discrecion a medida que descubre la necesidad de controlar . Generalmente produce "spagheti code"