CMMI es un conjunto de buenas practicas por lo que para comprenderlo bien lo primero es leer, leer y leer mas. La primera lectura es la documentación que proporciona el propio SEI.
1º Para la adquisición del producto.
2º Para el desarrollo de proucto.
3º Para los servicios que proporciona el producto.
jueves, 30 de diciembre de 2010
jueves, 23 de diciembre de 2010
La programación heroica
Esta metodología consiste en la ausencia total de planificación, seguimiento y autoridad en un proyecto de desarrollo software pero si mucha presión por parte de los responsables del proyecto para que las cosas salgan y se desarrollen las peticiones del cliente con prioridad total una vez que el cliente las comunica.
Al final el éxito o el fracaso del proyecto depende de la habilidad de los programadores y de su buen entendimiento.
Esta metodología, si se puede llamar así, da como resultado un proyecto completamente dividido en partes incomprensibles que hacen imposible su mantenimiento. Además, todos los miembros del equipo acaban quemadísimos.
¿A alguien le resulta familiar?
Al final el éxito o el fracaso del proyecto depende de la habilidad de los programadores y de su buen entendimiento.
Esta metodología, si se puede llamar así, da como resultado un proyecto completamente dividido en partes incomprensibles que hacen imposible su mantenimiento. Además, todos los miembros del equipo acaban quemadísimos.
¿A alguien le resulta familiar?
miércoles, 22 de diciembre de 2010
Debate. ¿SCRUM vale para todas las fases del proyecto?
Yo:
En mi humilde opinión, SCRUM es una buena metodología para el seguimiento y el desarrollo de software pero no es una metodología para empezar el proyecto. Se ha de implantar una vez ya se está en una etapa del desarrollado en el que se puede decir que se tiene una primera versión de la o las aplicaciones del proyecto.
Contertulio:
No entiendo porqué dices que no es una buena metodología para empezar el proyecto. Que sea una metodología ágil, que no se fomente el upfront design, etc, no quiere decir que empieces a codificar a lo loco sin pensar un poco. En muchos proyectos se hace la famosa iteración 0, en la que precisamente se piensa en todo esto. Lo que si que no se puede hacer es pasarte tres meses diseñando la aplicación.
Yo:
No quería decir hay que empezar a codificar sin más. SCRUM tiene una dinámica en la que cada sprint tiene valor por lo que ya es una ?release? de la aplicación o casi; por ese principio, si no tienes nada (acabas de empezar) ¿el primer y único spirnt debería ser el producto entero?.
Bueno, he sido un poco filósofo en el párrafo anterior. Perdón. Pero lo que quiero decir es que al empezar hay muchas tareas que en realidad no añaden valor directo como indica SCRUM por lo que la tendencia, en mi opinión claro, es amoldar SCRUM para poder hacer sprints que no tienen valor para el cliente, pero entonces ya no es SCRUM seria SCRUM versión beta 1.0.
Cuando digo amoldar me refiero a que si el sprint no genera una ?release? entonces genera una parte que habrá que integrar con otra parte que saldrá de otro sprint. No he visto nada en SCRUM que hable sobre cómo integrar partes. En este enlace esta mi opinión sobre subestimar los costes de integración
http://rumberomelo.blogspot.com/2010/12/la-excesiva-simplicidad.html
Contertulio:
Al finalizar cada sprint lo que entregas es producto potencialmente entregable, es decir, una o varias historias de usuario acabadas. Esto, obviamente, no quiere decir que esté todo lo que pide el cliente. En Scrum tienes una pila de producto y en cada sprint implementas lo que puedas por orden de prioridad. Por lo tanto, por ejemplo, en tu primer sprint podrias tener implementado el sistema de loguin de tu aplicación. Y esa história estará totalmente acabada, con sus tests de aceptación pasados, etc. El cliente la podrá evaluar y darla por buena o no. A partir de esto, se implementa otra(s) história(s) de usuario(s) que se integran con esta y que implementan otras cosas que requiere el usuario. No se implementan n historias en paralelo y después se integra, sinó justo al contrario, estás integrando continuamente.
Por otra part, es normal que Scrum no te hable de como integrar partes explicitamente. Scrum es un marco metodológico para la gestión del proyecto y se debe apoyar en buenas prácticas técnicas como la que se describen en XP. Si te fijas un poco en XP junto con Scrum, verás que la integración se hace continuamente, sprint a sprint, dia a dia, commit a commit.
Yo:
Siguiendo tú ejemplo. Supongamos que tenemos el modulo de login que estará totalmente acabado, se le presentará al cliente, le gusta y todo correcto. Otro sprint me va a dar el modulo de menú principal pero al empezar el desarrollarlo nos damos cuenta que tenemos que cambiar el modulo de login porque no se integran bien (modulo de login con modulo de menú principal) y el cambio es mejor hacerlo en el modulo de login. Por lo que tengo que parar el modulo de menú principal (sprint parado) y empezar un nuevo sprint que es modificación de modulo de login.
Me surgen varios problemas según he podido leer de SCRUM:
- No he visto como se tratan los sprint parados. ¿Cómo va eso? ¿Se para y se retoma desde donde se dejo?¿Se empieza de nuevo?
- Los sprint se generan siempre un día concreto de la semana o del mes, al tener que generarlos de urgencia se está rompiendo el ciclo normal de trabajo por lo que se asume un riesgo: ?como lo asimilará un cambio drástico en el ritmo de trabajo el equipo de desarrollo?.
SCRUM, como tú dices, intenta que si el cliente no puede ver la aplicación hecha que al menos vea algo que le guste; pero es que eso es imposible en una aplicación medio grande, hay demasiados factores y, además, en la mayoría de proyectos el cliente necesita una interfaz para ver el valor de la aplicación y esa interfaz puede que no exista porque no es parte de los requisitos.
SCRUM me parece buena metodologia pero cuando ya te has quitado de encima "los pequeños factores".
Contertulio:
Lo normal es que en la reunión de inicio de sprint, el equipo se dé cuenta que la nueva história que le pide el cliente requiere de la modificación de un elemento ya existente. No hay problema, se pone como tarea, se hace y listos. Que una história un dia determinado se dé por acabada no quiere decir que nunca más se toque lo que se ha implementado. Scrum abraza el cambio y lo vé como algo positivo, ya que acerca la aplicación a lo deseado por el cliente.
Por ejemplo, para empezar el cliente podría haber pedido una versión básica de login, y más adelante quiere añadir más funcionalidad. Cap problema, se hace y ya está.
Para para un sprint, se tiene que dar una cosa realmente excepcional, como por ejemplo una repriorización brutal a mitad de sprint. En general, no se rompen los sprints.
Yo:
El cambio al que me refiero no es una petición de cliente. Me refiero a que hay un problema de integración. Si, como creo que quieres decir, abrazo ese cambio en el login como una tarea del modulo de menú principal ¿no estoy perdiendo ese valor que se consigue al decir que con el primer sprint tengo algo con valor del que siempre podría partir?. Ten en cuenta que al desarrollar el modulo de menú principal te has dado cuenta que en verdad el modulo de login no es correcto pero para el cliente ya tiene valor porque lo ha visto.
¿No crees que SCRUM subestima el coste de codificación (cosa que no hace XP) e integración?
Y en otro orden de cosas, dar la posibilidad de asimilar en cualquier momento un requisito o modificación del cliente no sé si es buena idea. Teóricamente es perfecto, pero en la práctica puede que tu proyecto fuera para construir un coche y terminar con un avión.
Contertulio:
Empezemos por la primera. En un proyecto gestionado con Scrum, en cada sprint tenemos que tener implementado aquello que dá más valor al cliente. El cliente decidió que el loguin tal como lo definió aquel dia era lo más importante para él. Si n sprints después resulta que hay que modificarlo un poco para adaptarlo a otra historia, no pasa nada. Una história acabada es una história acabada para ese sprint. Si después se tiene que crear otra história que modifique la codificación de la primera, es que tiene mucho valor por el cliente y él estará encantado que la modifiques. Recuerda que el cliente en Scrum ve la aplicación al final de cada sprint, y la tiene que ver toda, no sólo lo nuevo. Por tanto, para él la nueva história tiene valor, y mucho.
Lo segundo. Scrum no subestima el coste de codificación. Recuerda que quien estima en Scrum es el equipo, és decir, quien lo va a codificar todo y a quien se va a exigir tener el producto funcionando a final de sprint, con lo que ya se cuidará de estimar todos los detalles que comporte la programación de la tarea.
Tercero, si acabas hacieno un avión, es que en el fondo el cliente queria hacer un avión y a principio de proyecto no lo sabía. Por eso es muy bueno no hacer un gran upfront design suponiendo que el tio queria hacer un coche pq vamos a sufrir mucho. Si vamos implementando história a história, poco a poco y nos vamos adaptando poco a poco a los cambios del cliente, esta transición será mucho más llevadera.
Yo:
Si teóricamente no te quito razón. Pero en la práctica, desde el punto de vista de estar allí en el proyecto, veo tantas cosas que no van a ser así. Las estimaciones hechas por el equipo teóricamente deben ser exactas (es la gente que lo va a implementar) pero en la práctica... ¿me vas a decir que TODOS los programadores asimilan y aceptan las pautas marcadas para el desarrollo y van a seguir el diseño?.
Lo del símil del avión no lo he concretado bien, quería decir ?puede que tu proyecto fuera para construir un coche y terminar con un avión. Y te han pagado por un coche?.
Respecto a modificar el login, dices: ?Si después se tiene que crear otra história que modifique la codificación de la primera, es que tiene mucho valor por el cliente y él estará encantado que la modifiques?. Él estará encantado si te ha pedido una modificación. Pero la modificación no te la ha pedido él, en el ejemplo quería decir que, al desarrollar, el equipo se ha dado cuenta que hay que modificarlo por lo que el cliente seguramente te dirá:?¿Pero eso no estaba ya??
Contertulio:
Las estimaciones son, por definición, inexactas. Eso si, serán mucho más exactas las que haga el equipo después de una buena reflexión en la reunión de inicio de sprint que no la de un analista o jefe de proyecto que haga al vuelo.
Que todos los programadores asimilen y acepten las pautas marcadas para el desarrollo y sigan el diseño, es tan ""fácil"" como hacer unas buenas revisiones de código a final del sprint.
El tema de la presupuestación es otro tema aparte. Si haces Scrum con proyectos de presupuesto cerrado, tendrás que empezar a negociar con él cliente. Si él pidió un coche y ahora te pide un avión, pués o lo quitas features a implementar del avión, o le cobras más. Pero este problema lo tendrás con Scrum y con todas las metodologías. Aunque bien gestionado, con Scrum lo harás mucho mejor :D
Y lo tercero, todo es comunicación. Esto se habla en la reunión de inicio de sprint. El cliente te cuenta lo que quiere hacer, tu le cuentas las implicaciones y él decide si tirar para adelante o no. La comunicación entre el equipo y el cliente ( o el Prodcut Owner ) es vital.
En mi humilde opinión, SCRUM es una buena metodología para el seguimiento y el desarrollo de software pero no es una metodología para empezar el proyecto. Se ha de implantar una vez ya se está en una etapa del desarrollado en el que se puede decir que se tiene una primera versión de la o las aplicaciones del proyecto.
Contertulio:
No entiendo porqué dices que no es una buena metodología para empezar el proyecto. Que sea una metodología ágil, que no se fomente el upfront design, etc, no quiere decir que empieces a codificar a lo loco sin pensar un poco. En muchos proyectos se hace la famosa iteración 0, en la que precisamente se piensa en todo esto. Lo que si que no se puede hacer es pasarte tres meses diseñando la aplicación.
Yo:
No quería decir hay que empezar a codificar sin más. SCRUM tiene una dinámica en la que cada sprint tiene valor por lo que ya es una ?release? de la aplicación o casi; por ese principio, si no tienes nada (acabas de empezar) ¿el primer y único spirnt debería ser el producto entero?.
Bueno, he sido un poco filósofo en el párrafo anterior. Perdón. Pero lo que quiero decir es que al empezar hay muchas tareas que en realidad no añaden valor directo como indica SCRUM por lo que la tendencia, en mi opinión claro, es amoldar SCRUM para poder hacer sprints que no tienen valor para el cliente, pero entonces ya no es SCRUM seria SCRUM versión beta 1.0.
Cuando digo amoldar me refiero a que si el sprint no genera una ?release? entonces genera una parte que habrá que integrar con otra parte que saldrá de otro sprint. No he visto nada en SCRUM que hable sobre cómo integrar partes. En este enlace esta mi opinión sobre subestimar los costes de integración
http://rumberomelo.blogspot.com/2010/12/la-excesiva-simplicidad.html
Contertulio:
Al finalizar cada sprint lo que entregas es producto potencialmente entregable, es decir, una o varias historias de usuario acabadas. Esto, obviamente, no quiere decir que esté todo lo que pide el cliente. En Scrum tienes una pila de producto y en cada sprint implementas lo que puedas por orden de prioridad. Por lo tanto, por ejemplo, en tu primer sprint podrias tener implementado el sistema de loguin de tu aplicación. Y esa história estará totalmente acabada, con sus tests de aceptación pasados, etc. El cliente la podrá evaluar y darla por buena o no. A partir de esto, se implementa otra(s) história(s) de usuario(s) que se integran con esta y que implementan otras cosas que requiere el usuario. No se implementan n historias en paralelo y después se integra, sinó justo al contrario, estás integrando continuamente.
Por otra part, es normal que Scrum no te hable de como integrar partes explicitamente. Scrum es un marco metodológico para la gestión del proyecto y se debe apoyar en buenas prácticas técnicas como la que se describen en XP. Si te fijas un poco en XP junto con Scrum, verás que la integración se hace continuamente, sprint a sprint, dia a dia, commit a commit.
Yo:
Siguiendo tú ejemplo. Supongamos que tenemos el modulo de login que estará totalmente acabado, se le presentará al cliente, le gusta y todo correcto. Otro sprint me va a dar el modulo de menú principal pero al empezar el desarrollarlo nos damos cuenta que tenemos que cambiar el modulo de login porque no se integran bien (modulo de login con modulo de menú principal) y el cambio es mejor hacerlo en el modulo de login. Por lo que tengo que parar el modulo de menú principal (sprint parado) y empezar un nuevo sprint que es modificación de modulo de login.
Me surgen varios problemas según he podido leer de SCRUM:
- No he visto como se tratan los sprint parados. ¿Cómo va eso? ¿Se para y se retoma desde donde se dejo?¿Se empieza de nuevo?
- Los sprint se generan siempre un día concreto de la semana o del mes, al tener que generarlos de urgencia se está rompiendo el ciclo normal de trabajo por lo que se asume un riesgo: ?como lo asimilará un cambio drástico en el ritmo de trabajo el equipo de desarrollo?.
SCRUM, como tú dices, intenta que si el cliente no puede ver la aplicación hecha que al menos vea algo que le guste; pero es que eso es imposible en una aplicación medio grande, hay demasiados factores y, además, en la mayoría de proyectos el cliente necesita una interfaz para ver el valor de la aplicación y esa interfaz puede que no exista porque no es parte de los requisitos.
SCRUM me parece buena metodologia pero cuando ya te has quitado de encima "los pequeños factores".
Contertulio:
Lo normal es que en la reunión de inicio de sprint, el equipo se dé cuenta que la nueva história que le pide el cliente requiere de la modificación de un elemento ya existente. No hay problema, se pone como tarea, se hace y listos. Que una história un dia determinado se dé por acabada no quiere decir que nunca más se toque lo que se ha implementado. Scrum abraza el cambio y lo vé como algo positivo, ya que acerca la aplicación a lo deseado por el cliente.
Por ejemplo, para empezar el cliente podría haber pedido una versión básica de login, y más adelante quiere añadir más funcionalidad. Cap problema, se hace y ya está.
Para para un sprint, se tiene que dar una cosa realmente excepcional, como por ejemplo una repriorización brutal a mitad de sprint. En general, no se rompen los sprints.
Yo:
El cambio al que me refiero no es una petición de cliente. Me refiero a que hay un problema de integración. Si, como creo que quieres decir, abrazo ese cambio en el login como una tarea del modulo de menú principal ¿no estoy perdiendo ese valor que se consigue al decir que con el primer sprint tengo algo con valor del que siempre podría partir?. Ten en cuenta que al desarrollar el modulo de menú principal te has dado cuenta que en verdad el modulo de login no es correcto pero para el cliente ya tiene valor porque lo ha visto.
¿No crees que SCRUM subestima el coste de codificación (cosa que no hace XP) e integración?
Y en otro orden de cosas, dar la posibilidad de asimilar en cualquier momento un requisito o modificación del cliente no sé si es buena idea. Teóricamente es perfecto, pero en la práctica puede que tu proyecto fuera para construir un coche y terminar con un avión.
Contertulio:
Empezemos por la primera. En un proyecto gestionado con Scrum, en cada sprint tenemos que tener implementado aquello que dá más valor al cliente. El cliente decidió que el loguin tal como lo definió aquel dia era lo más importante para él. Si n sprints después resulta que hay que modificarlo un poco para adaptarlo a otra historia, no pasa nada. Una história acabada es una história acabada para ese sprint. Si después se tiene que crear otra história que modifique la codificación de la primera, es que tiene mucho valor por el cliente y él estará encantado que la modifiques. Recuerda que el cliente en Scrum ve la aplicación al final de cada sprint, y la tiene que ver toda, no sólo lo nuevo. Por tanto, para él la nueva história tiene valor, y mucho.
Lo segundo. Scrum no subestima el coste de codificación. Recuerda que quien estima en Scrum es el equipo, és decir, quien lo va a codificar todo y a quien se va a exigir tener el producto funcionando a final de sprint, con lo que ya se cuidará de estimar todos los detalles que comporte la programación de la tarea.
Tercero, si acabas hacieno un avión, es que en el fondo el cliente queria hacer un avión y a principio de proyecto no lo sabía. Por eso es muy bueno no hacer un gran upfront design suponiendo que el tio queria hacer un coche pq vamos a sufrir mucho. Si vamos implementando história a história, poco a poco y nos vamos adaptando poco a poco a los cambios del cliente, esta transición será mucho más llevadera.
Yo:
Si teóricamente no te quito razón. Pero en la práctica, desde el punto de vista de estar allí en el proyecto, veo tantas cosas que no van a ser así. Las estimaciones hechas por el equipo teóricamente deben ser exactas (es la gente que lo va a implementar) pero en la práctica... ¿me vas a decir que TODOS los programadores asimilan y aceptan las pautas marcadas para el desarrollo y van a seguir el diseño?.
Lo del símil del avión no lo he concretado bien, quería decir ?puede que tu proyecto fuera para construir un coche y terminar con un avión. Y te han pagado por un coche?.
Respecto a modificar el login, dices: ?Si después se tiene que crear otra história que modifique la codificación de la primera, es que tiene mucho valor por el cliente y él estará encantado que la modifiques?. Él estará encantado si te ha pedido una modificación. Pero la modificación no te la ha pedido él, en el ejemplo quería decir que, al desarrollar, el equipo se ha dado cuenta que hay que modificarlo por lo que el cliente seguramente te dirá:?¿Pero eso no estaba ya??
Contertulio:
Las estimaciones son, por definición, inexactas. Eso si, serán mucho más exactas las que haga el equipo después de una buena reflexión en la reunión de inicio de sprint que no la de un analista o jefe de proyecto que haga al vuelo.
Que todos los programadores asimilen y acepten las pautas marcadas para el desarrollo y sigan el diseño, es tan ""fácil"" como hacer unas buenas revisiones de código a final del sprint.
El tema de la presupuestación es otro tema aparte. Si haces Scrum con proyectos de presupuesto cerrado, tendrás que empezar a negociar con él cliente. Si él pidió un coche y ahora te pide un avión, pués o lo quitas features a implementar del avión, o le cobras más. Pero este problema lo tendrás con Scrum y con todas las metodologías. Aunque bien gestionado, con Scrum lo harás mucho mejor :D
Y lo tercero, todo es comunicación. Esto se habla en la reunión de inicio de sprint. El cliente te cuenta lo que quiere hacer, tu le cuentas las implicaciones y él decide si tirar para adelante o no. La comunicación entre el equipo y el cliente ( o el Prodcut Owner ) es vital.
martes, 21 de diciembre de 2010
Reglas de XP
Una pagina donde se puede encontrar las reglas a seguir en cada aspecto de un proyecto software según la programación extrema (XP).
http://www.extremeprogramming.org/rules.html
http://www.extremeprogramming.org/rules.html
La excesiva simplicidad
Una creencia muy arraigada en todas las metodologías (XP, SCRUM, RUP, etc..) es pensar que al SIMPLIFICAR una tarea siempre se obtiene valor y se minimizan riesgos. Es decir, si hay que hacer una tarea entonces mejor hacer dos más sencillas o si hay que hacer un algoritmo mejor dividirlo en trozos.
Es obvio que es mejor hacer dos tareas que cuesten “20” que una que cueste “40” si tengo dos miembros de mi equipo que pueden llevar a cabo una tarea, además que es mejor asumir el riesgo de dos procesos que de uno ya que si tengo dos procesos y falla uno entonces el proceso total esta al 50% pero si solo tengo una tarea y ha fallado entonces el proceso total esta al 0%. Pero al pensar en la simplificación de una tarea, en dividirla, siempre se olvidan dos cosas o no se les da el impacto real que tienen:
Es obvio que es mejor hacer dos tareas que cuesten “20” que una que cueste “40” si tengo dos miembros de mi equipo que pueden llevar a cabo una tarea, además que es mejor asumir el riesgo de dos procesos que de uno ya que si tengo dos procesos y falla uno entonces el proceso total esta al 50% pero si solo tengo una tarea y ha fallado entonces el proceso total esta al 0%. Pero al pensar en la simplificación de una tarea, en dividirla, siempre se olvidan dos cosas o no se les da el impacto real que tienen:
- Integración: Si divides una tarea en subtareas luego hay que integrarlas para obtener la funcionalidad deseada y en muchos casos los costes de integración superan con creces la mejora que se consiguió al dividir la tarea.
- Penalización en rendimiento: La integración puede ser sencilla debido a que las fronteras entre subtareas esta clara y es muy flexible pero en cualquier aplicación medio compleja tanta modularidad y flexibilidad de comunicación suele traducir en que a la hora de probar la aplicación esta tiene un rendimiento pésimo.
lunes, 20 de diciembre de 2010
Entorno de pruebas para aplicaciones JAVA
Se tienen que hacer siempre pruebas de caja negra y de caja blanca.
Las pruebas de caja negra deben estar definidas por los analistas. Los analistas pueden definir las pruebas a su elección pero es responsabilidad del jefe de proyecto decidir si se cubren todos los aspectos necesarios y para ello es IMPRESCINDIBLE mirar algo de código y ejecutarlo. Las pruebas de caja negra se pueden definir como se crea más oportuna pero debe cumplir que al compilar una versión TODAS las pruebas de testeo de la aplicación deben de ser correctas, utilidades como MAVEN ofrecen esa posibilidad. Las pruebas se pueden definir a 3 niveles:
Las pruebas de caja blanca las puede definir un analista o el jefe de proyecto pero es muy importante que sea el miembro del equipo encargado de enseñar la aplicación al cliente. Los miembro del equipo responsable de ejecutar las pruebas deben de tener los suficientes conocimientos técnicos y de la aplicación para comprobar que las pruebas se realizan correctamente, es decir no basta con darle un botón y ver que la pantalla dice OK si, por ejemplo, es una operación de alta de cliente entonces hay que ver que en base de datos esta el cliente. La forma de definir las pruebas es muy subjetiva pero deben cumplir que sea CLARO y SIN LUGAR A DUDAS que cubren todos los casos de uso.
Las pruebas de caja negra deben estar definidas por los analistas. Los analistas pueden definir las pruebas a su elección pero es responsabilidad del jefe de proyecto decidir si se cubren todos los aspectos necesarios y para ello es IMPRESCINDIBLE mirar algo de código y ejecutarlo. Las pruebas de caja negra se pueden definir como se crea más oportuna pero debe cumplir que al compilar una versión TODAS las pruebas de testeo de la aplicación deben de ser correctas, utilidades como MAVEN ofrecen esa posibilidad. Las pruebas se pueden definir a 3 niveles:
- Interfaz: Son pruebas a los accesos de los usuario a la aplicación. Requieren que la aplicación este funcionando.
- Lógica: Son pruebas sobre clases a las que accede la interfaz y tiene significado dentro del contexto de la aplicación. No requieren que la aplicación este funcionando.
- Servicios: Son pruebas sobre clases a las que accede la lógica y son unidades de trabajo que al combinar de una manera (llamadas desde clases de lógica) tiene significado dentro del contexto de la aplicación. No requieren que la aplicación este funcionando.
Las pruebas de caja blanca las puede definir un analista o el jefe de proyecto pero es muy importante que sea el miembro del equipo encargado de enseñar la aplicación al cliente. Los miembro del equipo responsable de ejecutar las pruebas deben de tener los suficientes conocimientos técnicos y de la aplicación para comprobar que las pruebas se realizan correctamente, es decir no basta con darle un botón y ver que la pantalla dice OK si, por ejemplo, es una operación de alta de cliente entonces hay que ver que en base de datos esta el cliente. La forma de definir las pruebas es muy subjetiva pero deben cumplir que sea CLARO y SIN LUGAR A DUDAS que cubren todos los casos de uso.
jueves, 16 de diciembre de 2010
Una ayuda con SCRUM
En esta página podéis encontrar un libro en castellano sobre SCRUM gracias a Juan Palacio.
http://www.safecreative.org/work/0710210187520
http://www.safecreative.org/work/0710210187520
El gran fallo
El gran fallo de la gestión de proyectos consiste en tratar el desarrollo como algo “terciario”. Todas las metodologías para exponer, gestionar, seguir y mantener un software que yo conozco se centran más en problemas de alto nivel como:
No quiero decir que estos temas no sean importantes. SON MUY IMPORTANTES pero AUN ES MAS IMPORTANTE EL DESARROLLO DEL SOFTWARE. Por lo que si al planificar se tarda más en planificar, por ejemplo, como son los casos de uso que en planificar como se va a implementar las partes de la aplicación que hacen posible ese caso de uso entonces ya estamos cometiendo un fallo.
Una excepción es la programación extrema (XP) que si indica claramente la pautas para la codificación y el testeo.
- Como absorber los requerimientos del cliente.
- Como dividir el trabajo en tareas.
- Como presentar “release” de la aplicación.
- Que documentación aportar.
- Como absorber cambios cuando ya ha empezado el proyecto.
- Etc..
No quiero decir que estos temas no sean importantes. SON MUY IMPORTANTES pero AUN ES MAS IMPORTANTE EL DESARROLLO DEL SOFTWARE. Por lo que si al planificar se tarda más en planificar, por ejemplo, como son los casos de uso que en planificar como se va a implementar las partes de la aplicación que hacen posible ese caso de uso entonces ya estamos cometiendo un fallo.
Una excepción es la programación extrema (XP) que si indica claramente la pautas para la codificación y el testeo.
miércoles, 15 de diciembre de 2010
RUP ¿Cuál es el fallo?
La metodología RUP para el desarrollo de software es el gran padre de todas las metodologías que se siguen en todos los proyectos comerciales. En realidad se intenta utilizar RUP para el desarrollo de software pero al final la degradación de esta metodología es tal que el equipo siempre llega a esa sensación de que el proyecto no tiene rumbo.
Es entonces cuando ya no es metodología RUP, es una especie de “RUP v1” o “RUP v1.3”. Lo curioso es que cuando se analizan estas “derivadas de RUP“, te das cuenta de que potencian todas las carencias de RUP y las virtudes desaparecen.
El gran fallo de RUP es que es demasiado teórico (UML, diagramas, documentación para esto, documentación para lo otro), genérico y se trata el desarrollo como un paso más (por no decir que lo trata como un apartado dentro de un paso más). Este último problema es el más grave porque, al final, el desarrollo y todo lo que conlleva (diseño, implementación, pruebas, seguimiento) es en lo que se gasta la inmensa mayoría del tiempo del proyecto.
Es entonces cuando ya no es metodología RUP, es una especie de “RUP v1” o “RUP v1.3”. Lo curioso es que cuando se analizan estas “derivadas de RUP“, te das cuenta de que potencian todas las carencias de RUP y las virtudes desaparecen.
El gran fallo de RUP es que es demasiado teórico (UML, diagramas, documentación para esto, documentación para lo otro), genérico y se trata el desarrollo como un paso más (por no decir que lo trata como un apartado dentro de un paso más). Este último problema es el más grave porque, al final, el desarrollo y todo lo que conlleva (diseño, implementación, pruebas, seguimiento) es en lo que se gasta la inmensa mayoría del tiempo del proyecto.
lunes, 13 de diciembre de 2010
Competencia
Al principio de un proyecto hay tiempo, hay dinero, hay gente, hay buenas intenciones, hay planes para un desarrollo correcto pero los proyectos se van degenerando con el tiempo y no solo desaparecen todos estos factores sino que aparecen preguntas como “¿Cómo se ha liado esto?”, “¿En que hemos fallado?”, “¿Como seguimos?”.
Para evitar la degeneración de un proyecto un factor clave es la competencia. La competencia es la funcionalidad de un individuo dentro de un grupo de trabajo. Para asegurarse que cada individuo comprende y sigue su competencia hay que:
Supongamos el siguiente ejemplo, tenemos un proyecto donde definimos las categorías de jefe, analista y programador.
1º Definir que hace cada categoría:
Para evitar la degeneración de un proyecto un factor clave es la competencia. La competencia es la funcionalidad de un individuo dentro de un grupo de trabajo. Para asegurarse que cada individuo comprende y sigue su competencia hay que:
- Definir que categorías estratifican a todos los miembros del proyecto y las competencias de cada categoría.
- Asegurarse de que toda categoría superior tiene que tener una impresión empírica de las categorías inferiores.
Supongamos el siguiente ejemplo, tenemos un proyecto donde definimos las categorías de jefe, analista y programador.
1º Definir que hace cada categoría:
- Jefe:
- Relación con el cliente
- Seguimiento de los hitos
- Analista:
- Traducir hitos en tareas
- Agrupar el software desarrollado en cada tarea para obtener el producto final
- Programador:
- Implementar tareas
2 º Supervisión:
- Jefe:
- El código tiene la calidad deseada
- El código realiza la funcionalidad deseada
- La división en tareas es correcta
- La integración es correcta
- Analista:
- El código tiene la calidad deseada
- El código realiza la funcionalidad deseada
- Programador:
- Nada
viernes, 10 de diciembre de 2010
Necesidad de jerarquía
Siempre se han de establecer eslabones en la cadena de mando de un proyecto. El jefe tiene que tener la visión global del proyecto, la que tiene el cliente y además siempre está bien que revise el código, los equipos de desarrollo, haga pruebas, etc.. para tener un contacto más directo con el desarrollo y sacar sus propias conclusiones. Pero a la hora de evaluar resultados y repartir trabajo solo debe hablar con los analistas que están por debajo inmediatamente de él; y estos con los programadores que están por debajo. Si el jefe habla directamente con un programador es un síntoma de que algo está fallando.
Suscribirse a:
Comentarios (Atom)