Reescribiendo la función buggiest en el sistema ofrece mucho más beneficio que trabaja en un área relativamente estable. Lo mismo vale para las organizaciones: si los vendedores cerrar docenas de ofertas, pero no hay programadores para crear el vaporware, gastando más dinero capacitar a los vendedores no ayudarán. Fijar el equipo de desarrollo. Esto es obvio, pero noción de identificación de la debilidad de una organización de software fue el germen de la idea se describe a continuación.
He trabajado con decenas de organizaciones a través de los años, y todos tienen sus puntos fuertes y débiles. Me han pedido en numerosas ocasiones para evaluar “¿cómo va nuestro proceso de desarrollo de software?” Ciertamente puedo cavar y ver sus debilidades, pero que tengan un sistema de calificación externa, como la tabla de abajo, permite que la recomendación más razonado.
La siguiente tabla resume las categorías de software de la madurez de desarrollo dentro de una organización. Fue inspirado por el CMM (Capability Maturity Model), pero de ninguna manera se trata de emular.
Para utilizar esta tabla, evaluar primero donde la organización es con respecto a cada área. Desde mi experiencia, la mayoría de la organización no se ajusta simplemente en un nivel de madurez, en lugar diferentes niveles en diferentes áreas. Ellos son mejores en algunas cosas más que otras. Por ejemplo, es común tener control de código fuente funciona bien, pero no existe un sistema de seguimiento de errores.
Una vez que haya hecho esta evaluación, las organizaciones fuertes y débiles serán más evidentes. El CMM eco que antes de llegar a la madurez en un área, y la organización debería abordar las otras áreas en primer lugar. Esto simplemente significa que se centran en la mejora de las áreas donde es más débil. Centrándose en las áreas más débiles proporcionará el mayor beneficio para la inversión cambio organizativo. Esa fue la idea detrás de esta tabla poniendo juntos.
El nivel 1 es el nivel más bajo. A menudo se caracteriza por “sorpresas”. Se indica por una organización de software que ha entregado una pieza de software, y por desgracia, muchas organizaciones no están en este nivel.
Nivel 2 organizaciones han entregado el software, pero siempre sin contratiempos significativos. A menudo se caracteriza por “decepción”. Hay fallos de encendido, proyectos abandonados, pero el software se apagan.
El nivel 3 es la organización de software madura que disponga de las personas y proyectos alineados. Oportunidades se identifican, software creado, y los clientes satisfechos. No habrá errores, pero se identifican tan pronto como sea posible.
| Requisitos, el producto y la gestión de proyectos | ||
|---|---|---|
| el software de trabajo se describen los requisitos; futuros requisitos pueden ser identificados, pero son priorizados por la ONU, incompleta; el proceso es caótico o ad hoc; cambiando de forma rápida visión del producto; el éxito puede requerir heroísmo; fracasos; proyectos abandonados | gestión de proyectos activos, los éxitos consistentes; publicado, los requisitos (o historias de usuario) priorizado; combinado con simulacros de incendio, comunicados con retraso o con errores; el proceso de desarrollo de productos se define, aunque no necesariamente seguidos o efectiva | el éxito predecible; ágil, eficiente, maximizar el valor; institucionalizada, optimizando; ambos planes estratégicos y tácticos, con la capacidad de ser oportunista; rara vez construir funciones de bajo valor; comprensión del proceso compartido; capacidad de volver a dar prioridad a los requisitos de manera eficiente; estimaciones fiables; gestión de riesgos |
| Equipo de programación | ||
| los individuos construyen los productos | equipo funcional, propiedad del código, el código de la guía de estilo; diseños compartida según sea necesario | propiedad del código compartido, los diseños de software comunes, modelos y estrategias; cumplimiento estilo de código, revisiones de código; el desarrollo profesional, el entrenamiento cruzado; |
| Código | ||
| “Hey, ¡funciona!”; conocimiento silo-ed; código de campos de minas y zonas con errores; soluciones locales; áreas de legado no modificables | funciona bien; algunas áreas problemáticas legado; conceptos centrales del negocio validados y documentados; duplicar soluciones a los mismos problemas | propiedad colectiva; consistencia; organizado; patrones y herramientas modernas; herramientas modernas integradas |
| Control de calidad | ||
| sistema de seguimiento de defectos incluye post-its y listas de tareas pendientes; para el control de calidad, todos los chips en, o “equipo de ventas se ve por encima” | sistema de seguimiento de defectos, plan de control de calidad; pruebas funcionales; puede tener algunas pruebas automatizado, la unidad de pruebas; la mayoría de los cambios pasan por las pruebas del sistema, pero pueden ser arreglos de emergencia que se saltan el proceso de | integrado en el desarrollo; integración continua, las métricas de cobertura de código, otras métricas de software, según sea necesario; plan de control de calidad en su lugar y ejecutado |
| Herramientas de programación | ||
| herramientas (editores, compiladores, etc.) | herramientas profesionales modernos | herramientas unificadas, modernos y profesionales |
| Fuente de gestión de código y se basa (gestión de la configuración) | ||
| tener el código fuente en la mano, copias de seguridad, comunicados numeradas | herramienta moderna como SVN, CVS, Git, p4, etc .; sobre todo script del poder construye | vinculación de los cambios de código a los requisitos y los insectos; visibilidad y métricas en el código; completamente con guión y automatizado construye; |
| Proceso de liberación | ||
| determinada (o retraso) por la calidad del software y la terminación característica | programado basándose en la finalización función a intervalos regulares; primeras características sacrificios de planificación; finales de sacrificio de calidad o la fecha de envío | calidad siempre liberable; mantener la calidad y fecha de lanzamiento; sacrificar características de bajo valor |
Derechos de autor (c) 2007-2016 NDP software. Todos los derechos reservados.
Recent Comments