Unconference.

Descubrí el formato Open Space en Agile Open Spain 2009 y me sorprendió lo maravillosamente bien que funcionó, pero asigne la responsabilidad de su éxito a la buena onda que nos embriagó a todos los que participamos en aquel sorprendente y exitoso evento.

Hoy he vuelto a toparme con este enfoque de reunión al leer Understanding the Unconference donde he vuelto a leer los principios de un Open Space:

1) Whoever comes is the right people,

2) Whatever happens is the only thing that could have,

3) Whenever it starts is the right time, and

4) When it’s over, it’s over.

o lo que es lo mismo:

Cualquier persona que se presente en una reunión es la persona adecuada (cualquier participante en una reunión es correcto simplemente por que se ha preocupado en venir).

Cualquier cosa que esté sucediendo es la única cosa que podremos llegar a tener (estate atento a lo que está pasando ahora, en lugar de preocuparte sobre lo que podría pasar).

Sea cual sea el momento en que comience, es el momento correcto (este principio ayuda a superar la falta de un horario o agendas previo al Open Space y enfatiza la creatividad y la innovación).

Cuando se acabó, se acabó (fomenta que los participantes no desperdicien el tiempo y, por el contrario, que cambien a otro tema cuando una discusión fructífera deja de serlo).

y un enlace me llevo a otro enlace ( blog unconference) dónde encontre las siguientes presentaciones:

y por último, o quizás en el medio, llegué a Opening Space for Peace and High Performance dónde encontré Tales of Open Space, libro gratuito donde nos cuentan el origen de Open Space.

Contratos “ágiles”.

Al poco de descubrir SCRUM, o las metodologías ágiles en general, creo que a todos nos entra la duda de si seremos capaces de venderlas a nuestros clientes. Para ayudar a disipar esta duda Ángel Medinilla hizo esta presentación:

que hoy he descubierto podemos complementar con esta otra de Rachel Weston y Chris Spagnuolo de Rally Software:

IPMA y The APM Group firman un acuerdo de colaboración.

A estas alturas es difícil que se pueda cuestionar que la disciplina de “Dirección de proyectos” está despertando interés e incorporándose a la empresa. Quizás nos gustaría que fuese más deprisa, que cuando nuestras alumnos sonrían esa sonrisa no sea irónica sino de satisfacción por validar en clase lo que en ven en su trabajo, que hubiese más herramientas que soportasen nuestro trabajo en lugar de ser nosotros quien soportemos o suframos las herramientas…

Pero estamos avanzando y podemos mirar al futuro con optimismo o al menos yo me atrevo a hacerlo y creo que IPMA y The APM Group hacen lo mismo al firmar un acuerdo de colaboración con los siguientes objetivos:

• To publicise the mapping between ICB.3® and PRINCE2® as developed by GAPPS and verified by IPMA and APM Group.
• To encourage IPMA members and PRINCE2® qualified people to research and write articles comparing and contrasting the ICB.3® and PRINCE2®.
• To recognize that PRINCE2 provides knowledge and understanding of a number of the concepts included in the ICB.3® and in due course IPMA will develop supplementary exams to enable PRINCE2® Practitioners to achieve appropriate IPMA qualifications i.e. at levels C & D.
• To raise awareness of the IPMA member association’s individual membership schemes among the APM Group’s examination candidates.
• To bring the IPMA member associations´ corporate membership schemes to the attention of the APM Group’s Accredited Organizations.

Enhorabuena por el acuerdo y a seguir todo trabajando para mejorar y divulgar la Dirección de proyectos.

•  

¿El project management tiene sexo?

 

Pues parece que sí. En los últimos meses he asistido a varias reuniones tanto del PMI como de Agile Spain y las mujeres que asisten no representan más del 30% de los asistentes. Ayer en la reunión mensual de PMI de Madrid esa era la situación.

Quizás es el reflejo de la realidad en España dónde aún no hemos llegado ni a una igualdad de oportunidades ni de sueldos para las mujeres o, quizás, simplemente que no es una profesión atractiva para ellas por motivos que desconozco.

Este jueves en el Segundo Encuentro de Directores de Proyecto del PMI de Madrid tendremos una nueva oportunidad de validar esta situación aunque entre los registrados en LinkedIn vuelven a repetirse las proporciones, 8 a 2.

Que alguien me explique esto para intentar ponerle remedio. Que quede claro: ¡La dirección de proyectos no es una profesión de hombres, la dirección de proyectos no tiene sexo!

Actualización:

