Cómo intentamos trabajar en equipo y qué resultó de ello

Cómo intentamos trabajar en equipo y qué resultó de ello

Comencemos en orden

Qué significa esta imagen un poco más adelante, pero por ahora déjame comenzar con la introducción.

En un frío día de febrero no había señales de problemas. Un grupo de estudiantes inocentes acudió por primera vez a tomar una clase sobre un tema que decidieron llamar “Metodología para la organización del diseño y desarrollo de sistemas de información”. Hubo una conferencia regular, el profesor habló sobre métodos de desarrollo flexibles, como Scrum, nada presagiaba problemas. Y al final la maestra anuncia:

Quiero que usted mismo experimente todas las dificultades del trabajo en equipo, se divida en grupos, elabore un proyecto, nombre un líder y pasen juntos por todas las etapas de diseño. Al final espero de usted un producto terminado y un artículo sobre Habré.

Aquí es donde comienza nuestra historia. Como bolas de billar, rebotamos unos en otros hasta que la energía del impacto se disipó y se reunió un grupo de 7 personas. Quizás esto sea demasiado para un proyecto de formación, pero está bien para distribuir mejor los roles. Comenzó una discusión sobre ideas para el proyecto, desde "Tomemos un proyecto ya hecho" hasta "Emulador para la formación de objetos espaciales". Pero al final surgió la idea, cuyo nombre leéis en la primera imagen.

Detener la procrastinación: qué es, con qué se come, cómo la desarrollamos y qué surgió de ella

La historia la contaré en nombre del director del proyecto que, por suerte o por desgracia, me fue asignado. Entonces, ¿qué idea se nos ocurrió? Inspirándonos en el popular despertador "Shake Alarm Clock" de SupperCommon, es decir, la función de bloquear completamente el teléfono inteligente hasta que el usuario realiza una determinada acción que probablemente hará que se despierte, decidimos crear una aplicación similar que le ayudará a conseguirlo. deshacerse de la adicción al teléfono, siguiendo el mismo principio que "Agita el despertador"

¿Cómo funciona?

El usuario configura temporizadores
-Tiempo que se puede dedicar a un teléfono inteligente.
-Tiempo sin smartphone (período de bloqueo)
Cuando el temporizador expira, aparece una superposición en la pantalla que no se puede minimizar.
-Para cerrar la superposición, debes realizar una pequeña prueba (ingresar una contraseña en un teclado confuso, resolver un problema matemático, agitar el teléfono durante un par de minutos)
Después de desbloquear de esta forma, el tiempo que se puede pasar en el smartphone se reduce a la mitad, y así hasta un minuto.

Construyendo un equipo

En primer lugar, era necesario determinar quién haría qué y en qué idioma se escribiría todo esto. Creo que esto tiene poco que ver con la gestión de proyectos, porque cuando reúnes un equipo para un proyecto real, inmediatamente reúnes a los que necesitas. Como resultado, también asumí la carga de diseñador, elegí un gerente de equipo que tenía buena experiencia en el desarrollo de aplicaciones, le asignaron tres programadores y dos más se convirtieron en evaluadores. Por supuesto, el lenguaje de programación se eligió en función de las habilidades. Como resultado, se decidió utilizar Java, ya que todos los programadores estaban familiarizados con él.

Establecer tareas

Por recomendación del docente, se creó un tablero de tareas en un servicio gratuito. Trello. Se planeó trabajar según el sistema Scrum, donde cada flujo sería una especie de aplicación completa.
Sin embargo, en realidad, todo esto surgió de una corriente grande y larga, en la que constantemente se realizaron ediciones, adiciones y correcciones.

Cómo intentamos trabajar en equipo y qué resultó de ello

Escribimos especificaciones

Influenciado por el libro de Savin “Testing.com”, tenía mi propia idea en la cabeza de cómo debería organizarse todo. Todo comenzó escribiendo especificaciones, creo que sin una descripción clara de lo que esperamos, qué y cómo debería funcionar, nada funcionará. Los programadores programarán todo como lo ven, los probadores probarán algo más, el director esperaba el tercero, pero resultará ser el cuarto como siempre.
Escribir especificaciones no es fácil, es necesario pensar en todos los detalles, todos los matices. Por supuesto, nada funcionó la primera vez. Como resultado, las especificaciones se complementaron y rehicieron 4 veces. Puedes encontrar la última opción al final del artículo, en la sección de enlaces.

dibujando un diseño

El diseño en una aplicación móvil es lo más importante. Sin embargo, no todos entienden esto, incluso en mi equipo, muchos argumentaron con vehemencia conmigo que el diseño no es necesario, que esta es la parte menos importante de la aplicación, etc. No deberías ser tan ingenuo. En primer lugar, un diseño ya hecho facilita el trabajo del programador; no tiene que pensar qué poner, dónde y dónde, simplemente toma y compone lo dibujado. Junto con las especificaciones, el diseño libera casi por completo la mente del programador de cosas innecesarias y le da la oportunidad de concentrarse en la lógica. En general, primero se dibujó un diseño prototipo (terrible):

Cómo intentamos trabajar en equipo y qué resultó de ello

Pero luego el diseño fue peinado y devuelto a la normalidad.
(Enlace a todos los elementos de diseño al final del artículo).

Cómo intentamos trabajar en equipo y qué resultó de ello

Programación

La programación es difícil, pero posible. Omitiré este punto, ya que no lo he abordado personalmente. Los programadores hicieron una gran cantidad de trabajo, sin el cual todo no tendría sentido. Por supuesto, logramos hacer realidad algunas de nuestras ideas. Y el programa aún necesita mejoras. Hay muchos errores y funciones que deben eliminarse. Si tuviéramos más tiempo saldríamos de la alfa profunda, pero por ahora podéis probar la aplicación al final del artículo.

Bueno, sobre las pruebas.

¿Qué es lo principal en programación? En mi opinión, lo principal es que todo funcione y luzca como debería. No siempre funciona bien y no de inmediato. Esto requiere pruebas. A mis evaluadores les propuse un modelo de prueba utilizando casos de prueba. Primero, los casos de prueba se escriben en total conformidad con las especificaciones y luego se realizan pruebas sobre ellos. Puedes ver lo que surgió de esto en los enlaces a continuación.

Gracias por leer. Espero que hayas encontrado al menos algo útil aquí, tal vez una idea para tu startup, o tal vez algún buen consejo o una herramienta.

Enlaces:

Más reciente especificaciones.
Diseño en Figma.
Casos de prueba и informes de errores.

La aplicación en sí está activada. HokeyApp. — La aplicación se creó con el nombre HandsOff, ni siquiera preguntes por qué (porque Stop Procrastination es demasiado largo).

Bueno al final

¿Crees que todo esto tenía sentido?

Solo los usuarios registrados pueden participar en la encuesta. Registrarsepor favor

¿Es necesaria esa práctica en las instituciones educativas y qué tan útil y aplicable es en la vida real?

  • Experiencia necesaria e invaluable.

  • Necesario, aunque un poco de experiencia.

  • Casi inútil, como mucho entenderás las características generales del trabajo en equipo.

  • Pérdida de tiempo y esfuerzo

2 usuarios votaron. No hay abstenciones.

Fuente: habr.com

Añadir un comentario