Categorías
Programación

Manifiesto de producto

Product Manifesto Values

  • Solving Problems over implementing solutions
  • Outcome Orientation over defining features
  • Hypotheses Validation instead of following opinions
  • Empathizing with End-Users instead of presuming their needs

Product Manifesto Principles

  1. Generating value is the ultimate measure of success.
  2. Establishing clarity on what value means and what doesn’t is key to success.
  3. Never start evaluating solutions until you understand the problem.
  4. Set one priority at a time and say no to whatever distracts you from that.
  5. Embrace learning by finding fast ways of validating assumptions.
  6. Leadership trusts the product teams to do the right thing. Therefore, product teams are empowered to make decisions.
  7. Don’t keep useless features in the product; remove what doesn’t add value.
  8. Set a due day for backlog items, continuously adapt to what you’ve learned. Remove items when the due date is reached.
  9. Strive for alignment with stakeholders instead of trying to please them.
  10. Learn how to differentiate needs from wants.
  11. End-users feedback matters more than stakeholders’ opinions.
  12. Define what leads to success, and create ways of measuring it daily.

Agile manifesto is long gone! We need a product manifesto! — David Pereira

Una respuesta al Agile Manifesto, pero poniendo el foco en el producto. Y tiene sentido.

Categorías
Programación

Como denominar número de versiones correctamente

Dado un número de versión MAYOR.MENOR.PARCHE, se incrementa:

  1. la versión MAYOR cuando realizas un cambio incompatible en el API,
  2. la versión MENOR cuando añades funcionalidad que compatible con versiones anteriores, y
  3. la versión PARCHE cuando reparas errores compatibles con versiones anteriores.

Hay disponibles etiquetas para prelanzamiento y metadata de compilación como extensiones al formato MAYOR.MENOR.PARCHE.

Versionado Semántico 2.0.0

Toda la vida haciéndolo mal 🙂

Categorías
Programación

Principios de diseño de Python (El Zen de Python)

  1. Beautiful is better than ugly.
  2. Explicit is better than implicit.
  3. Simple is better than complex.
  4. Complex is better than complicated.
  5. Flat is better than nested.
  6. Sparse is better than dense.
  7. Readability counts.
  8. Special cases aren’t special enough to break the rules.
  9. Although practicality beats purity.
  10. Errors should never pass silently.
  11. Unless explicitly silenced.
  12. In the face of ambiguity, refuse the temptation to guess.
  13. There should be one– and preferably only one –obvious way to do it.
  14. Although that way may not be obvious at first unless you’re Dutch.
  15. Now is better than never.
  16. Although never is often better than right now.
  17. If the implementation is hard to explain, it’s a bad idea.
  18. If the implementation is easy to explain, it may be a good idea.
  19. Namespaces are one honking great idea — let’s do more of those!

PEP 20 — The Zen of Python —Tim Peters

Nota sobre el punto 14 (Although that way may not be obvious at first unless you’re Dutch): Guido van Rossum, creador del lenguaje de programación Python, era holandés.

Observación: el punto 20 de este Zen of Phyton nunca se llegó a escribir.