feed

Metodologías de programación

Cuando todos son ventajas, Sprint Backlog. Hablando de Scrum.

6 comentarios

Sprint Backlog en TFS Preview

El desarrollo de aplicaciones de Software es un trabajo extremadamente complejo que requiere de profesionales con un alto nivel de conocimientos, con talento, con capacidad intelectual y, además, vocación para hacer frente a la necesidad de una continua actualización.

Puede ser que no sea imparcial ya que yo soy programador, pero no conozco ninguna profesión que necesite un reciclaje y aprendizaje constante al nivel de la de “pica código”. Sobre todo porque estamos en un frenesí de novedades que lleva el dicho “camarón que se duerme se lo lleva la corriente” a su más cruel realidad.

Para aumentar la complejidad, es un trabajo que se realiza en equipo, y con problemas de comunicación y de organización inherentes a las propias limitaciones del lenguaje natural. Todos habremos tenido la experiencia de que un requisito, una funcionalidad, descrita al detalle en un documento tanto en el qué, como en el cómo, de repente se da la vuelta y donde describía hacer una cosa nos encontramos que se podía interpretar de otra forma muy distinta. Y cuanto mayor fuera el esfuerzo necesario para completar el requisito, más dudas y equívocos emergían.

Leer más

Anunciate aquí
Anunciate aquí

Pomodoro, un reloj de cocina muy productivo

8 comentarios

Pomodoro Technique

Las metodologías de producción y desarrollo, ya sean en cascada, en espiral o agiles, son en sí mismas una rama completa dentro de la amplia industria de la informática.

Diseñadas y descritas para la gestión del Ciclo de Vida de equipos multidisciplinares durante el desarrollo de software, sufren revoluciones y evoluciones en sus definiciones en búsqueda de la mejora continua.

Pero si estoy yo solo, y tengo la inquietud de mi permanente tendencia a la procrastinación, es decir no hacer hoy lo que puedes hacer mañana, del tiempo que pierdo en todo tipo de interrupciones y en la perdida de foco constante por interrupciones varias. ¿Qué hago?

Pon un reloj de cocina como gestor de trabajo personal, y trata con la técnica Pomodoro.

Leer más

Anunciate aquí

Mejorando con la práctica: Katayunos

6 comentarios

katayunos.jpeg

Los Coding Kata consisten en resolver pequeños problemas de dominio conocido que nos sirven para practicar elementos de programación así como nuestras habilidades en el uso de TDD.

Por otro lado, el desayuno es la comida más importante del día, la que nos aporta energía para comenzar el trabajo con “marcha y ritmo” y preparados para la aventura. ¿Pero que obtenemos de juntar un desayuno con un coding kata?.

Leer más

¿Qué metodología de desarrollo usas en tu trabajo diario?: la pregunta de la semana

2 comentarios

cabecera

A diario en nuestro trabajo como programadores nos enfrentamos al desarrollo de productos concretos. Cada uno de nosotros lo abordamos de una forma distinta aplicando nuestro propio proceso de trabajo (interno o externo).

No todos los proyectos son susceptibles de aplicar, por ejemplo, metodologías ágiles como Scrum o Kanban. En otros se debe seguir usando metodologías más clásicas porque son imposibles de implantar por diversos motivos, el jefe o el cliente. O quizás ni siquiera nos planteamos utilizar algo concreto y vamos de un lado a otro desorientados. ¿Es vuestro caso?

¿Qué metodología de desarrollo usas en tu trabajo diario?

Recordad que para responder, debéis hacerlo desde nuestra sección Genbeta Dev Respuestas (sigue el enlace).

Leer más

Pilas de Producto, hablando de Scrum

9 comentarios

Product Backlog Team Foundation Service

La Pila de Producto, o Product Backlog, es un artefacto del marco de trabajo para la gestión agile de proyectos de desarrollo de software, SCRUM. Y que es, en líneas generales, una lista ordenada u priorizada de las tareas que componen un proyecto de aplicación.

Aunque SCRUM no lo define, el formato que más se utiliza para la tarjeta de trabajo que compone una Pila de Producto es la Historia de Usuario. Sin que haya mayores problemas en utilizar Casos de Uso, o una lista de tareas.

Lo importante es que el propio esfuerzo de realizar la división en tareas implica una organización del trabajo y una primera visión del alcance del proyecto. Es decir, qué es lo que se quiere obtener después de semanas o meses de trabajo.

Leer más

Historias de usuario, una forma natural de análisis funcional

