… de personas y sistemas.
Desarrollo de Software
Agregando columnas auto increment
19 may
Estoy trabajando en una demo/tutorial sobre desarrollo evolutivo de bases de datos y sus herramientas.
Ya que ayer instalamos un mysql en un cliente para operaciones de software configuration management, se me ocurrió utilizar mysql para el tutorial/demo en cuestión.
Me encontré con algo curioso al intentar agregar una columna auto-incremental a una tabla existente.
Dada esta tabla:
create table program (required_solo_hs int not null, required_inst_hs int not null, required_hs int not null
Intenté agregar una columna id:
alter table program add column id int not null auto_increment
Obteniendo el siguiente error;
Script line: 1 Incorrect table definition;there can be only one auto column and it must be defined as a key
La solución es simplemente indicar que dicha columna además de auto increment es primary key:
alter table program add column id int not null auto_increment key;
Una vez más.. posiblemente a alguien le resulte útil.
Windows Vista 64bits & MySQL: ERROR 1045 (28000): Access denied for user ‘root’@'localhost’
18 may
Hoy en Kleer, pasamos por la experiencia de instalar MySQL 5.1 por primera vez en Vista 64bits. Lejos de ser una instalación amena, como las que estamos acostumbrados, esta nos hizo transpirar la gota gorda.
Luego de bajar el instalador de 64bits, instalarlo y configurarlo, el asistente de configuración no paraba de dar el error:
ERROR 1045 (28000): Access denied for user 'root'@'localhost'
Probamos infinidad de soluciones, pero ninguna funcionó. Salvo la siguiente:
- Parar el servicio “MySQL” desde “Control Panel->Administrative Tools->Services”
- Ir a “C:\Windows\System32″
- Buscar el file cmd.exe, hacer click derecho con SHIFT presionado y seleccionar “Run as administrator”
- Ejecutar el siguiente comando:
mysqld --skip-grant-tables
- Dejar esa ventana corriendo
- Abrir otra ventana de terminal, esta vez NO como administrator: “Start->Run->cmd” ENTER
- Ejecutar el siguiente comando:
mysql -u root mysql
- Walá! Estamos adentro. Ejecutar la siguiente sentencia, cambiando MyPass por un password real que quieras setear:
UPDATE user SET Password=PASSWORD('MyPass') where USER='root'; FLUSH PRIVILEGES; - Salir:
exit
- Cerrar la ventana
- Cerrar la ventana que estaba corriendo como administrator
- Abrir el task manager y matar todos los procesos “mysqld” (debería haber uno solo, de otro usuario “Administrator”)
- Levantar el servicio desde “Control Panel->Administrative Tools->Services”
- Conectarse nuevamente, esta vez como lo veníamos haciendo:
mysql -u root -p
Con este último paso, ya deberían estar conectados sin problemas. Espero esta solución pueda servirle a alguien y se ahorren un buen tiempo.
Agile en Acción! – Marzo 2010 – Review
28 mar
Del 16 al 26 de marzo de 2010 se realizó el workshop Agile en Acción! en la ciudad de Buenos Aires.
Esta edición estuvo dirigida a 15 participantes, quienes mediante una serie de talleres basados en requerimientos reales, crearon las EPICs y User Stories, determinaron su priorización y estimación, crearon el Product Backlog, definieron Velocity, armaron el Release Plan, y terminaron realizando una serie de ejercicios de retrspectiva.
Hubo un clíma muy bueno entre las personas y los equipos que se armaron y todos nos divertimos bastante a lo largo de los 4 días. Dejo aquí las fotos del curso: http://bit.ly/alQC2j
Saludos!
Habra un nuevo Agile en Acción! en Abril-2010: http://bit.ly/agile-en-accion–abril-2010
Roles Ágiles
11 feb
“Los miembros de un equipo de Scrum están acostumbrados a ver dos nuevos roles en sus proyectos: el ScrumMaster y el Product Owner. Pero los cambios a un equipo de proyecto Scrum van mucho más allá de la introducción de dos nuevos roles. Por ejemplo, la naturaleza auto-organizada de un equipo Scrum elimina el rol del líder técnico, los individuos deben ver más allá de sus especialidades y ayudar al equipo de cualquier forma posible; el énfasis se traslada de la simple escritura de requerimientos a la conversación sobre los mismos, y los equipos deberán producir algo tangible para el final de cada Sprint. Porque estos cambios alteran los roles y relaciones dentro del equipo y la organización, muchos contribuyen a los desafíos que estas organizaciones enfrentan cuando adoptan Scrum.”
Esta es una serie de traducciones al español del artículo publicado el 12 de Enero en InfoQ con un extracto del libro “Succeeding with Agile: Software Development Using Scrum” de Mike Cohn que habla acerca de cómo se ven afectados estos roles al transicionar a Scrum:
- Analistas
- Gerentes de Proyectos
- Gerentes Funcionales
- Programadores
- DBAs
- Testers
- Arquitectos
- Diseñadores de UX
He encontrado muchas cosas interesantes y dignas de un buen debate. Seguramente proponga discutir el tema en alguno de los encuentro ágiles que hacemos mensualmente en Buenos Aires.
Diseñadores de Experiencia de Usuario Ágiles
10 feb
“Los miembros de un equipo de Scrum están acostumbrados a ver dos nuevos roles en sus proyectos: el ScrumMaster y el Product Owner. Pero los cambios a un equipo de proyecto Scrum van mucho más allá de la introducción de dos nuevos roles. Por ejemplo, la naturaleza auto-organizada de un equipo Scrum elimina el rol del líder técnico, los individuos deben ver más allá de sus especialidades y ayudar al equipo de cualquier forma posible; el énfasis se traslada de la simple escritura de requerimientos a la conversación sobre los mismos, y los equipos deberán producir algo tangible para el final de cada Sprint. Porque estos cambios alteran los roles y relaciones dentro del equipo y la organización, muchos contribuyen a los desafíos que estas organizaciones enfrentan cuando adoptan Scrum.”
Esta es una serie de traducciones al español del artículo publicado el 12 de Enero en InfoQ con un extracto del libro “Succeeding with Agile: Software Development Using Scrum” de Mike Cohn. Hoy publico la sección de “Diseñadores de Experiencia de Usuario” como parte de la serie “Roles ágiles“.
Diseñadores de Experiencia de Usuario Ágiles
Los diseñadores de experiencia de usuario (User Experience Designers) a menudo tienen una preocupación legítima con la adopción de Scrum. A pesar de que están acostumbrados a trabajar de forma iterativa, prefieren ejecutar sus iteraciones antes que el resto del proyecto. En un proyecto Scrum, sin embargo, no queremos hacer todo el trabajo UED antes de comenzar las actividades de desarrollo. Más >
Testers Ágiles
9 feb
“Los miembros de un equipo de Scrum están acostumbrados a ver dos nuevos roles en sus proyectos: el ScrumMaster y el Product Owner. Pero los cambios a un equipo de proyecto Scrum van mucho más allá de la introducción de dos nuevos roles. Por ejemplo, la naturaleza auto-organizada de un equipo Scrum elimina el rol del líder técnico, los individuos deben ver más allá de sus especialidades y ayudar al equipo de cualquier forma posible; el énfasis se traslada de la simple escritura de requerimientos a la conversación sobre los mismos, y los equipos deberán producir algo tangible para el final de cada Sprint. Porque estos cambios alteran los roles y relaciones dentro del equipo y la organización, muchos contribuyen a los desafíos que estas organizaciones enfrentan cuando adoptan Scrum.”
Esta es una serie de traducciones al español del artículo publicado el 12 de Enero en InfoQ con un extracto del libro “Succeeding with Agile: Software Development Using Scrum” de Mike Cohn. Hoy publico la sección de “Testers”” como parte de la serie “Roles ágiles“.
Testers Ágiles
Durante años, el enfoque de la prueba se ha basado en la definición de Philip Crosby de la calidad: la conformidad con los requisitos. Si la calidad es la conformidad con los requisitos, entonces los mejor es que dichos requisitos estén escritos. Esto ha llevado a muchos Testers a una búsqueda exagerada de un documento de requerimiento perfecto con el que puedan confirmar el cumplimiento del sistema. Sin embargo, si bien la conformidad con los requisitos es buena, la conformidad con las necesidades de los usuarios es aún mejor. En el uso de Scrum reconocemos que es imposible predecir a la perfección todas las necesidades de los usuarios. Más >
Programadores Ágiles
5 feb
“Los miembros de un equipo de Scrum están acostumbrados a ver dos nuevos roles en sus proyectos: el ScrumMaster y el Product Owner. Pero los cambios a un equipo de proyecto Scrum van mucho más allá de la introducción de dos nuevos roles. Por ejemplo, la naturaleza auto-organizada de un equipo Scrum elimina el rol del líder técnico, los individuos deben ver más allá de sus especialidades y ayudar al equipo de cualquier forma posible; el énfasis se traslada de la simple escritura de requerimientos a la conversación sobre los mismos, y los equipos deberán producir algo tangible para el final de cada Sprint. Porque estos cambios alteran los roles y relaciones dentro del equipo y la organización, muchos contribuyen a los desafíos que estas organizaciones enfrentan cuando adoptan Scrum.”
Esta es una serie de traducciones al español del artículo publicado el 12 de Enero en InfoQ con un extracto del libro “Succeeding with Agile: Software Development Using Scrum” de Mike Cohn. Hoy publico la sección de “Programadores” como parte de la serie “Roles ágiles“.
Programadores Ágiles
¿Qué hacen los programadores en un equipo Scrum? Programan. Prueban. Analizan. Diseñan. Hacen todo lo necesario para ayudar al equipo a completar el trabajo comprometido en un sprint. A pesar de que está bien tener un equipo de especialistas en Scrum, los especialistas tienen que estar dispuestas a trabajar fuera de su especialidad cuando sea necesario por el bien del equipo. Más >
Gerentes Funcionales Ágiles
2 feb
“Los miembros de un equipo de Scrum están acostumbrados a ver dos nuevos roles en sus proyectos: el ScrumMaster y el Product Owner. Pero los cambios a un equipo de proyecto Scrum van mucho más allá de la introducción de dos nuevos roles. Por ejemplo, la naturaleza auto-organizada de un equipo Scrum elimina el rol del líder técnico, los individuos deben ver más allá de sus especialidades y ayudar al equipo de cualquier forma posible; el énfasis se traslada de la simple escritura de requerimientos a la conversación sobre los mismos, y los equipos deberán producir algo tangible para el final de cada Sprint. Porque estos cambios alteran los roles y relaciones dentro del equipo y la organización, muchos contribuyen a los desafíos que estas organizaciones enfrentan cuando adoptan Scrum.”
Esta es una serie de traducciones al español del artículo publicado el 12 de Enero en InfoQ con un extracto del libro “Succeeding with Agile: Software Development Using Scrum” de Mike Cohn. Hoy publico la sección de “Gerentes Funcionales” como parte de la serie “Roles ágiles“.
Gerentes Funcionales Ágiles
Los gerentes funcionales, tales como gerentes de desarrollo, gerentes de QA, etcétera, que están acostumbrados a trabajar de una forma matricial seguirán trabajando de esa manera en los proyectos Scrum. Un gerente funcional típico probablemente experimentará cierta disminución en el poder después de la transición, pero esto dependerá en gran medida de cómo el rol fue definido en la organización antes de la transición. Más >
Arquitectos Ágiles
1 feb
“Los miembros de un equipo de Scrum están acostumbrados a ver dos nuevos roles en sus proyectos: el ScrumMaster y el Product Owner. Pero los cambios a un equipo de proyecto Scrum van mucho más allá de la introducción de dos nuevos roles. Por ejemplo, la naturaleza auto-organizada de un equipo Scrum elimina el rol del líder técnico, los individuos deben ver más allá de sus especialidades y ayudar al equipo de cualquier forma posible; el énfasis se traslada de la simple escritura de requerimientos a la conversación sobre los mismos, y los equipos deberán producir algo tangible para el final de cada Sprint. Porque estos cambios alteran los roles y relaciones dentro del equipo y la organización, muchos contribuyen a los desafíos que estas organizaciones enfrentan cuando adoptan Scrum.”
Esta es una serie de traducciones al español del artículo publicado el 12 de Enero en InfoQ con un extracto del libro “Succeeding with Agile: Software Development Using Scrum” de Mike Cohn. Hoy publico la sección de “Arquitectos” como parte de la serie “Roles ágiles“.
Arquitectos Ágiles
Muchos arquitectos han trabajado durante años para merecer el título de arquitecto. Están legítimamente orgullosos de sus conocimientos, experiencia y capacidad para proponer soluciones elegantes a los desafíos técnicos y de negocio. Me parece que muchas de las preocupaciones planteadas por los arquitectos frente a la adopción de Scrum se pueden ubicar en estas dos categorías:
- ¿Las Personas seguirán aplicando las arquitecturas que les digo?
- ¿Cómo puedo asegurar que construiremos un producto con buena arquitectura sin una fase de diseño de arquitectura?
Gerentes de Proyecto Ágiles
29 ene
“Los miembros de un equipo de Scrum están acostumbrados a ver dos nuevos roles en sus proyectos: el ScrumMaster y el Product Owner. Pero los cambios a un equipo de proyecto Scrum van mucho más allá de la introducción de dos nuevos roles. Por ejemplo, la naturaleza auto-organizada de un equipo Scrum elimina el rol del líder técnico, los individuos deben ver más allá de sus especialidades y ayudar al equipo de cualquier forma posible; el énfasis se traslada de la simple escritura de requerimientos a la conversación sobre los mismos, y los equipos deberán producir algo tangible para el final de cada Sprint. Porque estos cambios alteran los roles y relaciones dentro del equipo y la organización, muchos contribuyen a los desafíos que estas organizaciones enfrentan cuando adoptan Scrum.”
Esta es una serie de traducciones al español del artículo publicado el 12 de Enero en InfoQ con un extracto del libro “Succeeding with Agile: Software Development Using Scrum” de Mike Cohn. Hoy publico solo la sección de “Gerentes de Proyecto” como parte de la serie “Roles ágiles“.
Gerentes de Proyecto
En un proyecto con un proceso de desarrollo secuencial, el gerente del proyecto tiene la difícil tarea de asegurar que el producto que desea un cliente es el que se desarrolla. Para ello, el gerente del proyecto debe tratar de manejar todo lo relacionado con el alcance, costo, calidad, personal, comunicación, riesgo, adquisiciones, etc. Algunas de estas responsabilidades en realidad pertenecen a otros. El control del Alcance, por ejemplo, por derecho le pertenece al cliente. Más >
