{"id":34112,"date":"2019-10-31T21:56:27","date_gmt":"2019-10-31T18:56:27","guid":{"rendered":"https:\/\/prohoster.info\/blog\/kak-my-pytalis-v-komandnuyu-rabotu-i-chto-iz-etogo-vyshlo\/"},"modified":"2019-10-31T21:56:27","modified_gmt":"2019-10-31T18:56:27","slug":"kak-my-pytalis-v-komandnuyu-rabotu-i-chto-iz-etogo-vyshlo","status":"publish","type":"post","link":"https:\/\/prohoster.info\/es\/blog\/news\/kak-my-pytalis-v-komandnuyu-rabotu-i-chto-iz-etogo-vyshlo","title":{"rendered":"C\u00f3mo intentamos trabajar en equipo y qu\u00e9 result\u00f3 de ello","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"C\u00f3mo
\n<\/p>\n

Vamos por partes<\/h3>\n

\nQu\u00e9 significa esta imagen un poco m\u00e1s tarde, pero ahora perm\u00edtanme comenzar con una introducci\u00f3n.<\/p>\n

En un fr\u00edo d\u00eda de febrero, nada presagiaba problemas. Un grupo de estudiantes inocentes lleg\u00f3 por primera vez a la clase de una asignatura que decidieron llamar 'Metodolog\u00eda de organizaci\u00f3n de dise\u00f1o y desarrollo de sistemas de informaci\u00f3n'. Era una clase normal, el profesor hablaba sobre m\u00e9todos de desarrollo \u00e1giles, como Scrum, y nada presagiaba problemas. Y al final, el profesor anunci\u00f3: <\/p>\n

Quiero que experimenten todas las dificultades del trabajo en equipo, div\u00eddanse en grupos, piensen en un proyecto, nombren a un l\u00edder y pasen juntos por todas las etapas del dise\u00f1o. Al final, espero de ustedes un producto terminado y un art\u00edculo en Habr.<\/p><\/blockquote>\n

Y aqu\u00ed comienza nuestra historia. <\/a><\/noindex> Como bolas en una mesa de billar, nos rebotamos unos contra otros, hasta que la energ\u00eda del impacto se disip\u00f3 y se form\u00f3 un grupo de 7 personas. Quiz\u00e1s sea demasiado para un proyecto acad\u00e9mico, pero para distribuir roles mejor, es lo ideal. Comenz\u00f3 la discusi\u00f3n sobre ideas para el proyecto, desde 'Tomemos un proyecto ya hecho' hasta 'Emulador de formaci\u00f3n de objetos espaciales'. Pero al final, surgi\u00f3 la idea cuyo nombre ya le\u00edste en la primera imagen. <\/p>\n

Stop Procrastination \u2014 qu\u00e9 es, c\u00f3mo se utiliza y c\u00f3mo lo desarrollamos y qu\u00e9 sali\u00f3 de ello<\/h2>\n

\nLa narraci\u00f3n ser\u00e1 en primera persona, desde la perspectiva del l\u00edder del proyecto, que, por suerte o desgracia, me han nombrado a m\u00ed. Entonces, \u00bfqu\u00e9 idea se nos ocurri\u00f3? Inspirados por el popular despertador 'Shake Alarm' de SupperCommon, especialmente por la funci\u00f3n de bloquear completamente el funcionamiento del smartphone hasta que el usuario realice una determinada acci\u00f3n que, muy probablemente, lo despierte, decidimos crear una aplicaci\u00f3n similar que ayude a deshacerse de la dependencia del tel\u00e9fono, utilizando el mismo principio que el 'Shake Alarm'.<\/p>\n

Principio de funcionamiento.<\/h3>\n

El usuario establece temporizadores
\n- Tiempo que se puede pasar en el smartphone
\n- Tiempo sin smartphone (per\u00edodo de bloqueo)
\nUna vez que el temporizador ha expirado, aparece una superposici\u00f3n en la pantalla que no se puede cerrar
\n- Para cerrar la superposici\u00f3n, hay que pasar una peque\u00f1a prueba (ingresar una contrase\u00f1a en un teclado confuso, resolver un problema matem\u00e1tico, sacudir el tel\u00e9fono durante un par de minutos)
\nDespu\u00e9s de desbloquear de esta manera, el tiempo que se puede pasar en el smartphone se reduce a la mitad, y as\u00ed hasta un minuto.\n<\/p><\/blockquote>\n

Construimos un equipo<\/h3>\n

Para empezar, era necesario definir qui\u00e9n se encargar\u00eda de qu\u00e9 y en qu\u00e9 idioma se escribir\u00eda todo esto. Creo que esto tiene poco que ver con la gesti\u00f3n de proyectos, ya que cuando re\u00fanes un equipo para un proyecto real, convocas inmediatamente a aquellos que necesitas. Al final, tambi\u00e9n asum\u00ed la carga del dise\u00f1ador, eleg\u00ed a un team lead que ten\u00eda 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\u00f3n se eligi\u00f3 seg\u00fan las habilidades. Al final, se decidi\u00f3 usar Java, ya que todos los programadores estaban familiarizados con \u00e9l.<\/p>\n

Establecemos tareas<\/h3>\n

Siguiendo la recomendaci\u00f3n del profesor, se cre\u00f3 un tablero de tareas en un servicio gratuito. Trello<\/a><\/noindex>. Se plane\u00f3 trabajar bajo el sistema Scrum, donde cada stream representar\u00eda una aplicaci\u00f3n completa.
\nSin embargo, en realidad, de todo esto result\u00f3 un solo gran y largo stream, en el que se realizaban constantemente modificaciones, adiciones y correcciones. <\/p>\n

\"C\u00f3mo
\n<\/p>\n

Escribimos especificaciones<\/h3>\n

Bajo la influencia del libro de Savin \"Testing.com\", ten\u00eda en mente mi propia visi\u00f3n de c\u00f3mo deber\u00eda estar estructurado todo. Todo comenz\u00f3 con la redacci\u00f3n de especificaciones, ya que considero que sin una descripci\u00f3n clara de lo que esperamos, de qu\u00e9 y c\u00f3mo deber\u00eda funcionar, nada funcionar\u00e1. Los programadores programar\u00e1n todo como ellos ven, los testers probar\u00e1n otra cosa, el jefe esperar\u00e1 algo diferente, y al final resultar\u00e1, como siempre, algo cuaternario.
\nEscribir especificaciones no es f\u00e1cil, se deben considerar todos los detalles y matices. Por supuesto, nada sali\u00f3 bien a la primera. Al final, las especificaciones se complementaron y se rehacieron 4 veces. La \u00faltima versi\u00f3n la puedes encontrar al final del art\u00edculo, en la secci\u00f3n de enlaces. <\/p>\n

Dise\u00f1amos el dise\u00f1o<\/h3>\n

El dise\u00f1o en una aplicaci\u00f3n m\u00f3vil es lo m\u00e1s importante. Sin embargo, no todos lo entienden, incluyendo a muchos de mi equipo que discutieron apasionadamente conmigo que el dise\u00f1o no era necesario, que era la parte menos importante de la aplicaci\u00f3n, etc. No hay que ser tan ingenuo. Primero, un dise\u00f1o terminado facilita el trabajo del programador, no necesita pensar en qu\u00e9 y d\u00f3nde colocar cada cosa, simplemente toma lo que se ha dibujado y lo codifica. Junto con las especificaciones, el dise\u00f1o libera casi por completo la mente del programador de cosas innecesarias y le permite concentrarse en la l\u00f3gica. En general, primero se dibuj\u00f3 un dise\u00f1o de prototipo (horrible):<\/p>\n

\"C\u00f3mo
\n
\nPero luego el dise\u00f1o fue ajustado y llevado a una forma aceptable.
\n(Enlace a todos los elementos de dise\u00f1o al final del art\u00edculo).<\/p>\n

\"C\u00f3mo
\n<\/p>\n

Programaci\u00f3n<\/h3>\n

Programar es dif\u00edcil, pero posible. Dejar\u00e9 de lado este tema, ya que personalmente no me he involucrado en esto. Los programadores realizaron un gran trabajo, sin el cual todo ser\u00eda sin sentido. Claro que se logr\u00f3 implementar parte de las ideas. Y la aplicaci\u00f3n a\u00fan necesita mejoras. Hay muchos errores y caracter\u00edsticas que hay que corregir. Si tuvi\u00e9ramos m\u00e1s tiempo, habr\u00edamos salido de la profunda fase alfa, pero por ahora pueden probar la aplicaci\u00f3n al final del art\u00edculo.<\/p>\n

Y sobre las pruebas<\/h3>\n

\u00bfQu\u00e9 es lo m\u00e1s importante en la programaci\u00f3n? 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\u00f3 de esto puede ser visto a continuaci\u00f3n en los enlaces. <\/p>\n

Gracias por leer. Espero que hayan encontrado aqu\u00ed al menos algo \u00fatil, quiz\u00e1s una idea para su startup, o tal vez un buen consejo o herramienta.<\/p>\n

Enlaces:<\/h3>\n

\u00daltimos la especificaci\u00f3n<\/a><\/noindex>.
\nDise\u00f1o en Figma<\/a><\/noindex>.
\nCasos de prueba<\/a><\/noindex> y informes de errores<\/a><\/noindex>.<\/p>\n

La propia aplicaci\u00f3n en HokeyApp<\/a><\/noindex>. \u2014 La aplicaci\u00f3n se construy\u00f3 bajo el nombre HandsOff, ni siquiera pregunten por qu\u00e9 (porque Stop Procrastination es demasiado largo).<\/p>\n

Y al final<\/h3>\n

\u00bfQu\u00e9 piensan, tuvo todo esto sentido?<\/p>\n

Solo los usuarios registrados pueden participar en la encuesta. Inicie sesi\u00f3n<\/a><\/noindex>, por favor.<\/p>\n

\u00bfEs necesaria tal pr\u00e1ctica en las instituciones educativas y cu\u00e1n \u00fatil y aplicable es en la vida real?<\/h2>\n