Come abbiamo cercato di lavorare in squadra e cosa ne è uscito.

Come abbiamo cercato di lavorare in squadra e cosa ne è uscito.

Procediamo in ordine

Spiegherò che cosa significa questa immagine più tardi, ma ora permettetemi di iniziare con un'introduzione.

In un freddo giorno di febbraio, nulla preannunciava problemi. Un gruppo di studenti innocenti si era presentato per la prima volta a una lezione di un corso chiamato "Metodologia dell'organizzazione della progettazione e dello sviluppo dei sistemi informativi". Era una lezione comune, il docente parlava dei metodi agili, come Scrum, e nulla sembrava sospetto. E così, verso la fine, il docente annuncia:

Desidero che sperimentiate le difficoltà del lavoro di squadra. Dividetevi in gruppi, ideate un progetto, nominate un leader e affrontate insieme tutte le fasi della progettazione. Alla fine, mi aspetto un prodotto finito e un articolo su Habr.

Ecco dove inizia la nostra storia. Come palle da biliardo, rimbalzavamo l'uno contro l'altro finché l'energia dell'impatto non si è dissipata e ci siamo riuniti in un gruppo di 7 persone. Forse per un progetto di apprendimento è un numero eccessivo, ma è l'ideale per meglio distribuire i ruoli. È iniziata una discussione sulle idee per il progetto, spaziando da "Prendiamo un progetto già pronto" a "Un emulatore per la formazione di oggetti spaziali". Ma alla fine è emersa l'idea il cui nome avete letto nella prima immagine.

Stop Procrastination — cos'è, come funziona e come lo abbiamo sviluppato e cosa ne è venuto fuori

La narrazione sarà fatta dalla prospettiva del project manager, che per fortuna o sfortuna è stato nominato proprio me. E quindi, quale idea ci è venuta in mente? Ispirandoci al popolare sveglia "Shake Alarm" di SupperCommon, in particolare alla funzione di bloccare completamente il funzionamento dello smartphone finché l'utente non compie un'azione specifica che probabilmente lo farà svegliare, abbiamo deciso di creare un'app simile che aiuti a liberarsi della dipendenza da telefono, seguendo lo stesso principio di "Shake Alarm".

Principio di funzionamento

L'utente imposta i timer
-Tempo che si può trascorrere con lo smartphone
-Tempo senza smartphone (periodo di blocco)
Dopo il timer, appare un overlay sullo schermo che non può essere chiuso
-Per chiudere l'overlay è necessario superare una piccola prova (inserire una password su una tastiera confusa, risolvere un problema matematico, scuotere il telefono per qualche minuto)
Dopo lo sblocco in questo modo, il tempo che si può passare con lo smartphone si riduce della metà, e così fino a un minuto

Costruendo un team

Innanzitutto, era necessario determinare chi si occuperebbe di cosa e in quale linguaggio tutto questo sarebbe stato scritto. Penso che questo abbia poco a che fare con la gestione dei progetti, poiché quando si forma un team per un progetto reale, ci si circonda già delle persone necessarie. Alla fine ho preso anche l'onere del design, ho scelto un team leader che avesse una buona esperienza nello sviluppo di applicazioni, a lui sono stati assegnati tre programmatori, e altri due sono diventati tester. Certamente, il linguaggio di programmazione è stato scelto in base alle competenze. Alla fine, si è deciso di utilizzare Java, poiché tutti i programmatori lo conoscevano.

Assegniamo compiti

Su raccomandazione del docente, è stata creata una board di task su un servizio gratuito Trello. Era previsto lavorare secondo il sistema Scrum, dove ogni stream avrebbe rappresentato un'applicazione finita.
Tuttavia, nella realtà, tutto ciò si è trasformato in un lungo stream unico, nel quale venivano costantemente apportate modifiche, integrazioni e correzioni.

Come abbiamo cercato di lavorare in squadra e cosa ne è uscito.

Scriviamo le specifiche

