Vamos por partes
Qué significa esta imagen un poco más tarde, pero ahora permítanme comenzar con una introducción.
En un frío día de febrero, nada presagiaba problemas. Un grupo de estudiantes inocentes llegó por primera vez a la clase de una asignatura que decidieron llamar 'Metodología de organización de diseño y desarrollo de sistemas de información'. Era una clase normal, el profesor hablaba sobre métodos de desarrollo ágiles, como Scrum, y nada presagiaba problemas. Y al final, el profesor anunció:
Quiero que experimenten todas las dificultades del trabajo en equipo, divídanse en grupos, piensen en un proyecto, nombren a un líder y pasen juntos por todas las etapas del diseño. Al final, espero de ustedes un producto terminado y un artículo en Habr.
Y aquí comienza nuestra historia. Como bolas en una mesa de billar, nos rebotamos unos contra otros, hasta que la energía del impacto se disipó y se formó un grupo de 7 personas. Quizás sea demasiado para un proyecto académico, pero para distribuir roles mejor, es lo ideal. Comenzó la discusión sobre ideas para el proyecto, desde 'Tomemos un proyecto ya hecho' hasta 'Emulador de formación de objetos espaciales'. Pero al final, surgió la idea cuyo nombre ya leíste en la primera imagen.
Stop Procrastination — qué es, cómo se utiliza y cómo lo desarrollamos y qué salió de ello
La narración será en primera persona, desde la perspectiva del líder del proyecto, que, por suerte o desgracia, me han nombrado a mí. Entonces, ¿qué idea se nos ocurrió? Inspirados por el popular despertador 'Shake Alarm' de SupperCommon, especialmente por la función de bloquear completamente el funcionamiento del smartphone hasta que el usuario realice una determinada acción que, muy probablemente, lo despierte, decidimos crear una aplicación similar que ayude a deshacerse de la dependencia del teléfono, utilizando el mismo principio que el 'Shake Alarm'.
Principio de funcionamiento.
El usuario establece temporizadores
- Tiempo que se puede pasar en el smartphone
- Tiempo sin smartphone (período de bloqueo)
Una vez que el temporizador ha expirado, aparece una superposición en la pantalla que no se puede cerrar
- Para cerrar la superposición, hay que pasar una pequeña prueba (ingresar una contraseña en un teclado confuso, resolver un problema matemático, sacudir el teléfono durante un par de minutos)
Después de desbloquear de esta manera, el tiempo que se puede pasar en el smartphone se reduce a la mitad, y así hasta un minuto.
Construimos un equipo
Para empezar, era necesario definir quién se encargaría de qué y en qué idioma se escribiría todo esto. Creo que esto tiene poco que ver con la gestión de proyectos, ya que cuando reúnes un equipo para un proyecto real, convocas inmediatamente a aquellos que necesitas. Al final, también asumí la carga del diseñador, elegí a un team lead que tenía una buena experiencia en el desarrollo de aplicaciones, y a su cargo se asignaron tres programadores, y otros dos se convirtieron en testers. Por supuesto, el lenguaje de programación se eligió según las habilidades. Al final, se decidió usar Java, ya que todos los programadores estaban familiarizados con él.
Establecemos tareas
Siguiendo la recomendación del profesor, se creó un tablero de tareas en un servicio gratuito. . Se planeó trabajar bajo el sistema Scrum, donde cada stream representaría una aplicación completa.
Sin embargo, en realidad, de todo esto resultó un solo gran y largo stream, en el que se realizaban constantemente modificaciones, adiciones y correcciones.
Escribimos especificaciones
Bajo la influencia del libro de Savin "Testing.com", tenía en mente mi propia visión de cómo debería estar estructurado todo. Todo comenzó con la redacción de especificaciones, ya que considero que sin una descripción clara de lo que esperamos, de qué y cómo debería funcionar, nada funcionará. Los programadores programarán todo como ellos ven, los testers probarán otra cosa, el jefe esperará algo diferente, y al final resultará, como siempre, algo cuaternario.
Escribir especificaciones no es fácil, se deben considerar todos los detalles y matices. Por supuesto, nada salió bien a la primera. Al final, las especificaciones se complementaron y se rehacieron 4 veces. La última versión la puedes encontrar al final del artículo, en la sección de enlaces.
Diseñamos el diseño
El diseño en una aplicación móvil es lo más importante. Sin embargo, no todos lo entienden, incluyendo a muchos de mi equipo que discutieron apasionadamente conmigo que el diseño no era necesario, que era la parte menos importante de la aplicación, etc. No hay que ser tan ingenuo. Primero, un diseño terminado facilita el trabajo del programador, no necesita pensar en qué y dónde colocar cada cosa, simplemente toma lo que se ha dibujado y lo codifica. Junto con las especificaciones, el diseño libera casi por completo la mente del programador de cosas innecesarias y le permite concentrarse en la lógica. En general, primero se dibujó un diseño de prototipo (horrible):
Pero luego el diseño fue ajustado y llevado a una forma aceptable.
(Enlace a todos los elementos de diseño al final del artículo).
Programación
Programar es difícil, pero posible. Dejaré de lado este tema, ya que personalmente no me he involucrado en esto. Los programadores realizaron un gran trabajo, sin el cual todo sería sin sentido. Claro que se logró implementar parte de las ideas. Y la aplicación aún necesita mejoras. Hay muchos errores y características que hay que corregir. Si tuviéramos más tiempo, habríamos salido de la profunda fase alfa, pero por ahora pueden probar la aplicación al final del artículo.
Y sobre las pruebas
¿Qué es lo más importante en la programación? A mi parecer, lo principal es que todo funcione y se vea como debe. Lo que debe salir, no siempre sucede de inmediato. Para ello es necesaria la prueba. A mis testers, les propuse un modelo de prueba utilizando casos de prueba. Primero se escriben los casos de prueba de acuerdo con las especificaciones, y luego se realizan las pruebas. Lo que resultó de esto puede ser visto a continuación en los enlaces.
Gracias por leer. Espero que hayan encontrado aquí al menos algo útil, quizás una idea para su startup, o tal vez un buen consejo o herramienta.
Enlaces:
Últimos .
Diseño en .
y .
La propia aplicación en . — La aplicación se construyó bajo el nombre HandsOff, ni siquiera pregunten por qué (porque Stop Procrastination es demasiado largo).
Y al final
¿Qué piensan, tuvo todo esto sentido?
Solo los usuarios registrados pueden participar en la encuesta. , por favor.
¿Es necesaria tal práctica en las instituciones educativas y cuán útil y aplicable es en la vida real?
Es necesaria, es una experiencia invaluable.
Es necesaria, aunque tengo poco experiencia.
Casi inútil, máximo entenderás las características generales del trabajo en equipo.
Una pérdida de tiempo y esfuerzo.
Votaron 2 usuarios. No hay abstenciones.
Fuente: habr.com
