21:53
Juan MC Larrosa
Gestión de proyectos
"La gestión de proyectos es la disciplina de organizar y gestionar los recursos de tal manera que estos recursos ofrecen todo el trabajo necesario para completar un proyecto dentro del alcance, tiempo y limitaciones de costo definidas". [Wikipedia]
Un director de proyecto rara vez toma parte en las actividades que producen el resultado final, lo que hace más bien es esforzarse por reducir el riesgo general de fracaso.
Los 5 principios de selección de personal
· Elegir los mejores talentos
· Coincidencia de trabajo (Job Matching)
· Progresión de carrera
· Equilibrio de equipo
· Eliminación del personal que no se adapte
¿Qué características muestra un buen equipo?
· Compartir visión/objetivo
· Identidad de equipo
· Estructura guiada por resultados
· Miembros competentes
· Compromiso con el equipo
· Confianza mutua
· Interdependencia
· Comunicación efectiva
· Autonomía
· Delegación de autoridad (Empowerment)
· Tamaño de equipo pequeño
Gestión de Proyectos orientada a objetivos[1]
Fijar objetivos claros, con fechas de entrega claros, con la menor presencia de ambigüedades es el principio de un proyecto de software. Esa misma claridad ayuda a resolver muchos más problemas de los que se supone.
La gestión de la naturaleza humana
Si todos hicieran lo que debían hacer, no tendríamos necesidad de los administradores de proyectos o jefes de equipo. Si los programadores siempre escribieran código libre de errores, no tendríamos necesidad de equipos de prueba de software. Sin embargo, la realidad de nuestra industria es que los equipos necesitan líderes y gerentes, y el código necesita de pruebas. Como jefe de proyecto, usted se encontrará la tentación de culpar a los miembros del equipo cuando se escribe el código con errores o no cumplir con los compromisos del proyecto, que es una reacción natural, pero una errónea. Si el equipo fuese perfecto, no tendría que estar allí. Su papel, en gran medida, es ayudar al equipo a superar su propia naturaleza humana. Aquí están algunas de las expresiones del equipo de software, convirtiéndose en protagonista condición humana que se puede esperar: Los desarrolladores de software a escribir el código que está lejos de ser perfecto, con diseños que sean más convenientes que estratégicos. Los miembros del equipo participarán en disputas tristes, sin sentido, e infantiles sobre las cosas más triviales. El trabajo se ampliaría para dar cabida a el tiempo asignado para su realización (y más), y los proyectos se ejecutarán tarde. El equipo va a hacer todas estas cosas, no porque son malos, estropeados o infantiles, sino simplemente porque son humanos.
Haz que se sientan apreciados. La gente lucha entre sí a menudo porque están preocupados por su propio sentido de logro y la percepción sobre su trabajo. Cuando los empleados sienten que sus contribuciones son limitadas o están siendo percibidas de esa manera, es común que su frustración se dirija a sus compañeros de trabajo (y su jefe). Los psicólogos llaman a esta "proyección". Haga cumplidos periódicamente… son gratis.
Haz que se sientan apreciados. La gente lucha entre sí a menudo porque están preocupados por su propio sentido de logro y la percepción sobre su trabajo. Cuando los empleados sienten que sus contribuciones son limitadas o están siendo percibidas de esa manera, es común que su frustración se dirija a sus compañeros de trabajo (y su jefe). Los psicólogos llaman a esta "proyección". Haga cumplidos periódicamente… son gratis.
El estado del proyecto hace girar al mundo. Es triste pero cierto. Cuando usted pide una actualización sobre el estado de los entregables del proyecto, los empleados se sienten obligados a entregar un buen mensaje. Recoger con regularidad informes sobre la situación mantiene a los miembros del equipo constantemente interesado en la producción de mensajes de buenas noticias para su gestión. El estado es una entidad que tipo Zen que exige el equilibrio. El personal subalterno y de bajo rendimiento puede tolerar más porque lo necesitan. El personal superior y las superestrellas que requieren menos molesta y más. Uso de informes de estado como un dispositivo para mantener a las personas en el camino y se centró, pero la demanda con cuidado con un ojo avizor sobre quién lo está pidiendo y cómo ello lo percibirán.
Ofrecer una salida para salvar la cara. A veces es necesario señalar a las personas que hicieron una macana o se fueron de ruta. Tienen que cambiar su forma o solucionar un problema. Como un jefe de proyecto y personal, no puede escapar a eso. Dicho esto, desea que la persona que recibe el mensaje de que abandone la sala motivados para cambiar y seguir trabajando con entusiasmo. Si alguien se deja sentir abatido, deprimido, o a la defensiva, las cosas pudiera derivar en resultados cada vez peores. Para evitar esto, asegúrese de que todas las conversaciones duras proporcionen al destinatario una salida para salvar la cara, una manera de salir de la sala con una sonrisa. No es tan difícil de hacer. Conceder algunos puntos, o puntos parciales, sobre las causas últimas por lo general se desinfla mucha de la tensión. En segundo lugar, a pesar de los problemas que se encuentran en proceso, permiten ser optimistas para el futuro si las cosas pueden dar la vuelta.
Haciendo uso de los estudiantes
Los estudiantes son mano de obra barata, a menudo muy productiva, y un gran forma de bajo riesgo para identificar el talento de estrellas. Incluso mejor, por lo general están felices y dispuestos de hacer todo el trabajo duro que sus bien pagados empleados superestrellas no quieren. Siempre me he sentido fuertemente que los estudiantes de prácticas a los estudiantes la cooperación triunfo para el valor debido a la complejidad de las posiciones de software en general significa que los primeros meses en el software trabajo es aprendizaje puro.
Para la mayoría de las posiciones de cooperación, el trabajo dura sólo unos meses, por lo que el tiempo efectivo que usted puede salir de los estudiantes es bastante escaso y, en algunos casos, los estudiantes de cooperación drenan más recursos que los que proveen. Los estudiantes de prácticas se suelen colocar por 8-16 meses, y se puede obtener un valor importante de ellos durante ese tiempo. Es un proceso de bajo riesgo para la identificación de talentos.
Piense en las prácticas de estudiantes como de su oportunidad de "probar y comprar." Si los estudiantes son superestrellas, usted descubrirá rápidamente a través del curso de su trabajo de duración. Si los estudiantes salen grandes o no, la experiencia de trabajo de duración dará una comprensión mucho más profunda de sus capacidades de una breve entrevista o prueba de aptitud podría hacerlo. Si un estudiante es un fiasco, no hay mucho daño, y no tiene la obligación de contratarlo de nuevo una vez que el estudiante termine su plazo. Los estudiantes son una fantástica manera de reclutar a los mejores y más brillantes, con poco riesgo, mientras que les asigna algunas de las tareas bajas en las que no quieres gastar sus programadores de alto costo y altamente experimentados.
El valor de medir el valor
Una de las cosas más difíciles para un equipo de desarrollo, y también uno de los más poderosos, es medir el valor del software que se crea. Es sensacional cómo medir el valor crea valor en sí mismo. Una de las grandes cosas acerca de la medición es que se presta a la imágenes. Se puede ilustrar un número en la forma de un gráfico de líneas, un gráfico de barras u otra forma. Considere un par de ejemplos de mi propia experiencia en IBM.
De ratones, hombres, y los planes de proyecto
Los planes de proyectos de software siempre tienen componentes de negocio (quien es nuestra audiencia, cuáles son las ventajas y beneficios que esperamos traer a ellos, cómo vamos a llevar nuestra tecnología al mercado, cómo va a ser monetizado), los de ingeniería (definiciones de características y especificaciones, el diseño, código, pruebas unitarias, pruebas de función, integración y pruebas de aceptación y pruebas del sistema), y los proyectos asociados a la gestión (análisis de dependencia, de personal y cronograma de desarrollo). En un sector tan dinámico como el nuestro, es virtualmente imposible planificar todos los aspectos de un proyecto desde el principio y ejecutar sin necesidad de variar el plan.
"No hay plan de batalla que sobreviva al contacto con el enemigo." De hecho, sólo los encuentros iniciales de una batalla pueden ser realmente previstas (y sólo si usted está planeando el primer ataque). Si hay un lugar común de la planificación de proyectos de software, es que el plan con el que se termina no puede ser el plan con el que se comenzó. Si es así, uno de los siguientes ha ocurrido:
· Usted es un adivino y ha predicho el futuro con facilidad.
· Usted está trabajando en un proyecto muy simple, y es probable que no necesitaba nada lo suficientemente sofisticados como para llamarse plan.
· No han reaccionado a los cambios del entorno que te rodea, y que está a punto de entregar un proyecto de software que se ha incumplido gravemente sus objetivos.
Los planes de proyecto cambian, ya que, en cualquier proyecto con complejidad moderada, ciertos parámetros no se pueden conocer desde el principio. Desde el momento en que comienza hasta el momento en que el proyecto se completa, las piezas en movimiento, tales como una mejor comprensión de las necesidades, las partidas que se ejecutan antes de lo previsto (unas pocas) y otros que desbordan (varias), competidores introducen saltos en tecnología que fuerzan a modificar su estrategia, y la gente que mover, cambiar o desaparecer. Las estrategias de desarrollo iterativas han ayudado a hacer que la adaptación sea más natural, pero el cambio de un plan de negocios nunca es fácil.
La evaluación de la madurez de su desarrollo
El punto más importante acerca de metodologías de desarrollo de software es contar con una metodología y asegúrese de que el equipo lo está utilizando. Si usted está poniendo hacia fuera código sin un proceso establecido para ello, se va a quemar más tiempo y generar más errores en la parte final. El resultado neto será excesos de programación y presupuesto, de menor calidad y los requisitos probablemente no alcanzados. Las metodologías principales ampliamente en uso hoy en día incluyen los métodos ágiles de desarrollo, proceso en cascada de desarrollo de software, y la creación rápida de prototipos. Vale la pena conocer lo que cada uno de estos es en realidad.
Desarrollo iterativo
Qué es: Una metodología para el desarrollo de software que hace hincapié en la creación de software en las ondas de función. Cada ola debe ser totalmente funcional antes de proceder a la siguiente. Los equipos normalmente evolucionan a partir de un proceso en cascada de un proceso iterativo y luego a procesos más ágiles.
Ventajas: Esta metodología tiende hacia un entorno de desarrollo más estable debido a las características siguientes se construyen sobre una base estable. Generar las primeras etapas de aprendizaje para mejorar la siguiente. Los problemas son descubiertos antes. Características desarrolladas en algunas de las primeras iteraciones de obtener una mayor exposición a las pruebas y análisis de usabilidad.
Desventajas: las características finales del ciclo presionan en tiempo, poniendo un alto riesgo de baja calidad o falta de entrega. Los equipos maduros cortarán funciones para mantener la calidad y el horario características de alto riesgo temprano y de bajo riesgo (o de baja importancia) hacia el final, reduciendo al mínimo este peligro.
Scrum
Qué es: Una estrategia para organizar a la gente en un equipo de desarrollo para el trabajo de alta eficiencia y colaboración. Un scrum es un grupo de personas trabajando en un proyecto, cada uno con funciones específicas, como propietario de producto y un scrum master. Los scrums se reúnen regularmente (a diario) a tiempo fijo (por ejemplo, 15 minutos) y se organizan en torno a períodos "sprints", de tiempo de un par de semanas con los objetivos específicos definidos por el scrum. El scrum también hace hincapié en demos y la retroalimentación de los primeros usuarios. Además de las reuniones diarias, programan reuniones para ayudar a planificar los sprints y revisar las pruebas de sprints.
Ventajas: Este método es efectivo para forzar/fomentar la colaboración, el logro de respuesta temprana, y mantener el ritmo. El Scrum es un lugar sencillo, ideal para empezar como una incursión en los métodos ágiles. La metodología scrum/ágil se extiende a la planificación y gestión en todo el ciclo de desarrollo en orden de prioridad.
Desventajas: Aunque las reuniones diarias de scrum fomentar la colaboración y el progreso, algunas personas pueden empezar a tratar a presionar implacable en las actualizaciones y en el status de desarrollo. En segundo lugar, el scrum no es un proceso de desarrollo completo, es mejor aplicada como parte de un proceso iterativo/ágil. No cubre la tecnología/desarrollo de las prácticas, ni tampoco trata de iniciar un proyecto o la puesta en producción.
· Al iniciar cada iteración, el equipo revisa el trabajo pendiente del proyecto y selecciona la parte que terminará como un incremento de funcionalidad incorporado al software al terminar la iteración.
· Al final de la iteración el equipo presenta el incremento de funcionalidad a las partes implicadas en el proyecto.
El equipo revisa los requisitos, considera la tecnología disponible, evalúa sus conocimientos, y de forma colectiva determina cómo implementar la funcionalidad.
Roles
Scrum tiene una estructura muy simple. Todas las responsabilidades del proyecto se reparten en 3 roles:
· Propietario del producto
· Equipo
· Gestor de Scrum (Scrum manager o Scrum Master)
Características
· Scrum es un método adaptativo de gestión de proyectos que se basa en los principios ágiles:
· Colaboración estrecha con el cliente.
· Predisposición y respuesta al cambio
· Prefiere el conocimiento tácito de las personas al explícito de los procesos
· Desarrollo incremental con entregas funcionales frecuentes
· Comunicación verbal directa entre los implicados en el proyecto
· Motivación y responsabilidad de los equipos por la auto-gestión, auto-organización y compromiso.
· Simplicidad. Supresión de artefactos innecesarios en la gestión del proyecto.
Proceso de desarrollo ágil
Qué es: También conocido como el Proceso de entrega ágil disciplinado, esto es una expansión del modelo de desarrollo iterativo en una metodología de software en toda regla de desarrollo. Se añade de scrum diario, equipos multidisciplinarios (desarrollo, pruebas de usabilidad, beta y envasado, comercialización, y así sucesivamente), y los ciclos de prueba totalmente completos para cada iteración. El desarrollo ágil hace hincapié en la adaptación a los conocimientos adquiridos en cada iteración.
Ventajas: El desarrollo ágil añade mejoras significativas en la calidad sobre la base iterativa modelo de desarrollo a través de más pruebas exhaustivas de cada iteración. Los scrums diarios mantienen a todo el equipo coordinado, y los equipos multidisciplinarios para que el trabajo es más que un festival de codificación. El desarrollo ágil captura el valor de negocio deseado (con especial énfasis en las historias de usuario para dar cuerpo a las definiciones tradicionales de problema) y busca una retroalimentación constante que los objetivos se están abordando.
Desventajas: Agotamiento. El desarrollo ágil es increíblemente eficaz, pero mantiene una intensa presión sobre los equipos de medida que pasan de iteración a iteración. La intensidad es mucho mayor que el desarrollo iterativo solo porque la metodología incluye varios aspectos adicionales del proceso de desarrollo, aparte de diseño y código.
En segundo lugar, como con cualquier modelo iterativo, las características finales del ciclo consiguen exprimir todo el tiempo.
En tercer lugar, la voluntad de adaptar los planes de producto basado en una nueva comprensión de cada iteración significa que los miembros del equipo (y empresarios) no puede saber con certeza lo que va a ser entregada hasta muy tarde. Un punto importante obstáculo se produce cuando los equipos de liderazgo tratan de aplicar los métodos ágiles para entregar proyectos de alcance fijo en una línea de tiempo fijo. Lo ágil se presta a sí mismo a la adaptación y la voluntad de compromiso en el contenido o en el cronograma a medida que las iteraciones perfeccionan la comprensión del equipo de las necesidades y prioridades.
En cuarto lugar, a diferencia de la metodología de cascada, que durante años ha abogado que el código sea probado por gente que no es su autor, el desarrollo ágil promueve las pruebas basada en autor como un método para acelerar el ciclo de prueba. Esto se suma a las pruebas de eficiencia, pero también presenta un riesgo considerable, ya que cualquier mala interpretación de los requisitos del proyecto que el programador tenía durante la edición del código probablemente se extenderá en el esfuerzo de la prueba.
XP: Programación Extrema
Qué es: Esta variación del desarrollo ágil pone gran énfasis en la programación por parejas (ver foto abajo), el desarrollo basado en pruebas (TDD), en el lugar las necesidades del cliente, la refactorización del diseño, y las revisiones de código intensa.
Ventajas: XP lleva los beneficios de las mejores características de ingeniería de software a un extremo. Se impone la idea de que dos cabezas piensan mejor que uno en cualquier trabajo de diseño y codificación, y el énfasis en las revisiones de código lleva a la calidad del código notablemente más altas que las revisiones de código siguen siendo la industria el método más eficaz para la detección de defectos y eliminación.
Desventajas: Los extremos rara vez son saludables en todos los aspectos de la vida, y por lo general este modelo no escala a los equipos grandes. A través de TDD, casos de prueba se escriben antes que el código del producto, que define la función prevista del producto aún está por escribirse. Debido a que los casos de prueba son en sí mismos el código, los defensores de XP escribir código que define el código (en lugar de escribir una especificación del lenguaje natural), un enfoque que algunos han argumentado que es incómodo y desalienta a recursos eficaces requisito.
Desarrollo lean
Qué es: Esta metodología de gestión de proyectos está estrechamente relacionado con el desarrollo iterativo. Favorece las decisiones de ciclo tardías, donde más conocimiento y entendimiento se dispone: “Comprométete a lo más tarde posible." Se hace hincapié en la reducción de residuos y la sobrecarga de proceso, se trata de reducir la burocracia. El desarrollo Lean también hace hincapié en la entrega de productos al mercado lo más rápido posible. El mantra del desarrollo magra dice mucho de su filosofía: "Piensa en grande, actúa pequeño, falla rápido, aprende rápido".
Ventajas: Este método mejora la eficiencia de la organización mediante la eliminación de residuos. La metodología Lean hace hincapié en la evaluación continua, idealmente a través de la medición, para eliminar los residuos. Esto explica por qué las obras de desarrollo ágil, proporcionando las filosofías fundamentales detrás de él. Requisitos y código que no contribuyen al valor de los clientes se dejan de lado. Los planes de producto no son considerados compromisos hasta tan tarde en el programa como sea posible.
Desventajas: el desarrollo Lean es más sobre los principios que de procesos. Es la metodología para los líderes para ayudarlos a implementar el desarrollo ágil de manera eficiente e integrar el proceso de desarrollo ágil con el pensamiento de negocios. El desarrollo Lean es alto en ideales, pero un poco menos específico acerca de las medidas preceptivas para su ejecución. De hecho, es más conceptual, y se necesita un mayor esfuerzo de aplicar que, por ejemplo, meter el scrum. Los programadores junior a menudo pierden el valor.
Lean Startup
“Lean Startup" es un término acuñado por Eric Ries, su método aboga por la creación de prototipos rápidos diseñados para poner a prueba hipótesis sobre el mercado, y utilizar la retroalimentación de los clientes para evolucionar mucho más rápido que a través de las prácticas más tradicionales de desarrollo de productos, tales como el modelo de cascada. No es raro ver a Lean Startups liberar el código nuevo a los tiempos de producción de muchas veces al día, a menudo usando una práctica conocida como la implementación continua.
Según el New York Times, "El término ‘lean startup" fue acuñado por el Sr. Ries, de 31 años, ingeniero, empresario y blogger. Su inspiración, dice, fue el proceso de manufactura lean, afinado en las fábricas japonesas hace décadas y centrada en la eliminación de cualquier obra o inversión que no produzca valor para los clientes. "
Lean startup es a veces descrito como Lean Thinking aplicada al proceso empresarial. Un principio central del pensamiento Lean es reducir los residuos. Los procesos lean startup reducen los residuos mediante el aumento de la frecuencia de contacto con clientes reales, por lo tanto, de las pruebas y evitan suposiciones incorrectas del mercado tan pronto como sea posible [5]. Este enfoque trata de mejorar las tácticas empresariales históricas, reduciendo el trabajo necesario para evaluar los supuestos sobre el mercado, y disminuyendo el tiempo que toma una empresa para encontrar la tracción del mercado. Esto se conoce como producto viable mínimo (MVP).
En The Entrepreneur's Guide to Customer Development, Brant Cooper y Patrick Vlaskovits añaden un cuarto elemento, y que es el uso de potentes herramientas de análisis y de bajo costo y fácil de usar. Si bien algunas características de los lean startups se han practicado durante años, la confluencia de estas tendencias es un reciente fenómeno que aumenta la velocidad de iteración o el "número de ciclos de aprendizaje por dólar", como el foco de negocios que ajustan productos a mercados. [6]
Principios del Lean Startup
· Entrepreneurs are Everywhere
o En Estados Unidos… pero acá también "Think big. Start small. Scale Fast."
· Entrepreneurship is Management
o Un emprendimiento es una institución, no sólo un producto por eso requiere un tipo de gestión enfocado en un ambiente de extrema incertidumbre.
· Validated Learning
o Los emprendimientos existen para aprender cómo construir una empresa sostenible. Este aprendizaje puede ser validado científicamente realizando experimentos frecuentes que le permiten al emprendedor evaluar cada elemento de su visión.
· Innovation Accounting
o Hay que medir progresos, establecer puntos de referencia y priorización de tareas. Eso requiere un tipo de contabilidad diseñada para emprendimientos.
· Build-Measure-Learn
o Todos los emprendimientos convierten ideas en productos, miden como responden los clientes y aprender si pivotear o perseverar. Todos los emprendimientos deben acelerar este bucle.
Proceso de Desarrollo de Cascada
Qué es: Este es el modelo clásico de desarrollo de software, donde el desarrollo progresa en una secuencia lineal desde los requisitos hasta la especificación, luego el diseño, código, unidad, prueba de verificación funcional, prueba de integración, de aceptación/beta, prueba del sistema de verificación, y el producto listo para despachar.
Ventajas: Los desarrolladores de software saben lo que tienen que hacer por adelantado. Los planificadores de negocios, marketing, y todos los equipos de ventas comprender el contenido del producto y fecha de lanzamiento desde el principio. Bajo riesgo para desarrollos bien conocidos y tecnología familiar.
Desventajas: comprenden plenamente las necesidades y complejidad de producir una solución que va a entregar en 9-18 meses es por lo general casi imposible de hacer por adelantado. El proceso de cascada casi garantiza una necesidad de un cambio de plan a mitad de ciclo, pero no está bien diseñado para darle cabida. En segundo lugar, un ámbito fijo y horario aprieta calidad cuando aumenta la presión programar en la parte final del ciclo, donde todas las pruebas y corrección de defectos se producen. Por adelantado los planes son frágiles y se rompen con facilidad. Mercados, necesidades del cliente, adquisiciones, competencia, y consideraciones similares cambiantes continuamente rompen el plan.
Figura 1. Modelo de Cascada
Prototipado rápido
Qué es: Esta es la idea de que cualquier software de diseño complejo debe ser un prototipo antes una prueba de concepto, para entender sus fortalezas y debilidades antes de ejecutarlo. Este modelo se utiliza a menudo como una fase temprana del modelo de desarrollo cascada.
Ventajas: El prototipado rápido saca mucho del riesgo del proceso de desarrollo de cascada. Los primeros prototipos ayudan a explorar los límites de un diseño propuesto al inicio del ciclo.
Desventajas: el código del prototipo suele ser bastante desordenado y limitado. Después de un prototipo exitoso, el código de prototipo debe ser desechado, y el equipo debe continuar el enriquecimiento del proyecto utilizando la metodología de cascada clásica. Sin embargo, los equipos han encontrado por doquier que es casi imposible resistirse a usar el código de prototipo como el punto de partida para el desarrollo de productos. El resultado neto es un producto final integrado en su núcleo en la parte superior de la baja calidad del código no fiable.
Figura 2. Historia del uso de los modelos de ciclo del software
Procesos de desarrollo de software actualmente
Las organizaciones modernas de desarrollo tienden cada vez más hacia los métodos ágiles (ver el lado izquierdo de la figura), pero los métodos ágiles también tienen sus problemas. Ya sea que elija una estrategia ágil o un modelo más clásico, puede aplicar estos métodos para gestionar una organización de software de primera clase y desarrollar software de alta calidad.
Prueba de Madurez
PREGUNTA SI? PUNTOS
1. ¿Su equipo históricamente entrega los proyectos con las características de mayor prioridad, con una calidad excelente, y en 20% antes de la fecha de entrega prevista originalmente? (10 puntos)
2. ¿Su equipo utiliza un sistema de seguimiento de defectos? (10 puntos)
3. ¿Su equipo utiliza un sistema de control de código fuente? (10 puntos)
4. ¿Está claro para cada arquitecto, programador y tester el proceso que se debe utilizar para los requerimientos, especificación, el seguimiento de la gestión de código, pruebas y defectos? (10 puntos)
5. ¿Su equipos crea y revisa planes de prueba que definen las pruebas que pretenden llevar a cabo? (10 puntos)
6. ¿Su equipo de gestión de proyecto rastrea la tasa de defectos de las nuevas tasas de arribo y del tamaño nuevos retrasos?
7. ¿Todas las personas que trabajan en el producto tiene una definición clara y unánime para la palabra "hecho?" (5 puntos)
8. ¿Llevas a cabo pruebas de campo (programas alfa y beta) y/o estudios de usabilidad para obtener retroalimentación temprana? (5 puntos)
9. ¿Sus desarrolladores entiendan claramente los objetivos de negocio a corto plazo para el producto que están trabajando, como la claridad en lo que los segmentos principales del mercado que son para el producto? (5 puntos)
10. ¿Su equipo de pruebas interno puede escalar con el tamaño y la intensidad de su mayor número de usuarios esperado? (5 puntos)
11. ¿Tiene la organización de desarrollo una mayor claridad tanto en la fecha de finalización del proyecto y una serie de hitos intermedios? (5 puntos)
12. ¿Su equipo crea y revisa completamente las especificaciones del producto antes de que esté más del 30% terminado con la fase de codificación? (5 puntos)
13. ¿Tiene su equipo descripción por escrito de los requisitos del proyecto, en la forma de una especificación, enunciados de los problemas, o los escenarios de usuario? (5 puntos)
14. ¿Están por lo menos el 80% de los casos de prueba automatizados y se realizan de forma periódica? (5 puntos)
15. Total (puntuación máxima: 100)
Si su puntaje es inferior a 70 en esta prueba, tienes un serio problema con la madurez de su organización de software.
Si su puntaje es mayor de 90, felicitaciones, en mi opinión, está trabajando en un grupo que está en el percentil más alto de madurez en desarrollo de software.
Defectos de software y costos y eficiencias
Siempre es bueno captar los defectos del software en las etapas iniciales de cualquier ciclo de desarrollo de software. Si éstos salen a la luz en los estadios finales, resulta en altos costos y riesgos para todo el proyecto.
· Más costos de soporte significan menos dinero para un nuevo desarrollo.
· Desarrolladores de software gruñones significa un equipo de desarrollo menos motivado y eficiente.
· Defectos a finales del ciclo en gran medida afectan la capacidad del equipo para concluir el proyecto, dando lugar a excesos de horario.
· Menor calidad en el producto enviado conduce a menor satisfacción del cliente y reduce el éxito del producto. La baja calidad se traduce rápidamente a reducción de los ingresos.
Con el entendimiento de que los esfuerzos de calidad en las partes finales del ciclo cuestan dramáticamente más y produce menos, ¿cómo un aspirante a gerente de proyectos evitará los escollos y atolladeros de la detección tardía en el ciclo?
· Revisiones de diseño, especificación, y código siguen siendo el método más eficaz para la detección de defectos tempranos.
· Use una metodología de desarrollo iterativa para que las pruebas se lleven a cabo en las olas durante todo el ciclo de desarrollo, no como una masa de fondo del proceso.
· Construya en la capacidad de prueba mediante la adición de numerosos puntos de seguimiento, afirmaciones y ganchos de programación que puede obligar a las condiciones de prueba (por ejemplo, la simulación de una restricción de memoria o falla en el dispositivo cuando no existe).
Posted in: 
.png)
0 comentarios:
Publicar un comentario