agile - servicios - metodologia six sigma pdf
Gestión de la calidad Six Sigma y desarrollo de software (10)
¿Es posible utilizar Six Sigma Quality Management con los Procesos de Desarrollo de Software?
¿Cuál es tu experiencia en eso?
Si está utilizando un método ágil como Scrum o XP, ¿no es Six Sigma demasiado burocrático?
Me refiero a la gestión de calidad en el desarrollo de software en general, desde la recopilación de requisitos hasta el despliegue y las operaciones, y no solo la fase de construcción (herramientas como TDD y pruebas unitarias que ya están establecidas como mejores prácticas).
He utilizado una amplia gama de metodologías, Six Sigma, Agile, etc. En realidad, el éxito de la gestión de calidad en el desarrollo de software depende de una cosa clave. La codicia del equipo Todo se reduce a eso. Un buen equipo puede trabajar dentro de una metodología horrible y hacer que funcione. Por eso son buenos. El proceso es importante y puede hacer que un mal proceso sea más eficiente, pero todo depende del equipo.
Para que Six Sigma sea útil, necesita métricas o procedimientos fácilmente comparables.
El software es demasiado abstracto para tener el tipo de métricas necesarias.
Tal vez una buena pregunta para hacer sería
¿Existe alguna herramienta de control de calidad para el desarrollo de software similar a Six Sigma para el mundo de producción y fabricación?
Si lo entiendo correctamente, Six Sigma depende de tener métricas significativas y mensurables. ¿Cuál será el tuyo? KLOC? Clases registradas en tu archivo? Velocidad Agile?
Six Sigma funciona muy bien en las plantas de las tiendas, pero no creo que el desarrollo de software sea lo suficientemente "similar a un artilugio" para adaptarse a dicho enfoque.
Six Sigma funciona bien con procesos reproducibles. Con eso, me refiero a un proceso puro que produce consistentemente (o se supone que produce) el mismo resultado. Dado que el desarrollo de software rara vez produce el mismo resultado, SS no es realmente aplicable, IMO. Esto se debe a que el desarrollo de software es más una práctica que un proceso.
Una vez dicho esto, no hace daño leer sobre él y tratar de ver qué ideas de alto nivel se pueden poner en el desarrollo de software ...
Six Sigma puede ser una buena opción para los equipos de mantenimiento que tienen una gran acumulación de elementos de trabajo discretos.
Design for Six Sigma tiene algunos elementos que se pueden aplicar a la creación de un nuevo producto de software.
Y dado que la mayoría del software es un habilitador para un proceso empresarial, y ese proceso comercial puede ser un proceso altamente repetido donde se pueden aplicar las herramientas estadísticas de Six Sigma, Six Sigma puede ser un factor determinante para entregar el software más valioso valor de negocio máximo. Puede eliminar la emoción del proceso de toma de decisiones para la priorización de características. Si tiene un entorno en el que el gerente de producto / actor que grita más fuerte o más elocuentemente tiene sus cosas construidas, se puede aplicar Six Sigma para corregir ese aspecto insalubre de su proceso de desarrollo al poner alguna medida racional detrás del proceso de priorización.
Definitivamente es posible siempre y cuando no esté desarrollando un nuevo producto.
Solo sigue estos pasos.
1) Crea una versión libre de errores de la aplicación. Esto puede requerir una considerable cantidad de esfuerzo, por lo tanto, es mejor seleccionar una aplicación que sea de alcance trivial.
2) Vuelva a crear la aplicación desde cero y compare la iteración con el ideal creado en el paso 1 para crear una métrica.
3) Ajuste su proceso para lograr una alineación más cercana junto a la métrica en la siguiente iteración.
4) Ve al paso 2.
¿Qué? ¿No creas la misma aplicación una y otra vez en tu tienda? Hmm, no creo que Six Sigma vaya a ser de mucha utilidad en ese escenario.
Tenía un profesor en una clase que enseñaba seis sigma y otras técnicas de eficiencia de fabricación, y después de decirle que estaba en el campo del desarrollo de software sugirió el libro Lean Software Development . Desafortunadamente no lo he leído, pero parece que se trata de aplicar algunos de los conceptos aplicables de Six Sigma y Lean Manufacturing a la producción de software (como eliminar desperdicios, reducir defectos, mejorar continuamente). Aquí hay un libro blanco corto que describe el desarrollo de software lean.
Hay partes del desarrollo de software que no encajan bien, ya que no proporcionan un proceso con una distribución normal de resultados. Por otro lado, el enfoque en el riesgo, el valor y hacer las cosas bien es esencial
[edit] Eche un vistazo al modelo Cynefin (en wikipedia) para comprender por qué grandes partes del desarrollo de software se encuentran en el dominio complejo.
He utilizado Six Sigma para proyectos específicos de pruebas de rendimiento que comienzan con una declaración de problemas medible específica y finalizan con una medida de contador que nuevamente se puede medir. El DMAIC se presta a la optimización del rendimiento, al igual que las herramientas y técnicas de análisis causal, diseño de experimentos, etc.
No estoy seguro de seguirte.
SixSigma es una metodología para gestionar las variaciones de procesos que utiliza datos y análisis estadísticos para medir y mejorar el rendimiento operativo de una empresa.
Así que tome cualquier proceso (SDP u otro), elija lo que quiere medir, identifique los problemas, planifique las soluciones, evalúe los impactos.
Los proyectos de SixSigma en los que participé fueron bastante transversales y no están vinculados a un ciclo de vida del software.
Por transversal, quiero decir transversal al proceso de "diseño-desarrollo-construcción-entrega del producto" que es desarrollo de software.
Por ejemplo, en un entorno en el que necesitamos producir un conjunto de programas que se ejecutan en nuestra plataforma de producción interna, la mayoría de nuestros proyectos SixSigma se centran en la Arquitectura Operacional , que es "hacer operativo un entorno de ejecución" (cómo configurar servidores y redes para detener, actualizar, instalar y ejecutar un conjunto de ejecutables, y eso para muchos proyectos, cada uno con su propio SDP).
Esa es una noción transversal a cualquier SDP que desee, ya que al final, todos esos "Procesos de Desarrollo" tienen un solo objetivo en común: poner su software en producción.
Los criterios de medición fueron precisos y reproducibles, desde el momento en que se administraron las fusiones necesarias para consolidar un ejecutable final hasta el número de errores de combinación y los errores de implementación (debido a etiquetas incorrectas o notas de versiones defectuosas).
Todos esos pasos en falso se publicaron después del lanzamiento, y el objetivo era reducirlos.
Un efecto secundario fue identificar un flujo de trabajo de fusión inadecuado, flujo de trabajo que, una vez solucionado, nos permitió reducir en gran medida los errores en el conjunto final de entregas.