Transcripciones
1. Introducción: Hola allá y bienvenidos. Aquí te dejamos un
resumen muy rápido de este curso. Este es un curso que no te
enseñará cómo hacer ninguna codificación. A no te enseñará a
diseñar una interfaz de usuario brillante. No te
demostrará cómo publicitar y lanzar una aplicación para hacerse
viral a través de Internet. Ahora en su lugar, este
curso le
proporciona una visión general integral
del ciclo de vida de desarrollo de software ágil que
puede aplicar a cualquier producto
digital que tenga previsto desarrollar. Y explica qué integrantes del
equipo y
conjuntos de habilidades necesitas apuntar
contigo para tener éxito. Mi nombre es Alex. Tengo mi sede en Londres, Reino Unido y en
los últimos dos años he estado trabajando como elite senior y gerente de
proyectos en grandes proyectos de
transformación digital, típicamente para bancos, consumidores, al por menor, y clientes de atención médica. Al final de este curso, conocerás la
diferencia entre el desarrollo de
software
Agile y Waterfall. Entiendes los roles y
responsabilidades clave de los miembros del equipo y de un equipo de desarrollo ágil, incluyendo el tuyo propio en la
forma como gerente de proyecto. Y podrás
explicar cada fase del ciclo de vida de desarrollo
de software Agile, que incluye la fase de
ideación, elaboración de requisitos, diseño y la construcción de
tu software y mostrando que está probado
de forma regular y eventualmente llegando a
lanzarlo al mercado. El curso está muy
dirigido a principiante, ponlo partidos interesados
en el desarrollo de software. Es posible que ya seas
desarrollador junior o diseñador queriendo cambiar a un puesto de gestión de
proyectos. O tal vez eres un innovador con una gran idea para una herramienta digital. Pero estás bastante inseguro por dónde
empezar o qué
conjunto de habilidades se requiere, en cuyo caso este
curso es para ti. Si suena
interesante, entonces vamos empezar y meternos en ello.
2. Desarrollo de acuarela: Por lo que el enfoque dentro del mundo del desarrollo de
software, tienden a ser dos ideas clave para enfoques clave para el desarrollo de
software. Uno es el enfoque de cascada y el otro
es el Agile. Cascada es una metodología
secuencial donde tarea un
poco más lineal. En tanto que en contraste, ágil es una
metodología muy iterativa, que incluye un proceso cíclico
y colaborativo. Es un debate muy acalorado
qué es mejor y qué es mejor. En mi opinión personal, dependerá mucho la preferencia
por tu proyecto,
tu conjunto de habilidades y la
naturaleza del proyecto. Y si necesitas
un proceso iterativo o tal vez uno secuencial. No obstante,
ciertamente hay un sesgo, diría que 20 como desarrollo
ágil en el desarrollo de
software. Y como resultado, hoy nos
centraremos en eso. No obstante, vamos a
sumergirnos en cascada vey rápidamente sólo para que tengas
un entendimiento también. El modelo de cascada es definitivamente el
más antiguo y sencillo. Básicamente terminamos una fase y luego iniciamos la siguiente página. Es muy fácil, muy
sencillo. Entonces como resultado o como
ejemplo en esta diapositiva, es posible que quieras hacer
todo el análisis del proyecto primero y después, y solo entonces inicias
tu desarrollo back-end. Definitivamente son algunos
beneficios que pueden ser, que se pueden argumentar
para los desarrolladores y clientes acordaron bastante temprano en lo que realmente se construirá. En un principio,
se define el análisis, se define el alcance del trabajo. Y eso hace que
la planificación sea un poco más
directa. De una manera similar progresa
bastante fácilmente medido. Tienes en mente este
ámbito de trabajo completo. Y como resultado,
se puede decir con bastante facilidad cuánto se ha construido
ya a partir de eso. En consecuencia, el software puede
diseñarse completa y
con mucho cuidado basado en la comprensión
completa de todos los
entregables de software. Pero una vez más,
eso es de la teoría. Y definitivamente
hay muchos inconvenientes que se
han visto en la práctica
real. Quizás lo más importante,
yo argumentaría es la falta de efectividad
de los requisitos. Si comienzas, cuando
inicias un nuevo proyecto, la realidad es que
no sabes nada. No sabes de
la complejidad, no
sabes
construir nada todavía. No sabes qué quiere
el cliente, cómo
va a responder el mercado. Entonces lo que sea que analices
desde el principio, tal vez no completamente significativo al final una vez
que lances el producto. Entonces, una vez más, cualquier pequeño
detalle que pueda quedar fuera, detalles que pueden estar
completamente equivocados. Entonces sostendrán todo el proceso
quiere descubierto. Y como resultado, un proyecto no sólo
se retrasa, sino que se vuelve bastante costoso. Además, una vez que lanzas algo después de mucho tiempo de
analizar, desarrollar y probar bien podría ser que el producto al final sea
completamente indeseable o tal vez
anticuado para el momento
en completamente indeseable o tal vez que lo de la vida. Por lo que la posibilidad de que un
cliente esté insatisfecho con el
producto de software entregado es definitivamente alta. Y una vez más, eso
se vuelve costoso.
3. Desarrollo ágil: Entonces cuando se trata de ágil, una lección rápida de historia aquí
es algo así como alrededor del 2000, 2001 la gente se reunió, los desarrolladores de
software se
juntaron y
compartieron mucho la frustración sobre la actual estado de cosas, cómo
se estaba abordando el desarrollo de software. Y lo
que es más importante, todos coinciden
en que la excesiva planificación
y documentación del desarrollo de software
es ineficiente. Y realmente lo que
importa es complacer a sus clientes y
eso se está perdiendo. Por lo que como resultado,
introdujeron y ocurrió el desarrollo ágil de
software. El desarrollo ágil de software
tiende o busca
romper todo el trabajo de
desarrollo en hitos más pequeños. Y construyes tu app, tu producto en una
serie de ciclos. Entonces, una vez más,
en lugar de construir todo y luego lanzarlo, solo
te enfocas en una determinada
característica que luego lanzas y luego llevas en cada ciclo como
se ve en esta diapositiva, nosotros incluyen que te similares
etapas como una cascada, haces algo de planeación, haces las pruebas de desarrollo
y revisas. Pero una vez más,
crucialmente, luego
envías, luego lanzas a los
clientes desde el principio. Y como resultado, cada lanzamiento proporciona un
campo de pruebas donde
con bastante rapidez estás destinado a obtener
retroalimentación del cliente, del mercado real. Y en base a eso, puedes
entonces iterar y cambiar tu producto a las necesidades reales del
cliente y del mercado. En realidad, la consideración clave aquí cuando se trata
de ágil es que el cliente está en el corazón
del equipo de desarrollo y el cliente trabaja muy,
muy de cerca. Colaboran, y es el cliente el que los
invitados a ver y utilizar el producto desde el principio y como resultado, pueden
proporcionar comentarios. Y en base a eso, las cosas
cambian todo el tiempo. No hay un plan lineal
que se esté siguiendo. Pero más bien después de
un lanzamiento rápido, es el cliente quien proporciona sus comentarios y el plan
se está adaptando en consecuencia. Hay algunos
principios clave que
surgieron que se nos
ocurrió como resultado. Y es decir, queremos enfocarnos en los individuos y las interacciones
sobre los procesos y herramientas. Es la gente, los clientes que en el corazón de todo, no
está procesada ni herramientas
o puede que
alguna vez hayas establecido, adaptaremos las cosas todo el
tiempo de una manera similar. Es software de trabajo, cosas
reales que está ahí fuera y
trabajando y siendo usado. Eso es
más importante que la
documentación excesivamente completa, los planes de
proyectos, etcétera. Absolutamente, es
importante anotar
las cosas para compartir conocimientos, pero
el software de trabajo es lo más importante. Como que ya lo he
insinuado. La
colaboración con el cliente es clave. La realidad de la vida es, mira, el cliente no
sabe lo que quiere. Probablemente no
lo hagan bien la primera vez y
cambiarán de opinión. Y así trabajar duro con
los clientes, pero esa es una especie de la
realidad del trabajo. No tiene absolutamente
ningún punto de tener un contrato en su lugar y
apegarse al contrato. Cuando resulta
que un cliente no está absolutamente
interesado fue escrito. ¿ Qué está escrito en ella? Sí. Por lo que todo se está adaptando a los comentarios de los clientes para
invertir lo que encuentran. En lugar de apegarse a
algo que se ha negociado hace muchos, muchos años. Y eso realmente
me lleva al último punto. Estamos solo, quieres
responder al cambio. No quieres
seguir un plan que
se ha configurado hace un tiempo,
sino más bien, respondes a lo que el cliente
ha percibido. Si te interesa más, esos principios echen un vistazo
al Manifiesto Agile que se estableció por los
desarrolladores de software en 2001. Se trata de unos fundamentos de clave para desarrollo
efectivo de software se está utilizando todo el tiempo a través de
todos los grandes proyectos. En software.
4. Ceremonias ágiles: De verdad quiero
tocar las ceremonias Ágiles, que es una
palabra muy elegante para reuniones. Simplemente tocaré
44 ceremonias clave de reuniones
clave que se están utilizando dentro, dentro del desarrollo de
software. Y qué planeación sprint,
planeación sprint. Detrás hay mucho más
detalle,
pero bastante abstracto,
bastante alto nivel, significaría que
planeas lo que
vas a construir dentro de
la próxima semana o así. Entonces todos los desarrolladores, analistas, diseñadores, etcétera, sobre todo los
clientes y
gerentes de producto se unen y deciden cuál es
la siguiente característica, cuál es lo siguiente
que nosotros quieres construir? Una mujer se compromete con eso
dentro de esa sesión de planeación. Y el objetivo es
construir algo dentro de las próximas dos
semanas y muere. Y de nuevo, seguido de liberación que
vimos que justo ahora. El siguiente es
dirigir el stand-up diario. Tendrás que ponerte de pie. Dicho eso, creo que la
mayoría de los equipos realmente lo hacen. Pero dentro del nombre es diario y es el
equipo que se reúne. Y el énfasis aquí es
mucho en la comunicación, comunicación
regular
dentro del stand-up diario. Y en realidad es solo una sesión de 15
minutos cada mañana, comunicas lo
que has hecho ayer, lo que estás planeando
hacer hoy. Y lo más importante,
si tienes algún problema de riesgo que
experimentes donde necesitas ayuda. Y así todo desarrollador,
analista, diseñador, quien sea que esté en el equipo
funcional, como parte de la reunión. Y como resultado, con bastante rapidez obtienes actualizaciones de
cada miembro del equipo y entiendes dónde está todo
el mundo y si
alguien necesita ayuda. Cuando se trata de comunicación, la comunicación
visual
es importante. Se quiere visualizar lo que en realidad
se está construyendo. Se quiere obtener
retroalimentación con bastante rapidez. Y como resultado, tienes una demo de sprint puede suceder
cada semana y pasar cada,
cada dos semanas más o menos. Pero la idea detrás de
eso es otra vez, quiere compartir luego
fue a fallar a menudo se
quiere obtener retroalimentación muy a menudo en una
cuenca que quiere iterar. Por lo que una demo de sprint puede ser cualquier cosa desde algún desarrollo
que se haya hecho, hasta un nuevo diseño, hasta algunos comentarios de los clientes
que puedan haber recibido. La idea es que a través de todas
las diversas funcionalidades, diversas funciones dentro del equipo, quiera tener una cuota
transfronteriza con los integrantes del equipo
lo que está sucediendo. Por último, hay una retrospectiva. Realmente todo lo que dice es que el equipo se reúne
después de ciertos periodos de tiempo. Tiende a ser después de un sprint
que se ha completado. El Sprint puede ser cualquier cosa
desde una especie de semana, dos semanas, cuatro semanas máximo. Pero la idea es que el equipo se junte y discuta lo que ha ido bien dentro de ese ciclo de trabajo y lo
que hay que mejorar. Una vez más, es mucho
una herramienta para la comunicación. Asegurarse de que
las personas colaboren, asegurándose de que
todos estén contentos, asegurándose de que el
equipo trabaje eficientemente. Y realmente que cualquier
uso de un riesgo puede
mitigarse en cualquier diferencial futuro.
5. Los miembros y habilidades de tu equipo: Entonces teorías, grado,
metodología es impresionante. Ninguno de ellos importa.
Si en realidad no tienes algo
que poner en práctica. Para poner algo en práctica, necesitas gente real,
necesitas un equipo. Por lo que en esta sección,
proporcionaremos una visión rápida de cómo se ve un equipo típico de
Agile. Por supuesto, no se
equivoquen como siempre. Depende del tamaño del gasto, de su complejidad y
madurez de su proyecto. Pero la idea es tener una idea de especie de los
típicos integrantes del equipo. Tan famoso mismo
software es fácil, gente está caliente y voy a estar bien. Personalmente encuentro
que eso es cierto. Por lo que invierte en tu equipo. Echemos un vistazo.
Ante todo en el mundo Ágil, ese es el Scrum
Maestro de una palabra de fantasía. Si lo desea,
puede perdonarle que diga el gerente de proyecto, gerente de
programa. Hay matices a eso, pero por el bien de una especie de panorama
de alto nivel, creo que podemos decir que tal vez
el caso un maestro de scrum es responsable de repetir
un pegamento entre todos, entre todos los partes interesadas,
la gente, desarrolladores, analistas, diseñadores declinan
al cliente y así sucesivamente. Es entonces quien gestionó
el proceso de planeación. Conducen múltiples lanzamientos, facilitan la planificación
de liberaciones. Ellos son los
responsables de la programación de todas las ceremonias Ágiles
que hemos mencionado. Dan acceso
a herramientas y personas. Y como ejemplo, cualquier cosa que salga de
una reunión diaria de standup, realmente, las acciones que son responsables de las suyas hasta encontrar al dueño adecuado. Scrum master también es reportar sobre el estado del proyecto a todas las direcciones
hacia abajo y hacia arriba. Lo llaman coordinar apoyo
de liberación. Se encargan de
las evaluaciones de riesgos. Entonces mira, como puedes ver, es un trabajo muy diverso, conjunto
diverso de responsabilidades
que es difícil de definir. Pero realmente quieren ayudar a
proteger al equipo y desbloquear cualquier problema y asegurar que se sigan los procesos Agile para ser, para ser eficientes y para ser
efectivos en tu desarrollo. Todo producto con
un propietario de producto, alguien que es responsable la visión para la visión a corto plazo así
como a largo plazo. Y así el
propietario del producto típicamente es el CEO del
producto realmente. Ellos son
responsables del mercado y el caso empresarial de cualquier
tipo de análisis competitivo. Tienden a ser expertos en
la industria, conociendo la industria y
los clientes de adentro hacia afuera. Tienen una idea
del retorno de la inversión y del beneficio neto. Están representando
a sus clientes. Por lo que a menudo más que no, es el dueño viene
con los requisitos. Alguien que priorice el trabajo y así representa
lo que el cliente, al
menos lo que piensa que quiere
el cliente. Entonces una
persona crucial, crucial dentro del equipo. A menudo los analistas de negocios se sientan muy cerca del propietario del producto. Porque como mencioné,
los requisitos
suelen estar determinados por parte
del cuerpo en eso. Pero realmente es
actual en el nombre
el analista de negocios es responsable de cualquier solución
analítica. Aumentan el valor del negocio colaborando con
el propietario del producto. Crean un
rezago de producto, que de nuevo, es una palabra elegante de decir
un conjunto de requisitos. Podrán desarrollar un caso de
negocios trabajando muy de cerca
con la parte Maja. Y luego lo importante,
anotan los requisitos. Entonces ellos, ellos, no se
detienen en el alto nivel, pero en realidad
entran al detalle, los
anotan todos y
los transmiten al resto de los equipos. A menudo, la mayoría de las veces, los requisitos
siempre deben hacerse en equipo. Pero es el negocio fuera
de esta responsabilidad el redactar realmente
en transmitido al hacer, por ejemplo, un plan de sprint. Por último, podrán apoyar
las prácticas Ágiles. Alentaron
la mejora de los servicios y por supuesto se
convierten en expertos
dentro de ciertas funciones. El diseñador UX y UI, existe una importante
diferenciación entre UX y UI. El diseñador de Ux, por ejemplo, puede estar realizando investigaciones de usuarios. Están creando persona de usuario, que es una representación
de esa investigación de usuarios. Podrán determinar la arquitectura
de
información de un producto digital. Pueden estar
dibujando flujos de usuario, o pueden estar
dibujando lo que una aplicación, qué diseño, diseño
posiblemente podría mirar,
amor Mira, aspecto. Y luego en base a
eso, crean prototipos que
se están probando. En tanto que en contraste, pero
no siempre exclusivamente, un diseñador de interfaz de usuario entonces
pone eso en un diseño de interfaz de usuario real. Yo, el diseño de alta fidelidad
se ve bien y
parece el
producto final que está siendo desarrollado por el equipo de
desarrollo. Por lo que en general,
responsable de mapeo
de trayectos, se están definiendo los flujos de extremo a extremo y diseños responsables de estar sentados junto
con los clientes. Trata de entender
lo que buscan. Y haciendo montones y
montones de pruebas y luego traduciendo eso
en un diseño real. Un desarrollador, de nuevo, en un nombre, desarrolla ciertas,
ciertas características, pero creo que es importante, hay
responsabilidades adicionales. Eso a menudo se pasa por alto. Los desarrolladores son cruciales para
estimar el tamaño de cualquier nuevo requisito en cualquier evaluación de la viabilidad
técnica. Ayudaron a entender
qué se puede hacer, en qué marco temporal, qué tan
complejo y puede ser, qué puede requerirse, y así sucesivamente. Por lo que ovalan junto
con un equipo, ayudan a implementar los artículos
atrasados. Ellos, aseguran que se está
haciendo
pruebas para que todo lo se está haciendo se está
diseñando y definiendo. Además del desarrollo
real, también
aseguran el control
de calidad. No sólo se está desarrollando, sino que también se está
probando a fondo antes, antes de que entre en la etapa de
envío al mercado. Y mencioné las pruebas, mencioné antes de
que estén las pruebas a menudo también
se pasa por alto. Es absolutamente crucial que
pruebes tu aplicación, que pruebes tus nuevos futuros antes de que se esté
enviando al mercado. Y así los probadores de QA calidad
aseguran el aseguramiento. Se encargan
de redactar planes de prueba, que impusieron la
aceptación general de nuevas características. Lo hicieron como mentalmente. Y también automatizan
ese enfoque general. Desarrolladores y probadores trabajan muy estrechamente juntos e integran
continuamente código con estas
construcciones
manuales y automatizadas que las pruebas funcionales y las
pruebas de regresión y así sucesivamente. Y
entraremos en los detalles de las pruebas más adelante sólo porque
creo que es tan importante. Pero una vez más, prueba ya que
miden la calidad que la
encuentran en primer lugar
para mejorar la calidad. Y hicieron cumplir un tema de
calidad como y las mejores prácticas con eso se están llevando a
cabo todo el tiempo. Ahora, no se equivoquen. Estos son sólo algunos ejemplos. Los equipos son pequeños y
grandes dependiendo la madurez y complejidad
y tamaño de tu proyecto, necesitarás una solución
arquitectos para definir el panorama
tecnológico general. Es necesario tener
ciertos entornos disponibles donde pueda probar,
escribir, codificar y luego desplegar
eventualmente. Quieres asegurarte de
que los lanzamientos se estén haciendo de manera automatizada. Probablemente quieras a alguien
que maneje tus datos. Necesitas un equipo de operaciones, usa investigadores, redactores. Quieres asegurarte de
que el producto de extremo a extremo sea un seguro, seguro. Y de nuevo, cuando se trata, posible
que necesites algunos abogados son algunos
consejos de cumplimiento y así sucesivamente. Por lo que realmente no se detiene ahí. Pero lo importante es que el típico equipo
cross-funcional, tal vez integrado por estos miembros del equipo
Agile que se han mencionado. Nos hemos olvidado de la más
importante y hemos estado enfatizando algunas veces y
así deberíamos una vez más. Es tu cliente. Debes estar lo más cerca
posible de tu
cliente como puedas. Diseñas para tu
cliente, no para ti mismo. Y ese es el error
número uno. Vemos todo el tiempo. Creemos que sabemos lo que quiere
el cliente, pero realmente sólo construimos hacia nuestras propias necesidades y pensamiento. Sí, claro, hay
otras personas como yo y por lo tanto debería ser lo
correcto que estamos construyendo. Confía en mí, no lo sabes y te equivocarás
o el edificio. Por lo que consigue a tu cliente en la
realización de la investigación de clientes
todo
el tiempo prueba con los clientes y de la manera Agile que
hemos discutido, lanza muchas veces hazlo temprano, hazlo todo el tiempo y
aprender de los errores. Aprende de los comentarios que
un cliente te proporciona.
6. La fase de idea: De acuerdo, Hablamos sobre
el ciclo de vida
del ciclo de vida de desarrollo de software todo el tiempo. Y es muy simple ya que posiblemente
podría visualizarse así. Tienes una idea. Se quiere participar en una fase de descubrimiento
donde se extienda la idea poco más uso de los requisitos
definidos
y se acumula. Por lo que primer conjunto de diseños. Después lo construyes, lo pruebas, y
luego lo lanzas. Nuevamente, nosotros dentro del mundo
Ágil aquí. Entonces, no confundas esto como
la metodología de la cascada, sino más bien estás mirando un cierto futuro que
estás construyendo. Sí. Y luego das
un lanzamiento y lo
haces una y
otra vez una y otra vez. Dijimos antes, cada
bien empieza con una idea. Posibilidades de que puedas tener uno o quizá no tengas
absolutamente ninguno, ambos como perfectamente bien. En la idea. Rara vez sucede cuando simplemente
te sientas, tienes que trabajar hacia ello. Y si no tienes suficiente
idea, entonces está bien. El mejor lugar para
empezar es
entrenarte realmente todos los
días y solo pensar, ya
sabes, ¿cuál es
el problema y cuál es una solución potencial
en mi vida cotidiana? De verdad te quieres preguntar
todo el tiempo, ¿por qué hacemos
las cosas de cierta manera? ¿ Existe una mejor manera
de resolver un problema? Y si se puede identificar
un problema o
una especie de ineficiencia del mercado,
si se quiere. Ya estás a mitad de camino. Ahora. Hay montones de
formas de llegar con ideas
geniales y sin duda
iría mucho más allá
del alcance de este curso para explorarlas todas,
pondré algo en
la descripción si puedo. Pero, pero lo que me gusta
y siempre uso es a creación y al uso
del viaje del cliente. El viaje del cliente
realmente no es más un proceso que tipo de
mira a lo que el usuario sufre. Digamos, por ejemplo, un usuario puede estar mirando tu sitio web de comercio electrónico
que estás construyendo. Al principio, hay
un día de etapa de descubrimiento. Necesitan enterarse del hecho de que tu
sitio web existe, quiere poseer o
pueden que ellos navegan, pasan por lo que
se puede comprar en tu sitio web. Hacen algo pensando en ello. Hacen una evaluación de like, vale mi tiempo y mi
dinero para hacer esa compra? Y luego eventualmente sí hacen su compra donde
potencialmente están bastante ansiosos por ello hasta que vean su autoconfirmación final que el pago ha pasado. Y esa es la experiencia
de extremo a extremo. Se quiere buscar
cada una de esas etapas en el sitio de acción
que sufre el usuario. Entonces, por ejemplo, en
la etapa de descubrimiento, estás en una especie de
etapa de conciencia. Estás tratando de
enterarte del servicio que
estás brindando. El accionar puede ser que
abras la app, el sitio web que puedes
ver tutorial, y el tipo
de emoción del usuario en este punto es que son curiosos
y luego el bebé, pero escépticos en cuanto lo que estás tratando de venderlos. Pero son curiosos. tanto que un inconsciente en
la etapa de compra más adelante, ahora
están convencidos de su producto y
usted está vendiendo día. Tienen ganas de tenerla. Y la acción es hacer el
pago y luego hacer el pago. Pero la emoción aquí es mucho más de lo que están estresados
y están buscando la afirmación de que absolutamente indefinidamente deberían estar haciendo esos pagos de punto de compra y ojalá sean entonces posteriormente
feliz de haberlo hecho. Y el punto que estoy tratando de
hacer aquí es dentro del propio viaje del
cliente, esa es una capacidad para entender lo que el
usuario está sintiendo, qué se trata,
y de manera fundamental lo que se puede mejorar dentro de un viaje
existente. O importante, lo que puedes
crear un nuevo viaje y un nuevo producto o nuevo proyecto es algo que podría
deleitar al cliente, algo que los
hace felices
entendiendo lo que los
diversos procesos, cuáles son las diversas etapas, entender
por lo que
pasa
el cliente , es tu capacidad, tu oportunidad de mejorar y hacer que ese
proceso sea muy suave.
7. La fase de Discovery (tecnología): Ahora, con una idea en
mente para tu proyecto, quieres asegurarte de entrar una etapa de descubrimiento antes de construir
realmente algo. La idea detrás de la etapa de
descubrimiento es plasmar
sus requerimientos, jugar con el
primer conjunto de diseños para visualizar cómo podría ser un
producto. Probablemente no te sorprendas cuando digo que incluso
puedes girar, probablemente
debería incluso probarse con clientes que ya
en esta etapa. Y para determinar también cómo se va a construir
realmente la aplicación, ¿qué tecnologías se
van a utilizar? Entonces con eso en mente, comenzaremos con la visión general de la
solución. En este punto, es
el arquitecto
de soluciones del plomo tecnológico y los diversos
desarrolladores que se unen. Y quieren transmitir y determinar la visión general de la solución. Es mucho proporcionar una visión general de cómo
se va a construir
cada componente y masticar Eso va
a estar bien construido. Por lo que una visión general de la solución es
un esqueleto
de un programa, de una característica de un proyecto por un
faltante un elemento importante en esa arquitectura del proyecto, puede poner en peligro el éxito
de todo su proyecto. No podemos enfatizar esto lo suficiente. Una arquitectura
adecuada permitirá ahorrar mucho tiempo, energía y costos en el futuro. Quieres asegurarte de
que te acerques esto. Ahora, cualquiera, cualquier
diseño de arquitectura generalmente comprende múltiples
capas dentro de la aplicación, como la
capa de presentación en la misma parte superior. Eso es lo que el usuario
tiende a ver que como la interfaz de usuario
a lleva componentes, el diseño de interacción,
eso es lo que el usuario tiende
realmente a ver
al usar su producto. Debajo se encuentra una capa de negocio
que involucra o incluye toda la lógica empresarial o los
procesos, todos los flujos. Y luego, por último, debajo de
eso está la capa de datos, que a su vez incluye
toda su lógica de datos antigua, la base de datos en sí, y así sucesivamente. Eso, que a su vez se está
envolviendo. Se desea asegurarse de que
tiene seguridad en su lugar, cualquier tipo de configuración. No vamos a entrar en
todo el detalle aquí es obviamente un trabajo muy complejo, y lo está haciendo generalmente
un arquitecto de soluciones, por el líder tecnológico y por los diversos desarrolladores de
tu equipo que juntos transmitir y imaginar
cómo se está
construyendo su producto desde el punto de vista de una capa
tecnológica. Como siempre dudan numerosos
enfoques y tecnologías en sus lenguajes de programación
que se pueden utilizar para, para construir un diseño técnico de tan alto
nivel o en pila de tecnología corta. Y como siempre, todos tienen
fortalezas y carencias. Algunos son más baratos de usar, pero tal vez menos performantes. Otros pueden tardar mucho
más en implementarse. Podría ser incluso exagerado
o ser un mejor desempeño. En consecuencia. La
peor posibilidad es construir sobre una pila de tecnología moribunda o
poco confiable. Por lo que queremos asegurarnos de
que no hagas eso. Si cometes ese error, es posible que tengas que reconstruir
toda la aplicación nuevamente. O pagas prima por
los desarrolladores que avancen. Y de nuevo, sin
entrar en demasiado detalle, hay tan pocos principios
clave
que quiero resaltar cuando se
trata de la pila. Y es decir, se quiere construir con base en los
siguientes principios. Tiene que ser eficiente. Sí, por lo que tu aplicación
tiene que realizar las tareas y realiza las
funciones en cualquier condición. Por lo que tiene que ser confiable
con cualquier tipo de carga, cualquier tipo de cantidad de usuarios estando en tu,
en tu plataforma. Debe ser flexible. La solución elegida tiene
que ser fácil de cambiar. Se pueden cambiar elementos y no
debe influir en
que el conjunto, todo
el proyecto automáticamente, de manera negativa. Deberían poder extenderla. Por lo que quieres poder agregar tantas funciones
como quieras aplicación 2D. Es importante destacar que
debería ser escalable. Siempre debe ser
posible extender. El arquitectura,
debe permitir el desarrollo
directo y
varios hilos paralelos. Y por último, testability. Absolutamente debes poder
probar la arquitectura fácilmente, lo que significa que disminuye el
número de errores y aumenta su confiabilidad. Una vez más, ese es el trabajo
del arquitecto de soluciones.
8. La fase de descubrimiento (diseño y mapa mapa): Ir, entrar en una esfera
completamente diferente en cuanto al trabajo. De antemano se mencionó el diseño UX. Y de nuevo, esto es de la visualización de cómo
podría verse el producto. Sí, Así que aquí en la fase de
descubrimiento, comenzamos por crear
diseños y pantallas, y empezamos a asignar
cada función y datos. Está completamente bien que
vivan en múltiples lugares. No tienes idea de dónde simplemente se sienta en el momento actual, solo
estás jugando. Y la mayoría de las veces, este proceso se lleva a
cabo
en pizarras, en papel, o como puedes
ver actualmente en pantalla, algún tipo de herramienta de garabatos donde puedes
asegurarte de que puedes jugar bastante rápido
y cambiar las cosas rápidamente sin
tomar demasiado tiempo. Aquí la idea es que
quieras hacer cambios, quieres hacer eso ahora más que
más tarde en el proceso. Actualmente es mucho más barato
borrar algo. Entonces más tarde en el, en la biblioteca hay que
reescribir abrigo entero. Está bien.
Los flujos de trabajo son los caminos, los usos pueden viajar dentro de tu app. Sí, Entonces otra vez, dentro de eso, quieres considerar
cada una de las cosas que el usuario debería estar haciendo
en una determinada pantalla, cuántos clics
les toma completar una acción. Quieres asegurarte de
que cada click sea un aditivo de dos que realmente
no toma demasiado tiempo ni trabajo para
lograr algo. A medida que encuentre problemas con su flujo de trabajo, actualice
esos wireframes. Entonces lo que vemos y esos garabatos se llaman
wireframes ahí arriba, luego empezar de nuevo las pruebas
con un cliente, se
asegura de que funcione
antes de
entrar en algunos diseños más complejos. Lo que tiendes a hacer aquí
es usar también prototipos. Por lo que el modelo click-through es donde pones todos
esos wireframes juntos y tienes la capacidad de
simplemente hacer click a través de ellos
como si fuera una aplicación real, pero sin haber hecho
ningún desarrollo real. Una vez más, si fantástica manera de
probar algo en el
teléfono muy rápidamente para pruebas más realistas
y obtener retroalimentación de
inmediato de ahí. Esta es una manera fantástica de entender cuáles son
tus requisitos. Esto es en lo que entra un
analista de negocios. Entonces digamos, por ejemplo, que un UX está en
peligro determinó una especie de diseño UX
en el lado izquierdo. Como puedes ver,
tenemos un menú donde sea barra de
búsqueda tenemos algún
tipo de filtro en la parte superior, tienes varias,
varias cosas. Por lo que haga clic en tales como talleres
o marketplace o lo pueda ser en esa aplicación en
particular. Y así se
transmitió fácilmente actualmente visualmente necesita ser puesto
en más detalle en 3D, eso se convierte en el rezago
de requisitos. Por lo que un analistas de negocios trabajarán conjunto con el
propietario del producto,
con los diseñadores, con los desarrolladores para
asegurar la visión y que los diseños ahora se están poniendo
en requerimientos reales. Y se están definiendo
con detalle más antiguo que es necesario para que desarrollador
luego construya realmente. Por último, y nuevamente, un aspecto completamente diferente del trabajo es la hoja de ruta del producto. Esto es lo que entra un propietario de producto, el CEO del producto. Y dentro de la fase de descubrimiento, se
quiere tener una idea
algo. No tiene que
ser demasiado preciso, pero quieres tener una idea de
los
temas de alta prioridad que
ayudarán a todos realmente a enfocar su tiempo y energía
para hacer algunas cosas. Va ellos bien, producto ágil, hoja de ruta es la idea detrás de
eso como herramienta de navegación. Sí, ayuda a los equipos a
concentrarse en dónde están, dónde van, pero también les
da la libertad de
corregir el curso según sea necesario. Entonces, por ejemplo, si somos
uno clave en este momento, entendemos lo que
estamos construyendo en el próximo par de meses. Pero sigue siendo la
libertad de cambiar y adaptar lo que se pueda
construir en Q2, q4. Por lo que realmente una hoja de ruta de
producto ágil es una estrategia de
alto nivel visualizar, y está enfocada en
resultados en lugar salidas y charlas de, y temas y épocas
más que en características. Entonces nada se define
en ese punto. Entonces visualización e
indicación de lo que está por venir. Y eso ayuda a comunicar la estrategia del producto con las otras partes de la
organización y con un cliente. Y asegúrate de que
obtienes buy-in de tu equipo y de las partes interesadas
clave. En general, eso fue
una visión rápida de varias cosas que
podrías estar haciendo en la fase de
descubrimiento. Como siempre, hay mucho más. Depende del proyecto. Pero mira, asegurarte de que tengas una sólida base tecnológica y una visión general de la solución
es absolutamente crucial. Sí quieres tener una especie
de ir a visualizar cómo podría ser
el producto final y probarlo con los clientes. Temprano. Se quiere tener una idea de los requisitos que
se están construyendo en el primer conjunto de semanas por
venir que está haciendo
el analista de negocios. Y se quiere asegurar que
el CEO del producto, ese dueño del producto sea capaz de transmitir la
visión y adónde vamos, no sólo dentro de las próximas semanas
inmediatas, sino realmente con una visión
a largo plazo dice y cómo es que se vea el
producto final. Si eso se hace además cualquier otra cosa
que pueda tener que hacer, entonces entramos a la fase Bill.
9. La fase de desarrollo: De acuerdo, construido probablemente uno de los periodos más interesantes e intensos
dentro del proyecto, posiblemente la fase de ideación
y descubrimiento, así
como la
fase de lanzamiento hacia el final, toma significativamente menor
tiempo que la fase de construcción, bien
puede ser el 70, 80 por ciento del proyecto de extremo a extremo que se ocupará de la fase
Bill y como resultado, en increíblemente importante pero también donde la mayoría de las cosas salen mal. Y así necesito que me mejoren. Es un proceso largo y
no quiere ser pasado por alto. Vamos a echar
un vistazo rápido al día que trabaja para el equipo, que está dentro del mundo Ágil, vas a estar siguiendo. Este flujo
de trabajo aquí es de alto nivel nuevamente, que es que tienes el atraso de requisitos que has
reunido previamente. Y así cada día realmente, vas a elegir qué artículo
vas a abordar. Vas a poner
eso en el OpenFlow. Y luego con el tiempo eso
se va a seleccionar entonces por estar en progreso
me está desarrollando. Entra en el aseguramiento de calidad de
la columna QA donde se está
probando. Una base en eso. Si es pasiva va a hacer
y si no ha pasado, se remonta a lo en progreso. mayoría de las ocasiones, eso realmente sucede
físicamente en una pared, en una pizarra, o similares, por
supuesto, también se pueden hacer
digitalmente. Pero a menudo,
son sólo un montón de carteles que se están
entregando de columna en columna. Y es una gran manera de,
para que los equipos visualicen
qué trabajo se está haciendo. Y bases de datos, sobre todo
haciendo un stand up para visualizar y
transmitirse a todos lo que
se está trabajando activamente. Y muy rápidamente
podrás
ver si hay algún impedimento, si hay alguno tan bloqueador. ¿ Por qué cierto boleto, por qué cierto requisito no
está avanzando? Entonces ese es el flujo de trabajo general
de extremo a extremo. Se toma un requisito
y se abre camino a través de las diversas etapas del
flujo de trabajo. Y pobre punto de vista
de análisis de negocios. Ahora es el objetivo
escribir las historias de usuarios, los requisitos que son, se llaman historias de usuarios. Y como ejemplo, si tomas, por ejemplo, el menú, sea que
ahora cierta característica, ciertos requisitos. Se tiende a escribirlo en
el siguiente formato, que es el, se
define para quién es. Entonces en este caso, es un
usuario que ya ha bloqueado en tu aplicación como
usuario autenticado, luego
defines el objetivo
para ese usuario en particular. Por lo que en este caso,
quiero acceder
al menú lateral que es el
deseado como objetivo. Y luego dices, bueno, ¿por qué? Entonces, ¿qué, qué es el, entonces qué? Y así lo define como
un para que en este caso, pueda ver cualquier tipo de características
adicionales que puedan estar disponibles dentro,
dentro del producto. Por lo que una vez más, Diócesis del
negocio fuera de este trabajo. Esto entra en
mucho más detalle, pero a alto nivel se
enumera como una historia de usuario. ¿ Dónde encuentras
quién es el usuario? ¿ Qué quieren hacer, cuál es la acción y por qué? ¿ Cuál es el objetivo? Por lo que como usuario autenticado, quiero acceder a un
menú lateral para poder ver cualquier
característica adicional retocando en especie de una tarea de muy alto nivel para el analista de
negocios. De manera similar, un diseñador de UX al que hemos tocado antes ha definido
varios flujos de trabajo. Bayas, pantallas UX, pantallas
experimentadas en Estados Unidos que pueden
mirar hacia arriba, se ven así. En este punto, puedes
garabatos y ciertamente nada que quieras enviar y
lanzar al mercado real. Por lo que ahora es en este punto
el tipo de tareas para los diseñadores pongan eso en algo un poco más brillante, en una interfaz de usuario real. Y así puede, por ejemplo, convertirse en algo así. Sí, vas de una
interfaz UX y eso es entonces ser interpretado por los diseñadores como de la interfaz de usuario final o los desarrolladores
realmente van a estar recogiendo y
desarrollando Naturalmente. Entonces también tenemos que construir, absolutamente
no vamos a
entrar en eso en este curso en
particular. Muchas y muchas
formas diversas de construir código, pasando por diferentes
idiomas y así sucesivamente. Habrá un curso completamente diferente, todo
un curso distinto. Entonces vamos a
tener que saltarnos eso. Pero una vez más, ten en cuenta, estamos siguiendo la metodología
Agile en nuestro ejemplo particular. Sí, así que vamos a pasar por
el flujo de trabajo de análisis, facturando todo el asunto por una determinada característica y la
están liberando muy rápidamente para que obtengamos comentarios del
cliente de inmediato. Antes de hacer eso sin embargo, hay un aspecto que quiero
enfatizar y que es probar. Entonces no vamos a estar tocando
el desarrollo hoy, pero creo que las pruebas son algo que
queremos echar
un vistazo rápidamente antes de que cualquier
futuro sea liberado. Debe ir una prueba
exhaustiva de alimentos, y debe hacerlo
todo el tiempo en idealmente, se debe hacer automáticamente. Entonces echemos un vistazo a eso.
10. La fase de prueba (n.º 1): Entonces probando,
ahora he mencionado muchas
veces lo crucial y absolutamente importante que
encuentro pruebas y estar dentro de cualquier pieza del ciclo de vida de
desarrollo de software. Afortunadamente en estos días la
tecnología nos permite una vida mucho más fácil de las pruebas de cápsulas y mucho
de ella se puede automatizar, mientras que algunos, algunos aspectos
de, por supuesto todavía tienen que ser hechos manualmente por el desarrolladores, todos los testículos, equipos de
aseguramiento de calidad o incluso
negocios fuera de esto, quienquiera que quizá
gerentes de parques y así sucesivamente. Si estamos viendo
la aplicación, las pruebas son cruciales sin embargo, así que echemos un
vistazo a los diversos tipos de pruebas que se están haciendo
típicamente. Una es las pruebas unitarias, generalmente en un
hacer degenerado realizado por los desarrolladores. Utilizan pruebas manuales o automatizadas y
aseguran que cada unidad en su software cumpla con los
requisitos del cliente. Por lo que una vez más, puede o bien
probar esos casos de prueba, principalmente que por supuesto,
requiere mucho tiempo. Toma mucho tiempo,
es repetitivo, y por lo tanto toma bastante
esfuerzo en. buena noticia es sin embargo, herramientas
automatizadas de automatización de pruebas en estos días, pueden permitirte
grabar y guardar una prueba, y por lo tanto puedes
reproducirla tantas veces como sea necesario sin ningún tipo de
más. intervención humana. Por lo que en cualquier momento se está
desarrollando y desplegando nueva frialdad antes de la implementación, un desarrollador es escribir su prueba unitaria y es
ejecutar las pruebas unitarias, asegurando que esa nueva pieza
particular de se ha probado a fondo
con base en el requisito. A continuación, pruebas de integración,
absolutamente cruciales. Piénsalo como los modelos
individuales se están probando primero de manera aislada
como parte de las pruebas unitarias. Pero una vez que eso se haya completado
ahí entonces se integró. Entonces si estuvieras
pensando, piénsalo como un edificio, un auto, puedes ser unidad probando las
puertas, tal vez, ya sabes, probando el motor, ese maletero, cualquiera que
sea el color, cualquiera que sea. Pero luego uno por uno,
integrando lentamente eso también
como un solo sistema. Y así las pruebas de integración
aseguran que cualquier tipo de nuevo código cambie cualquier cosa que
agregue al sistema en general, no impacta la funcionalidad existente
del software. Se quiere asegurarse de comprobar que el
comportamiento combinacional tenga sentido. Se desea validar si
los requisitos se
implementan correctamente o no. A menudo, a esto le siguen
las pruebas del sistema, lo que significa que queremos
probar todo un sistema. Todos los modelos, todos los componentes
están integrados con el fin de
verificar que el sistema funciona
como se esperaba o no. Una vez más, si piensas
en el ejemplo del auto, Es genial que hayas comprobado
a fondo que cada artículo individual ha
sido ha sido probado por unidad. No habias comprobado que
están todos integrados e integrados probados mientras
armabas el auto. Pero entonces, por último, no olvides todo
el auto en sí todavía necesita ser revisado para todos los
diversos aspectos,
requisitos, y necesita
ser conducido sin problemas, tiene que tener los descansos
y marchas adecuados y necesita trabajar por miles y miles
de millas continuamente. El color necesita tener sentido. Por lo que el sistema en su conjunto fue también una parte crucial a probar
y eso se está haciendo después las pruebas de integración como
parte de las pruebas de sistema. Es posible que haya mencionado
al cliente de vez
en cuando en este curso, y no es de extrañar aquí entonces las pruebas de aceptación del
usuario se
denominan
comúnmente como en breve UAT. Y recompensa que significa
es, ya sabes, mostrar el producto
o la característica a un cliente y ellos hacen
las pruebas hacia adelante. Por lo que la gente
real, los clientes reales determinaron
si piensan que el software que has creado puede ser aceptado
en, puede salir a vivir. Esto, por tanto, no es tan automatizado como los ejemplos
anteriores. Más bien, se trata de sesiones
intensivas en tiempo, pero esperemos
sesiones irregulares donde personas
reales, usuarios reales
se unen como parte de pequeños grupos. Eso puede ser familia en Francia, yo puedo ser adoptantes tempranos, eso podría ser usuarios del poder, eso podría ser gente por la
que pagas dinero. Y realmente quieres
tener varias formas
de probar que
quieres a veces solo mostrarles el software y preguntar
qué piensan. Y por otro lado, quizá
quieras ser muy específico y escribir casos de prueba y proporcionar muestras
muy específicas para ser exploradas por estos usuarios
en particular. Y luego tienen muchas oportunidades para
brindarte retroalimentación.
11. La fase de prueba (n.º 2): Realmente esto
te da la oportunidad tener una retroalimentación muy abierta por parte personas que van a estar usando tu aplicación al
final, en el mundo real. El desempeño es,
por supuesto, un aspecto crucial. Imaginar que construyes un sitio web, pero no carga a
las personas que tienden a hacer clic distancia después de 2.5th de no
ver tus resultados. Por lo que es increíblemente
importante probar tanto para las pruebas bajas hacer tiempos de
uso normales y horas pico, pero también para probar el estrés
su aplicación IE, intenta deliberadamente encontrar
formas de romper el sistema. Cada vez más usuarios estás
siendo un, siendo asimilado? Y se quiere comprobar,
hace escala el sistema. Hay mucho regresa al de aplicación y
arquitectura Oval marco
de aplicación y
arquitectura Ovalque
hemos discutido previamente. Quieres asegurarte de
que una tecnología que tienes que
diseñar y imaginar, en
realidad este trabajo es capaz de lidiar con todos los usuarios están accediendo a tu plataforma. Por lo general, la accesibilidad
se conoce como navegar por las pautas de
accesibilidad de contenido web. Se trata de un conjunto
reconocido internacionalmente de recomendaciones para mejorar la accesibilidad
web. Ese es un ejemplo particular
para, para el diseño web. Pero realmente, sí aplica
a cualquier cosa que realmente tu app o lo que sea que puedas estar
construyendo en un mundo digital, quieres asegurarte de
que todo el mundo pueda y sea capaz de usar
tu producto final. Y entonces de lo que estaba
conformado es
asegurarme de que la visión
sea muy clara. Es decir, tienes quizás, ya sabes, usuarios con problemas de visión
severamente. Necesitan poder
usar tu aplicación. Puede que haya personas dificultades auditivas y quizá sordas. Y sí tienen que contar con
unas herramientas particulares para acceder a la movilidad de la
aplicación. Aquellos a quienes les resulte
difícil usar un mouse o teclado, se
quiere
brindarles alternativas. Y luego pensar, pensar en entender a las
personas que tienen dislexia, autismo, cualquier tipo de dificultades de
aprendizaje. Nuevamente, desea proporcionar un enfoque simplificado para que
utilicen la aplicación. En consecuencia, aunque
sea legal o no, se quiere
pensar absolutamente en la accesibilidad
desde el principio. Si quieres rediseñar nuestra necesidad de rediseñar
en retrospectiva, confía en mí,
va a tomar tiempo. Va a necesitar
una cantidad demencial de esfuerzo y costo para hacerlo. Así que piénsalo como un requisito
clave absoluto desde
el principio, ejecuta todas tus pruebas
de accesibilidad desde el Early on
auto-desarrollo. Y te vas a ir
a una cosa voladora. De manera similar. La compatibilidad garantiza
que su software pueda ejecutarse en diferentes
navegadores y sistemas operativos. En estos días tenemos miles de tamaños de dispositivos con los que lidiar. Todos se ven diferentes
en diferentes pantallas. Piénsalo, de iOS, pero particularmente Android
y tener una gran cantidad de tamaños de un dispositivo
diferenciado y sistemas operativos. Entonces, ya sabes, constantemente, quieres asegurarte de que el nuevo software que
inicias en cualquier
nuevo futuro que estás lanzando sea compatible con estos requisitos que se
pueden hacer manualmente, pero cada vez más, la mayor parte se
está haciendo automatizado de manera automatizada
a través de
emuladores y simuladores donde ya
ni siquiera se necesita ningún dispositivo. Todo está hecho en la Nube. Y puedes asegurarte de que sabías que código se ejecuta a través de todas
esas plataformas. Y por último, cada
vez más crucialmente, creo que para todos y
sobre todo porque se ha recibido bastantes
escrutinio mediático es por supuesto, la seguridad de la aplicación. Es necesario asegurarse de
que
realiza pruebas de pluma regulares. ¿ Estás probando seguridad? Mira, si tienes una tienda de
comercio electrónico, por ejemplo, y puedes ver las compras
en línea, estarás retrocediendo información de
persona, información tarjetas
de
crédito y así sucesivamente. El usuario tiene que confiar en ti. Y si no lo hacen, entonces
no tienes clientes. Y B, puede que tengas un gran
problema con las autoridades. Pero vas
a ver que no hay seguridad significa que se otorgue cualquier tipo de acceso
autorizado
para proteger los datos. Y el
acceso no autorizado está restringido. Y quieres
asegurarte de que no
tengas vulnerabilidades en ningún tipo de código propio y código personalizado o en cualquier código de
terceros. Ten en cuenta si tus usuarios
de diferente proveedor, te aparece con un tercero, absolutamente
quieres
asegurarte de que
también sean capaces de
soportar cualquier ataque. Una vez más, eso es sólo
una visión general
de alto nivel de las pruebas típicas que se están realizando. Hay, como siempre, más. Es suave
dependiendo de pendiente de tu, tu complejidad
y del tamaño de tu proyecto en cuanto a
cuánto hagas de cuál. Pero es crucial que
las pruebas sean una especie de aspecto clave y monetario de su aplicación de
software. Ese enfoque.
12. La fase de lanzamiento: Y casi estamos ahí. El almuerzo, probablemente
el más intenso, tal vez la parte más emocionante de todo
el ciclo de vida que
hemos mirado hasta ahora. Probablemente has estado
pensando en tu idea desde
hace años, si no más. Y ahora el último par de
meses has estado construyendo tu código, tus desarrollos, diseñas, y ahora
estás listo para lanzar el primer conjunto de
características al mercado. Cuando se trata del lanzamiento, siempre
es una buena idea dar inicio a las cosas con
amigos y familiares. Tienes un poco más de una
especie de público amistoso. Y puedes probar
y obtener retroalimentación. Temprano. De nuevo, me estoy repitiendo, pero no subestimes
la importancia de
una especie de retroalimentación amistosa inicial de los
clientes donde
puedas iterar
y mejorar con bastante rapidez tu producto. También date la mente cuando
sí lanzas algo a, por ejemplo, una App Store, siempre
es un proceso que
quieres asegurarte de que el APSA correctamente configurado
para su lanzamiento. Tienes que llenar un par de formularios por cada tienda que vayas a enviar pantalla muestra un poco de un material de marketing,
toda una descripción. Por lo que también
se ha hecho un poco de trabajo ahí. Y después sea Google o Apple, podrán Mallory revisar todas estas apps enviadas
a la App Store. Bueno, Apple en realidad allí
tan más que, que Google. Pero es posible
que no presionen un montón de cambios basados
en tu configuración. Por lo tanto, ten eso en cuenta cuando se
trata de tu línea de tiempo. Una vez que estás en vivo y los productos fuera en
el mercado real, hay por supuesto,
algunas formas de
promocionarlo aparte de sus amigos y familiares y especie
de boca a boca. El obvio en estos
días son las redes sociales. Sé ese Twitter,
tiktok, y lo que sea. Redes profesionales
como LinkedIn. Esa es una avenida data uno lo es más para los
bloggers y vloggers, progresa a través del marketing de
afiliados. Y por supuesto, si
sí tienes el dinero, entonces puedes participar en un anuncio de
campaña más extenso. Hazlo lentamente al principio
y obviamente a más
agresivamente en cuanto a cuándo
planeas un lanzamiento completo. Pero, pero una cosa que
quiero enfatizar es que este no es el fin, ¿verdad? Por lo que el desarrollo de aplicaciones no se
detiene en la fase de lanzamiento. Más bien, es un
ciclo continuo de iteración, como lo hemos enfatizado muchas
veces en el mundo del desarrollo ágil. Y así quieres
asegurarte monitorear la app y
la captación por parte de los usuarios. Desea asegurarse de
que es capaz de
acceder a cualquier accidente que
pueda haber experimentado. Existen bibliotecas que
sí hacen un seguimiento de esas. Y te dicen lo que estaba haciendo
el usuario, el dispositivo que estamos usando, cualquier tipo de información técnica
que pueda ser importante para especie de replicar
el problema. Definitivamente quieres empezar a entender mejor a tus usuarios. Se desea hacer uso
de herramientas analíticas como Google o
Facebook analytics. Y eso otra vez, te ayuda a entender quién está usando la app. Cuál es su edad, su género, de
dónde son,
qué idiomas hablan, y así sucesivamente. ¿ Cuántas veces usan la app cuando estamos
haciendo el día? Cuánto tiempo se está
gastando en la app, qué pantallas se están viendo, predominantemente,
cuáles no, y así sucesivamente. Soy fantásticas,
oportunidades impresionantes por ahí. La creación de
mapas de calor donde se puede ver dónde hace clic la gente,
qué pantallas. Haré clic en eso
con más frecuencia y así sucesivamente. Pero realmente la idea
aquí es que eres capaz mejorar en base a
esos análisis. No se quiere
simplemente construir sobre porciones del capítulo
allí rara vez se utilizan, pero se quiere invertir
donde está la acción, ¿cuál es el mayor
potencial de crecimiento? Y son realmente esas
herramientas las que proporcionan perspicacia, asegura de
medir el rendimiento. Ya mencioné antes, la gente no es muy paciente cuando se
trata de eso. Por lo que desea medir
el desempeño técnico y la facilidad de sistema que implementamos, cuenta con un amplio monitoreo de
desempeño en su lugar todo el tiempo. De esa forma podrás
rastrear cuántas veces ha
ocurrido una acción, cuánto tiempo tardó. Y, y de nuevo, encuentras eso como una buena oportunidad de
espacio para la optimización. También puedes poner cualquier
alerta y lugar para saber cuándo una acción tal vez esté tomando un poco más lenta
si tu servidor, tu entorno está sobrecargado. Por lo que bastante críptico y
buscas arreglarlos también. Y entonces por supuesto,
incluso una especie de
monitoreo manual a la hora de
mirar la App Store,
por ejemplo, sí responden a
los comentarios de costos de los clientes. Tome sus comentarios
en, en cuenta, asegúrese de que el
gerente de producto sí los vea. Y de acuerdo con el, esa es la retroalimentación clave que
necesitas con el fin mejorar y rápidamente
obtienen otra siguiente iteración
de tu aplicación.
13. Conclusión: Eso nos lleva a la conclusión donde termina el curso. Espero que esas diversas etapas
del ciclo de vida de desarrollo de software tuvieran
sentido y te resultara
algo útil. Mira, si hay una cosa que
diría al final es una talla única que se ajusta a
todos no es eso. Si bien la metodología del desarrollo
ágil y
que el proceso en sí mismo sí funciona y se puede aplicar
absolutamente de
manera consistente. Por supuesto, sí
depende en gran medida del proyecto, la complejidad, el tamaño, el, el, el, el financiamiento
está disponible para ti, el conjunto de habilidades de la
gente, y así sucesivamente. Y cada proyecto es diferente. Y en uno, puede ser pesado,
pesado en tecnología y
sistemas back-end y el dominio empresarial, mientras que otros, puede estar
mucho más enfocado en el diseño
gráfico y la ingeniería de
sonido y el desarrollo ahí. Y necesitas
adaptarte como se requiere S. Y lo único que
diría desde una
perspectiva de gestión de proyectos, o que seas
gerente de producto o director general de una pequeña startup
es debidamente por valores. Porque tú como, como PM, como gerente de proyecto
o alguien que
no está involucrado en
cada etapa, sino más bien el pegamento
entre las personas. Nunca vas a ser
el experto en nada. Realmente más. Eres tú quien proporcionó
una visión general holística, pero no eres un experto en dominios. Por lo que debidamente por esos valores, me gustan los que
se muestran en la pantalla. Confianza, empatía, transparencia,
y colaboración. Asegurar que los equipos
puedan autoorganizarse, empoderarlos, que
puedan hacer lo necesario
para resolver el problema. Y creo que si sí lideras por esos valores y si
estableces esa confianza y una especie de creer en
los conjuntos de habilidades de la gente, entonces tú también puedes construir
un prodrug asesino, un
producto digital impresionante que el ciclo de vida de
desarrollo de software que se ha presentado hoy. Eso fue todo.
Espero que eso haya sido divertido. Espero que eso haya sido útil si
hay alguna pregunta. No dudes en contactarme
y te veremos la próxima vez.
Alexander F
