Hace unos minutos me enteré de una lamentable perdida... Para todos los involucrados en la mejora, saben y reconocen el trabajo de Watts Humphrey.
http://www.sei.cmu.edu/newsitems/Humphrey_obituary.cfm
Lamentable ausencia física.
jueves, 28 de octubre de 2010
martes, 27 de julio de 2010
SPI MANIFESTO
Values
People – Must involve people actively and affect their daily lives not to be focused on management alone
Business – What you do to make business successful – this is not about living to deploy a standard, reach a maturity level, or obtain a certificate even though it can certainly help do all of those things
Change – Process improvement is inherently linked with change – we realize and accept that we cannot continue to live as we do today – we must change – perhaps a little or perhaps a lot
Principles
People
Know the culture and focus on needs
Motivate all people involved
Base improvement on experience and measurements
Create a learning organization
—
Business
Support the organization’s vision and business objectives
Use dynamic and adaptable models as needed
Apply risk management
—
Change
Manage the organizational change in your improvement effort
Ensure all parties understand and agree on process
Do not lose focus
__
What is this?
In September 2009 a group of experts in Software Process Improvement (SPI) from all over the world gathered in connection with the EuroSPI Conference for a workshop at Universidad de Alcalá in Spain.
EuroSPI's mission is to develop an experience and knowledge exchange platform for Europe where SPI practices can be discussed and exchanged and knowledge can be gathered and shared. At the workshop 15 experts presented their ‘wisdom’ grounded in many years of process improvement experience. Based on the presentations, 30 workshop participants brainstormed core values and principles specifically for process improvement. Via affinity analysis and group thinking exercises we ended up with a manifesto for SPI. At the end of the workshop 4 values and 14 principles were identified. Among the group of participants, authoring
responsibilities were distributed on a voluntary basis backed by personal justification. Some values and principles were focused on by more then one volunteer. By mid-October 2009 all the contributions were available to the editors, who edited the document thoroughly. A number of principles were written with considerable overlap so it was obvious that they should be consolidated.
The same consolidation needs were applied to one of the values. The editors restructured the documented and edited the text so that it introduces itself in a uniform style. The result was a document with three core values and eleven principles. This document was ready in November 2009. Eight reviewers read the resulting document and commented thoroughly. Finally all the comments were addressed in this final version from January 2010, including a joining of two principles and a shorter formulation of the principles – so the final document consists of three values and ten principles. A final review was performed by Tim Kasse.
Manifest – what is that?
A ‘manifest’ makes things clear and obvious or evident. This manifest gives expression to state-of-the-art knowledge on SPI. It is based on hundreds of person-years of practice and experience from organisations worldwide.
What to use the manifest for?
You can use the manifest to obtain knowledge on SPI. It will help you to remember what is important about Software Process Improvement? Each value and the consequent principles are written so you can easily place yourself into the problem and its context. Short explanations for each value are provided that can further augment your understanding. Each value also has some relevant examples that will make it easier to learn and remember the values and principles. You can use the manifest when you are responsible for planning a SPI project. The third manifest value states that SPI is actually really about change. Thus, you can apply the principles in your SPI project that will support the necessary corresponding change in the organisation.
We hope you enjoy reading the manifesto and find the contents useful.
Jan Pries-Heje and Jørn Johansen
People – Must involve people actively and affect their daily lives not to be focused on management alone
Business – What you do to make business successful – this is not about living to deploy a standard, reach a maturity level, or obtain a certificate even though it can certainly help do all of those things
Change – Process improvement is inherently linked with change – we realize and accept that we cannot continue to live as we do today – we must change – perhaps a little or perhaps a lot
Principles
People
Know the culture and focus on needs
Motivate all people involved
Base improvement on experience and measurements
Create a learning organization
—
Business
Support the organization’s vision and business objectives
Use dynamic and adaptable models as needed
Apply risk management
—
Change
Manage the organizational change in your improvement effort
Ensure all parties understand and agree on process
Do not lose focus
__
What is this?
In September 2009 a group of experts in Software Process Improvement (SPI) from all over the world gathered in connection with the EuroSPI Conference for a workshop at Universidad de Alcalá in Spain.
EuroSPI's mission is to develop an experience and knowledge exchange platform for Europe where SPI practices can be discussed and exchanged and knowledge can be gathered and shared. At the workshop 15 experts presented their ‘wisdom’ grounded in many years of process improvement experience. Based on the presentations, 30 workshop participants brainstormed core values and principles specifically for process improvement. Via affinity analysis and group thinking exercises we ended up with a manifesto for SPI. At the end of the workshop 4 values and 14 principles were identified. Among the group of participants, authoring
responsibilities were distributed on a voluntary basis backed by personal justification. Some values and principles were focused on by more then one volunteer. By mid-October 2009 all the contributions were available to the editors, who edited the document thoroughly. A number of principles were written with considerable overlap so it was obvious that they should be consolidated.
The same consolidation needs were applied to one of the values. The editors restructured the documented and edited the text so that it introduces itself in a uniform style. The result was a document with three core values and eleven principles. This document was ready in November 2009. Eight reviewers read the resulting document and commented thoroughly. Finally all the comments were addressed in this final version from January 2010, including a joining of two principles and a shorter formulation of the principles – so the final document consists of three values and ten principles. A final review was performed by Tim Kasse.
Manifest – what is that?
A ‘manifest’ makes things clear and obvious or evident. This manifest gives expression to state-of-the-art knowledge on SPI. It is based on hundreds of person-years of practice and experience from organisations worldwide.
What to use the manifest for?
You can use the manifest to obtain knowledge on SPI. It will help you to remember what is important about Software Process Improvement? Each value and the consequent principles are written so you can easily place yourself into the problem and its context. Short explanations for each value are provided that can further augment your understanding. Each value also has some relevant examples that will make it easier to learn and remember the values and principles. You can use the manifest when you are responsible for planning a SPI project. The third manifest value states that SPI is actually really about change. Thus, you can apply the principles in your SPI project that will support the necessary corresponding change in the organisation.
We hope you enjoy reading the manifesto and find the contents useful.
Jan Pries-Heje and Jørn Johansen
domingo, 11 de julio de 2010
Cambios planeados para CMMI 1.3
Uno de los cambios que me parecen interesantes, y que por supuesto ha notificado el SEI para la versión 1.3 de CMMI-DEV es:
REQM ya no estará en las PA´S de INGENIERÍA, ya que formará parte de las áreas de procesos de ADMINISTRACIÓN DE PROYECTOS.
REQM ya no estará en las PA´S de INGENIERÍA, ya que formará parte de las áreas de procesos de ADMINISTRACIÓN DE PROYECTOS.
jueves, 8 de julio de 2010
Arquitectura de software, en menos de 59 palabras
Es la estructura o estructuras del sistema, incluye los elementos de software, las propiedades externas visibles, así como sus relaciones.
Una abstracción que describe los elementos de software.
Direcciona las responsabilidades, comportamientos y propiedades de los elementos de software
Es un vehículo para la comunicación.
Es una abstracción transferible y reusable.
Fuente:
Software Architecture Fundamentals: Technical, Business, and Social Influences
Webinar
SEI
Una abstracción que describe los elementos de software.
Direcciona las responsabilidades, comportamientos y propiedades de los elementos de software
Es un vehículo para la comunicación.
Es una abstracción transferible y reusable.
Fuente:
Software Architecture Fundamentals: Technical, Business, and Social Influences
Webinar
SEI
jueves, 24 de junio de 2010
Administración de la configuración...
Me encantó...
Administración de la configuración: Saber lo que tienes en el refrigerador y cuando poder comerlo...
__
CMMIusuarios, gran analogía :)
Tomado del Nick de Ernesto Corona, LA.
Administración de la configuración: Saber lo que tienes en el refrigerador y cuando poder comerlo...
__
CMMIusuarios, gran analogía :)
Tomado del Nick de Ernesto Corona, LA.
lunes, 14 de junio de 2010
Necesito implementar CMMI, ¿Por dónde inicio?
Hace un par de días recibi la pregunta que da título al presente post -en modo pánico o modo desesperación-...
Antes que implementar cualquier modelo de mejora de procesos es importante saber que se necesita, o dicho de mejora manera el objetivo de la organización o empresa... Si no tienes claro que necesitas tener o ser, entonces lo primero que debes preguntarte es que problemas necesitas eliminar de tu organización...
Para ciertas organizaciones está claro que necesitan tener productos de calidad, mejorar el servicio al cliente y por ende reducir los costos de operación... Sin embargo podríamos iniciar desde eliminar mermas, estandarizar la manera de trabajo y especificar los costos que genera todo el proceso de producción y servicio en nuestra empresa... O como dijera Silvio, que no es lo mismo pero es igual, lo que se busca es mejorar organizacionalmente...
El implementar mejoras no obedece a ser los primeros en usar un modelo, o ser los primeros en certificarse u obtener un nivel de madurez, requiere de claridad de objetivos y claridad de visión...
Me ha tocado platicar con empresas que solo quieren implementar CMMI por que su proveedor se los requiere, o porque la mayoría de las empresas de la región están obteniendo cierto nivel de madurez, y porque requieren estratégicamente tener una bandera en la que se sustenten para poder venderse...
El fin justifica los medios, dicen varios, sin embargo creo que es de suma relevancia localizar el verdadero origen de la iniciativa, y para eso hay varias justificaciones, y si ponemos como pauta principal el mejorar la manera de trabajo, eliminar vicios y reducir costos, ¿A qué empresa no va a interesarle lo anterior?
Ahora también es importante no perder de vista que, al manejar una iniciativa por terceros, es imperativo mostrar las razones por las cuales arrancaremos el proyecto de mejora (la organización que quiere mejorar)... La manera en la que el tercero (consultor, empresa de consultoria), les esquematice el mapa bajo el cual alcanzaran la meta (de una manera muy sencilla), es la referencia básica bajo la cual implementaran las mejoras... Si no saben esquematizarlo, explicarselo o peor aún no viene explicado en la propuesta en cuestión, olvide seguir con ellos... Si no saben como llegar, no sabrán como ayudarle...
Si usted es curioso, y decide iniciar el proyecto por su cuenta, no olvide revisar previamente el ciclo de Deming, le será de mucha utilidad y no le quitará más de una hora el revisar resumenes asociados...
Respuesta concreta, se inicia por el principio y eso es, saber qué se quiere mejorar y por qué.
Antes que implementar cualquier modelo de mejora de procesos es importante saber que se necesita, o dicho de mejora manera el objetivo de la organización o empresa... Si no tienes claro que necesitas tener o ser, entonces lo primero que debes preguntarte es que problemas necesitas eliminar de tu organización...
Para ciertas organizaciones está claro que necesitan tener productos de calidad, mejorar el servicio al cliente y por ende reducir los costos de operación... Sin embargo podríamos iniciar desde eliminar mermas, estandarizar la manera de trabajo y especificar los costos que genera todo el proceso de producción y servicio en nuestra empresa... O como dijera Silvio, que no es lo mismo pero es igual, lo que se busca es mejorar organizacionalmente...
El implementar mejoras no obedece a ser los primeros en usar un modelo, o ser los primeros en certificarse u obtener un nivel de madurez, requiere de claridad de objetivos y claridad de visión...
Me ha tocado platicar con empresas que solo quieren implementar CMMI por que su proveedor se los requiere, o porque la mayoría de las empresas de la región están obteniendo cierto nivel de madurez, y porque requieren estratégicamente tener una bandera en la que se sustenten para poder venderse...
El fin justifica los medios, dicen varios, sin embargo creo que es de suma relevancia localizar el verdadero origen de la iniciativa, y para eso hay varias justificaciones, y si ponemos como pauta principal el mejorar la manera de trabajo, eliminar vicios y reducir costos, ¿A qué empresa no va a interesarle lo anterior?
Ahora también es importante no perder de vista que, al manejar una iniciativa por terceros, es imperativo mostrar las razones por las cuales arrancaremos el proyecto de mejora (la organización que quiere mejorar)... La manera en la que el tercero (consultor, empresa de consultoria), les esquematice el mapa bajo el cual alcanzaran la meta (de una manera muy sencilla), es la referencia básica bajo la cual implementaran las mejoras... Si no saben esquematizarlo, explicarselo o peor aún no viene explicado en la propuesta en cuestión, olvide seguir con ellos... Si no saben como llegar, no sabrán como ayudarle...
Si usted es curioso, y decide iniciar el proyecto por su cuenta, no olvide revisar previamente el ciclo de Deming, le será de mucha utilidad y no le quitará más de una hora el revisar resumenes asociados...
Respuesta concreta, se inicia por el principio y eso es, saber qué se quiere mejorar y por qué.
sábado, 5 de junio de 2010
"Establish and maintain"
"Establish and maintain" - Establecer y mantener, en el modelo CMMI, implica más que la simple traducción... Significa que para ejercer la política recopilación de requerimientos (por ejemplo), en una empresa, división u organización es necesario: formular la política, definirla documentalmente, mantenerla actualizada y lo más importante: usarla.
Suscribirse a:
Entradas (Atom)