Twitter Updates for 2012-10-05
- Bob Mansfield, el hombre al que Apple no deja jubilarse – Tecnología http://t.co/ehm86Uco vía @elconfidencial #
Powered by Twitter Tools
Powered by Twitter Tools
Powered by Twitter Tools
Fuente: http://www.reformingprojectmanagement.com/2003/11/14/273/
A reader asked the group how Scrum compares with Critical Chain Project Management (CCPM).
Scrum is one of several Agile/Lean Software Development techniques. The opposite of Scrum/Agile/Lean is the waterfall development lifecycle where analysis, design, development, system testing, and user acceptance testing are done in sequential phases. Scrum/Agile/Lean works in short iterations – between 1 and 12 weeks each.
[This is a fine example of Goldratt’s Evaporating Cloud]
D - Allow change throughout project B - Build functionality required by customer A - Have a successful software project C - Deliver on time and to budget D'- Agree scope up-front and don't allow change throughout project
[Read the above chart this way: I want (A) a successful software project. To be successful I need (B) to build the functionality required by my customer. And I need (C) to deliver on time and on budget. For me to build the functionality required by my customer I need (D) to allow for change throughout the project. However, for me to deliver on time and budget I need (D’) to agree to the scope up-front and not allow changes throughout the project. (D) and (D’) are in conflict and cannot coexist.]
In a traditional/waterfall environment «change control» is the mechanism used to do both D and D’ poorly.
[Clarke examines three cause and effect assumptions behind the evaporating cloud as it was described. He sets out to invalidate each one.]
[Those of you who use the Last Planner System™ will recognize similarities with Scrum. The backlog of tasks grows, as does a weekly work plan, as the project goes along. Project performers take tasks from the backlog making promises to complete them. The Scrum approach is done or not done. No credit for effort. And very much like lean, people understand their projects as complex and evolving.]
Despite these differences I believe that CC and Scrum are not only complimentary but synergy should be gained by using both together. That said, I don’t know of anyone doing this. Scrum is mostly used in IT along with changed engineering practices, but it has been used in non-IT projects.
fuente: http://www.re-inventa.com/scrum-vs-itil/
¿Está ITIL reñido con Scrum o, por el contrario, son compatibles? Principalmente es una duda que le surge a personas del ámbito de desarrollo de software que están dando sus primeros pasos en el agilismo y que han oído hablar sobre ITIL y sus bondades, aunque todavía no lo conocen con suficiente profundidad.
Pues bien, la respuesta es simple pero compleja al mismo tiempo. ITIL y Scrum, aunque pueden guardar cierta relación, son cosas muy distintas. Están completamente enfrentados a nivel de objetivos y de filosofía subyacente pero, a pesar de ello, pueden compatibilizarse sin que necesariamente haya menoscabo de ninguno de los dos enfoques. En mi opinión, el objetivo tiene que ser obtener lo mejor de ambos mundos y, por experiencia personal, puedo asegurar que se trata de algo completamente factible.
En esta línea, ya escribí una entrada sobre lo que yo denomino Agile ITIL, en la que explico mi experiencia aplicando Scrumban + ITIL en el área de sistemas de Biko. En este post, en cambio, mi objetivo es aclarar en mayor medida cuáles son las diferencias y algunos de los nexos de unión entre Scrum e ITIL.
.
Scrum es una metodología ágil de gestión de proyectos (project management) orientada a ámbitos poco ordenados:
ITIL es un marco predictivo de buenas prácticas en gestión de servicios de TI, que suele aplicarse en ámbitos ordenados:
Aunque llegados a este punto resulta sencillo identificar las diferencias entre Scrum e ITIL, anexo la siguiente tabla que resulta más gráfica:
Además de los puntos ya mencionados en las definiciones, en la tabla he añadido elproceso de mejora continua. Aunque el proceso de mejora de ambas metodologías se basa en la filosofía del ciclo de Deming (PDCA), Scrum, con sus retrospectivas, hace mayor énfasis en el expertise y la percepción de los miembros del equipo (orientación a personas); mientras que ITIL se fundamenta en métricas objetivas relacionadas con el nivel de desempeño de los procesos (orientación a procesos). Obviamente, cada una tiene sus pros y sus contras.
Otro aspecto diferencial es la amplitud de miras. Mientras que el ámbito de Scrum es genuinamente el proyecto, obviando los aspectos a nivel organizacional y confiando en la auto-organización del equipo, ITIL tiene una perspectiva más holística: destaca la relevancia de alinear los proyectos y servicios con las necesidades y los objetivos de negocio, el desarrollo de los profesionales del equipo para que puedan responder a las necesidades organizativas, la gestión del conocimiento, etc. Para tal propósito, ITIL explicita diversos procesos y funciones específicos.
Como puede verse, las diferencias son múltiples y reseñables. Sin embargo, a pesar de ello, existen más nexos de unión entre ambos enfoques de lo que pueda parecer a primera vista. Saber combinar e hibridar las prácticas y herramientas de ambos enfoques de la manera adecuada, es la clave para obtener lo mejor de los dos mundos y un rendimiento extraordinario.
Vamos a poner como ejemplo que nuestro núcleo duro es la gestión de operaciones. Nuestro equipo se dedica a gestionar varios servicios de tecnologías de la información para una organización determinada: administrar y mantener una intranet, un servicio de correo electrónico, un ERP, etc. En este caso, ITIL debería tener un gran peso en la gestión de nuestro día a día.
Sin embargo, llega el momento de implantar un nuevo servicio. Esto se trata de un proyecto en toda regla.
ITIL nos indica aspectos que debemos tener en cuenta en el diseño de dicho servicio: gestión del nivel de servicio, gestión de la disponibilidad del servicio, gestión de la capacidad del servicio, gestión de la seguridad del servicio…
Sin embargo, ITIL no entra en el detalle de cómo debe gestionarse el proyecto de implementación en sí mismo. No habla sobre si el equipo debe ser multidisciplinar o no, ni de los roles que debe haber dentro del equipo, ni cómo deben gestionarse el alcance, el cronograma, la calidad, la comunicación con los interesados o el riesgo.
En este punto es donde fácilmente pueden entrar en juego diversas metodologías y marcos de gestión de proyectos, es más, es más que recomendable incorporarlos. Entre las distintas metodologías, obviamente podemos optar por Scrum. Además, por tratarse de una metodología iterativa, personalmente, la recomiendo con especial profusión. En este punto, Scrum e ITIL tienen una elevada afinidad porque comparten el enfoque PDCA, como ya hemos comentado.
Tomando en cuenta esta perspectiva, parece muy adecuado realizar pruebas piloto (podríamos considerarlas el símil de los prototipos) a usuarios clave durante la fase de transición del servicio y, obviamente, implantar el servicio siguiendo una filosofía incremental; poniendo en vivo primero aquellos aspectos más prioritarios del servicio y desarrollando posteriormente aquellos más accesorios, a medida que se obtiene feedback y fruto de ello se introducen otros cambios. Es más, esta forma de implementar un servicio, que se percibe tan afín a Scrum, sigue al 100% el ciclo de vida de los servicios planteado por ITIL.
Por otra parte, mencionar que dos mecanismos de coordinación de Scrum que son muy valiosos y que pueden incorporarse fácilmente en una organización que ya esté realizando ITIL son el scrum diario o reunión de seguimiento y las reuniones de retrospectiva.
Ahora vamos al caso contrario. Una organización orientada a proyectos, como suele ser la clásica consultora de comunicación online especializada en portales corporativos.
En este entorno, lo que debe predominar es Scrum. No hay dos proyectos iguales y, quienes conozcan bien este ámbito, sabrán que los requerimientos cambian frecuentemente a lo largo del proyecto y que la pericia del equipo de desarrolladores, consultores, etc. juega un papel fundamental en el éxito del proyecto (muy por encima de trazar un buen plan al inicio del proyecto).
Este es un buen ejemplo de cómo podemos enriquecer Scrum con prácticas procedentes de otros enfoques y marcos, ya sean o no ágiles. Por ejemplo: podemos crear un híbrido con Kanban (Scrumban) para gestionar todas esas pequeñas peticiones que nos llegan durante el transcurso de una iteración, podemos incorporar prácticas comoTDD (que viene de XP) para enriquecer nuestro sistema de gestión de la calidad… ytambién podemos incorporar procesos y funciones de ITIL. Por ejemplo:
Aunque las posibilidades son múltiples y sé que se me quedan muchas en el tintero, por no hablar de profundizar en mayor medida y con mayor detalle en las ya expuestas, espero haber cumplido con mi objetivo y haber resuelto las principales dudas que tenían en mente aquellos que alguna vez me han preguntado por el tema.
Obviamente estoy abierto a responder a todas las dudas que me dejéis en la forma de comentarios, así como a entablar un constructivo debate con aquellos que no compartan mi visión sobre la compatibilidad entre Scrum e ITIL. 😉
Fuente: http://en.wikipedia.org/wiki/Critical_chain_project_management
Critical chain project management (CCPM) is a method of planning and managing projects that puts the main emphasis on the resources required to execute project tasks. It was developed by Eliyahu M. Goldratt.
This is in contrast to the more traditional critical path and PERT methods, which emphasize task order and rigid scheduling. A Critical Chain project network will tend to keep the resources levelly loaded, but will require them to be flexible in their start times and to quickly switch between tasks and task chains to keep the whole project on schedule.
Critical chain project management is based on methods and algorithms derived from Theory of Constraints. The idea of CCPM was introduced in 1997 in Eliyahu M. Goldratt’s book, Critical Chain. Application of CCPM has been credited with achieving projects 10% to 50% faster and/or cheaper than the traditional methods (i.e. CPM, PERT, Gantt, etc.) developed from 1910 to 1950s.
From numerous studies by Standish Group and others as of 1998 for traditional project management methods, only 44% of projects typically finish on time, projects usually complete at 222% of the duration originally planned, 189% of the original budgeted cost, 70% of projects fall short of their planned scope (technical content delivered), and 30% are cancelled before completion.[citation needed]
These traditional statistics are mostly avoided through CCPM. Typically, CCPM case studies report 95% on-time and on-budget completion when CCPM is applied correctly. Mabin and Balderstone,[1] in their meta-analysis of seventy-eight published case studies, found that implementing Critical Chain resulted in mean reduction in lead-times of 69%, mean reduction of cycle-times of 66%, mean improvement in due date performance of 60%, mean reduction in inventory levels of 50% and mean increases in revenue / throughput of 68%.
With traditional project management methods, 30% of the lost time and resources are typically consumed by wasteful techniques such as bad multi-tasking, student syndrome, In-box delays, and lack of prioritization.
In project management, the critical chain is the sequence of both precedence– and resource-dependent terminal elements that prevents a project from being completed in a shorter time, given finite resources. If resources are always available in unlimited quantities, then a project’s critical chain is identical to its critical path.
Critical chain is used as an alternative to critical path analysis. The main features that distinguish the critical chain from the critical path are:
CCPM planning aggregates the large amounts of safety time added to tasks within a project into the buffers in order to protect due-date performance, and to avoid wasting this safety time throughbad multitasking, student syndrome, Parkinson’s Law and poorly synchronized integration.
Critical chain project management uses buffer management instead of earned value management to assess the performance of a project. Some project managers feel that the earned value management technique is misleading, because it does not distinguish progress on the project constraint (i.e. on the critical chain) from progress on non-constraints (i.e. on other paths). Event chain methodology can be used to determine a size of project, feeding, and resource buffers.
A project plan is created in much the same fashion as with critical path. The plan is worked backward from a completion date with each task starting as late as possible.
A duration is assigned to each task. Some software implementations add a second duration: one a «best guess,» or 50% probability duration, and a second «safe» duration, which should have higher probability of completion (perhaps 90% or 95%, depending on the amount of risk that the organization can accept). Other software implementations go through the duration estimate of every task and remove a fixed percentage to be aggregated into the buffers.
Resources are assigned to each task, and the plan is resource leveled, using the aggressive durations. The longest sequence of resource-leveled tasks that lead from beginning to end of the project is then identified as the critical chain. The justification for using the 50% estimates is that half of the tasks will finish early and half will finish late, so that the variance over the course of the project should be zero.
Recognizing that tasks are more likely to take more rather than less time due to Parkinson’s law, Student syndrome, or other reasons, «buffers» are used to monitor project schedule and financial performance. The «extra» duration of each task on the critical chain—the difference between the «safe» durations and the 50% durations—is gathered together in a buffer at the end of the project. In the same way, buffers are gathered at the end of each sequence of tasks that feed into the critical chain. It is the date at the end of the project buffer that is communicated to external stakeholders as the delivery date.
Finally, a baseline is established, which enables financial monitoring of the project.
An alternate duration-estimation methodology uses probability-based quantification of duration using Monte Carlo simulation. In 1999, a researcher[who?] applied simulation to assess the impact of risks associated with each component of project work breakdown structure on project duration, cost and performance. Using Monte Carlo simulation, the project manager can apply different probabilities for various risk factors that affect a project component. The probability of occurrence can vary from 0% to 100% chance of occurrence. The impact of risk is entered into the simulation model along with the probability of occurrence. The Monte Carlo simulation runs over 10,000 iterations and provides a density graph illustrating the overall probability of risk impact on project outcome.
When the plan is complete and the project ready to kick off, the project network is fixed and the buffers size is «locked» (i.e. their planned duration may not be altered during the project), because they are used to monitor project schedule and financial performance.
With no slack in the duration of individual tasks, the resources are encouraged to focus on the task at hand to complete it and hand it off to the next person or group. The objective here is to eliminate bad multitasking. This is done by providing priority information to all resources. An analogy is drawn in the literature with a relay race. Each element on the project is encouraged to move as quickly as they can: when they are running their «leg» of the project, they should be focused on completing the assigned task as quickly as possible, with minimization of distractions and multitasking. In some case studies, actual batons are reportedly hung by the desks of people when they are working on critical chain tasks so that others know not to interrupt. The goal, here, is to overcome the tendency to delay work or to do extra work when there seems to be time. The CCPM literature contrasts this with «traditional» project management that monitors task start and completion dates. CCPM encourages people to move as quickly as possible, regardless of dates.
Because task durations have been planned at the 50% probability duration, there is pressure on the resources to complete critical chain tasks as quickly as possible, overcoming student’s syndrome and Parkinson’s Law.
Monitoring is, in some ways, the greatest advantage of the Critical Chain method. Because individual tasks will vary in duration from the 50% estimate, there is no point in trying to force every task to complete «on time;» estimates can never be perfect. Instead, we monitor the buffers that were created during the planning stage. A fever chart or similar graph can be easily created and posted to show the consumption of buffer as a function of project completion. If the rate of buffer consumption is low, the project is on target. If the rate of consumption is such that there is likely to be little or no buffer at the end of the project, then corrective actions or recovery plans must be developed to recover the loss. When the buffer consumption rate exceeds some critical value (roughly: the rate where all of the buffer may be expected to be consumed before the end of the project, resulting in late completion), then those alternative plans need to be implemented.