Poco después de haber escrito este artículo encuentro este otro que viene a cuento: Project Management Battle of the Sexes

Mis recomendaciones. Semana 38.

 

In English:

Better projects. The zen of scrum. Fantasctic presentation about SCRUM.

Chief Happiness Officer. How NOT to lead geeks. 

 

En español:

Jesús Encinar. 10 consejos sobre como gestionar un equipo.

nodos en la red. Minimum Vaible Product (MVP). ¿Los proyectos necesitan desde el principio todos los requisitos identificados?

La masa, el ladrillo, la bota, el bocadillo… Software e innovación… innovación y software: ¿existe un proceso? Interesantísimo el proyecto ITEI en el que está participando Rodrigo Corral

El blog de Pablo Fernando Sánchez. Captura de requerimientos: Más sobre RCL. Sobre el nuevo proyecto del IEEE para desarrollar un lenguaje estándar para la captura de requisitos.

Algunas referencias interesantes. 5-sep-2009

He encontrado algunas referencias que creo os podrá resultar interesantes. Aunque las voy publicando en Twitter entiendo que no todos me seguís por este medio. Ahí van:

• Project Management en procesos de cambio:

Presentación realizada por José Luis Muñoz Manazas el 2 de marzo de 2009 y disponible en el portal de capítulo del PMI de Madrid. A destacar la presentación de la curva “J” como herramienta de cambio.

• La credibilidad del jefe de proyecto:

En este artículo Alfonso Bucero nos explica la importancia que tiene obtener la confianza de nuestro clientes por medio de la credibilidad ganada a través del cumplimiento de nuestros compromisos.

• 101 claves de tecnologías de la información para directivos.

Libro que puedes descargar gratuitamente. Capítulos:

•  
  • Gestionar clientes
  • Gestionar negocios
  • Gestionar rendimiento
  • Gestionar talento
  • Gestionar usuarios
  • Gestionar información
  • Gestionar comunidades

Espero poder sacar tiempo para leerlo y comentarlo.

El jefe de proyecto debe conocer la tecnología… resultados y algunas conclusiones.

El pasado 23 de julio cree dos encuestas, una en este blog y otra en Linkedin, ambas con la misma pregunta: ¿El jefe de proyecto debe conocer la tecnología utilizada en el desarrollo del proyecto? Estos son los resultados parciales:

 

 

y este es el resultado agregado:

 

 

Pero antes de continuar quiero agradecer a todos los que han participado en la cuesta, y especialmente a aquellos que han dejado mensajes, su participación: ¡MUCHAS GRACIAS!

Aunque quizás lo parezca no es éste un asunto ni sencillo ni trivial. Aunque podemos centrar la reflexión en proyectos de tecnología dentro de este subconjunto hay una diversidad enorme en la que habría que manejar muchas variables como tamaño (en esfuerzo, número de participantes,…), dispersión geográfica del equipo y del proyecto, multiculturalidad, duración del proyecto, tipo de proyecto: de infraestructuras, desarrollo, implantación de soluciones empresariales; entre otras variables. Por lo tanto, la pregunta, con respuestas cerradas, es muy limitada.

Que no hay una solución válida para todos los posibles escenarios parece obvio, pero es indudable que la opinión mayoritaria es que un jefe de proyecto debe conocer la tecnología con la que se va a desarrollar el proyecto. Y esto es así quizás porque estamos mirando hacia adentro, hacia el equipo que va a realizar el proyecto y consideramos imprescindible una comunicación fluida y un liderazgo técnico sobre el equipo. Esto, sin duda, es imprescindible en equipos pequeños, menos de 10 personas, y con requisitos claros. Pero no todos los proyectos son así.

Echemos un vistazo a algunas opiniones sobre los principales motivos por los que fracasan los proyectos.

• Encuesta en allPM: In your experience, the #1 reason projects fail is…

• Estudio realizado en 2007 por Computer Associates en 2007. Los tres principales motivos del fracaso de los proyectos:
  • poor forecasting (50%),
  • project scope increasing during implementation (39%), and
  • issues of interdependencies and conflicts between multiple projects (36%).

Referencias:

Over budget IT projects costing UK Plc £256m* per year

New research into IT project failures

 

• Chaos Report

 

• Capers Jones: entrevista en Lider de Proyecto.com

Las cuatro razones principales por la que fracasan los proyectos son:

1) Estimaciones tempranas son inexactas y rechazadas por los clientes;

2) El control de calidad no es muy bueno;

3) El control de cambio no es muy bueno;

