Como probamos o traballo en equipo e que resultou

Tomemos isto en orde

Que significa esta imaxe un pouco máis tarde, pero de momento permíteme comezar coa introdución.

Nun frío día de febreiro non había sinais de problemas. Un grupo de estudantes inocentes veu por primeira vez a tomar unha clase sobre unha materia que decidiron denominar “Metodoloxía para organizar o deseño e desenvolvemento de sistemas de información”. Había unha charla regular, o profesor falou de métodos de desenvolvemento flexibles como Scrum, nada presaxiaba problemas. E ao rematar o profesor anuncia:

Quero que experimentes ti mesmo todas as dificultades do traballo en equipo, que te divídase en grupos, que dea un proxecto, que designe un líder e que pase por todas as fases do deseño xuntos. Ao final, espero de ti un produto acabado e un artigo sobre Habré.

Aquí é onde comeza a nosa historia. Como bolas de billarda, botamos uns nos outros ata que se disipou a enerxía do impacto e xuntámonos un grupo de 7 persoas. Quizais isto sexa demasiado para un proxecto de formación, pero é correcto distribuír mellor os papeis. Comezou unha discusión de ideas para o proxecto, desde "Let's take a ready-made project" ata "Emulator for the formation of space objects". Pero ao final xurdiu a idea, cuxo nome ledes na primeira imaxe.

Detén a procrastinación: que é, con que se come e como o desenvolvemos e que resultou

A historia será contada en nome do director do proxecto, que, por sorte ou por desgraza, foi asignado a min. Entón, que idea veunos á cabeza? Inspirados no popular reloxo espertador "Shake Alarm Clock" de SupperCommon, é dicir, a función de bloquear completamente o teléfono intelixente ata que o usuario realice unha determinada acción que probablemente o faga espertar, decidimos crear unha aplicación similar que axudará a conseguir librar da adicción ao teléfono, co mesmo principio que "Axita o espertador"

Principio de funcionamento

O usuario establece temporizadores
-Tempo que se pode gastar nun smartphone
- Tempo sen un teléfono intelixente (período de bloqueo)
Cando expira o temporizador, aparece unha superposición na pantalla que non se pode minimizar
-Para pechar a superposición, cómpre facer unha pequena proba (introducir un contrasinal nun teclado confuso, resolver un problema de matemáticas, axitar o teléfono durante un par de minutos)
Despois de desbloquear deste xeito, o tempo que se pode gastar no smartphone redúcese á metade, e así ata un minuto.

Construíndo un equipo

En primeiro lugar, era necesario determinar quen faría que e en que lingua se escribiría todo isto. Creo que isto ten pouco que ver coa xestión de proxectos, porque cando montas un equipo para un proxecto real, inmediatamente reúnes aos que necesitas. Como resultado, tamén asumín a carga dun deseñador, escollín un xefe de equipo que tiña boa experiencia no desenvolvemento de aplicacións, asignáronlle tres programadores e dous máis convertéronse en probadores. Por suposto, a linguaxe de programación escolleuse en función das habilidades. Como resultado, decidiuse usar Java, xa que todos os programadores estaban familiarizados con el.

Establecemento de tarefas

Por recomendación do profesor, creouse un taboleiro de tarefas nun servizo gratuíto Trello. Estaba previsto que funcionase segundo o sistema Scrum, onde cada fluxo sería unha especie de aplicación completa.
Non obstante, en realidade, todo isto saíu dun fluxo grande e longo, ao que se facían constantemente edicións, engadidos e correccións.

Escribimos especificacións

Influenciado polo libro de Savin "Testing.com", tiña a miña propia idea na miña cabeza de como se debería organizar todo. Todo comezou coa escritura de especificacións, como creo, sen unha descrición clara do que esperamos, que e como debería funcionar, nada funcionará. Os programadores programarán todo tal e como o ven, os probadores probarán outra cousa, o xestor esperaba o terceiro, pero será o cuarto coma sempre.
Escribir especificacións non é doado, hai que pensar en todos os detalles, en todos os matices. Por suposto, nada funcionou a primeira vez. Como resultado, as especificacións foron completadas e refixadas 4 veces. Podes atopar a última opción ao final do artigo, na sección de ligazóns.

Debuxar un deseño

Deseño nunha aplicación móbil é o máis importante. Non obstante, non todos o entenden, incluso dende o meu equipo, moitos argumentaron comigo con vehemencia que o deseño non é necesario, que esta é a parte máis sen importancia da aplicación, etc. Non deberías ser tan inxenuo. En primeiro lugar, un deseño preparado facilita o traballo do programador; non ten que pensar en que poñer onde e onde, só toma e tipografía o que está debuxado. Xunto coas especificacións, o deseño libera case completamente a mente do programador de cousas innecesarias e dálle a oportunidade de concentrarse na lóxica. En xeral, primeiro deseñouse un prototipo (terrible):

Pero entón o deseño foi peiteado e volveu á normalidade.
(Ligazón a todos os elementos de deseño ao final do artigo).

Programación

Programar é difícil, pero posible. Omitirei este punto, xa que eu non o tratei persoalmente. Os programadores fixeron unha gran cantidade de traballo, sen o cal todo non tería sentido. Por suposto, conseguimos facer realidade algunhas das nosas ideas. E o programa aínda ten que mellorar. Hai moitos erros e funcións que hai que eliminar. Se tivésemos máis tempo, sairíamos do alfa profundo, pero de momento podes probar a aplicación ao final do artigo.

Ben, sobre as probas

Cal é o principal na programación? Na miña opinión, o principal é que todo funcione e se ve como debería. Non sempre funciona ben e non de inmediato. Isto require probas. Aos meus probadores propúxenlle un modelo de proba utilizando casos de proba. En primeiro lugar, os casos de proba escríbense de acordo coas especificacións e, a continuación, realízanse as probas. Podes ver o que saíu disto nas seguintes ligazóns.

Grazas por ler. Espero que atopes polo menos algo útil aquí, quizais unha idea para a túa posta en marcha, ou quizais algún bo consello ou unha ferramenta.

Referencias:

Última especificacións.
Deseño activado figma.
Casos de proba и informes de erros.

A aplicación en si está activada HokeyApp. — A aplicación construíuse co nome HandsOff, nin sequera pregunte por que (porque Deter a procrastinación é demasiado longa).

Pois ao final

Cres que todo isto tiña sentido?

Só os usuarios rexistrados poden participar na enquisa. Rexístrate, por favor.

É necesaria esa práctica nas institucións educativas e que tan útil e aplicable é na vida real?

• Necesaria, experiencia inestimable

• Necesítase, aínda que un pouco de experiencia

• Case inútil, como moito entenderás as características xerais do traballo en equipo

• Unha perda de tempo e esforzo

Votaron 2 usuarios. Non hai abstencións.

Fonte: www.habr.com