Как се опитвахме да работим в екип и какво излезе от това

Нека да започнем отначало

Какво означава тази рисунка малко по-късно, а в момента нека започна с въведението.

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

Искам да изживеете всички трудности на екипната работа, разделете се на групи, помислете за проект, назначете ръководител и преминете заедно през всички етапи на проектиране. В края очаквам от вас готов продукт и статия в Хабра.

Тук започва нашата история. Както топки в билярд, ние се отблъсквахме един от друг, докато енергията на удара не се разсее и заедно не се събрахме в група от 7 души. Може би за учебен проект това е твърде много, но за по-добро разпределение на ролите е точното. Започна обсъждане на идеи за проекта от „Нека вземем готов проект“ до „Емулатор за формиране на космически обекти“. Но в крайна сметка премина идеята, чието име прочетохте на първото изображение.

Stop Procrastination — какво е това, с какво се яде и как го разработихме и какво излезе от това

Разказът ще бъде от името на ръководителя на проекта, който по щастие или нещастие бях назначен аз. И така, каква идея ни хрумна? Вдъхновени от популярния будилник „Shake Alarm“ от SupperCommon, а именно функцията за напълно блокиране на работа на смартфона, докато потребителят не извърши определено действие, което вероятно ще го накара да се събуди, решихме да създадем подобно приложение, което да помогне да се освободим от телефонната зависимост, по същия принцип, както „Shake Alarm“

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

Потребителят настройва таймери
- Време, което може да се прекарва на смартфона
- Време без смартфон (период на блокиране)
След изтичане на таймера на екрана се появява overlay, който не може да бъде затворен
- За да затворите overlay, трябва да преминете през малко изпитание (да въведете парола на заплетена клавиатура, да решите математическа задача, да разклатите телефона за няколко минути)
След като се отключи по този начин, времето, което може да се прекара на смартфона, се намалява наполовина, и така до една минута.

Създаваме екип

Първо трябваше да определим кой с какво ще се занимава и на какъв език всичко това ще бъде написано. Мисля, че това има малко общо с управлението на проекти, тъй като когато събираш екип за реален проект, веднага събираш нужните хора. В крайна сметка на мен ми беше възложено и дизайнера, избрах един тимлид с добър опит в разработката на приложения, на когото бяха подчинени трима програмисти, а още двама станаха тестировчици. Разбира се, езикът за програмиране беше избран според уменията. В крайна сметка беше решено да се използва Java, тъй като всички програмисти бяха запознати с него.

Поставяме задачи

По препоръка на учителя беше създадена дъска с задачи на безплатния сервис Trello. Планирано беше да работим по системата Скрам, където всеки стрийм ще представлява завършено приложение.
Но на практика от всичко това излезе един дълъг стрийм, в който постоянно се внасяха корекции, допълнения и поправки.

Пишем спецификации

Под влиянието на книгата на Савин "Тестироване.com", имах представа как всичко трябва да бъде устроено. Всичко започна с написването на спецификации, тъй като смятам, че без ясно описание на това, което очакваме, как и какво трябва да работи, нищо няма да проработи. Програмистите ще програмират всичко, както го виждат, тестировчиците ще тестват нещо друго, ръководителят ще очаква трето, а всъщност ще се получи четвърто.
Да се пишат спецификации не е лесно, трябва да се обмислят всички детайли, всички нюанси. Разбира се, от първия път нищо не се получи. В крайна сметка спецификациите бяха допълвани и преработвани 4 пъти. Последният вариант можете да намерите в края на статията, в раздела за връзки.

Рисуваме дизайн

Дизайнът в мобилното приложение е най-важният елемент. Въпреки това, не всички го осъзнават, включително и много от моя екип, които яростно спореха с мен, че дизайнът не е необходим, че това е най-маловажната част от приложението и така нататък. Не бива да бъдете толкова наивни. На първо място, готовият дизайн улеснява работата на програмиста, той не трябва да мисли къде и какво да сложи, а просто взима и реализира това, което е нарисувано. Заедно със спецификациите, дизайнът почти изцяло освобождава ума на програмиста от ненужни неща и му дава възможност да се съсредоточи върху логиката. Общото е, че първо беше нарисуван прототипен (ужасен) дизайн:

Но след това дизайнът беше оправен и приведен в нормален вид.
(Връзка към всички елементи на дизайна в края на статията).

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

Програмирането е сложно, но възможно. Пропускам този момент, тъй като лично не съм се занимавал с него. Програмите бяха извършени от програмисите, без които всичко щеше да бъде безсмислено. Разбира се, успяхме да реализираме част от идеите. Но програмата все още се нуждае от доработка. Много бъгове и функции, които трябва да бъдат отстранени. Ако имахме повече време, щяхме да излезем от дълбоката алфа, а засега можете да тествате приложението в края на статията.

И малко за тестването

Какво е най-важното в програмирането? По мое мнение, най-важното е всичко да работи и да изглежда така, както трябва. Както трябва, не се получава винаги и не веднага. За това е необходимо тестване. На моите тестировчици предложих модел на тестване с използване на тест-кейсове. Първо се пишат тест-кейсове в съответствие със спецификациите, а след това се провежда тестване по тях. Какво излезе от това можете да видите по-долу в линковете.

Благодаря, че прочетохте. Надявам се, че сте намерили нещо полезно тук, може би идея за вашия стартъп или полезен съвет или инструмент.

Връзки:

Последни спецификация.
Дизайнът в Figma.
Тест-кейсове и бъг репорти.

Самото приложение на HokeyApp. — Приложението беше билдвано под името HandsOff, даже не питайте защо (защото Stop Procrastination е твърде дълго).

И накрая

Как мислите, имаше ли всичко това смисъл?

Само регистрирани потребители могат да участват в анкетата. Влезте, моля.

Нужна ли е такава практика в учебните заведения и колко е полезна и приложима в реалния живот?

• Нужна е, безценен опит.

• Нужна е, макар и опитът да е малко.

• Почти безполезна, максимум ще разбереш общите черти на работата в екип.

• Празна загуба на време и усилия.

Гласували 2 потребителя. Няма въздържали се.

Източник: habr.com