4) El rastreo del progreso es sumamente malo.

 

• Study: 68 percent of IT projects fail

According to new research, success in 68% of technology projects is “improbable.” Poor requirements analysis causes many of these failures, meaning projects are doomed right from the start.

Referencias:

The Impact of Business Requirements on the Success of Technology Projects de IAG Consulting

La definición de los requisitos es crítica.

 

Todos los estudios u opiniones anteriores coinciden en un aspecto:

La definición del alcance, de los requisitos, y la gestión del cambio es probablemente el aspecto más importante en la gestión de los proyectos.

 

y esta es una visión más global, una visión de 360 grados que abarca a todos los stakeholders, a todos los interlocutores del proyecto y no solo al equipo de ejecución del mismo.

Esto hace importante, podríamos decir que imprescindible, que el jefe de proyecto deba conocer el entorno del proyecto para así poder entender los requisitos del mismo. Pero qué es el entorno del proyecto. Desde mi punto de vista el entorno incluye aspectos como los siguientes no indicando el orden una prioridad de unos sobre otros:

• Sector económico: Banca, industria, administración pública, etc.
• Empresa: conocimiento de la empresa y sus particularidades en el que se desarrolla el proyecto.
• Departamento de la empresa: finanzas, compras, ventas, operaciones,…
• Tecnología.

Con esto el jefe de proyecto podra entender y gestionar los requisitos funcionales y no funcionales del proyecto teniendo unos más peso que otros en función de los objetivos del proyecto y, por lo tanto, teniendo un mayor peso en las competencias esperadas del jefe de proyecto.

 

_________________________________________________________

Entradas relacionadas:

El jefe de proyecto debe conocer la tecnología…

Are Project Managers Too Focused on Technology and Tasks?

Algunos pecados capitales en el proceso de estimación.

Steve McConnel autor de Software Estimation. Demystifying the Black Art y CEO de Construx pone a nuestra disposición un Webinar gratutito, 10 Deadly Sins of Software Estimation – los 10 pecados capitales de la estimación de software-,  basado en el libro referido. Así presenta Steve este Webinar:

The average project overruns its planned budget and schedule by 50%-80%. In practice, little work is done that could truly be called "estimation." Many projects are scheduled using a combination of legitimate business targets and liberal doses of wishful thinking. In this talk, award-winning author Steve McConnell presents 10 of the worst ways estimates go wrong, and presents time-tested rules of thumb for dramatically improving estimation accuracy

El seminario, de casi una hora de duración, aunque los últimos 15 minutos son de preguntas, nos lanza verdades de Perogrullo o pecados capitales que en más de una ocasión nos hacen sonreír y poner cara de “joder, pero que razón tiene” como la siguiente:

Assuming that the sales department is better at estimating software projects than the programmers are

o

Creating estimates that assume that no one will go to training …

or attend meetings …

or be called to work on another project …

Seminario imperdible que me recordado que tengo el libro en la pila de pendientes y no termina de salir de ahí.

Podéis descargaros la presentación desde aquí.

Por cierto, recordad que una buena estimación es uno de los primeros pasos hacía el éxito o fracaso de un proyecto, ¿o era el acierto o error de una estimación?

Ingeniería del software a debate.

My early metrics book, Controlling Software Projects: Management, Measurement, and Estimation (Prentice Hall/Yourdon Press, 1982), played a role in the way many budding software engineers quantified work and planned their projects. In my reflective mood, I’m wondering, was its advice correct at the time, is it still relevant, and do I still believe that metrics are a must for any successful software development effort? My answers are no, no, and no.

Esta afirmación realizada por Tom DeMarco en el artículo Software Engineering: An Idea Whose Time Has Come and Gone? dio lugar a este otro artículo Software Engineering: Dead? el cuál llegó por twitter a ojos del agudo, provocador, ácido, ingenioso… e imprescindible Ricardo Galli quien ha escrito ¿”Ingeniería” del software? Ahora vienen los mea culpa.

En este último artículo Ricardo rechaza la calificación de ingeniería “a un proceso que tiene poco que ver con los de las ingenierías tradicionales” y critica al “establishment de la “ingeniería del software”” e incluso hace de futurólogo “en unos pocos años veremos que el hot topic en las publicaciones de ingeniería del software serán estudios de caso de grandes proyectos de software libre”.

Pues gracias Ricardo de nuevo por mantener abierto el debate, por ser capaz de argumentar como pocos, por persistir y difundir tus ideas. ¿Se puede crecer sin el debate, sin reflexión, sin disentir?