30 comentarios

Historias de Usuario

Hoy es el día 0 del proyecto que me va a llevar a mí y al resto de compañeros a construir una buena y bonita aplicación, de la cual nos ha hablado con entusiasmo nuestra directora, nuestro gerente y el jefe de proyecto.

Tiene pinta de ser un poquillo compleja y, además, el JP lleva casi un mes escribiendo el documento de análisis funcional que estamos esperando como agua de Mayo. A ver si firma de una vez el cliente y nos ponemos a lanzar líneas de código.

La cara de todos se queda un poco más pálida cuando nos encontramos enfrente de 150 páginas de casos de uso, tablas de funcionalidades, de acciones externas e internas, de diagramas de estado, de esquemas de datos, de diagramas de clases. Todo siguiendo un estricto UML.

Para finalizar, o en medio de todo este volumen de papel, me encuentro con la matriz de trazabilidad que relaciona los diferentes casos de uso con el requisito que lo cumplimenta y que, seamos sinceros, es absolutamente ilegible en cuanto supera las 20 filas por 20 columnas.

Leer más

Errores comunes al hacer pruebas de software de nuestro código

7 comentarios

Test de software

Los desarrolladores cada vez estamos más concienciados de la importancia de las pruebas de software. Pero no podemos pasar por alto la calidad de estas pruebas, ya que podemos caer en errores no contemplados sin darnos cuenta. No es suficiente con hacer un par de tests y pensar que todo está todo correcto porque nuestra aplicación pasa esos tests, es importante pararse a pensar si cómo hemos planteado las pruebas es la forma correcta para detectar errores reales del código.

No soy un experto en realizar tests, pero como muchos desarrolladores estoy comenzando con TDD por eso quiero compartir con vosotros algunos errores comunes a la hora de hacer tests que extraído de un interesante post en Dzone sobre testing. Es un breve repaso en cada ámbito que podéis completar en los comentarios. Hablaremos sobre pruebas unitarias, mocks, test de integración, test funcionales y BDD.

Leer más

Antipatrones Agiles, ¿quien no se siente identificado con alguno?

4 comentarios

El Grito del Scrum Master

En el grupo de yahoo[foro-agiles], Daniel Ceillan publicó hace una pocas horas un interesante listado de anti patrones de metodologías ágiles.

Es curioso que me siento identificado con la práctica totálidad de los mismos y que, al igual que al resto del grupo, me ha puesto una gran sonrisa en la cara.

Me daré por satisfecho si le alegro la mañana a algún compañero.

Leer más

¿Nos equivocamos al usar DateTime.Now?

10 comentarios

UTC vs hora local
Antes de nada, os aviso de que no voy a denostar por completo el uso de DateTime.Now, ni de las estructuras similares que existen en cada lenguaje. Obviamente, cada vez que tengamos que mostrar a los usuarios un dato horario, lo ideal es dárselo en su formato local, aquél que conocen y saben interpretar de forma inmediata sin necesidad de realizar cálculos mentales.

Sin embargo, todas las operaciones internas en las que intervenga una hora deberían hacerse con horas en Tiempo Universal Coordinado, más conocido como UTC. Aunque a algunos pueda parecerles un capricho o un formalismo innecesario, son varias las situaciones en que agradeceremos usar UTC, y no solamente por su invariabilidad, sino también por su eficiencia.

Leer más

Pon un tablero Kanban en tus desarrollos

6 comentarios

LeanKitKanban portada

Uno de los mayores males que azota la productividad de las empresas de desarrollo de software es la metodología de desarrollo ASM: A Salto de Mata. Es decir “Aquí lo pillo y aquí lo mato“ o dicho de otra forma, la inexistencia de un método de producción ordenado.

Además, la nula visibilidad del flujo de trabajo produce efectos muy perniciosos como son la simultaneidad de los proyectos por encima de la capacidad de los desarrolladores o la existencia de la figura del “Hero” en contrapunto al equipo y el conocimiento compartido.

El Kanban (del japonés: kanban, donde kan significa “visual,” y ban significa “tarjeta“ o “tablero“) es, en la versión nacida y evolucionada en Toyota, una completa y compleja metodología de señalización. Pero en este artículo me refiero a la simple herramienta visual compuesta por el tablero y las tarjetas que soporta.

Es el primer paso que deben completar los desarrolladores para iniciar el camino de convertirse en un equipo Agile de desarrollo.

Leer más

Anunciate aquí

WSL Weblogs SL