Предложение за процеса и изискванията за отборните проекти
Инспириран от темата за записването за Javascript apps отборните проекти, искам да изложа едни свои виждания в лицето им на предложения, как би трябвало да протече работата по отборния проект, така че ясно да се открои кой е работил и кой не и да няма субективизъм. Или както Кико каза в другата тема - да не става така, че по-силните да не оставят по-слабите да работят, а после на всичкото отгоре да излязат и да кажат, че останалите не са работили.
Минава записването. Отборите се разпределят. На всеки отбор се дава 1 ден да излъчи кандидати за "Team leader". След това на отборът се дава 1 ден да гласува за тези кандидати, като гласуването за себе си не е позволено. (Естествено има го вариантът всеки да събере един глас, тук може да се измисли нещо по-хитро?). Съответно излъчва се Team leader на отбора.
Тук трябва да има строги изисквания какъв ще е процесът, който всеки отбор трябва да следва. Основната задача, освен да пише код, на тим лидера ще е да се грижи установеният процес да работи.
Процесът, който ще предложа е инспириран от съвременните методологии за проджект мениджмънт.
Нека вземем за пример, че за отборния проект след установяване на кой ще е тим лидер остават 20 дни. От тук започва да тече и deadline-а на проекта.
20 дни се разделят на ПЕТ четиридневни итерации. Първата итерация задължително е установяване на останалите роли в проекта. След като учим HQC и Unit testing предлагам за задължително да има един QA в отбора.
Останалите ЧЕТИРИ итерации трябва да са изцяло development, testing && integrating насочени.
Според изискванията на отборния проект, например, всеки член е задължен да има по 5 къмита в 5 различни дни, тим лидерът се нагърбва с тежката задача, да разпредели достатъчно продуктивни задачи на съотборниците си, така че всяка задача да изисква поне един къмит, и така до поне 5тия къмит.
Всяка задача ТРЯБВА да се логва в тракинг системата която се ползва. В случая, ако е задължително използването на Github - в тракинг системата на гитхъб (Issues таба).
На представянето на екипния проект да може да се каже за някой съотборник, че не е участвал, САМО АКО не са успели да се свържат с него или след като са успели и е добавен към колабораторите на репозиторито и са му асайннати ПЕТ или повече валидни задачи, той НЕ Е резолвнал ПОНЕ ПЕТ от тях и съответно НЯМА ПЕТ къмита в 5 различни дни (или итерации най-добре).
Ако тимлидерът не се справи с тази задача, отборът може да излъчи чисто демократично друг такъв. Ако отборният проект фейлне заради лоша организация от към тим лидер, виновни са всички - за избирането на такъв тим лидер и за неуспешното избиране на нов такъв.
За цялостното оценяване на проекта да се гледа не само крайния продукт, но и процесът на работа, след като всичко ще се траква в тикети, разпределени в итерации, да се гледа дали срокът на итерациите а спазен и други неща, които говорят за успешното или съответно неуспешното сработване на отборите.
Също така може да се види какви точно са били разпределени задачите, и дали на някого не му е разпределено просто да ъпдейтва README.md с по 1 символ на таск.
Ако смятате, че идеята с подобен проектов мениджмънт ще е трудна да се реализира заради например недостатъчно опит на участващите, предлагам да се организира кратък курс по Съвременни практики за управление на проекти, с времетраенето на Javascript OOP курса.
Кико, мисля, че да, ако имахме team leader щяхме да се хванем по-рано за работа и да направим нещо по-завършено. НО, според мен, този вариант е:
- доста теоретичен. Както много хора казаха преди мен, не винаги има доброволци да са тийм лийдъри и всъщност точно това се случи при нас - нямаше някой желаещ да загуби страшно много време в разпределяне на задачи и помагане на по-слабите (ако предположим, че TL е с опит).
- по-скоро вреден за успеха. Работата по проектите никога не ми е носила толкова знания, колкото домашните. Не за първи път казвам ,че се записвам на отборна работа не за да си науча материала от курса, а за да се ориентирам как се работи по по-голям проект (да дълбаеш чуждия код, да недоумяваш какво са правили нинджите и да се научиш да не се панираш и комплексираш като се сравняваш с тях). За мен, тъй като съм начинаеща и всеки курс ми носи абсолютна нова информация, отборните проекти са нещо второстепенно. Не в смисъла на по-маловажни, а в смисъла на нещо, което идва второ. Както покрива е безспорно важен за една къща, но ако няма основи - ходи слагай покрива! Ако имаше някой, който да ме насилва да работя през целия срок на курса основно по проекта, научила-недонаучила, на изпита щях да имам по-нисък резултат. То и затова според мен хората бачкат по проекта основно в последните дни. Така е по-добре, струва ми се, всеки да си преценява силите, кога е готов и може с нещо да помогне.
(В тази връзка, браво на колегите, които са предложили на Наков за настоящия курс по JS Aps да изнесе същественото (BaaS-a) като второ домашно!)
С други думи, аз не искам да имаме назначени тийм лийдъри, още по-малко пък искам мен да ме назначат за такъв! Просто нямам време за това, а и не мисля, че е от полза. Е, ако съм на работа, няма не искам и друг решава, кое е полезно за фирмата :)
Хайде и от мен един въпрос: нали правите нещо подобно на TL в присъствените отбори с менторите, как е там?
Менторите са само теоретични тим лидери. Много от нещата, които един тим лидер трябва да изпълнява на тях по правило са им забранени. А останалите пожелателни неща, някои от тях не ги и вършат. Например първият ни ментор се отнесе много несериозно.
P.S.: Дори мешаницата по кода, в която ти се налага да се ориентираш (което смяташ за полезно, всъщност, и безспорно е, де...) може да се менажира и да е по-малко, ако тим лидерът се постарае да разпредели така задачите, че да няма някакви огромни колизии или gap-ове.
@Кико, всъщност огромният проблем е това сещане да се работи последните дни. Някак си ми се иска да се избегне и да се отдаде повече важност на екипните проекти. Честно казано нямам конкретно теоретическо решение как да стане. До колкото до това дали има хора с такива качества и то достатъчно много - ами може би наистина няма, но това нез начи, че няма да се развият впоследствие.