Како се обидовме со тимска работа и што излезе од неа

Да го земеме во ред

Што значи оваа слика малку подоцна, но засега да почнам со воведот.

Во студениот февруарски ден немаше знаци на неволја. Група невини студенти првпат дојдоа да одат на час на тема што решија да ја наречат „Методологија за организирање дизајн и развој на информациски системи“. Имаше редовно предавање, наставникот зборуваше за флексибилни развојни методи, како што е Scrum, ништо не навестуваше проблеми. И на крајот наставникот објавува:

Сакам сами да ги искусите сите тешкотии на тимската работа, да се делите во групи, да смислите проект, да назначите лидер и заедно да ги поминете сите фази на дизајнирање. На крајот, очекувам од вас готов производ и статија за Habré.

Ова е местото каде што започнува нашата приказна. Како топки во билијард, се одбивме еден од друг додека енергијата на ударот не се потроши и не се собра група од 7 луѓе. Можеби ова е премногу за проект за обука, но правилно е подобро да се распределат улогите. Започна дискусијата за идеи за проектот, од „Ајде да земеме готов проект“ до „Емулатор за формирање на вселенски објекти“. Но, на крајот дојде идејата, чие име го прочитавте на првата слика.

Стоп за одложување - што е тоа, со што се јаде и како го развивме и што излезе од тоа

Приказната ќе биде раскажана во име на раководителот на проектот, кој, за среќа или за жал, ми беше доделен. Па, каква идеја ни дојде на ум? Инспирирани од популарниот будилник „Shake Alarm Clock“ од SupperCommon, поточно функцијата за целосно блокирање на паметниот телефон додека корисникот не изврши одредена акција што најверојатно ќе предизвика негово будење, решивме да создадеме слична апликација која ќе помогне да се ослободете се од зависноста од телефонот, на истиот принцип како „Протресете го будилникот“

Принцип на работа

Корисникот поставува тајмери
-Време што може да се потроши на паметен телефон
-Време без паметен телефон (период на блокирање)
Кога ќе истече тајмерот, на екранот се појавува преклоп што не може да се минимизира
-За да го затворите преклопот, треба да поминете низ мал тест (внесете лозинка на збунувачка тастатура, решите математички проблем, протресете го телефонот неколку минути)
По ваквото отклучување, времето што може да се потроши на смартфонот се преполови и така до една минута.

Градење тим

Прво, требаше да се одреди кој што ќе прави и на кој јазик сето ова ќе биде напишано. Мислам дека ова нема многу врска со управувањето со проекти, бидејќи кога ќе соберете тим за вистински проект, веднаш ги собирате оние што ви требаат. Како резултат на тоа, го презедов и товарот на дизајнер, избрав еден тим менаџер кој имаше добро искуство во развој на апликации, му беа доделени тројца програмери, а уште двајца станаа тестери. Се разбира, програмскиот јазик беше избран врз основа на вештините. Како резултат на тоа, беше одлучено да се користи Java, бидејќи сите програмери беа запознаени со тоа.

Поставување задачи

По препорака на наставникот беше креирана табла за задачи на бесплатна услуга Trello. Планирано беше да се работи според системот Scrum, каде секој стрим би бил еден вид комплетна апликација.
Меѓутоа, реално сето тоа произлезе од еден голем и долг поток, на кој постојано се правеа уредувања, дополнувања и корекции.

Ние пишуваме спецификации

Под влијание на книгата на Савин „Testing.com“, имав своја идеја во мојата глава за тоа како сè треба да биде уредено. Се започна со пишување спецификации, како што верувам, без јасен опис што очекуваме, што и како треба да работи, ништо нема да работи. Програмерите ќе програмираат сè како што ќе видат, тестерите ќе тестираат нешто друго, менаџерот го очекуваше третото, но ќе испадне четврто како и секогаш.
Пишувањето спецификации не е лесно, треба да размислите низ сите детали, сите нијанси. Се разбира, ништо не функционираше првиот пат. Како резултат на тоа, спецификациите беа дополнети и преработени 4 пати. Последната опција можете да ја најдете на крајот од статијата, во делот за врски.

Цртање дизајн

Дизајнот во мобилната апликација е најважната работа. Сепак, не секој го разбира ова, вклучително и од мојот тим, многумина жестоко се расправаа со мене дека дизајнот не е потребен, дека ова е најневажниот дел од апликацијата итн. Не треба да си толку наивен. Прво, готовиот дизајн ја олеснува работата на програмерот; тој не мора да размислува што да стави и каде, тој само зема и го напише она што е нацртано. Заедно со спецификациите, дизајнот речиси целосно го ослободува умот на програмерот од непотребни работи, и му дава можност да се концентрира на логиката. Во принцип, прво беше нацртан прототип (страшен) дизајн:

Но, тогаш дизајнот беше исчешлан и вратен во нормала.
(Линк до сите елементи на дизајнот на крајот од статијата).

Програмирање

Програмирањето е тешко, но можно. Ќе ја испуштам оваа точка, бидејќи лично не сум се занимавал со ова. Програмерите направија огромна работа, без која сè ќе беше бесмислено. Секако, успеавме да реализираме дел од нашите идеи. И програмата сè уште има потреба од подобрување. Има многу грешки и функции што треба да се отстранат. Да имавме повеќе време, ќе излеземе од длабоката алфа, но засега можете да ја тестирате апликацијата на крајот од статијата.

Па, за тестирање

Што е главната работа во програмирањето? Според мое мислење, главната работа е дека сè работи и изгледа како што треба. Не секогаш функционира како што треба и не веднаш. Ова бара тестирање. На моите тестери им предложив модел за тестирање користејќи тест случаи. Прво, тест случаите се напишани во целосна согласност со спецификациите, а потоа се врши тестирање на нив. Можете да видите што излезе од ова на линковите подолу.

Ви благодариме за читањето. Се надевам дека најдовте барем нешто корисно овде, можеби идеја за вашиот стартап, или можеби некој добар совет или алатка.

Референци:

Најнови спецификации.
Дизајн на Фигма.
Тест случаи и извештаи за грешки.

Самата апликација е вклучена HokeyApp. — Апликацијата е изградена под името HandsOff, не прашувајте зошто (бидејќи Стоп за одложување е предолго).

Па на крајот

Дали мислите дека сето ова има смисла?

Само регистрирани корисници можат да учествуваат во анкетата. Најави се, вие сте добредојдени.

Дали е потребна ваква практика во образовните институции и колку е корисна и применлива во реалниот живот?

• Потребно, непроценливо искуство

• Потребно, иако малку искуство

• Речиси бескорисни, најмногу ќе ги разберете општите карактеристики на работата во тим

• Губење на време и напор

Гласаа 2 корисници. Нема воздржани.

Извор: www.habr.com