Todas las startups tienen algún riesgo y más si tienes una idea pero no un cofundador técnico. Atlas es un Empresa de desarrollo de software a la medida quien ha actuado como el cofundador técnico faltante para nuevas empresas en el pasado, y aquí están nuestras ideas sobre cómo reducir el riesgo de proyectos de software al acercarse a una empresa de desarrollo de software para convertirse en su cofundador técnico.
Atlas ha estado en el negocio por más de 10 años y en ese tiempo hemos encontrado lo que funciona y lo que no para reducir el riesgo de fallas en los proyectos de software. Nosotros personalmente estamos a favor de la metodología ágil para desarrollo de software personalizado y explicaremos por qué, pero es importante comprender que, en algunos casos, un enfoque ágil para el desarrollo de software puede revelar problemas en la gestión de proyectos, pero no resolverlos.
Antes de sumergirnos en la defensa del desarrollo de software ágil, veamos primero el método tradicional de desarrollo de software que a menudo solicitan la mayoría de los clientes de Atlas: el modelo en cascada.
El modelo de cascada es un proceso de diseño secuencial (no iterativo) que se utiliza en los procesos de desarrollo de software en los que se considera que el progreso fluye constantemente hacia abajo (como una cascada) a través de las etapas de concepción, iniciación, análisis, diseño, construcción, prueba, producción/ implementación y mantenimiento. Se originó en las industrias de fabricación y construcción: entornos físicos altamente estructurados donde los cambios posteriores son prohibitivos, si no imposibles. Debido a que se creó en un momento en que no existían metodologías formales de desarrollo de software, este modelo centrado en el hardware se adaptó fácilmente para el desarrollo de software.
Wikipedia
El modelo de cascada, a pesar de todas sus deficiencias, se ha utilizado con éxito en una serie de industrias, incluidas las militares, el desarrollo espacial y la atención médica. Estas industrias son entornos regulados y estrictamente controlados donde las decisiones las toman expertos y la vida de las personas depende de que las decisiones sean correctas la primera vez. no hay lugar para
Ups, eso no funcionó. Esconde los cuerpos e intentemos de otra manera.
foto de Peter Kemp/Paul Smith
Esta figura proporciona una representación visual del modelo de cascada. Inmediatamente se dará cuenta de que una vez que comienza el proceso de desarrollo de software, es imposible volver al principio y aquí radica el último problema de la cascada.
Muchos de los proyectos de desarrollo de aplicaciones que se llevarán a cabo este año y el próximo serán iniciados y financiados por personas que no entienden las complejidades de escribir software y que no conocen todas sus necesidades de software de antemano.
No importa cuantas técnicas de recopilación de requisitos de software En Atlas tratamos de extraer los requisitos de software completos de nuestros clientes, si el propietario del producto no sabe lo que no sabe, no puede proporcionar la información correcta. No es culpa de ellos, es solo un hecho desafortunadamente.
Ahora imaginemos por un momento que el equipo de desarrollo de software ignora los problemas anteriores porque el cliente les está mostrando un puño lleno de dólares. Reuniendo lo mejor que pueden los requisitos de software incompletos, se lanzan por la cascada (modelo) como un dispositivo de natación con una especificación funcional del tamaño de toda la Enciclopedia Británica.
El cliente se para en la cascada (modelo) y mira y está emocionado. Está seguro de que entre él y el equipo de desarrollo de software cumplieron con todos los requisitos y luego BOOM, llegan al fondo de la cascada (modelo) y comienzan a ahogarse. Resultó que la especificación funcional tenía agujeros, y no ayudaría remar o sacar agua. Además, el cliente ha visto una vista previa de la aplicación y desea realizar una serie de cambios de última hora.
Bajo la presión de un plazo ajustado y también de un presupuesto ajustado, el equipo de desarrollo de software ahora debe remar y saltar más fuerte para cumplir con el plazo. Producen una aplicación subóptima que cumple exactamente con las especificaciones del cliente, pero podría haber sido mucho mejor si solo se hubiera adoptado un enfoque más iterativo.
foto de Sistemas informáticos atlas ltd
Eso nos lleva a metodología ágil como se muestra en la figura. ¿Crees que la agilidad es el camino a seguir? Bueno, Agile es igual de peligroso si no se hace correctamente, y ciertamente no es una solución para todos los problemas descritos aquí. Para ser verdaderamente ágil, aún se requiere un plan general y los planes para cada iteración aún deben establecerse antes de que comience el desarrollo del software.
Una metodología de desarrollo ágil garantiza que el desarrollo de software se realice en colaboración y que el riesgo se comparta de manera más equitativa entre ambas partes. En otras palabras, el equipo de desarrollo de software todavía puede tirarse río abajo, pero en este caso el cliente está en el bote ayudando a remar y recoger agua. Se trata de colaboración.
Atlas hizo la transición de la mayoría de nuestros proyectos de la metodología en cascada a la ágil en 2011, y tenemos la intención de asegurarnos de que solo usamos la metodología ágil en el futuro cuando sea posible. Estos son nuestros principales consejos y trucos que hemos utilizado para garantizar que todos nuestros proyectos de software, independientemente del tamaño y el riesgo, tengan las mejores posibilidades de entregarse a tiempo y dentro del presupuesto:
- Cuando se nos acerca un cliente que quiere crear una aplicación web y esta es su primera aplicación web o ingresa a una nueva industria, lo alentamos encarecidamente a crear un MVP (Producto mínimo viable) Primero. Tratar de crear una aplicación con todo tipo de campanas y silbatos es innecesariamente costoso y, por lo general, un desastre.
- De vez en cuando recomendamos crear una prueba de concepto. Esto es particularmente útil cuando una o más áreas del requisito general de la aplicación están en alto riesgo debido a la complejidad técnica o la dependencia de un sistema de terceros.
- Continúe desde el punto 2; Cuando creamos una prueba de concepto, se la mostramos a tantas personas como sea posible antes de continuar. Si es una solicitud interna, muéstrasela a tus empleados. Si planea vender la aplicación, muéstrela a tantos clientes potenciales como sea posible antes de continuar. Sí, toma tiempo, sí, toma mucho esfuerzo, pero es menos costoso reconocer desde el principio que estás en el camino equivocado.
- Si una prueba de concepto es exagerada, siempre recomendamos crear al menos wireframes (vinagre balsámico es nuestra herramienta de elección a menos que un prototipo HTML tenga más sentido). Incluso los wireframes más simples capturarán la imaginación del propietario de un producto y lo harán pensar en detalles que pueden haber pasado por alto anteriormente. Dado que una imagen vale más que mil palabras, nos aseguramos de que los wireframes sean parte de nuestros planes de iteración, ya que son difíciles de malinterpretar y, por lo tanto, pueden minimizar la ambigüedad.
- Utilizamos un portal de clientes para promover la transparencia. En particular, nos aseguramos de que los clientes puedan realizar un seguimiento de lo que estamos trabajando en la iteración actual. Agregamos problemas potenciales al portal para su discusión tan pronto como los encontramos, en lugar de esperar a la próxima reunión.
- Hablando de reuniones, insistimos en que las partes interesadas clave del producto asistan a todas las reuniones de fin de sprint para proporcionar comentarios. Somos tan firmes en este punto que incluimos este requisito en nuestro contrato de desarrollo de software ágil.
- Nunca nos atascamos en desagradables negociaciones de contratos. El desarrollo de software es un esfuerzo de colaboración con riesgo compartido y nuestro acuerdo de desarrollo de software refleja este enfoque. En lugar de discutir los contratos en detalle, preferimos centrarnos en desarrollar la aplicación de nuestros clientes.
Con o sin Agility, los consejos y trucos anteriores nos han ahorrado miles de horas de tiempo de desarrollo de software desperdiciado. Esperamos que puedan hacer lo mismo por usted.
