Escucha a tus clientes
Viernes, Julio 16th, 2010
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.
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.
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?
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.
El tema de la codificación de los estándares es algo muy recurrente entre desarrolladores de software, cuyas opiniones divergentes plantean cuestiones que van desde por qué necesitamos estas restricciones a cómo podríamos trabajar sin ellas.
¿Has oído alguna de estas frases últimamente?
