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

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

Нека да започнем по ред.

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

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

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

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

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

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

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

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

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

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

Определяме задачи

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

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

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

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

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

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

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

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

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

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

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

А за тестването

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

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