“Crear” una aplicación es bastante vago. Sin embargo, la respuesta es no, no es simple. Hay un montón de cosas que debes hacer y nunca termina. Tiene dos opciones, seguir el ciclo de desarrollo ágil estándar de la industria (mi empresa hace esto) o tratar de externalizar por su cuenta (supongo que sin conocimientos de codificación). En la última opción, no olvide que necesitará desarrollo una y otra vez a lo largo de la vida de la aplicación.
¿Qué tipo de código necesitas?
Se necesita más de solo 1 codificador. Necesita personas que sean más artistas (pero que sigan haciendo código) o desarrolladores de Experiencia de usuario (UX). Luego, están los desarrolladores de backend que escriben código en varios idiomas (al mismo tiempo ocasionalmente), en el desarrollo de aplicaciones los dos lenguajes “nativos” son Java para Android y Objective-C / Swift para Apple. Por eso es imposible responder a esta pregunta realmente. También hay otros codificadores, pero creo que entiendes, se necesita un pueblo.
- ¿Qué determina el "orden de capas" de las vistas en iOS?
- ¿Es una mala idea tener diferentes archivos .xib para cada dispositivo?
- ¿Por qué el código Swift se compila tan lentamente?
- ¿Cuál es la mejor manera de comenzar con la programación de juegos iOS?
- ¿Cuál es la diferencia entre Xcode BETA8 y Xcode7?
¿Por qué necesitas actualizar continuamente?
Google, Apple, sus usuarios, usted y todo lo demás son cosas en las que se basa su aplicación. Cualquiera de estos o una combinación de ellos puede hacer que su aplicación deje de funcionar y perderá usuarios. Solo toma Oculus como ejemplo. Agregaron una función y los perdió millones de usuarios (más aquí). Los equipos con codificadores (como Oculus) trabajan en un flujo de desarrollo ágil que les permitió reaccionar muy rápidamente y solucionarlo, pero aún así perdieron muchos usuarios (como yo). Hay muchas historias sobre este tipo de cosas. No puede salirse con la suya “simplemente creando una aplicación”, eso es un mito.
¿Qué es el desarrollo ágil?
El desarrollo ágil toma lo que necesita para desarrollar (aplicación o cualquier software) e instituye un montón de ceremonias, roles y velocidad en su empresa. Todo esto se hace a través de “sprints” de desarrollo que el propietario de un Producto dicta a través de una lista de compromisos atrasados que se discute con todo el equipo a menudo (se REQUIERE la entrada de desarrollo), todo mientras se enfoca al usuario y se giran todas las nuevas iteraciones a su alrededor. CENTRADO EN EL USUARIO
Definiciones informales
- Dueño del producto
Usaré nuestro sistema para que pueda ver cómo funcionan estas cosas. Primero, tenemos el alcance bajo control al darle retroalimentación de nuestros equipos de desarrollo, ventas y ágiles. Con el código, hay muchas cosas que se pueden hacer y muchas formas de atacar el problema. Como propietario del producto, es su responsabilidad decir sí o no a las funciones para cualquier iteración dada.
- Lista de compromisos pendientes
Este es el elemento vital en tus planes. Lo que debe hacer es tomar un montón de historias de usuarios para obtener las características y piezas del desarrollo que desea. Una vez que obtiene esa lista reducida a una porción manejable, el desarrollo le permite saber cuánto tiempo tomará y cuánto costará desarrollar esa iteración. A partir de ahí, puede decir “sí” o “no”, en cuyo caso avanzamos con el desarrollo real o tratamos de refinar aún más el alcance para generar un costo / tiempo de desarrollo. abajo.
El objetivo es tener sprints que duren de 1 a 2 semanas para cuando empiece a rodar (después del MVP).
- Historias de usuarios
Las historias de usuario son lo que escribe para “ponerse en el lugar de sus usuarios”. Estos se utilizan para ayudar a conectar más profundamente lo que necesita desarrollado con POR QUÉ lo necesita desarrollado. Esto es importante para que su equipo de desarrollo lo sepa mientras lo ayudan a refinar el alcance y considerar qué piezas estarán en el próximo sprint.
Los usuarios son su foco # 1 (seguido de cerca por cómo va a ganar dinero con él). Si tiene usuarios, probablemente encontrará una manera de monetizarlos. Sin embargo, es inteligente tener un plan para hacer que sus usuarios sean tan felices y dependientes de su aplicación que le pagarán (y le pagarán) por la experiencia.
Por lo tanto, debe tener excelentes historias de usuario que sean exactamente lo que quieren. Si se balancea y falla, vuelve al tablero de dibujo y soluciona el problema. No tenga miedo de fallar, eso sucede todo el tiempo con estas cosas, tenga miedo de NO APRENDER de esas fallas y todo esto comienza con lo bueno que es ponerse en su lugar (en mi opinión).
- Sprints
Estas son rondas de desarrollo rápido. Finalmente, el objetivo es de 1 a 2 semanas, como se indicó anteriormente. Sin embargo, antes de eso, tu MVP necesitará construirse (más aquí) y eso llevará algún tiempo. Con expertos en desarrollo a la mano, será mucho más fácil saber cuánto tiempo tomará y, a través de una planificación detallada, su presupuesto definitivamente puede tenerse en cuenta. ¡Tenga en cuenta que los codificadores en Estados Unidos, Canadá y el Reino Unido cuestan entre $ 100 y $ 200 por hora! Puede ser caro rápidamente.
Mantener pequeñas iteraciones en el futuro (después de MVP) ayudará a reducir en gran medida la cantidad de inversión en ingeniería que realiza en una pieza determinada.
Recientemente encontré este video (no de nuestro equipo) que explica esto con más profundidad y muy bien.
¿Existen alternativas al desarrollo ágil?
Sí, el desarrollo en cascada es lo que usarías si subcontratas tu desarrollo. Es entonces cuando le dice al equipo lo que necesita, lo desarrolla, lo implementa a los usuarios, encuentra otro equipo para solucionar los problemas que han surgido y repite. Este proceso es necesariamente más largo y por qué las aplicaciones tercerizadas están atrasadas y probablemente ni siquiera pueden gastar lo suficiente para mantener el ritmo.
Vamos a pensarlo. Para encontrar un equipo lleva un mes más o menos, luego el equipo desarrolla lo que desea en los próximos dos meses, luego lo implementa a los usuarios (MVP). ¡Excelente! Ahora, sus usuarios comienzan a quejarse o desean nuevas características mejores para mantenerlos en su aplicación, comprometidos, con mayor frecuencia y por períodos más largos de tiempo. NECESITAS esto, así que encuentras otra empresa para desarrollarlo (o ir a lo mismo). Le cobrarán por un proyecto completamente nuevo y su desarrollo (nuevamente) tomará uno o dos meses (suponiendo que pueda analizar las cosas correctamente como no codificador, lo cual es MUY difícil).
En pocas palabras, ágil es mejor y es por eso que los equipos con codificadores siempre vencerán a los equipos que subcontratan, en mi opinión. También puede tener uno por $ 495 / m con nuestra membresía.
Tenemos una publicación en nuestro sitio web que compara esto con un mecánico de automóviles que puede leer aquí
Como puede ver, es una historia interminable y el costo puede escaparse sin conocimiento del código y de cómo desarrollar una aplicación. Ni siquiera me he metido en los diferentes lanzamientos que tendrá que hacer (su MVP va a un grupo de prueba muy pequeño de familia y amigos idealmente, por ejemplo). La prueba también es vital porque no existe una aplicación completamente libre de errores (en todos los dispositivos). Incluso el mejor congelador, bloqueo o exuda repelente para el usuario. Podría continuar, pero me detendré por ahora.
Si eres amigo de un programador, habla con ellos para que te ayuden a buscar personas que trabajen en tu proyecto. Si no lo hace, venga a tomar nuestra prueba de 5 días y podemos ayudarlo a refinar su alcance y mostrarle cómo funcionaría el sistema para usted.