Mi opinión es que Tom DeMarco, más allá de un mea culpa que no creo que haga pues ni DeMarco ni ningún gurú puede sentirse responsable de la falta de criterio u análisis de todos los que le siguen a pies puntillas, hace una reflexión sobre la utilizad y fin de la ingeniería del software:

For the past 40 years, for example, we’ve tortured ourselves
over our inability to finish a software project on time and on budget. But as I hinted earlier, this never should have been the supreme goal. The more important goal is transformation, creating software that changes the world or that transforms a company or how it does business.

Ni las métricas, ni ninguna metodología, ni ningún proceso son un fin en sí mismo sino medios o herramientas para conseguir objetivos, fines o misiones. Como dijo Joaquín Salvachúa en WIMS 2.0: “La nueva realidad de la red” “There is no magic on OpenSource per se” y que podemos extrapolar a todo lo anterior: ni en metodologías ágiles, ni en métricas, ni en ninguna ingeniería.

Por último, no dejéis de leer los comentarios de los dos artículos escritos a partir del inicial de DeMarco pues ahí está el debate, es decir, el lugar donde crecer y construir algo mejor.

Otros artículos relacionados:

• Navegapolis.net: La Ingeniería del Software tiene aún muy poco camino recorrido

 

CEPIS UPGRADE. Algunas ediciones interesantes.

Javier me ha recordado la posibilidad de leer gratis

y me puesto a buscar algunas ediciones que me pudieran interesar siendo este el resultado:

 

Vol. VIII, issue no. 5,
October 2007

Advanced Information Systems Project Management

 

 

 

 

 

 

 

 

 

 

Vol. IX, issue no. 1,
February 2008

 

IT Governance

 

 

 

 

 

 

 

 

 

 

 

Vol. VIII, issue no. 3,
June 2007

 

ICT Certifications for Informatics Professionals

2009 Kerzner International Project Manager of the Year™ Award.

Do you know a project manager who has exemplified superior performance and outstanding project management methods, skills, and techniques? Esta es la pregunta que nos hacen desde la APM, The Association for Project Management invitándonos a participar en el 2009 Kerzner International Project Manager of the Year™ Award y que nos permite conocer cómo la APM evalúa la excelencia en la dirección de proyectos.

Este es mi resumen y reformulación del cuestionario para sugerir una candidatura, más abajo puedes ver las preguntas, y que intenta describir brevemente el perfil de un excelente director de proyectos:

• Aportar valor a la organización a través de los proyectos.
• Obtener buenos resultados en los proyectos.
• Hard skills:
  • Estudiar sobre dirección de proyectos.
  • Conocer el estado del arte de la profesión y contribuir a su mejora.
  • Transmitir el conocimiento y experiencia a su equipo.
• Soft Skills:
  • Tener vida personal.
  • Ser un líder.
  • Ser honrado, integro.
  • Ser creativo e innovador.

Estas son sus preguntas y criterios. Las negritas y comentarios en español son míos:

1. – Aportación de valor a la organización.

From a project management perspective, what do you believe is the most significant contribution you or your nominee made to the organization as a result of the project or projects that you or they managed?

2. -Formación y mejora continua.

How have you or your nominee demonstrated interest in continuing education and personal development of project management skills and techniques?

3. – Liderazgo.

How would you describe you or your nominee’s project management and team leadership philosophies? Provide specific examples of these skills and how they were used to motivate project teams.

4.- Conocimiento de las tendencias en dirección de proyectos y contribución a la mejora de la profesión.

How do you or your nominee demonstrate an awareness of trends in the project management profession? How do you or your nominee contribute to the continued development of tools, techniques, and best practices to enhance the profession across various industries

5.- Armonización de la vida profesional y personal.

Considering today’s complex demands on one’s professional and personal lives, what are some of the creative ideas/tools that you or your nominee use to maintain a balanced life approach?

6.- Contribución a la formación de otros a través de la tutoría, mentorship, o coaching.

Project managers often become mentors for people entering the project management field. Describe you or your nominee’s mentorship capabilities and effectiveness as a coach and mentor.

7.- Integridad.

Integrity is a key characteristic of an effective manager. How do you or your nominee demonstrate personal integrity and promote integrity within the organization?

8.- Creatividad e innovación.

The demands of the project manager position require the ability to be creative and to inspire innovation within the project team. Describe how you or your nominee encourage innovative thinking and creativity.

9.- Características de los proyectos gestionados.

