Потребителска история
Потребителските истории са ефективен начин за заявяване на изискванията за софтуер в процес на разработка. Такива истории съдържат кратки съвети от името на потребителя на софтуера.
Тъй като в методологията на Scrum поставянето на цели обикновено е прерогатив на клиента or собственика на софтуера, те се считат за основния начин за влияние върху процеса на разработка. Всяка потребителска история има ограничение в количеството текст и сложността на представянето. Историята най-често се пише на малък лист, което само по себе си ограничава обема.
Благодарение на потребителските истории можете да documentирате желанията на клиента и бързо да отговорите на изискванията на пазара.
Потребителската история трябва да се счита за опростена мярка на изискванията, тъй като не включва proceduresа за тестване за приемане. Компилацията на потребителската история трябва да отговаря на proceduresата за допускане. Това ще гарантира, че потребителската история постига целта си.
Структурата на историята изглежда така: „Като потребител <тип потребител>, искам да извърша <действие>, за да получа <резултат>“ (Като собственик на продукт искам ...). Такава структура е не само проста, но и разбираема за всички.
Ползи от използването на потребителски истории:
- Историите са малки и лесни за създаване.
- Помогнете на всички заинтересовани страни да обсъдят работата по проекта и неговата подкрепа.
- Не изискват постоянна поддръжка.
- От meaning само когато се използва.
- Подобрете взаимодействието с клиента.
- Благодарение на тях можете да разделите проекта на малки етапи.
- Улесняване на работата по проекти с недобре разбрани изисквания.
- Опростете оценката на задачите.
Недостатъци на потребителските истории:
- Без предварително споразумение proceduresите могат да затруднят използването му като основа за споразумение.
- Използването им изисква близък контакт с клиента по време на целия проект, което понякога затруднява работния процес.
- Те имат недостатъци при мащабиране на големи проекти.
- Пряко свързано с професионалното ниво на разработчиците.
- Използва се за започване на дискусия, но не може да прекрати дискусия и не се използва за системна documentация.
Назад
Продуктовото изоставане представлява текущите задачи под формата на списък, съставен по приоритет. Списъкът се формира въз основа на пътната карта (пътната карта) на проекта и точките, заложени в нея. Най-важните задачи обикновено са в горната част на списъка. Това е необходимо, за да се разбере коя работа трябва да се извърши първо.
Екипът за разработка избира скоростта на изпълнение на изостаналите задачи, независимо от желанията на клиента, но въз основа на неговата квалификация и опит от минали спринтове. Изключително нежелателно е да „коригирате“ програмисти. Екипът сам избира задачи от изоставането според собствените си съображения и възможности. Изпълнението се извършва без прекъсване (Kanban) or няколко итерации (Scrum).
Две важни условия за изоставане
Ядрото на изоставането на продукта се състои от пътна карта, предложения и условия за изпълнение. Epics съдържа условия и потребителска история. Нека разгледаме отблизо типичен пример за пътна карта.
Създаването на уебсайта „Екипи в космоса” е първото предложение от пътната карта. Той трябва да бъде разделен на епоси (на фигурата те са показани в зелен, син и тюркоазен цвят) и потребителска история за всеки епос.
Клиентът на софтуера формира един списък от няколко потребителски истории. Ако е необходимо, той може да промени реда, в който се изпълняват историите, така че разработчиците първо да се справят с един от най-важните епоси (вляво) or да проверят How работи резервацията на билети с отстъпка. За да направите това, трябва да внедрите истории от епоси (вдясно). И двете опции можете да видите по-долу.
Въз основа на Howви фактори клиентът трябва да даде приоритет?
- Уместност за потребителите.
- Наличието на обратна връзка.
- Сложност на разработката.
- Връзката между задачите (за да завършите "B", първо трябва да направите "A").
Приоритетите в работата се определят от клиента, но други страни могат да изразят мнението си по този въпрос. Успехът на изоставането зависи, наред с други неща, от мненията на клиентите и програмистите. Заедно те могат да постигнат по-добри резултати и да осигурят навременна доставка на готовия продукт.
Как да запазите изоставане
Ако изоставането вече е създадено, след това трябва периодично да го променяте в хода на по-нататъшната работа. Клиентът на софтуера трябва да се увери, че изоставането е правилно компorрано преди всяко ново планиране на итерация. Това ще помогне да се изяснят приоритетите or да се промени нещо след анализа на последната итерация. Коригирането на изоставането в Agile понякога се нарича „подстригване“ or „усъвършенстване“ or „поддръжка на изоставане“.
Ако изоставането вече е сравнително голямо, тогава клиентът трябва да групира задачите по краткосрочно и дългосрочно изпълнение. Краткосрочните назначения трябва да бъдат внимателно проверени, преди да им бъде даден този статут. Ще трябва да съставите потребителска история, да разберете всички нюанси в екипа.
Що се отнася до дългосрочните задачи, силно е желателно разработчиците да им дадат оценка. Това ще улесни приоритизирането. Може би нещо ще се промени, но екипът ще подобри разбирането си за задачите и ще свърши работата по-бързо.
Закъснението е важен компонент между клиента и програмния екип. Клиентът винаги може да промени приоритетите си въз основа на отзиви от клиенти, прогнози or нови изисквания.
Препоръчително е да избягвате да правите промени директно по време на работа. Това се отразява зле на работния процес и емоционалното състояние на програмистите.
Спринт
Спринтът е кратък период, през който трябва да се свърши предварително договорено количество работа. Спринтовете са базирани на методологии Scrum и Agile. Изборът на правилните спринтове помага на един гъвкав екип да разработи качествен софтуер.
„Използвайки Scrum, можете да разработите продукт в няколко итерации с ясна продължителност – спринтове. Помага за разделянето на големи проекти на по-малки задачи“, казва Меган Кук, Jira Lead в Atlassian.
Как Scrum планира и изпълнява спринтове?
Според авторите на методологията Scrum, за да планират бъдещия спринт, е необходимо всеки да се събере на отделна среща. На това събитие членовете на екипа трябва да намерят отговор на два основни въпроса: Howво трябва да се направи в този спринт и How най-добре да го направим?
Клиентът на софтуера, Scrum master и програмистите участват в определянето на списъка с работни задачи. Клиентът обяснява целта на спринта и задачите от изоставането.
След това екипът разработва план, според който ще бъдат изпълнени задачите в спринта. Този план, заедно с избраните работни елементи, се нарича спринтово изоставане. След срещата за планиране екипът се захваща за работа. Разработчиците избират задачи от натрупаните задачи, тъй като работата е завършена, статусът на всяка задача се променя от „В ход“ на „Готово“.
По време на спринта екипът провежда ежедневни Scrum срещи (stand-up) за обсъждане на текущи проблеми и напредък. Такива срещи са необходими, за да се идентифицират трудностите, които могат да повлияят на завършването на спринта.
Ако спринтът е завършен, тогава екипът показва резултатите от своята работа при прегледа на резултатите (демо). Всеки участник в проекта може да се запознае с резултатите. Запознаването трябва да се извърши преди готовият code да бъде обединен в производствената среда.
Ретроспективата завършва цикъла от спринтове. На него екипът идентифицира области, които трябва да бъдат подобрени в бъдещ спринт.
На Howво да обърнете внимание и Howво да не правите
Повечето млади екипи намират за трудно да въведат спринтове в работния си процес за първи път. За да избегнете проблеми, ви препоръчваме да прегледате списъка с действия, които изискват приоритетно внимание.
Какво трябва да направим:
- Проверете дали екипът разбира целта на спринта и How ще успее. Това е необходимо, за да вървим всички заедно към успешен резултат.
- Трябва да имате ясно и разбираемо изоставане. Ако неизпълнените задачи не са поддържани правилно, това може да се превърне в проблем, който може да повреди работния процес.
- Уверете се, че оценката ви за темпото на работа е правилна, като вземете предвид летните ваканции и други фактори.
- Участвайте активно в планирането на спринта. Насърчете членовете на екипа да разширят плана за истории, грешки и задачи.
- Отказ на задачи, по време на които разработчиците няма да могат да разрешат проблеми със зависимостите.
- След като планът бъде одобрен, назначете служител, който ще отговаря за въвеждането на данни в програмата за управление на проекта (Jira карти и др.).
Какво да избягвате:
- Не прекалявайте с голям брой истории, преценявайте трезво темпото на работа и не възлагайте задачи, които трудно ще изпълните на спринт.
- Бъдете внимателни към качеството на работата си. Проверете дали имате достатъчно време за контрол на качеството и коригиране на грешки в codeа.
- Уверете се, че всички членове на екипа разбират ясно съдържанието на спринта. Не преследвайте скоростта. Целият екип трябва да се движи заедно.
- Не натоварвайте разработчиците с допълнителна работа. Очаквайте скоро нов спринт.
- Ако екипът изрази загриженост относно натовареността or крайния срок, трябва да вземете предвид тяхното мнение. Справете се с проблемите и ги коригирайте, ако е необходимо.
схватка дъска
Scrum Board е инструмент, който показва How се извършва работата на Scrum Team. Можете да показвате информация на такава дъска на хартия, на стена or в електронен вид (JIRA, Trello).
Scrum дъската има поне три колони: Задачи, В ход и Готово. Ето примерна дъска:
Scrum дъската съдържа цялата информация от неизпълнените задачи, предварително одобрена за планиране. По правило картите с бизнес задачи се закрепват на дъската по приоритет отгоре надолу. Можете да ги разделите на специфични видове работа (работа върху code, дизайн и други).
След като част от работата е завършена, картата се премества през дъската към следващата колона. За да се покаже видимостта на напредъка на работата на екипа, „оставащата работа“ по дни в Burndown Chart помага.
Можете също така да използвате дъска за флипчарт. На него имената на произведенията са изписани на хартиени стикери и закрепени на дъската. Веднага след като работата приключи, стикерите се преместват в друга колона.
диаграма на изгаряне
Графиката за изгаряне показва количеството свършена работа и количеството останала работа. Той се актуализира всеки ден и е достъпен за всички заинтересовани страни. Графиката е необходима, за да покаже напредъка в работата по спринта.
Има два вида диаграми:
- Графика на изгаряне, показваща напредъка на работата в спринт.
- Графика на изгаряне, показваща напредъка на работата до пускането на продукта (данните са обобщени от няколко спринта).
Примерна диаграма:
Този пример използва психология: диаграмата не показва броя на изпълнените задачи, а броя на оставащите (неизвършени).
Тоест, ако екипът е изпълнил 90 задачи от 100, тогава може да има фалшиво усещане, че всичко е готово. В крайна сметка напредъкът от 90 до 100 задачи всъщност не променя нищо.
Ако покажете броя на оставащите задачи, тогава няма How да не забележите How всеки път те стават все по-малко и по-малко. Това подсъзнателно стимулира участниците в проекта да постигнат целта по-бързо - на дъската не трябва да има незавършени задачи.