Diferencia entre revisiones de «Kent Beck»

(Fuentes)
(Fuentes)
 
Línea 116: Línea 116:
 
* [http://booksforgeeks.com/author/kent-beck Libros de Kent beck]. Disponible en "booksforgeeks.com". Consultado el 8 de noviembre del 2011.
 
* [http://booksforgeeks.com/author/kent-beck Libros de Kent beck]. Disponible en "booksforgeeks.com". Consultado el 8 de noviembre del 2011.
 
* [http://www.google.com.cu/search?tbm=isch&hl=es&source=hp&biw=1024&bih=576&q=Kent+beck&btnG=Buscar+im%C3%A1genes&gbv=2&oq=Kent+beck&aq=f&aqi=&aql=&gs_sm=s&gs_upl=0l0l0l946l0l0l0l0l0l0l0l0ll0l0 Imagen Kent beck].  Disponible en "www.google.com.cu". Consultado el 8 de noviembre del 2011.
 
* [http://www.google.com.cu/search?tbm=isch&hl=es&source=hp&biw=1024&bih=576&q=Kent+beck&btnG=Buscar+im%C3%A1genes&gbv=2&oq=Kent+beck&aq=f&aqi=&aql=&gs_sm=s&gs_upl=0l0l0l946l0l0l0l0l0l0l0l0ll0l0 Imagen Kent beck].  Disponible en "www.google.com.cu". Consultado el 8 de noviembre del 2011.
[[Categoría:Científicos]][[Categoría:Tecnólogos e Ingenieros]][[Categoría:Informáticos]][[Categoría:Personalidades]][[Categoría:Programadores]][[Categoría:Personalidades de la ciencia]][[Categoría:Investigadores]]
+
[[Categoría:Científicos de Estados Unidos]][[Categoría:Ingenieros de Estados Unidos]][[Categoría:Informáticos de Estados Unidos]][[Categoría:Programadores de Estados Unidos]][[Categoría:Investigadores de Estados Unidos]]

última versión al 11:11 17 nov 2017

Kent Beck
Información sobre la plantilla
Kent Beck.jpg
Creador de la Metodología ágil para el desarrollo de software.
NombreKent Beck Martin Fowler
NacimientoBandera de los Estados Unidos de América Estados Unidos
NacionalidadEstadounidense
OcupaciónProgramador

Kent Beck. Es uno de los creadores de la Metodología ágil para el desarrollo de software conocida como programación extrema. También creó, junto a Erich Gamma el framework de pruebas unitarias para Java, JUnit.

Bibliografía

Reflexiones

“El problema (de los proyectos de desarrollo de software) no es el cambio porque el cambio se va a producir; el problema, más bien, es la incapacidad de afrontar el cambio cuando se produce”.

Ahí, se encuentra uno de los grandes problemas de los proyectos de desarrollo de software y es el hecho de no enfocarse desde el punto de vista de que las especificaciones iniciales van a cambiar, ya sea porque el usuario no ha trasladado adecuadamente lo que quiere, porque el equipo de proyecto no ha interpretado correctamente lo que se le ha pedido o porque los requisitos y/o las prioridades han cambiado.

No es realista afrontar un proyecto de esa manera y sin embargo está a la orden del día encontrarnos con desarrollos que no tienen previsto un mantenimiento y eso es un error tanto aplicando metodologías ágiles como, sobre todo, aplicando metodologías clásicas.

El software se tiene que desarrollar pensando en que va a cambiar y los medios puestos a disposición del sistema de información (o del conjunto de sistemas de información de una organización) deben poder dar respuesta a cuando esos cambios se produzcan, que a veces no sabremos cuando, pero sí sabemos que ocurrirán.

Lineamientos principales

Valores

Son conceptos universales, idealmente se aplican en todos los ámbitos. Es el camino para conducir el propósito a la práctica.

Comunicación

Es un factor importante para crear sentido de equipo y lograr cooperación efectiva. Cuando surgen problemas sorpresivos puede ayudar a resolverlos. La mayor parte de los problemas son causados por carencia de conocimiento o por carencia de comunicación.

Si el problema tiene origen en la falta de conocimiento, no hay nada que pueda hacerse de antemano. Cuando encontremos un problema, preguntémonos si puede ser causado por una carencia de comunicación. Si es así, se debe analzar:

  • ¿Qué tipo de comunicación necesitamos para abordar el problema?
  • ¿Qué comunicación necesitamos para mantenernos fuera de esta situación en el futuro?

Simplicidad

Es el valor más intensamente intelectual. Se trata de pensar las cosas de forma de eliminar toda complejidad innecesaria.

Retroalimentación

Los cambios son inevitables y crean la necesidad del Feedback. Personalmente entiendo que es común el escenario en el cual la coyuntura nos condiciona a implementar funcionalidad de forma imperfecta en uno o varios aspectos. Esta situación crea una fuerte necesidad de Feedback, de otra forma se asume el riesgo de perpetuar esa imperfección y quizá ya nadie recuerde su existencia.

Existen fundamentalmente tres motivos que dificultan hacer las cosas bien al primer intento:

  • Al resolver un problema por primera vez, puede haber más de una solución que funcione o que la solución no sea totalmente clara.
  • Lo que es bueno hoy puede no serlo mañana.
  • Hacer algo con absoluta corrección podría insumir tanto tiempo que las circunstancias cambiantes futuras invaliden la solución de hoy, antes que se finalice.

Lograr satisfacción en un esquema de mejoras a cambio de, esperar la perfección al instante, es posible sólo acudiendo al Feedback, que puede producirse de varias formas:

  • Escuchar distintas opiniones sobre una idea.
  • Como se ve el código una vez implementada la idea,
  • Si los tests fueron fáciles de escribir,
  • Si los tests ejecutaron,
  • Cómo la idea funciona una vez que se hizo el deploy.

Un equipo debe esforzarse en generar tanto Feedback como pueda, tan rápidamente como le sea posible. Tan pronto como se conoce la situación, tan pronto podremos adaptarnos.

Coraje

Es la acción efectiva de enfrentar el temor.

A veces el coraje se manifiesta en forma de paciencia. Cuando uno sabe que existe un problema pero no lo conoce, se requiere coraje para esperar que se manifieste distintivamente. Hay que tener en cuenta que el coraje como valor principal, sin valores que contrabalanceen, puede ser peligroso, incluso puede jugar contra el espíritu del equipo. Pero cuando el coraje juega en confluencia con los otros valores es una herramienta poderosa.

Respeto

Este es el valor que subyace a los otros cuatro. XP funciona en un marco dónde cada integrante del equipo considera a cada otro y lo que está haciendo. La contribución de cada persona necesita respeto.

Otros

  • Seguridad.
  • Predicción.
  • Calidad de vida.

Las 4 reglas de Kent Beck para escribir código simple

  • Estar bien cubierto y satisfacer las aserciones de una buena batería de tests unitarios.
  • Expresar las ideas que nosotros como programadores queremos expresar código auto-documentado.
  • Decir cada cosa una única vez.
  • Evitar tener partes supérfluas: debe ser simple y satisfacer las necesidades actuales, sin pensar en lo que puede pasar en el futuro; y tener el mínimo número de clases y métodos teniendo en cuenta el Principio de Responsabilidad Única.

Véase además

Fuentes

  • Programación. Disponible en "www.extremeprogramming.org". Consultado el 8 de noviembre del 2011.
  • Las 4 Reglas de Kent beck. Disponible en "alonsogarciapablo.com". Consultado el 8 de noviembre del 2011.
  • Libros de Kent beck. Disponible en "booksforgeeks.com". Consultado el 8 de noviembre del 2011.
  • Imagen Kent beck. Disponible en "www.google.com.cu". Consultado el 8 de noviembre del 2011.