Please review the following questions and provide the requested information regarding the project or projects in which you or your nominee were recently involved.

What were the number of core and extended team members involved in the project?

What was the overall budget of the project?

What was the number of other projects being managed simultaneously?

What was the total value (combined budgets) of your or your nominee’s Project Portfolio at the time?

10.- Resultados obtenidos en los proyectos gestionados.

What quantifiable business results were achieved from implementation of your or your nominee’s project or projects?  Please address the following specifics:

Percentage that the project was completed under project budget.

Number of weeks that the project was completed ahead of schedule.

Amount that organizational operating costs were reduced.

Amount productivity was increased.

Amount of defects that were reduced.

 

¿Estás de acuerdo? ¿Te sobra o falta algo? ¿Te nominarías o nominarías a alguien?

Código deontológico del COEInf.

El Col legi Oficial d’Enginyeria en Informàtica de Catalunya (COEInf) ha publicado la una nueva versión del Código deontológico de la profesión de ingenierio en informática (pdf, 582 Kb) tal y como he podido saber por La Salle.

Espero que alguien se lo lea y lo aplique. Yo lo dejo en la carpeta de “en cuanto pueda” y lo subo a mi box.

Más información en Nova versió del Codi Deontològic de la professió d’Enginyer en Informàtica.

Sobre la Norma UNE 157801.

Por favor, necesito que alguien me explique para qué sive la norma UNE 157801:2007 Criterios generales para la elaboración de proyectos de sistemas de información (doc, 166 kb), no porque no entienda la sugerencia que hace sobre los “requisitos generales de la documentación del proyecto” sino porque no entiendo que una propuesta, puesto que no es más eso, tenga que ser elevada a la categoría de norma que aparece en el BOE cuando las marcos o metodologías de gestión de proyectos ya cubren estos aspectos, y en cualquier caso, la práctica de la dirección de proyectos da la experiencia para cubrir el desarrollo de estos entregables y otros muchos. ¿Hasta dónde hay que normalizar

Reproduzco a continuación la descripción que se hace de esta norma en la hoja informativa técnica del consejo general de la arquitectura técnica de España de mayo de 2008

Esta norma tiene por objeto establecer las características generales que deben ser cubiertas en los proyectos de sistemas de información a realizar, para que satisfagan los fines a los que están destinados.

El sentido tradicional que se le da a un proyecto implica dos partes bien diferenciadas: la elaboración del documento que especifica lo que se ha proyectado realizar y la ejecución de lo proyectado según está especificado en el documento del proyecto.

Por tanto en esta norma se pretende recoger la documentación que detalla la solución propuesta para el problema planteado y que es necesaria para que pueda realizarse el sistema de información objeto del proyecto definido en su alcance.

En cualquier caso, dado lo cambiante de las técnicas utilizadas en este tipo de proyectos y de la dinámica existente en las actividades de las organizaciones, si el comienzo del desarrollo del proyecto se dilatara sensiblemente en el tiempo, de forma que hubieran podido variar las premisas iniciales que sirvieron para su estudio, debe realizarse un revisión para valorar, y en su caso hacer, las modificaciones oportunas para adaptarlo a las nuevas circunstancias.

En esta norma no se pretende desarrollar ni condicionar los proyectos a ninguna metodología ni a ningún ciclo de vida que pueda emplearse en la elaboración de los mismos. Tampoco se establecen los procesos que necesiten realizarse, ni el estado del arte para el uso de estas tecnologías que, en caso de considerarse necesaria su inclusión, debe hacerse mediante la referencia a otras normas de carácter técnico que contemplen éstos aspectos.

El desarrollo de los aspectos indicados en esta norma depende del tipo de sistema de información de que se trate y de su objeto, que no se ciñe exclusivamente a los proyectos de desarrollo de aplicaciones, sino a todo el ámbito de las disciplinas que tengan que ver con los sistemas de información soportados por las denominadas Tecnologías de la Información y las Comunicaciones (TIC), y pueden hacer referencia a otras normas específicas.

Esta norma ha sido elaborada por el comité técnico AEN/CTN 157 Proyectos, cuya Secretaría desempeña el Colegio Oficial de Ingenieros Industriales de Cataluña.

Flexibilidad con Scrum, ahora en formato presentación.

Una vez más agradecer a Juan Palacio su generosidad. Si antes había compartido con nosotros su libro Flexibilidad con Scrum  que ya lleva más de 40.000 descargas, ahora comparte el mismo libro en formato presentación. Ante esto al menos se pueden hacer varias cosas:

