El cliente se equivoca a menudo.  La habitual costumbre de solicitar feedback a los clientes e incorporara esos comentarios en los productos es una forma brillante de producir prototipos. Los prototipos son, por supuesto,  esqueletos mal implementados en ese espejo un producto real. Su función es minimizar de forma rápida el riesgo que surge de vagas obligaciones, cuestiones que la ciencia desconoce o de otras inceridumbres. Los prototipos son inestimables cuando son necesarios, pero no son necesarios para cada producto. Al menos, no la mayoría.

Por ello, los equipos de ingenieros necesitan protección ante los clientes a la hora de desarrollar el producto real.
Pulsa aquí para leer el artículo completo en EE Times.

Una buena idea es un activo muy valioso, y un montón de buenas ideas pueden ser como un tesoro. Pero, ¿qué hacer con esas ideas? Muchas ideas se marchitan, no porque sean malas ideas, sino debido a una torpe presentación. La mayoría de las nuevas ideas que se nos ocurren tienen una mayor posibilidad de éxito si recordamos estas cuatro cosas:

1.    No se trata de ti
La mayoría de las veces, la gente persigue una idea nueva porque ven cómo les puede beneficiar. No te limites a decir por qué crees que tu idea es buena; tienes que ver el mundo desde otro punto de vista y tu idea, desde la perspectiva de la empresa. Si tu jefe se preocupa solo por el coste, hablar de calidad, velocidad, reutilización o elegancia no le van a convencer. Conecta tu idea con el punto de vista de aquellos que tienen que apoyarte
2.     Se trata de a quién conoces.
Llevar a buen término tus ideas es un proceso social. Necesitarás la ayuda y el interés de los demás para hacer tu idea realidad.

Pulsa aquí para seguir leyendo este artículo en Sticky Minds.

En las mejores estimaciones, el esfuerzo de desarrollo de software detrás del diseño de chips de 90 nm, ya ha superado el esfuerzo de desarrollo de hardware. El pronóstico para 2011 es que menos del 40 por ciento del costo global de desarrollo de chips se gastará en el hardware. Ahora mismo, el software ahora domina los ciclos del proyecto y establece cuándo un chip puede entrar en producción. Como resultado, se ha incrementado la importancia de la verificación de software, y a su vez, el software ha asumido un papel fundamental en el proceso de verificación de hardware.

Pulsa aquí para leer el artículo completo en Embedded Computing Design.

Pregunta a un ingeniero qué esta haciendo y habrá altas posibilidades de que su respuesta sea: “Estoy depurando errores”. Día sí y día no, proyecto tras proyecto, los ingenieros depuran errores; es parte de ser ingeniero. A veces, es sencillo y rápido, pero en ocasiones es duro, nada obvio, lleva tiempo y es impredecible. Todo el mundo sabe que la depuración da pavor, pero es necesaria como parte de los procesos de diseño y verificación. Una tendencia alarmante a la vez que innecesaria es el tiempo cada vez mayor que la depuración consume en el ciclo de diseño. A rasgos generales, la razón de esta tendencia es que las prácticas de depuración tradicionales no son apropiadas para los problemas de hoy en día.

Pulsa aquí para seguir leyendo este artículo en Embedded.com

Los resultados de encuestas realizadas en  2009 y 2010 muestran que los ingenieros de sistemas embebidos reconocen los prototipos como una metodología eficaz para acelerar la depuración de errores en sistemas embebidos, independientemente del tipo de sistema o su velocidad máxima.

En la búsqueda constante para reducir el tiempo de lanzamiento al mercado, reducir el tiempo dedicado a una tarea importante como la depuración es, sin duda, de gran valor. La creación de prototipos nos ayuda a acortar el tiempo de diseño global y, a su vez, aumenta la productividad del ingeniero.

Los innovadores, flexibles y potentes generadores de prototipos son uno de los elementos clave para acelerar la depuración de los sistemas embebidos. La innovación en la instrumentación puede llevar a los diseñadores a incrementar su productividad al ayudarle a diseñar mejor y más rápido.

