Здравейте приятели,
В тази публикация ще ви запозная с част от моите задължения в компанията, в която работех по време на създаването на тази публикация, а именно IT Project Management.
Какво представлява това?
Само по себе си това е управление на проекти в областта на информационните технологии (IT). Ефективният IT Project Management включва в себе си:
- планиране на IT проекти
- организиране на IT проекти
- разпределение на отговорностите за изпълнение на всички IT проекти
- контролиране на IT проекти
Дотук нищо по-различно от типичните мениджърски функции. Но различията следва да бъдат търсени в същината на проектите, а именно тяхнното направление „информационни технологии“.
Клиентът не знае какво точно иска!
Това е основният проблем при започване на почти всеки IT проект. В най-добрият случай клиентът ще разполага с идея какво трябва да се случи, но не и как точно да стане това. Точно тук следва да се намесят представителите от IT Project Management екипа, които да му помогнат при изготвяне на точните му изисквания. Този процес спада към планирането на проекта и е наречен още Requirements Engineering. Чрез дискусии с клиента мениджмънт екипа по управлението на IT проекта следва да достигне до финални и детайлни изисквания, чието изпълнение ще доведе до желаният краен резултат.
Веднъж изготвени, тези изисквания следва да бъдат организирани както във времето, така и спрямо техният приоритет. Съвсем логично е да се започне работа по най-големите и най-приоритетни задачи като за тях следва да се отдели и повече време.
Организацията на проекта включва още групирането на изискванията в различни категории. Това е необходимо за последващото разпределение на задачите и отговорностите по тяхното изпълнение, както и за контрола над IT проекта.
Как се групират изискванията в един IT проект?
Сега ще ви запозная с Agile методологиите за IT Project Management. Най-големите по обем и мащаб изисквания следва да бъдат групирани под формата на Epics. Всички по-малки изисквания следва да бъдат групирани като User Stories и разпределени под съответния Epic, за който се отнасят. Всяко едно User Story може при необходимост да бъде разбито на малки технически задачи. За всеки Epic, User Story и Technical Task следва да отговарят точно определени членове на Development екипа (програмисти).
Това са основните групи за изискванията, но те не са единствените. Когато има готова разработка по дадено User Story, то следва да бъде тествано от Quality Assurance екипа. За целта се създават задачи тип „Testing tasks“ и те се разпределят между тестърите. Те от своя страна изготвят доклади, въз основа на които могат да се създадат „Bug tasks„, които следва да бъдат разпределени отново между членовете на development екипа. В тези задачи се описват откритите бъгове и грешки, както и друга детайлна информация, която може да помогне на програмистите да поправят своя код. Необходимо е всеки един Bug task да бъде зададен като задача на програмиста, в чиито код е открит бъга.
Когато постъпват изисквания за подобрение на кода или добавяне на изцяло нови функционалности, които не са били известни в процеса на планиране, се създават или отделни user stories или задачи тип „Improvement tasks„.
Какво още е необходимо да се направи за групираните и зададени изисквания при IT проектния мениджмънт?
Самото групиране и задаване на изискванията, за да могат те да се превърнат в задачи е само началният етап от процесите по организиране на отговорностите за изпълнението на проекта и контролът над него. Всяка задача следва да бъде измерима както във времеви план така и спрямо необходимите усилия за нейното изпълнение. За първото се предвижда ориентировъчен брой дни (или часове) за всяка задача. За второто се използва измерителят „Story Points„, като той е приложим при user stories и improvement tasks. Всеки член на екипа оценява с точки трудността на задачата. Това се прави по време на ежедневните сбирки на екипа, наречени още Scrum Meetings.
Целта им е да се установи:
- Какво е свършено предния ден;
- Какво има да се свърши днес;
- Пред какви предизвикателства е изправен екипът;
- Къде може да има евентуален проблем поради неяснота в изискванията, настъпила в последния момент и други подобни въпроси
Какви роли имат членовете на мениджмънт екипа по управление на IT проекта?
- Scrum Master – провежда ежедневните Scrum Meetings и създава изискванията в системата за управление на проекта;
- Product Owner – представител на клиента, който отговаря за предоставяне на изискванията, изясняването им и съдейства за тяхното финализиране. Пред него следва да се представи крайният продукт;
- Requirements Engineer – лице, което изготвя изискванията след получената информация от клиента;
- Project Manager – лицето, което координира процесите и изготвя финалните документации и доклади;
В зависимост от натоварването и големината на проекта и екипа е допустимо едно лице да изпълнява повече от една роля. В моя случай аз съм и Requirements Engineer и Scrum Master и Project Manager, като част от тези задачи (особено стриктно техническите) се доразпределят и между останалите членове на екипа. В крайна сметка целта е да се работи без стрес и с професионализъм, за да се предостави желаното качество на крайния продукт за клиента.
Как се организира работата времево?
Вече станаха ясни измерителите във времеви план и спрямо необходимите усилия. В Agile е прието всички готови за работа User Stories и Improvement tasks, заедно с техните технически таскове и всички бъгове да се организират в цикли. Тези цикли се наричат Sprints. Един спринт е желателно да е около 2 седмици, но по преценка на клиента и спрямо неговият план той може да достигне до 1 месец (4 работни седмици).
Всяко изискване от горепосочените типове следва да влезе в Backlog-а. Това е списък със създадените задачи, който следва да се разпредели по различните sprint-ове. За да се сформира един sprint, това означава да се спазят дефинициите за готова за разработка задача – Definition of Ready (DoR). Това са строго заложени Agile изисквания, които докато не бъдат спазени не е удачно да се сформира Sprint.
Целият Sprint се оценява въз основа на сумарните Story Points, които са предвидени за отделните задачи. Всяка задача преминава през стандартен процес (освен, ако клиентът не зададе друго изискване).
Този процес се характеризира със следните статуси:
- Open – задачата е готова, влязла в Sprint и очаква старт на работата по нея от съответния програмист;
- In Progress – по задачата вече се работи;
- Closed – задачата е готова в смисъл на приключена и е отговорила на дефинициите за това – Definition of Done (DoD). Тези дефиниции за разлика от първите се определят от самия екип – Scrum Master и Development Team и са уникални за всяка компания и проект;
- Resolved – задачата е готова по смисъла на DoD. Използва се предимно при бъгове или задачи, които са отворени отново поради възникнал в последствие проблем. Resolved статуса има следните под-статуси:
- Fixed – поправен бъг или проблем;
- Won’t Fix – задачата няма да се поправи или не е необходимо да се поправя нещо, тъй като не е имало реален проблем или бъг
- Duplicate – това е дублираща задача, на друга, която вече е готова;
- Incomplete – задачата не е описана детайлно (липсва важна информация) и следва да се коригира преди да се започне работа по нея;
- Cannot Reproduce – всички опити по приключване на задачата са провалени или отново няма достатъчно информация за нея;
- Obsolete – темата на задачата не е актуална и следователно не бива да се работи по нея;
- Rejected – изискването в тази задача няма да бъде имплементирано;
- Postponed – имплементацията ще бъде отложена;
- Outdated – проблемът не е вече актуален;
- Друг статус, който може да бъде настроен в съответната IT Project Management система;
- Re-Opened – повторно отворена задача (вж. по-горе, какво означава това);
Когато се приключи един Sprint се оценява:
- Колко задачи бяха приключени и колко се прехвърлят в следващия Sprint;
- Каква е скоростта на работа на екипа спрямо сложността на задачите;
- Имало ли е промяна на времевия обхват и обхвата измерен със Story Points – Scope Change? Това се проявява при добавяне/премахване на задачи от Sprint, когато той вече е стартирал. Не е желателно да се случва това по принцип, но на практика се налага;
- Други оценки в зависимост от системата за управление на проекта;
Когато се затворят всички задачи за съответните епици, тогава и те следва да бъдат затворени. С това проектът приключва.
Изготвят се документации в началото, по време и най-вече в края на проекта. Те се предават, заедно със Source кода на клиента.
Крайната цел е клиентът да получи качествен софтуерен продукт и същевременно development и testing екипите да подобряват своите умения с всеки следващ Sprint.
С това накратко ви представих какво представлява IT Project Management-а.
За да получите повече информация по темата, ви препоръчвам да се запознаете със следните ресурси (списъкът ще се допълва с течение на времето):
- What is Definition of Done (DoD)?
- The Definition of Ready in Scrum
- IT project management definition
- The Main Benefit of Story Points