Sotto l'influenza del libro di Savin «Testing.com», avevo in mente la mia idea di come tutto dovesse essere strutturato. Tutto è iniziato con la stesura delle specifiche; senza una descrizione chiara di ciò che ci aspettiamo, di come e cosa dovrebbe funzionare, nulla funzionerà. I programmatori programmeranno tutto secondo la loro visione, i tester testeranno altro, il responsabile si aspetterà qualcos'altro e alla fine si avrà sempre un risultato diverso.
Scrivere le specifiche non è facile, è necessario pensare a tutti i dettagli, a tutte le sfumature. Certamente, la prima volta non è andata bene. Alla fine, le specifiche sono state aggiunte e riscritte 4 volte. L'ultima versione può essere trovata alla fine dell'articolo, nella sezione link.

Disegniamo il design

Il design nell'app mobile è fondamentale. Tuttavia, non tutti lo comprendono, compresi molti nella mia squadra che hanno combattuto strenuamente con me, sostenendo che il design non è necessario, che è la parte meno importante dell'applicazione, e così via. Non bisogna essere così ingenui. Innanzitutto, un design ben fatto facilita il lavoro del programmatore, che non deve pensare a cosa e dove inserire, ma può semplicemente prendere e realizzare ciò che è stato disegnato. Insieme alle specifiche, il design libera quasi completamente la mente del programmatore da elementi superflui, permettendogli di concentrarsi sulla logica. Inizialmente è stato disegnato un prototipo (orrendo) del design:

Come abbiamo cercato di lavorare in squadra e cosa ne è uscito.

Ma poi il design è stato perfezionato e portato a uno stato normale.
(Link a tutti gli elementi del design alla fine dell'articolo).

Come abbiamo cercato di lavorare in squadra e cosa ne è uscito.

Programmiamo

Programmare è difficile, ma si può fare. Tralascerò questo aspetto, poiché non ho esperienza personale in merito. Gli sviluppatori hanno fatto un lavoro enorme, senza il quale tutto sarebbe stato vano. Certamente sono riusciti a realizzare parte delle idee. Tuttavia, il programma ha ancora bisogno di perfezionamenti. Ci sono molti bug e funzionalità da rimuovere. Se avessimo avuto più tempo, saremmo emersi da una profonda fase alfa, ma nel frattempo puoi testare l'applicazione alla fine dell'articolo.

E ora sul testing

Cosa è fondamentale nella programmazione? A mio avviso, la cosa più importante è che tutto funzioni e appaia come dovrebbe. Non sempre è così e non accade subito. Per questo serve il testing. Ai miei tester, ho proposto un modello di test basato su casi di test. Inizialmente vengono scritti i casi di test in piena conformità con le specifiche, e poi si svolge il testing. Puoi vedere il risultato di quanto fatto nei link qui sotto.

Grazie per aver letto. Spero che tu abbia trovato almeno qualcosa di utile, forse un'idea per il tuo startup, o magari un buon consiglio o uno strumento.

Link:

Ultimi specifiche.
Design su Figma.
Casi di test e bug report.

L'applicazione stessa su HokeyApp. — L'applicazione è stata costruita con il nome HandsOff, non chiedetemi perché (perché Stop Procrastination è troppo lungo).

E infine

Cosa ne pensate, ha avuto senso tutto questo?

Solo gli utenti registrati possono partecipare al sondaggio. Accedi, per favore.

È utile avere questa pratica nelle istituzioni educative e quanto è applicabile nella vita reale?

  • Sì, è un'esperienza preziosa

  • Sì, anche se con poca esperienza

  • Quasi inutile, al massimo capirai le caratteristiche generali del lavoro in team

  • Una perdita di tempo e energie

Hanno votato 2 utenti. Nessun astenuto.

Fonte: habr.com

Acquista hosting affidabile per siti web con protezione DDoS, VPS VDS server 🔥 Acquista hosting affidabile per siti web con protezione DDoS, VPS VDS server | ProHoster