David’s Kindle Notes & Highlights for Historias de developers

los teléfonos inteligentes han revolucionado todos los aspectos de nuestras vidas y de nuestra forma de trabajar, desde cómo hacemos una reserva de hotel o de un vuelo a cómo pedimos un taxi desde un smartphone viendo en tiempo real en un mapa dónde está y cuándo va a llegar a donde estamos.

2%

Y debajo de toda esta revolución está el software. Y las empresas que sobrevivan y se reinventen para triunfar en este mundo digital al que nos estamos dirigiendo serán las empresas que entiendan y dominen el software.

2%

"apalancamiento".

2%

los subcontratados eran "más baratos", pues las propias finanzas de la empresa te forzaban a tener cierto nivel de apalancamiento en tu presupuesto anual para poder llevar a cabo los proyectos sin salirte del mismo.

2%

había 6 desarrolladores subcontratados por cada empleado propio.

2%

Durante estos años, hemos ido contratando más desarrolladores de software y formando a los que ya teníamos, cambiando la metodología para abandonar el CMMI2 y pasarnos a metodologías ágiles (Scrum en concreto) así como reforzar las otras disciplinas complementarias e igualmente necesarias para llevar a cabo el desarrollo de software con éxito como el grupo de experiencia de usuario, el departamento de QA,

2%

reconocimiento a los perfiles técnicos y de desarrollo que no querían convertirse en gestores.

2%

uso de APIs en REST a otros más culturales como el evitar la sobreingeniería o mejorar la comunicación, pasando por temas de rabiosa actualidad empresarial como la historia de Android, las nuevas tecnologías de bases de datos no relacionales o el trabajo que estamos desarrollando conjuntamente con Mozilla sobre Firefox OS.

2%

La sobreingeniería es la consecuencia de desarrollar intentando dar solución a funcionalidades futuras.

3%

los requisitos de un proyecto suelen cambiar y esa es una realidad que hemos de asumir desde el inicio del desarrollo. Los cambios realizados durante la fase de desarrollo implican modificar, adaptar o incluso desechar partes del código implementado.

3%

solemos implementar funcionalidad extra porque creemos que nos será útil más adelante.

3%

resultado final es la acumulación de fragmentos de código que nunca van a ser usados.

3%

nefasto a nivel individual y mucho más a nivel de equipo.

3%

consecuencias

3%

Mayor coste de tiempo (en su implementación) y en consecuencia, de presupuesto

3%

Aumento de la complejidad del código haciéndolo menos legible y menos mantenible

3%

Aumento del riesgo a tener nuevos bugs ya que hay funcionalidad que nunca se prueba

Dependiendo de si usamos TDD o no

3%

principios y buenas prácticas que nos ayudarán a desarrollar un código más “a prueba de cambios”.

3%

El método MoSCoW (Must, Should, Could, Won’t) Se aplica antes de iniciar la fase de desarrollo y sirve para priorizar los requisitos de las entregas en 4 niveles: Mínimos para considerar la entrega completada (Must) Importantes pero negociables (Should) Deseables pero no prioritarios (Could) Descartados para esta entrega (Won’t)

3%

La filosofía RERO (Release Early, Release Often)

3%

política de despliegues muy frecuentes para poder recibir feedback del usuario o cliente lo antes posible.

3%

en entornos cerrados donde el acceso está restringido a los desarrolladores, el equipo de pruebas y algunos usuarios finales,

3%

en startups, también se usa en entornos de producción

3%

La finalidad de esta metodología es no desviarnos de lo que el clie...

This highlight has been truncated due to consecutive passage length restrictions.

3%

estas técnicas se acaba traduciendo en una clara mejora en la relación desarrollo - producto que acaba resultando beneficiosa para ambas partes.

3%

principios más populares del mundo del desarrollo:

3%

Las fechas de entrega juegan en nuestra contra y su aplicación suele posponerse a la fase de refactor, una de las más importantes del ciclo de desarrollo.

3%

consejos prácticos

3%

no podemos olvidarnos del anti-patrón RSW (Reinventing the square wheel).

3%

Reutilizar código de fuentes fiables suele ahorrarnos mucho tiempo y un buen número de bugs

3%

reinventemos la rueda cuando las soluciones existentes no satisfagan nuestras necesidades o cuando queramos aprender más sobre ruedas.

4%

Cualquier ingeniería otorga

4%

conocimientos y capacidades para resolver problemas, además de ofrecer las herramientas básicas para que se ejecute la implementación de un proceso creativo.

4%

el desarrollo de software es algo muy creativo y debemos co...

This highlight has been truncated due to consecutive passage length restrictions.

4%

Puede haber muchas ideas, productos, servicios, programas o aplicaciones nuevas pero pocas de ellas pueden ser innovadores.

4%

sino en la ejecución, implementación y desarrollo de algo ya conocido o implementado por otro. En este último caso se puede ofrecer un valor añadido difícil de superar en el mercado aplicando la excelencia en la implementación en algún aspecto realmente diferencial.

4%

un valor añadido que es clave: la experiencia de usuario.

4%

la innovación proviene de enlazar creaciones e ideas existentes que aportan un valor y aplicación nuevos al encontrarse juntas.

4%

no es cuestión de encontrar “la idea feliz” sino más bien de tener un conocimiento previo de otros productos o servicios novedosos que existan en el mercado y que juntándolos creen algo nuevo y revolucionario.

4%

las elecciones en el diseño pueden tener consecuencias de peso en nuestros productos.

4%

tomar conciencia de la deuda técnica en la que se suele incurrir al diseñar y no implementar ciertas características técnicas necesarias

4%

un error muy común por querer construir algo novedoso a nivel técnico es el adoptar para todo las tecnologías que están en boga en un momento determinado.