• Dar las gracias
• Leer el libro
• Comprar el libro el lulu

View this document on Scribd

Introducción a Scrum con Autentia y Agile Spain.

 

Ayer tuve la suerte de asistir a la charla “Introducción a Scrum” organizada por Autentia y Agile Spain en la que fueron ponentes:

 

 

 

• Leo Antoli, consultor tecnológico y arquitecto senior en Autentia.
• Juan Gutiérrez, coach en F-Secure y anteriormente Scrum Master en Nokia. También es autor del blog Agilizar.
• Agustín Yagüe, profesor de la Universidad Politécnica de Madrid. Sus principales áreas de investigación incluyen: procesos software, mejora de procesos software, gestión de proyectos, metodologías ágiles de desarrollo, procesos y herramientas de pruebas de software y sistemas. Participa de forma activa en proyectos europeos centrados en desarrollo ágil. Forma parte de diversos comités técnicos y grupos de trabajo de normalización.

Como podéis ver en el álbum de fotos, a pesar de la pésima calidad de las mismas, la sala estaba llena y con un auditorio muy participativo que hizo muy amenas e interesantes las tres horas que finalmente duró el evento.

View Full Album

La sesión fue, como se hacía prever por su título, una introducción que despertó el gusanillo de la curiosidad por saber más. No se ocultaron las dificultades de su uso e incluso se expusieron visiones algo distintas entre la bondad del SCRUM puro y el SCRUM but, ese que consiste en adaptarlo a nuestra forma de entender los proyectos o, simplemente, a nuestras posibilidades.

Mi más sincera enhorabuena a Autentia y especialmente a Roberto Canales, creador y propietario de AdictosAlTrabajo.com y Director general de Autentia quien además de grabar la sesión para compartirla en breve – la ppt ya está disponilble en http://www.adictosaltrabajo.com/material_charlas/20090507/scrum.pdf - e a través de AdictosAlTrabajo contribuyó con sus aportaciones a conocer otra visión de SCRUM, el SCRUM but…

Por último, el Manifiesto por el Desarrollo Ágil de Software:

Individuos e interacciones sobre procesos y herramientas

Software que funciona sobre documentación exhaustiva

Colaboración con el cliente sobre negociación de contratos

Responder ante el cambio sobre seguimiento de un plan

¡Nos vemos en el próximo evento!

Presentación y videos de la conferencia:

La presentación en PDF en http://www.adictosaltrabajo.com/detalle-noticia.php?noticia=133

Vídeos:

1. http://www.youtube.com/watch?v=kxv9I4jsQhc&feature=channel_page
2. http://www.youtube.com/watch?v=kZmx8WpMvd8&feature=related
3. http://www.youtube.com/watch?v=Mj0SlK12BxU&feature=related
4. http://www.youtube.com/watch?v=miF2NIQqjME&feature=channel
5. http://www.youtube.com/watch?v=2FuEvIlTC80&feature=channel
6. http://www.youtube.com/watch?v=GKu47YOueJ0&feature=channel
7. http://www.youtube.com/watch?v=_GFQvLgXNM0&feature=related
8. http://www.youtube.com/watch?v=z_v1pJUOCek&feature=channel
9. http://www.youtube.com/watch?v=BAWi6a1dcvM&feature=related
10. http://www.youtube.com/watch?v=YkDsryNb4zE&feature=channel
11. http://www.youtube.com/watch?v=pqTduYpQyNs&feature=channel
12. http://www.youtube.com/watch?v=BtLOrEr7WJQ&feature=channel
13. http://www.youtube.com/watch?v=0SRYQp1OjwE&feature=channel
14. http://www.youtube.com/watch?v=3HpQcLYsCfM&feature=channel
15. http://www.youtube.com/watch?v=6jFWhfSJhaU&feature=channel
15b. http://www.youtube.com/watch?v=9KkAuKGEzMw&feature=channel
16. http://www.youtube.com/watch?v=W4XoLIhGgCQ&feature=channel
17. http://www.youtube.com/watch?v=y16LCozJXEA&feature=channel
18. http://www.youtube.com/watch?v=xis4Rt8zhI4&feature=channel
19. http://www.youtube.com/watch?v=THdmhssENu4&feature=channel
20. http://www.youtube.com/watch?v=UzMH-p5sCmQ&feature=channel
21. http://www.youtube.com/watch?v=ikrbF7CeVgs&feature=channel
22. http://www.youtube.com/watch?v=cEeVVCYn4PE&feature=channel