C贸mo tratamos de trabajar en equipo y qu茅 surgi贸

Stop Procrastination

Vamos en orden


驴Qu茅 significa esta imagen un poco m谩s tarde, y ahora perm铆tanme comenzar con una introducci贸n?

En un fr铆o d铆a de febrero, nada auguraba nada malo. El grupo de estudiantes inocentes lleg贸 por primera vez para una pareja en el tema, que decidieron llamar "Metodolog铆a para la organizaci贸n del dise帽o y desarrollo de sistemas de informaci贸n". Hubo una conferencia regular, la maestra habl贸 sobre m茅todos de desarrollo flexibles, como scrum, nada presagiado de problemas. Y al final, el profesor anuncia:
Quiero que experimente todas las dificultades del trabajo en equipo, se divida en grupos, presente un proyecto, designe un l铆der y atraviese todas las etapas de dise帽o juntos. Al final, espero de usted un producto terminado y un art铆culo sobre Habr.
Aqu铆 es donde comienza nuestra historia. Como bolas en el billar, nos rebotamos unos a otros hasta que la energ铆a del golpe se disip贸 y un grupo de 7 personas se reunieron. Quiz谩s esto sea demasiado para un proyecto de capacitaci贸n, pero para distribuir mejor los roles, eso es. Comenz贸 la discusi贸n de ideas para el proyecto, desde "Tomemos el proyecto terminado" hasta "Emulador para la formaci贸n de objetos espaciales". Pero al final, pas贸 una idea, cuyo nombre le铆ste en la primera imagen.

Detener la procrastinaci贸n: qu茅 es, con qu茅 se come, c贸mo lo desarrollamos y qu茅 surgi贸


La historia se llevar谩 a cabo en nombre del gerente del proyecto, quien afortunada o desafortunadamente me nombr贸. Entonces, 驴cu谩l es la idea que se nos ocurri贸? Inspirado por el popular reloj despertador "Shake Alarm Clock" de SupperCommon, es decir, la funci贸n de bloquear completamente el funcionamiento del tel茅fono inteligente hasta que el usuario realiza una determinada acci贸n, que es muy probable que lo despierte, decidimos crear una aplicaci贸n similar que ayudar谩 a eliminar la dependencia telef贸nica, por el mismo principio que "Agite el despertador"

Principio de funcionamiento


El usuario establece temporizadores
- Tiempo que puedes pasar en un tel茅fono inteligente
-Tiempo sin tel茅fono inteligente (per铆odo de bloqueo)
Despu茅s de que expira el temporizador, aparece una superposici贸n en la pantalla que no se puede minimizar.
-Para cerrar la superposici贸n, debe pasar una peque帽a prueba (ingrese la contrase帽a en un teclado confuso, resuelva un problema matem谩tico, agite el tel茅fono durante un par de minutos)
Despu茅s de desbloquear de esta manera, el tiempo que puede pasar en el tel茅fono inteligente se reduce a la mitad, y as铆 sucesivamente hasta un minuto.

Construyendo un equipo


Para empezar, era necesario determinar qui茅n har谩 qu茅 y en qu茅 idioma se escribir谩 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 responsabilidad del dise帽ador, eleg铆 un l铆der de equipo que ten铆a buena experiencia en el desarrollo de aplicaciones, se le asignaron tres programadores y dos m谩s se convirtieron en evaluadores. Por supuesto, el lenguaje de programaci贸n fue elegido por habilidad. Como resultado, se decidi贸 utilizar Java, ya que todos los programadores estaban familiarizados con 茅l.

Fijamos tareas


Por recomendaci贸n del profesor, se cre贸 un tablero de tareas en el servicio gratuito de Trello . Se plane贸 trabajar en el sistema Scrum, donde cada transmisi贸n ser谩 una especie de aplicaci贸n completa.

Sin embargo, de hecho, una gran y larga secuencia surgi贸 de todo esto, en la que se realizaron ediciones, adiciones y correcciones constantemente.

imagen

Escribir especificaciones

Bajo la influencia del libro de Savin, Testing.com, ten铆a en mi cabeza mi idea de c贸mo deb铆a organizarse todo. Todo comenz贸 con la escritura de especificaciones, que creo que sin una descripci贸n clara de lo que esperamos, qu茅 funcionar谩 y c贸mo nada funcionar谩. Los programadores programar谩n todo como ven, los evaluadores probar谩n otro, la cabeza estaba esperando el tercero, y resultar谩 como siempre el cuarto.

Escribir especificaciones no es f谩cil, debe pensar en todos los detalles, todos los matices. Por supuesto, no pas贸 nada la primera vez. Como resultado, las especificaciones se complementaron, rehechas 4 veces. Puede encontrar la 煤ltima opci贸n al final del art铆culo, en la secci贸n de enlaces.

Dibujar dise帽o


El dise帽o en una aplicaci贸n m贸vil es lo m谩s importante. Sin embargo, no todos entienden esto, incluido mi equipo, muchos argumentaron en茅rgicamente conmigo que el dise帽o no es necesario, que esta es la parte m谩s importante de la aplicaci贸n, etc. No seas tan ingenuo. En primer lugar, el dise帽o terminado es un alivio para el trabajo del programador, no necesita pensar d贸nde y d贸nde meter, solo toma y escribe lo que se dibuja. 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):

Dise帽o v1

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).

Dise帽o v2

Programable


La programaci贸n es dif铆cil, pero posible. Omitir茅 este momento, ya que personalmente no hice esto. Los programadores hicieron un gran trabajo, sin el cual todo ser铆a in煤til. Por supuesto, logr茅 realizar algunas de las ideas. Y el programa a煤n necesita refinamiento. Muchos errores y funciones que deben eliminarse. Si tuvi茅ramos m谩s tiempo, saldr铆amos del alfa profundo, pero por ahora puede probar la aplicaci贸n al final del art铆culo.

Bueno, sobre pruebas


驴Qu茅 es lo principal en la programaci贸n? En mi opini贸n, lo principal es que todo funciona y se ve como deber铆a. A medida que sale, no siempre es as铆 ni de inmediato. Esto requiere pruebas. Para mis evaluadores, propuse un modelo de prueba usando casos de prueba. Primero, los casos de prueba se escriben de acuerdo con las especificaciones, y luego se prueban. Lo que result贸 de esto se puede ver a continuaci贸n en los enlaces.

Gracias por leer Espero que encuentre al menos algo 煤til aqu铆, tal vez una idea para su inicio, o tal vez un buen consejo o una herramienta.

Referencias


脷ltimas especificaciones .
Dise帽o de Figma .
Casos de prueba e informes de errores .

La aplicaci贸n en s铆 en HokeyApp . - La aplicaci贸n se cre贸 bajo el nombre de HandsOff, ni siquiera pregunte por qu茅 (porque Stop Procrastination es demasiado largo).

Bueno al final


驴Crees que todo esto tiene sentido?

Source: https://habr.com/ru/post/452712/


All Articles