Publica tu how-to

Dinos como hacer lo que sabes hacer, mándanos un email a wdonet@gmail.com y lo publicamos (dos días máximo) o si te interesa unirte al equipo de redactores, también háznoslo saber por correo.

Mostrando entradas con la etiqueta planning. Mostrar todas las entradas
Mostrando entradas con la etiqueta planning. Mostrar todas las entradas

Mejores prácticas en JBPM

Me tope con un articulo sobre las mejores prácticas al usar JBPM y pues quise hacer una pequeña traducción al español, espero que nos sirva como referencia.
  1. Mantén ordenado tu contexto de ejecución. No mezcles variables de proceso con variables del modelo y mantenlo simple.
  2. Usa ExceptionHandler solo para asignar valores a variables o notificar errores. El manejo de excepciones en JBPM es distinto a java, pueden ser (A) cachadas por jbpm o (B) no cachadas y ser re-lanzadas al cliente que hizo un signal(). Así que no puedes usar exception-handler por ejemplo para controlar el flujo, es mas agradable cachar excepciones de la aplicacion en un Action y que éste, de acuerdo al error, asigne valores a una variable de contexto que permita al flujo (un Decision) tener el control de que procede.

XP Xtreme Programming: reglas

Reglas del XP

Planning

  1. User stories are written (o Casos de Uso).
  2. Release planning creates the schedule.
  3. Make frequent small releases.
  4. The Project Velocity is measured.
  5. The project is divided into iterations.
  6. Iteration planning starts each iteration.
  7. Move people around.
  8. A stand-up meeting starts each day.
  9. Fix XP when it breaks.

Designing

  1. Simplicity (mantener las cosas simples siempre ayuda!!!).
  2. Choose a system metaphor.
  3. Use CRC cards for design sessions.
  4. Create spike solutions to reduce risk.
  5. No functionality is added early.
  6. Refactor whenever and wherever possible (muy importante!!).

Coding

  1. The customer is always available.
  2. Code must be written to agreed standards.
  3. Code the unit test first (<- TDD).
  4. All production code is pair programmed.
  5. Only one pair integrates code at a time.
  6. Integrate often.
  7. Use collective code ownership.
  8. Leave optimization till last.
  9. No overtime.

Testing (http://www.agiledata.org/essays/tdd.html)

  1. All code must have unit tests.
  2. All code must pass all unit tests before it can be released.
  3. When a bug is found tests are created.
  4. Acceptance tests are run often and the