Barrapunto

Esto de las metodologías ágiles, de las que tanto se está hablando ( 1 , 2 , 3 , ... ) me suena a ponerle un nombre atractivo a la vieja costumbre de la chapuza y el salir del paso. Sobre todo la programación por parejas que me recuerda a Pepe Gotera y Otilio, o a Benito y Cía.
Seguro que estoy equivocado.

Cuando surgen formas nuevas de hacer las cosas es normal tener dudas. Por ello yo te recomiendo que visites el web o te compres algún libro o artículo (te recomiendo los de Martin Fowler). Después de leer lo mejor es probarlo tú mismo.

En ese momento podrás decir si es un nombre atractivo o una mejora sobre cómo se está desarrollando software actualmente. Y de primera mano, sin tener que fiarte de nadie ;)

PD: Yo puse la noticia pero debí hacer algo mal y ha salido como pobrecito hablador :(

A mi personalmente en algun caso puntual lo veo muy util, sobretodo cuando alguien esta atascado y pide ayuda a un compañero, pero tenerlo como metodología bueno, no me gustaría pasarme toda una jornada viendo como un compañero teclea y maneja la maquina, aun más si el compañero tiene mas nivel que yo no me voy a enterar casi de nada y llegara el momento en que me pierda, si la situación es la contraria, o yo acabare desquiciado explicandole lo que estoy haciendo o el no se enterara, asi que a no ser que ambos tengan el mismo nivel es muy dificil que eso funcione.

Solo tiene sentido programar por parejas si el nivel de las dos personas es similar. Si tu nivel es MUY inferior al de tu pareja, el invento no va a funcionar.

Además, se supone que el rol de "tecleador" precisamente es el menos creativo. Se supone que el que no "maneja" la máquina es el que está pensando y guiando al que "teclea". Por supuesto, los roles se intercambian periódicamente.

A veces el simple hecho de poner en palabras (para explicarlo a otro) el problema que tenemos, ayuda a comprenderlo mejor. Más de una vez he pedido ayuda a un compañero y mientras le explicaba lo que pasaba he encontrado yo mismo la solución.

Supongo que este efecto también se consigue programando por parejas.

http://barrapunto.com es la portada dinámica de Barrapunto.

http://www.barrapunto.com es la portada estática de Barrapunto.

Por alguna extraña razón, el demonio que sincroniza de vez en cuando la portada estática con la dinámica se ha muerto y así lleva desde el sábado... así que mientras tanto, hay que quitar las www o darle al logo como tú bien dices ;-)

A ver si volvemos a la normalidad de una vez por todas... gracias por vuestra comprensión. Lo sentimos de veras.

1. - Los puestos se turnan
   
2. - El que teclea es quien lleva el "ritmo" y el otro se encarga de "supervisar" ( Cuidado que en lugar de > has puesto < , eso es mejos si usas esta otra estructura de datos, esa fucncion de la libreria no se usa asi etc.. )
   
3. - El menos veterano adquiere conocimientos de primera mano , sin tener que perder mucho tiempo, Si uno no entiende que hace al otro simpre puede preguntar ;)
   
   
4. - Lo que se consigue con la programación en parejas es reducir el numero de errores en el codigo ( que aunque despistes como el de cambiar un + por un - luego no llevarian un buen rato de detectar) Segun los datos (no recuerdo la URL, pero en mi caso se cumple , sere un negado supongo :( ) el tiempo que estamos depurando , corrigiendo bugs , es mayor que esl que estamos programando propiamente dicho.
   
   
5. En cuanto a lo de la chapuza no estoy de acuerdo . El los libros de extreme programming tambien se dice que el la metodologia funciona en ciertas condiciones y respetando ciertas paracticas. Una de esas practicas son los test unitarios y el refactoring (OJO!! advierte que no se use el refactoring sin los test unitarios como harnes de seguridad). En el metodo "chapuza y pa lanate" no hay metodologia alguna
   
   
6. Es dificil explicar a tu jefe que dos persona con un teclado producen mas que de la manera tradicional :)
   
   
7. Es difici explicarle algunos clientes que tienen que tomar parte activa en el desarrollo
   

 