Lee el artículo completo en Embedded0 Computing Desing. 

A algunos equipos de testing les puede confundir cómo hacer la transición a ágil. Si formas parte de un equipo, probablemente tengáis pruebas manuales para la regresión, bien porque nunca habéis tenido tiempo para automatizarlas o bien porque habéis estado testeando desde la interfaz gráfica y no tiene sentido automatizarlas. En tu equipo habrá estupendos testers que puedan encontrar problemas en aplicaciones complejas pero que, sin embargo, no tienden a automatizar sus pruebas y necesitan un producto final antes de empezar a testearlo. Entonces, ¿cómo se puede equiparar el ritmo de trabajo de los testers al de los desarrolladores?

Este es un problema bastante común. En muchas empresas y organizaciones, los desarrolladores creen que han evolucionado a ágil mientras que los testers siguen atascados en pruebas manuales y no pueden mantener el ritmo. El problema no es que los testers sean demasiado lentos, sino que el equipo debe trabajar de forma paralela y, hasta que no lo consiga, los testers parecerán demasiado lentos.

Pulsa aquí para leer el artículo completo en Sticky Minds.

Los métodos ágiles se describen habitualmente como métodos de desarrollo de software. La mayoría de la documentación, como el Manifiesto Ágil, describe cómo se organizan los equipos ágiles y cómo deben trabajar, pero no describen el resto de aspectos que tienen lugar fuera del equipo de desarrollo.

Cuando los equipos empiezan a usar nuevos métodos, actúan de forma radicalmente diferente, especialmente en una empresa en la que, en otras circunstancias, no se cambiaría la forma de trabajar. Es imposible, entonces, que no surja ningún conflicto. Cuando te encuentres  con  normas ya existentes que se ponen en el camino del desarrollo de equipos ágiles, tendrás que elegir entre ignorar la norma, seguir la norma o intentar cambiarla.

Pulsa aquí para leer el artículo completo en Sticky Minds.

Las pruebas unitarias surgen tan pronto como el desarrollo de software en si mismo. Tiene sentido coger cada bloque de desarrollo de aplicaciones, desarrollarlo de forma aislada y ejecutarlo para asegurarse de que hace exactamente lo que debe sin interferir con el resto de la aplicación.

Hace unos años, el problema radicaba en no poder separar cada bloque de desarrollo de su entorno, compilarlo y ejecutarlo de forma unitaria. Para solucionarlo, es necesario un programa que ejecute las pruebas unitarias y que facilite una inicialización de secuencias para preparar las estructuras de datos para las pruebas unitarias que se van a realizar.

Pulsa aquí para leer el artículo completo en Embedded.com

¿Puede una organización grande adoptar métodos ágiles de desarrollo de software cuando la organización tiene la idea de que no todos los proyectos deben ser ágiles? En otras palabras,  ¿puede haber una mezcla de proyectos tipo cascada y proyectos ágiles en la misma organización? La respuesta corta es sí, sin embargo hay un costo que se debe pagar por esta convivencia.

La transición a software ágil suele ser paulatina en la mayoría de las empresas poco, para poder aprender de sus aciertos y errores y aplicar los nuevos conocimientos para la implantación de nuevos equipos ágiles. Este proceso puede llevar meses o años, dependiendo del tamaño de la organización y la gestión.

Haz click aquí para leer el artículo completo en Sticky Minds.

Los riesgos de requisitos se encuentran entre los riesgos más insidiosos que amenazan los proyectos de software. Tanto si se trata de requisitos que no se han definido correctamente, como de la falta de participación del cliente en las necesidades de desarrollo o incluso de requisitos defectuosos, se encuentran entre las principales razones por las que los proyectos fracasan. Un equipo de un proyecto puede marcar la diferencia mediante la adopción y aplicación de prácticas ágiles. Cuando se aplican correctamente,  las prácticas ágiles pueden mitigar los riesgos más comunes asociados con los requisitos en proyectos de desarrollo de software.

Pulsa aquí para leer el artículo completo en Sticky Minds.