martes, 21 de diciembre de 2010
miércoles, 15 de diciembre de 2010
martes, 14 de diciembre de 2010
"Elemental, querido..."
Aqui tenéis todo lo necesario para realizar el examen final de SQL...(si podéis verlo claro)
Hasta las 20:30!!
Suerte muchachos.
lunes, 13 de diciembre de 2010
La última prueba antes del día D
Os paso una serie de preguntas para probar vuestro nivel de SQL y coger confianza para el examen de mañana:
CICLISMO
a) Nombre de los ciclistas que hayan llevado maillot amarillo dos o más veces y que están en equipos donde ningún otro ciclista ha ganado tres o más etapas.
b) Codigo y color de los maillots + Número de veces que han sido llevados en total (llámalo num_total) + Número de veces que los ha llevado un equipo (llámalo num_equipo)+ Nombre del equipo, de aquellos maillots que empiezan por "a", "b", "c" o "d" y que han sido llevados en menos de tres ocasiones por ciclistas de un mismo equipo.
MUSICA
a) ¿Cuál es el disco más largo?
b) ¿Qué grupos han grabado con sólo una compañía discográfica?
c) ¿Y con todas ellas?
d) ¿Cuál es la duración media de las canciones grabadas por grupos europeos de más de un componente?
BIBLIOTECA
a)¿Cuál es el país que más obras ha escrito y cuantas, de cada temática?
b) Necesitamos conocer el nombre del autor y el título de los libros que han sido escrito por autores que sólo han trabajado una única temática y que están formados por una única obra de código impar.
CICLISMO
a) Nombre de los ciclistas que hayan llevado maillot amarillo dos o más veces y que están en equipos donde ningún otro ciclista ha ganado tres o más etapas.
b) Codigo y color de los maillots + Número de veces que han sido llevados en total (llámalo num_total) + Número de veces que los ha llevado un equipo (llámalo num_equipo)+ Nombre del equipo, de aquellos maillots que empiezan por "a", "b", "c" o "d" y que han sido llevados en menos de tres ocasiones por ciclistas de un mismo equipo.
MUSICA
a) ¿Cuál es el disco más largo?
b) ¿Qué grupos han grabado con sólo una compañía discográfica?
c) ¿Y con todas ellas?
d) ¿Cuál es la duración media de las canciones grabadas por grupos europeos de más de un componente?
BIBLIOTECA
a)¿Cuál es el país que más obras ha escrito y cuantas, de cada temática?
b) Necesitamos conocer el nombre del autor y el título de los libros que han sido escrito por autores que sólo han trabajado una única temática y que están formados por una única obra de código impar.
jueves, 25 de noviembre de 2010
martes, 23 de noviembre de 2010
Un artículo excepcional... no debéis dejar de leerlo
Sacado de http://www.ingsoftagil.com/
"Últimamente se están sucediendo varias noticias relacionadas con el problema de la precariedad laboral en el sector de la informática. El tema lleva sobre la mesa desde siempre, pero las dificultades actuales en el mercado laboral lo están acentuando.
Los debates sobre la cuestión casi siempre degeneran en guerras incendiarias ente los propios perjudicados. Sobre todo, cuando se tocan aspectos como el intrusismo, los colegios, o la utilidad de los planes de estudio. Un ejemplo es la famosa discusión entre ingenierosdeprimera.com y Ricardo Galli, creador de Meneame.com.
Otras veces el foro se convierte en una colección de insultos contra las cárnicas, como pasaba con www.trabajobasura.com, y otros sitios parecidos. Esto suele ser poco productivo, porque no logra cambiar nada.
Para mi, la raíz del problema de la precariedad laboral no está en las cárnicas, ni en la ausencia de colegios o sindicatos. La raíz está en la contratación de perfiles poco cualificados, y su consideración como peones albañiles.
Cuando digo perfiles poco cualificados no me refiero a titulados o no titulados. Me refiero a personas sin ninguna vocación, y sin ningún interés por aprender, empezando por aquellos, tanto informáticos como otros titulados, que afirman que "no han estudiado una ingeniería para acabar picándo código", o que "la labor de un ingeniero no es poner los ladrillos".
Precisamente las cárnicas, el bodyshopping, la deslocalización a otros a países, y gran parte de los males del mundo de los servicios de software, no son más que consecuencias de esta consideración del programador como un peón albañil.
A veces son estas mismas personas, los que desprecian la programación, quienes más se quejan del intrusismo. Pero estaréis de acuerdo en lo incoherente que resultaría revindicar la programación como una competencia exclusiva de los ingenieros informáticos, y mantener al mismo tiempo que la programación es impropia de un ingeniero. Tan incoherente como protestar por la contratación de licenciados en informática como "picadores", al mismo tiempo que se protesta por la contratación como programadores de profesionales de otras titulaciones. No tiene sentido tampoco que sean los menos cualificados para la programación, que son aquellos que la desprecian, quienes etiqueten a todos los demás como perfiles no cualificados para el desarrollo de software.
Más de uno estará pensando que no es la programación lo que les preocupa, sino la dirección o gestión de proyectos de software. Piensan que la verdadera labor de un ingeniero no es programar o poner ladrillos, sino dirigir proyectos o diseñar los sistemas.
Las personas que piensan así generalmente no están cualificadas para programar, ni para gestionar proyectos. Para lo primero es evidente: quien piense que programar es como poner ladrillos, es que no ha programado en su vida. Pero la programación no es una actividad de construcción, sino de diseño. No quiero extenderme demasiado, la mejor explicación al respecto es el artículo de Jack Reeves: el código es el diseño.
En cuanto a lo segundo, quienes piensan que lo propio de un ingeniero es ser jefe de proyecto, lo que reflejan es una concepción taylorista del proceso de desarrollo de software, y con esa mentalidad es difícil gestionar proyectos en la actualidad.
Permitidme un paréntesis sobre la gestión de proyectos. Creo que conocéis cual es la concepción taylorista y creacionista del proceso de desarrollo de software. Aquella basada en la división de las actividades de análisis, diseño , construcción y pruebas, entre distintos grupos de personas, con distintos niveles jerárquicos de responsabilidad, mediante un proceso secuencial, dentro de sistemas formales documentalmente pesados. Éste es el enfoque ortodoxo y académico que promueven las prestigiosas consultoras. Nada que ver, por supuesto, con el verdadero desarrollo profesional de software.
He visto alguna vez por Barrapunto chistes sobre el tema. Efectivamente, si a un consultor le encargasen auditar el desarrollo del kernel de Linux, se llevaría las manos a la cabeza: ¿dónde están los diagramas UML?, ¿dónde está el diagrama de Gantt?, ¿y los documentos de diseño?, ¿qué hacen todos estos ingenieros picando código?. Si un consultor soltara estas preguntas en las listas de correo del kernel, todos los hackers se reirían de él, aunque no creo que perdieran mucho tiempo con la guasa, tienen cosas más importantes que hacer. Pero cuando este mismo discurso se mantiene dentro de una empresa, ante un foro de gerentes, directivos, y otros consultores, todos acaban congratulándose de que alguien por fin les entienda, y de que se proponga empezar a hacer las cosas bien, de forma "industrializada", como una "ingeniería".
El taylorismo es obsoleto en todas las demás ingenierías desde los años 70, cuando se desarrolló el toyotismo. No se si os sonarán términos como "Lean", "Kanban", "Jidoka", o "Kaizen", propias del ámbito industrial, pero seguro que sí os suenan las metodologías ágiles de desarrollo como Scrum o Programación Extrema, donde no hay ni jefes, ni analistas, ni testers, sino simplemente equipos de desarrolladores auto-organizados, donde todos prueban, codifican, analizan y documentan. La ingeniería de software es, curiosamente, una de las disciplinas más reaccionarias ante estos enfoques. Habría que tirar a la basura, o mejor, quemar en la hoguera, toda la bibliografía taylorista sobre ingeniería de software, que parte de la visión de la programación como una actividad de construcción, y del programador como un peón albañil.
Las grandes consultoras han apoyado el taylorismo, o el desarrollo de software mediante mano de obra barata y poco cualificada, porque durante muchos años ha sido un modelo muy rentable. Cuanto más improductivo es el modelo, más personal requieren sus clientes, y durante más tiempo, lo que implica mayores ingresos y beneficios. Si además se establecen procesos formales lentos y pesados, basados en la elaboración de montañas de documentación, los proyectos requerirán cada vez más recursos y más tiempo. Esta dinámica no es realmente intencionada, ni es exclusiva de la ingeniería de software. La tendencia de toda organización a multiplicar la burocracia para maximizar el esfuerzo fue descrita por primera vez por Cyril Northcote Parkinson en 1955, y es conocida como la Ley de Parkinson.
Es difícil hablar de calidad, talento, experiencia o cualificación dentro de un mundo como el del sector de las IT y los servicios de software, que es exactamente como el que describió Parkinson, aunque él se refiriese a la administración colonial británica. La productividad no importa, y las personas no son más que material fungible.
El resultado inicial de este modelo ha sido el prestamismo laboral o el bodyshopping, que tan rentable fue para las cárnicas y las presuntas consultoras, transformadas en ETTs encubiertas. En poco tiempo lograron colocar a tanta gente que la demanda de informáticos se disparó, y muchos treparon de forma vertiginosa. El primer varapalo llegó en el 2000 con la crisis de la puntocom, y la puntilla llegó con el inicio de los procesos de externalización y deslocalización a otros países durante la década siguiente, en busca de mano de obra barata.
El efecto del offshoring o la deslocalización para las consultoras españolas ha sido devastador. Se han ido quedando progresivamente sin proyectos, a medida que sus clientes trasladaban sus desarrollos a países como la India. Quisiera poner como ejemplo Movistar, que hace un par de años trasladó los desarrollos de sus sistemas de información a las software factories de Accenture en Argentina. Estos procesos de externalización y deslocalización en Telefónica siguen su curso aún. Hace unas semanas, por ejemplo, se comentó la concentración de unos 300 trabajadores en protesta por la externalización de Telefónica I+D a Ericcson e Indra.
Los cientos de Trabajadores de I+D que han sido "invitados" a cambiar de empresa, son pocos comparados con los cerca de 2000 que Telefónica segregará a Telefónica Global Technology, la nueva empresa del grupo.
La presidenta de TGT es la argentina María Fernanda Torquati, anterior directora de sistemas de información de Telefónica. Podéis encontrarla en la foto junto a Cristina Fernández de Kirchner, y otros directivos de Telefónica y Accenture.
Mientras en España ésta deslocalización implica la destrucción de cientos de puestos de trabajo, en Argentina supone la creación de miles de ellos, aunque posiblemente no muy estables. El modelo que se está exportando allí es el modelo de las cárnicas, que tanto daño ha causado en España.
La moda de la deslocalización proviene de otro tipo de industrias, como la del sector textil o el sector del automóvil, donde existen actividades de fabricación intensivas en mano de obra. Lo que se trasladan son las actividades de construcción o fabricación, mientras el diseño se mantiene en Europa. No tendría sentido deslocalizar el diseño, ya que no suele ser una actividad acometible por fuerza bruta, sino por personal altamente experto y cualificado, y su deslocalización a países en vías de desarrollo no implicaría ninguna reducción de costes. De hecho, el offshoring de las actividades de diseño multiplica los costes, ya que merma la productividad y la calidad, entre muchas ochas.
Gran parte de las empresas que promovieron durante los 90 un offshoring de las actividades de I+D a países como la India, se encuentran ahora en un proceso inverso de retorno a sus países de origen. Una muestra sintomática de esta marcha atrás es la obra "Decline and Fall of The American Programmer" de Edward Yourdon (1992), vaticinando la desaparición de los programadores en EEUU como consecuencia de la deslocalización. La mejor muestra de que estaba equivocado es "Rise & Resurrection of the American Programmer", el libro que escribió después para explicar por qué había fallado en todos sus vaticinios. Si visitáis estas obras en Amazon, echad un vistazo a los comentarios de Peter Norving, director de desarrollo de Google. Podéis comprobar por las fechas que en España acarreamos un desfase respecto a estas tendencias.
La precariedad laboral en el sector de las consultoras y los servicios de software es simplemente consecuencia de un prejuicio: la consideración de los informáticos como peones albañiles. La subcontratación, la contratación de perfiles poco cualificados, el fenómeno de las cárnicas, y la deslocalización a países en vías de desarrollo, no son más que consecuencias directas de esta visión de los informáticos como albañiles, y de su labor como una actividad que puede hacer cualquiera, acometible por fuerza bruta.
Mientras, las consultoras en España han sido víctimas de sus propios errores, ya que aquello en lo que han fallado miserablemente es en explicar que lo que los proyectos requieren no es fuerza bruta, ni mano de obra barata, sino personal experto y cualificado. Este personal cualificado también es más barato, ya que es más productivo, y no sólo produce más, sino que produce mejor o con mayor calidad. Al fin y al cabo eso es lo que realmente la gente espera de un consultor: alguien cualificado y experto.
Cuando las consultoras decidieron dejar de ser consultoras, para convertirse simple y llanamente en ETTs de mierda, operando al borde de la legalidad, firmaron sus sentencias de muerte. Creo que muchas empresas deberían estar planteándose hoy si quieren ser realmente ETTs encubiertas, y dedicarse a competir en mano de obra barata (lo que se me antoja harto difícil), o volver a ser consultoras, y empezar a combatir desde ya los procesos de deslocalización en sus clientes. Claro, es poco creíble que los mismos que han defendido las bondades del offshoring y de las software factories, defiendan ahora un modelo completamente contrario.
Hoy las consultoras deberían ser las primeras interesadas en defender un modelo basado en la productividad, en la experiencia, la cualificación y el talento. Y los informáticos también. En vez de combatir la precariedad laboral mediante colegios, sindicatos y privilegios, creo que deberíamos unir esfuerzos en erradicar el prejuicio inicial, que es la consideración de los programadores como peones albañiles, y la programación como una actividad de construcción. Hace falta para ello reescribir los libros sobre ingeniería de software desde el principio, y eso es lo que yo he pretendido hacer con "Ingeniería de Software Ágil"."
Certificado SCRUM para desarrolladores
Muy interesante y una opción genial para diferenciarse de la competencia! Más información aquí.
lunes, 22 de noviembre de 2010
viernes, 19 de noviembre de 2010
Una opción muy interesante para hacer la FCT en el extranjero
Obra Social Caja Madrid convoca 197 becas dentro de su Programa de Eurobecas
para estudiantes de Formación Profesional
Obra Social Caja Madrid convocará el próximo año 197 'Eurobecas' para
estudiantes de Formación Profesional (FP) de toda España que deseen realizar
prácticas laborales en empresas europeas, ha informado Caja Madrid.
El plazo ya se ha abierto, y quien quiera solicitar una de estas becas
podrá hacerlo hasta el 24 de enero de 2011.
Ampliar la noticia:
http://www.europapress.es/ epsocial/obra-social/noticia- obra-social-caja-madr
id-convoca-197-becas-dentro- programa-eurobecas- estudiantes-formacion-profesi
onal-20101117183414.html
para estudiantes de Formación Profesional
Obra Social Caja Madrid convocará el próximo año 197 'Eurobecas' para
estudiantes de Formación Profesional (FP) de toda España que deseen realizar
prácticas laborales en empresas europeas, ha informado Caja Madrid.
El plazo ya se ha abierto, y quien quiera solicitar una de estas becas
podrá hacerlo hasta el 24 de enero de 2011.
Ampliar la noticia:
http://www.europapress.es/
id-convoca-197-becas-dentro-
onal-20101117183414.html
martes, 9 de noviembre de 2010
lunes, 8 de noviembre de 2010
martes, 2 de noviembre de 2010
miércoles, 27 de octubre de 2010
martes, 26 de octubre de 2010
Información Life Long Learning Programme
En esta página, información general del programa.
Los documentos de solicitud, son estos
- Formulario de solicitud
- Instrucciones para rellenar el formulario
- Orientaciones en cuanto al contenido de cada sección
Además para esta fase se debe preparar una serie de documentos:
- Presupuesto
- Declaration of Honour
- Legal Entity Form
- List of Associated Partners (optional)
- Third country participation (optional)
Luego, si la Comisión acepta el proyecto para financiación, el coordinador debe enviar la siguiente documentación a la Comisión:
- Letter of Mandate (una por socio, excepto el coordinador que no envía esta carta)
- Financial Identification Form
- Estatutos
- Financial Capacity Form
- Cuentas de pérdidas y ganancia de los 2 años anteriores
- Financial Guarantee (optional).
Todos estos documentos los podéis encontrar en: http://eacea.ec.europa.eu/llp/ funding/2010/call_lifelong_ learning_2010.php
lunes, 25 de octubre de 2010
TOP 3 Students
Tras las notas de esta 5ª Prueba de evaluación continua, el podio de la clase queda de la siguiente manera:
1º) Juan Ballester, con una media de 6.8
2º) Álex Argüelles, con una media de 6.52
3º) Freyder, con una media de 6.40.
Enhorabuena!!!
Al resto, tan sólo recordaros lo cerca que estáis y que unos buenos resultados en las próximas pruebas, sin duda, resultarán en una mejora sustancial de la media y a veros en los puestos de cabeza.
Mirad a Fernando Alonso!
Un abrazo.
1º) Juan Ballester, con una media de 6.8
2º) Álex Argüelles, con una media de 6.52
3º) Freyder, con una media de 6.40.
Enhorabuena!!!
Al resto, tan sólo recordaros lo cerca que estáis y que unos buenos resultados en las próximas pruebas, sin duda, resultarán en una mejora sustancial de la media y a veros en los puestos de cabeza.
Mirad a Fernando Alonso!
Un abrazo.
miércoles, 20 de octubre de 2010
miércoles, 6 de octubre de 2010
Evaluación del trabajo en equipo
Para contar con vuestra opinión, la más importante, a la hora de ponderar el trabajo en equipo de vuestros compañeros, os facilito el siguiente formulario (también lo tendréis en el menú de navegación situado a la izquierda del blog) para que podáis calificar el trabajo y actitud de vuestros compañeros.
Las modificaciones a la nota serán las siguientes:
AA 1.1
AB 1
AC / BB 0.9
BC / AD 0.85
CC / BD 0.75
CD 0.65
DD 0.45
Recordad describir bien la actividad evaluada, para evitar equívocos.
Las modificaciones a la nota serán las siguientes:
AA 1.1
AB 1
AC / BB 0.9
BC / AD 0.85
CC / BD 0.75
CD 0.65
DD 0.45
Recordad describir bien la actividad evaluada, para evitar equívocos.
martes, 5 de octubre de 2010
POO
Para el miércoles 13 de Octubre:
· Comenzamos el bloque de programación orientada a objetos. Cada equipo deberá hacer una presentación "gloriosa" de uno de los siguientes temas a elegir (el mecanismo de selección es "el último tonto" ;) , escribiendo un mensaje con el nombre del equipo y el tema seleccionado):
· Tema a) Historia y evolución de los lenguajes de programación.
· Tema b) POO: Herencia y Abstracción
· Tema c) POO: Polimorfismo y Encapsulamiento
· Tema d) POO: Principio de Ocultación y Recolección de basura.
· Tema e) Ventajas e inconvenientes de la POO frente a la programación estructurada.
Deberéis subir el documento resultante al portfolio de cada equipo.
Ánimo y un abrazote.
· Comenzamos el bloque de programación orientada a objetos. Cada equipo deberá hacer una presentación "gloriosa" de uno de los siguientes temas a elegir (el mecanismo de selección es "el último tonto" ;) , escribiendo un mensaje con el nombre del equipo y el tema seleccionado):
· Tema a) Historia y evolución de los lenguajes de programación.
· Tema b) POO: Herencia y Abstracción
· Tema c) POO: Polimorfismo y Encapsulamiento
· Tema d) POO: Principio de Ocultación y Recolección de basura.
· Tema e) Ventajas e inconvenientes de la POO frente a la programación estructurada.
Deberéis subir el documento resultante al portfolio de cada equipo.
Ánimo y un abrazote.
El inicio difuso planea sobre los equipos...
lunes, 27 de septiembre de 2010
Metodologías
Estas son las metodologías/frameworks a analizar:
SCRUM
RUP
XP
METRICA
KANBAN
SCRUM
RUP
XP
METRICA
KANBAN
Etiquetas:
ingenieria del software,
Metodologias desarrollo SW
Espaguetis y nubes...
Hoy hemos realizado una actividad muy interesante para reflexionar acerca del trabajo en equipo, de como organizarnos, de como resolver diferencias de criterios... todo de una manera muy dulce!!
viernes, 24 de septiembre de 2010
Ya tenemos equipos!!!
A partir de los resultados del test Belbin, el equipo de profes de 2º de DAI ha configurado los siguientes equipos:
EQUIPO 1: Sergio Fresneda, Salva Peris, Juan Ballester, José López, Álex Argüelles, Albert Bresó y José Vte. Maldonado.
EQUIPO 2: Félix Perona, Vicente Soria, Rubén Albiach, Esteban Salmerón, Jesús Pérez, Vlad, Berna Ramón, Freyder Espinosa.
Esto marcha!
EQUIPO 1: Sergio Fresneda, Salva Peris, Juan Ballester, José López, Álex Argüelles, Albert Bresó y José Vte. Maldonado.
EQUIPO 2: Félix Perona, Vicente Soria, Rubén Albiach, Esteban Salmerón, Jesús Pérez, Vlad, Berna Ramón, Freyder Espinosa.
Esto marcha!
miércoles, 22 de septiembre de 2010
Especificación de requisitos
En estos archivos:
hay plantillas y ejemplos de la estructura que IEEE recomienda para la definición de requisitos de un sistema software.
Esta PEC nº3 consiste en que, por equipos, penséis en los requisitos que debe tener una aplicación (se os asignará por sorteo), poniéndoos en la piel del cliente y que, por otra parte, consigáis definir bien lo que el cliente quiere actuando como analistas.
Se actuará por turnos y al terminar cada ronda, se cambiará el rol desempeñado.
El deliverable de esta PEC será un documento que, siguiendo el esquema IEEE, detalle a la perfección la funcionalidad de la aplicación así como una presentación que la explique.
hay plantillas y ejemplos de la estructura que IEEE recomienda para la definición de requisitos de un sistema software.
Esta PEC nº3 consiste en que, por equipos, penséis en los requisitos que debe tener una aplicación (se os asignará por sorteo), poniéndoos en la piel del cliente y que, por otra parte, consigáis definir bien lo que el cliente quiere actuando como analistas.
Se actuará por turnos y al terminar cada ronda, se cambiará el rol desempeñado.
El deliverable de esta PEC será un documento que, siguiendo el esquema IEEE, detalle a la perfección la funcionalidad de la aplicación así como una presentación que la explique.
Liberación de código (desde Barrapunto)
Durante la reciente QuakeCon, John Carmack anunció la liberación del código de los juegos Return to Castle Wolfenstein y Enemy Territory . Los desarrolladores de ioquake3 (el proyecto libre basado en Quake 3) ya tienen funcionando los proyectos iowolfet e iortcw, con su serviodor de Mercurial hg.ioquake.org para quien quiera clonar el proyecto. Hay que recordar que lo que es libre es el código, mientras que los recursos del juego (modelos, texturas niveles) siguen siendo propiedad de id Software y Activision.
martes, 21 de septiembre de 2010
Test Belbin
Hola a todos.
Aquí tenéis el enlace al famoso test Belbin que utilizaremos para configurar equipos lo más armonizados que podamos.
Cuando lo hayáis terminado, por favor, imprimidlo en PDF y colgadlo aquí.
A continuación, os dejo una breve explicación de los resultados del test:
CW: “Company Worker”. “Implementer”. Implantador.
CH: “Chairman”, “Co-ordinator”. Coordinador.
SH: “Shaper”.
PL: “Plant”.
RI: “Resource investigador”. Investigador de recursos.
ME: “Monitor”, “Evaluator”. Observador, evaluador.
TW: “Teamworker”. Trabajador de equipo.
CF: “Completer”, “Finisher”.Finalizador.
El rol dentro del equipo que presente la puntuación más alta indica cómo la persona que
ha contestado el cuestionario puede destacar en un equipo de gestión o de proyecto. Las
puntuaciones inmediatamente inferiores indican roles de soporte, los cuales deberían
asumirse por la persona en cuestión si por alguna razón el equipo tiene menos necesidad
del rol primario.
Los dos resultados más bajos representan posibles áreas de debilidad. Resulta
aconsejable que un directivo en vez de intentar mejorar en estas áreas debería buscar un
colega con fortalezas complementarias.
· “Plant”
Es el proveedor de ideas del equipo. Sabe como generar ideas para afrontar los
problemas que afectan al equipo. Tiene tendencia a trabaja mejor cuando se enfoca en
temas principales que en pequeños detalles.
· Investigador de recursos
Actúa como fuente de información e ideas. Sabe cómo establecer contactos con
personas externas al equipo que puedan ser útiles. Usualmente tienen una cartera de
contactos en continua expansión. Normalmente sacan provecho de estos contactos sin
consultar con el equipo.
· Coordinador
Provee liderazgo coordinando los esfuerzos y contribuciones de los miembros del
equipo.
· “Shaper”
Provee liderazgo dirigiendo y controlando los miembros del equipo. Ejerce una fuerte
influencia sobre el modo en que funciona el equipo. Tiende a impulsar al equipo hacia
sus objetivos. Es bueno en hacer que las cosas se hagan, pero puede agobiar a otros
miembros del equipo. Esta persona puede no ser el líder formal del equipo, pero sin
diplomacia sus características podrían ofender al líder formal.
· Evaluador
Sabe evaluar ideas y sugerencias. Tiende a ser objetivo y sabe analizar problemas y
evaluar alternativas. Comúnmente llamado también el “abogado del diablo”. Es
importante para estas personas señalar los problemas con tacto y no ser demasiado
crítico con las sugerencias de los demás.
· Miembro de equipo
Ayuda a mantener la armonía y el espíritu de equipo. Sabe mejorar la comunicación en
el equipo y hacer participar a las personas en debates. Es un rol importante dentro de un
equipo pero dado que la mayor parte de su trabajo se produce en un segundo plano, no
es fácil apreciar el valor de estas personas.
· Implantador
Es bueno en lograr resultados prácticos y detallados. Se le puede confiar la
responsabilidad de implantar las decisiones de equipo. Sabe como tomar ideas y planes
y convertirlos en procedimientos prácticos.
· Finalizador
Es el tipo de persona que presta especial atención a los detalles y se encarga de hacer un
seguimiento de las tareas inacabadas. Tiende a generar un sentimiento de urgencia
dentro del equipo y es bueno en mantener al equipo de acuerdo con la programación
establecida.
· Especialista
Provee conocimientos y habilidades singulares. En un entorno empresarial no suele ser
un miembro de equipo regular; habitualmente se le invita a participar en un equipo para
tratar temas o problemas específicos. No afecta directamente a la dinámica del equipo,
así que un equipo puede trabajar con éxito sin necesidad de un especialista. Es más un
papel que la persona puede jugar en un equipo que un tipo de personalidad. Un
especialista suele ser de ideas fijas e independiente, lo cual le hace adquirir sus
habilidades especiales.
Aquí tenéis el enlace al famoso test Belbin que utilizaremos para configurar equipos lo más armonizados que podamos.
Cuando lo hayáis terminado, por favor, imprimidlo en PDF y colgadlo aquí.
A continuación, os dejo una breve explicación de los resultados del test:
CW: “Company Worker”. “Implementer”. Implantador.
CH: “Chairman”, “Co-ordinator”. Coordinador.
SH: “Shaper”.
PL: “Plant”.
RI: “Resource investigador”. Investigador de recursos.
ME: “Monitor”, “Evaluator”. Observador, evaluador.
TW: “Teamworker”. Trabajador de equipo.
CF: “Completer”, “Finisher”.Finalizador.
El rol dentro del equipo que presente la puntuación más alta indica cómo la persona que
ha contestado el cuestionario puede destacar en un equipo de gestión o de proyecto. Las
puntuaciones inmediatamente inferiores indican roles de soporte, los cuales deberían
asumirse por la persona en cuestión si por alguna razón el equipo tiene menos necesidad
del rol primario.
Los dos resultados más bajos representan posibles áreas de debilidad. Resulta
aconsejable que un directivo en vez de intentar mejorar en estas áreas debería buscar un
colega con fortalezas complementarias.
· “Plant”
Es el proveedor de ideas del equipo. Sabe como generar ideas para afrontar los
problemas que afectan al equipo. Tiene tendencia a trabaja mejor cuando se enfoca en
temas principales que en pequeños detalles.
· Investigador de recursos
Actúa como fuente de información e ideas. Sabe cómo establecer contactos con
personas externas al equipo que puedan ser útiles. Usualmente tienen una cartera de
contactos en continua expansión. Normalmente sacan provecho de estos contactos sin
consultar con el equipo.
· Coordinador
Provee liderazgo coordinando los esfuerzos y contribuciones de los miembros del
equipo.
· “Shaper”
Provee liderazgo dirigiendo y controlando los miembros del equipo. Ejerce una fuerte
influencia sobre el modo en que funciona el equipo. Tiende a impulsar al equipo hacia
sus objetivos. Es bueno en hacer que las cosas se hagan, pero puede agobiar a otros
miembros del equipo. Esta persona puede no ser el líder formal del equipo, pero sin
diplomacia sus características podrían ofender al líder formal.
· Evaluador
Sabe evaluar ideas y sugerencias. Tiende a ser objetivo y sabe analizar problemas y
evaluar alternativas. Comúnmente llamado también el “abogado del diablo”. Es
importante para estas personas señalar los problemas con tacto y no ser demasiado
crítico con las sugerencias de los demás.
· Miembro de equipo
Ayuda a mantener la armonía y el espíritu de equipo. Sabe mejorar la comunicación en
el equipo y hacer participar a las personas en debates. Es un rol importante dentro de un
equipo pero dado que la mayor parte de su trabajo se produce en un segundo plano, no
es fácil apreciar el valor de estas personas.
· Implantador
Es bueno en lograr resultados prácticos y detallados. Se le puede confiar la
responsabilidad de implantar las decisiones de equipo. Sabe como tomar ideas y planes
y convertirlos en procedimientos prácticos.
· Finalizador
Es el tipo de persona que presta especial atención a los detalles y se encarga de hacer un
seguimiento de las tareas inacabadas. Tiende a generar un sentimiento de urgencia
dentro del equipo y es bueno en mantener al equipo de acuerdo con la programación
establecida.
· Especialista
Provee conocimientos y habilidades singulares. En un entorno empresarial no suele ser
un miembro de equipo regular; habitualmente se le invita a participar en un equipo para
tratar temas o problemas específicos. No afecta directamente a la dinámica del equipo,
así que un equipo puede trabajar con éxito sin necesidad de un especialista. Es más un
papel que la persona puede jugar en un equipo que un tipo de personalidad. Un
especialista suele ser de ideas fijas e independiente, lo cual le hace adquirir sus
habilidades especiales.
lunes, 20 de septiembre de 2010
Caso de estudio: Errores clásicos en un proyecto de desarrollo de software
Hoy, me gustaría que dedicáramos un rato a analizar a fondo este caso, extraido del Code Complete, de McConell para que, por equipos, presentárais un informe conteniendo:
caso1
- Errores detectados: quien lo comete, en qué consiste, etc...
- Maneras alternativas de actuar: ¿cómo hubiérais actuado vosotros?
caso1
viernes, 17 de septiembre de 2010
Equipos
Anotad aquí la configuración de vuestros equipos.
Portafolios personales
Acceded a este documento y, por favor, poned el link a vuestro portafolio personal.
¡Bienvenidos!
Hola a todos. Es un placer compartir con vosotros este curso 2010-2011, el cual confío que sea fantástico para todos y que aprendamos mucho unos de otros.
Para ir tomando contacto con la asignatura, os dejo la siguiente mini-intro:
Para ir tomando contacto con la asignatura, os dejo la siguiente mini-intro:
Suscribirse a:
Entradas (Atom)