No has sido demasiado crítico, no te preocupes. Somos completamente conscientes de que lo que más le falta al sitio web es contenido. También es lo más costoso de crear y es necesario tener un poco de paciencia.

Pero además, nunca hemos querido plantear el sitio web como un lugar donde sólo los que lo hemos fundado escribamos artículos o comentarios de libros. Eso no sólo sería excesivamente costoso para nosotros que sólo podemos dedicarle el tiempo libre, sino que además tendría muy poco valor porque sólo tendría la opinión de los de siempre.

Realmente lo que nos gustaría es que todos los que nos visitais aporteis algo. Desde enviar alguna noticia (5 min), hasta vuestra opinión sobre un artículo (15 min), o sobre una práctica concreta (30 Min). Y quien sabe, igual algunos os animais a escribir artículos (N min). Nosotros no pretendemos ser ni los que más sabemos ni los que mejor escribimos sobre este tema, pero seguro que algunos de nuestros visitantes lo son :-)

No me extrañan las respuestas que leo más arriba al final en España a programar full-time y de verdad se dedican 4 y dos estan detras de agile-spain....

Enhorabuena por el site, todavia tiene cosas que pulir, pero es un punto de encuentro cojonudo... por cierto porque no dais cursos presenciales o virtuales, lo digo porque más de un banco deberia mandar a todo el equipo completo de desarrollo a entender de que va XP.. ggod luck!

Estas seguro de eso?

A cuenta de lo del tío que programaba en parejas con un furby trucado (salió en un MBP), alguien contó que el programaba con un peluche estático. Cuando tenía un problema, se lo explicaba al peluche y así sacaba ideas. Decía además que si te da vergüenza que te vean con el muñeco, puedes mandarle correo explicando el problema y el efecto es parecido.

una manera de ponerle nombre a la chapuza y al aquí te pillo, aquí te mato

No. El XP bien hecho exige escribir las pruebas antes que el código y hacer pruebas por unidades (JUnit y demás) varias veces al día. Eso no es una chapuza. Otro asunto es que le llamen XP a cualquier cosa.

Puede que tengas razón en tu argumentación, pero no me ha gustado nada tu analogía con la arquitectura. Diseñar y construir edificios es una tarea completamente diferente al diseño y creación de software. Entre otras cosas, porque los edificios suelen tener una función específica bien conocida, no tienen tantos grados de libertad a la hora de ser implementados y los requisitos que las personas tienen en cuanto a los mismos no varían tan rápidamente con el tiempo. En el software todo esto es diferente.

Fíjate que al software le pedimos que sea flexible porque quizás dentro de dos años vayamos a necesitar tal cosa... en edificios esto no suele pasar. Incluso muchas veces queremos que sea reutilizable (y no sólo el diseño)... en arquitectura sólo se puede con el diseño. Un ejemplo de mala previsión en arquitectura son los edificios que no permiten el cableado que requieren las actuales necesidades... pero claro, esos edificios fueron construidos hace décadas. En el software este plazo es mucho más corto, a veces incluso ni existe.

Otra cosa es que esté por ver el campo de aplicación y la eficacia de la programación extrema. Hace una década, por ejemplo, se daba por supuesto que la creación de núcleos de sistemas operativos se podía hacer sólo con un grupo cerrado, compacto y localizado de programadores... hoy sabemos que esto no es cierto.

Con la programación extrema puede pasar igual. Pueden caer muchos argumentos que damos por sólidos e indiscutibles, o no. El tiempo y la experiencia dirán.

Este en un sitio donde la gente expresa sus opiniones con bastante libertad, así que no pretendo censurarte. Estoy seguro que la respuesta anterior te ha molestado, pero no me parece que merezca un insulto. ¿no cres?

Por cierto, para un asiduo colaborador de varios sitios web... que menos que un alias en barrapunto... Pobrecito Hablador :)