Anem en ordre
Què significa aquesta imatge una mica més endavant, però de moment permeteu-me començar amb la introducció.
En un fred dia de febrer no hi havia signes de problemes. Un grup d'estudiants innocents va venir per primera vegada a fer una classe sobre un tema que van decidir anomenar “Metodologia per organitzar el disseny i desenvolupament de sistemes d'informació”. Hi havia una conferència regular, el professor parlava de mètodes de desenvolupament flexibles, com Scrum, res no presagiava problemes. I al final el professor anuncia:
Vull que experimenteu vosaltres mateixos totes les dificultats del treball en equip, us dividiu en grups, elaboreu un projecte, nomeneu un líder i passeu junts totes les etapes de disseny. Al final, espero de vosaltres un producte acabat i un article sobre Habré.
Aquí és on comença la nostra història. Com boles de billar, vam rebotar els uns als altres fins que l'energia de l'impacte es va dissipar i un grup de 7 persones es va reunir. Potser això és massa per a un projecte de formació, però és correcte distribuir millor els rols. Va començar una discussió d'idees per al projecte, des de "Agafem un projecte ja fet" fins a "Emulador per a la formació d'objectes espacials". Però al final va sorgir la idea, el nom del qual llegiu a la primera imatge.
Atura la procrastinació: què és, amb què es menja i com l'hem desenvolupat i què en va sortir
La història s'explicarà en nom del responsable del projecte, que, per sort o per desgràcia, em va assignar. Aleshores, quina idea ens va venir al cap? Inspirats en el popular rellotge despertador "Shake Alarm Clock" de SupperCommon, és a dir, la funció de bloquejar completament el telèfon intel·ligent fins que l'usuari realitza una determinada acció que probablement farà que es desperta, vam decidir crear una aplicació similar que ajudarà a aconseguir desfer-se de l'addicció al telèfon, amb el mateix principi que "Shake the Alarm Clock"
Com funciona?
L'usuari estableix temporitzadors
-Temps que es pot passar en un telèfon intel·ligent
- Temps sense telèfon intel·ligent (període de bloqueig)
Quan el temporitzador expira, apareix una superposició a la pantalla que no es pot minimitzar
-Per tancar la superposició, heu de fer una petita prova (introduïu una contrasenya en un teclat confús, resoleu un problema de matemàtiques, sacseja el telèfon durant un parell de minuts)
Després de desbloquejar d'aquesta manera, el temps que es pot passar al telèfon intel·ligent es redueix a la meitat, i així fins a un minut.
Construir un equip
En primer lloc, calia determinar qui faria què i en quina llengua s'escriuria tot això. Crec que això té poc a veure amb la gestió de projectes, perquè quan formes un equip per a un projecte real, de seguida es reuneix aquells que necessites. Com a resultat, també vaig assumir la càrrega d'un dissenyador, vaig triar un cap d'equip amb bona experiència en el desenvolupament d'aplicacions, se li van assignar tres programadors i dos més es van convertir en provadors. Per descomptat, el llenguatge de programació es va escollir en funció de les habilitats. Com a resultat, es va decidir utilitzar Java, ja que tots els programadors el coneixien.
Establiment de tasques
Per recomanació del professor, es va crear un tauler de tasques en un servei gratuït . Estava previst que funcionés segons el sistema Scrum, on cada flux seria una mena d'aplicació completa.
Tanmateix, en realitat, tot això va sorgir d'un sol gran i llarg, al qual es feien constantment edicions, addicions i correccions.
Escrivim especificacions
Influenciat pel llibre de Savin "Testing.com", tenia la meva pròpia idea al cap de com s'havia d'organitzar tot. Tot va començar amb l'escriptura d'especificacions, com crec, sense una descripció clara del que esperem, què i com hauria de funcionar, res funcionarà. Els programadors programaran tot tal com ho veuen, els provadors provaran una altra cosa, el gerent esperava el tercer, però serà el quart com sempre.
Escriure especificacions no és fàcil, cal pensar en tots els detalls, tots els matisos. Per descomptat, res va funcionar la primera vegada. Com a resultat, les especificacions es van completar i es van refer 4 vegades. Podeu trobar l'última opció al final de l'article, a l'apartat d'enllaços.
Dibuixant un disseny
El disseny en una aplicació mòbil és el més important. Tanmateix, no tothom ho entén, inclòs el meu equip, molts em van argumentar amb vehemència que el disseny no és necessari, que aquesta és la part menys important de l'aplicació, etc. No hauries de ser tan ingenu. En primer lloc, un disseny ja fet facilita la feina del programador; no ha de pensar què posar on i on, només agafa i tipeja el que està dibuixat. Juntament amb les especificacions, el disseny allibera gairebé completament la ment del programador de coses innecessàries i li dóna l'oportunitat de concentrar-se en la lògica. En general, primer es va dibuixar un prototip (terrible):
Però després el disseny es va pentinar i es va tornar a la normalitat.
(Enllaç a tots els elements de disseny al final de l'article).
Programació
La programació és difícil, però possible. Ometré aquest punt, ja que no m'he ocupat personalment d'això. Els programadors van fer una gran quantitat de treball, sense la qual tot no hauria tingut sentit. Per descomptat, hem aconseguit fer realitat algunes de les nostres idees. I el programa encara necessita millores. Hi ha molts errors i funcions que cal eliminar. Si tinguéssim més temps, sortiríem de l'alfa profund, però de moment podeu provar l'aplicació al final de l'article.
Bé, sobre les proves
Què és el més important en la programació? Al meu entendre, el més important és que tot funcioni i es vegi com hauria de ser. No sempre surt bé i no de seguida. Això requereix proves. Als meus provadors, vaig proposar un model de prova amb casos de prova. En primer lloc, els casos de prova s'escriuen d'acord amb les especificacions i, a continuació, es realitzen proves sobre ells. Podeu veure què en va sortir als enllaços següents.
Gràcies per llegir. Espero que hàgiu trobat almenys alguna cosa útil aquí, potser una idea per a la vostra posada en marxa, o potser un bon consell o una eina.
Enllaços:
Més nou .
Disseny en marxa .
и .
L'aplicació en si està activada . — L'aplicació es va crear amb el nom de HandsOff, ni tan sols pregunteu per què (perquè Stop Procrastination és massa llarg).
Bé al final
Creus que tot això tenia sentit?
Només els usuaris registrats poden participar en l'enquesta. si us plau.
És necessària aquesta pràctica a les institucions educatives i fins a quin punt és útil i aplicable a la vida real?
-
Experiència necessària, inestimable
-
Necessari, encara que una mica d'experiència
-
Gairebé inútil, com a molt entendreu les característiques generals del treball en equip
-
Una pèrdua de temps i esforç
Han votat 2 usuaris. No hi ha abstencions.
Font: www.habr.com