Гнучкі Метедології Scrum

Гнучкі Метедології Scrum

від Видалений користувач -
Кількість відповідей: 5

 

  •       

Agile – сімейство процесів розробки, а не єдиний підхід у розробці програмного забезпечення. Agile не включає практик, а визначає цінності і принципи, якими керуються успішні команди. Включає в себе наступні методології: наступних методологій Extreme programming, Scrum, DSDM, Adaptive software development, Crystal Clear, Feature-driven development, Pragmatic Programming.

Основні ідеї:

  • Особистості та їх взаємодія є важливішим, ніж процеси та інструменти;
  • Працююче програмне забезпечення є важливішим, ніж повна документація;
  • Співпраця з замовником важливіша, ніж контрактні зобов’язання;
  • Реакція на зміни є важливішим, ніж дотримання плану.

Принципи:

задоволення клієнта за рахунок ранньої та безперебійної поставки цінного програмного забезпечення;
можливість змін вимог навіть наприкінці розробки (це може підвищити • конкурентоспроможність отриманого продукту);

  • часта поставка робочого програмного забезпечення (кожен місяць або тиждень або ще частіше);
  • тісне, щоденне спілкування замовника з розробниками протягом всього проекту;
  • проектом займаються мотивовані особистості, які забезпечені потрібними умовами роботи, підтримкою і довірою;
  • рекомендований метод передачі інформації – особиста розмова (обличчям до обличчя);
  • працююче програмне забезпечення – кращий вимірювач прогресу;
  • спонсори, розробники і користувачі повинні мати можливість підтримувати постійний темп на невизначений термін;
  • постійна увага поліпшенню технічної майстерності і зручному дизайну;
  • простота – мистецтво не робити зайвої роботи;
  • кращі технічні вимоги, дизайн та архітектура виходять у самоорганізованої команди;
    постійна адаптація до мінливих обставин.

Скрам (Scrum) – одна з найпопулярніших методологій гнучкої розробки. Scrum простий у використанні і робить акцент на якісному контролі процесу розробки.
У методології Scrum всього три ролі:

  • Scrum Master
  • Product Owner
  • Team

 (Scrum Master) – відповідає за успіх у проекті. По суті, Scrum Master є інтерфейсом між менеджментом і командою (менеджер проекту або тімліда). Важливо підкреслити, що Scrum Майстер не роздає завдання членам команди.

У Agile команда є самоорганізованою.
Основні обов’язки Скрам Майстра:

  • Створює атмосферу довіри
  • Бере участь у мітингах в якості фасилітатора
  • Усуває перешкоди
  • Робить проблеми і відкриті питання видимими
  • Відповідає за дотримання практик і процесу в команді
  • Scrum Майстер веде Daily Scrum Meeting і відстежує прогрес команди за допомогою Sprint Backlog, відзначаючи статус всіх завдань у спринті. ScrumMaster може також допомагати Product Owner створювати Backlog для команди.

Product Backlog – це пріоритезований список наявних на даний момент бізнес вимог і технічних вимог до системи. Product Backlog включає в себе use cases, defects, enhancements, technologies, stories, features, issues, і т.д .. Product backlog також включає завдання, важливі для команди, наприклад «провести тренінг», «додати всім пам’яті»
Product Backlog постійно переглядається і доповнюється – в нього включаються нові вимоги, видаляються непотрібні, переглядаються пріоритети. За Product Backlog відповідає Product Owner. Він також працює спільно з командою для того, щоб отримати наближену оцінку на виконання елементів Product Backlog для того, щоб більш точно розставляти пріоритети відповідно до необхідним часом на виконання.

Product Owner – це людина, яка відповідає за розробку продукту (представник замовника). Product Owner – це єдина точка прийняття остаточних рішень для команди в проекті.
Обов’язки Product Owner такі:

  • Управляє очікуваннями замовників і всіх зацікавлених осіб
  • Координує і пріорітизує Product backlog
  • Надає зрозумілі вимоги команді
  • Взаємодіє з командою і замовником
  • Відповідає за приймання коду в кінці кожної ітерації
  • Product Owner ставить завдання команді, але він не має права ставити завдання • конкретного члена проектної команди протягом спринту

Команда (Team). Команда бере на себе зобов’язання щодо виконання обсягу робіт на спринт перед Product Owner. Робота команди оцінюється як робота єдиної групи. У Scrum внесок окремих членів проектної команди не оцінюється, оскільки це розвалює самоорганізацію команди.
Обов’язки команди такі:

  • Відповідає за оцінку елементів backlog
  • Приймає рішення по дизайну
  • Розробляє софт і надає його замовнику
  • Відстежує власний прогрес (разом зі Скрам Майстром)
  • Відповідає за результат перед Product Owner

Selenium – це інструмент для тестування Web-додатків.
Офіційний сайт: http://seleniumhq.org
Selenium на даний момент є найпопулярнішим іструментом для автоматизації тестування web-додатків, оскільки він: безкоштовний, гнучкий, працює безпосередньо через браузер, доступний в різних мовах програмування. Важливим є те що тести Selenium виконуються безпосередньо в браузері як це роблять звичайні користувачі.

2 головні переваги Selenium:
Створення тестових сценаріїв Selenium відтворює дії користувача, тобто додаток тестується з точки зору кінцевого користувача.
Можливість запуску тестів в різних браузерах, що полегшує визначення несумісності браузера.
Selenium працює з:
Браузери: Internet Explorer, Mozilla Firefox, Safari, Chrome
Операційні системи: Microsoft Windows, Mac OS, Linux

 

У відповідь на Видалений користувач

Гнучкі Метедології Scrum

від Видалений користувач -

Scrum— підхід управління проектами для гнучкої розробки програмного забезпечення. Scrum чітко робить акцент на якісному контролі процесу розробки.
Scrum — це кістяк процесу, який включає набір методів і попередньо визначених ролей. Головні дійові особи — ScrumMaster, той хто опікується процесами, веде їх і працює як керівник проекту, Власник Продукту, людина, що представляє інтереси кінцевих користувачів та інших зацікавлених в продукті сторін, та Команду, яка включає розробників.
Протягом кожного спринту, 15-30 денного періоду (тривалість визначається командою), працівники створюють функціональний ріст програмного забезпечення.
Набір можливостей, які імплементуються кожного спринту, приходять з етапу, що має назву product backlog (документація запитів на виконання робіт), який має найвищу пріоритетність за рівнем вимог до роботи, що повинна бути виконана. Запити на виконання робіт (backlog items), що визначені протягом наради з планування спринту (sprint planning meeting), переміщуються в етап спринту. Протягом цієї наради Власник Продукту інформує про завдання, які він хоче, аби були виконані. Тоді Команда визначає, скільки з бажаного вони можуть зробити, щоб завершити необхідні частини протягом наступного спринту. Протягом спринту команда виконує визначений фіксований список завдань (т.з. backlog items). Впродовж цього періоду ніхто не має права змінювати перелік запитів на виконання робіт, що слід розуміти, як заморожування вимог (requirements) протягом спринту.
За методикою Scrum у виробничому процесі є визначені ролі, що розбиті на дві групи — «свиней» та «курей».
Свині використовуються для побудови продукту регулярно і часто (повністю задіяні), тоді як будь-які інші — кури, ті, що зацікавлені (і задіяні) в проекті, але не мають прямого стосунку до приготування страви. Потреби, бажання, ідеї та вплив курей беруться до уваги, але їм не завжди дозволяють прямо впливати, видозмінювати або включатися в хід Scrum проекту.
Product backlog (беклог)
Product backlog — це документ, який має список вимог до функціональності, які упорядковані згідно зі ступенем важливості. Product backlog представляє список того, що повинно бути реалізовано. Елементи цього списку називаються «історіями» (user story) або елементами backlog-у (backlog items). Product backlog відкритий для редагування усім учасникам Scrum-процесу.
Обов'язкові поля
ID — унікальний ідентифікатор, порядковий номер, який використовується для ідентифікації історій у разі їх перейменування.
Назва (Name) — стислий опис історії. Він повинен бути однозначним, щоб і розробники і product owner могли зрозуміти, про що йдеться і відрізнити одну історію від іншої.
Важливість (Importance) — ступінь важливості даної історії на погляд product owner ’a. Зазвичай являє собою натуральне число, іноді для цієї цілі використовуються числа Фібоначчі. Чим більше значення, тим вищий пріоритет.
Попередня оцінка (initial estimate) — початкова оцінка об'єму робіт, необхідних для реалізації історії порівняно з іншими історіями. Вимірюється у story point'ах. Приблизно відповідає числу «ідеальних людино-днів».
Як продемонструвати (how to demo) — стисле пояснення того, як завершена задача буде продемонстрована у кінці спринта. Дане поле може являти собою код автоматизованого приймального тесту.
Додаткові поля
Іноді, також, використовуються додаткові поля у product backlog, в основному для того, щоб допомогти product owner'у визначитися з його пріоритетами.
Категорія (track). Наприклад, «панель управління» чи «оптимізація». За допомогою цього поля product owner може легко вибрати усі пункти категорії «оптимізація» і задати їм низький пріоритет.
Компоненти (components) — указує, які компоненти (наприклад, база даних, сервер, клієнт) будуть зачеплені при реалізації історії. Дане поле складається з групи checkbox'ів, які відмічаються, якщо відповідні компоненти потребують змін.
Ініціатор запиту (requestor). Product owner може захотіти зберігати інформацію про усіх замовників, зацікавлених у даній задачі. Це потрібно для того, щоб тримати їх у курсі діла про хід виконання робiт.
ID у системі обліку помилок (bug tracking ID) — якщо ви використовуєте окрему систему обліку помилок, тоді у описі історії корисно зберігати посилання на всі дефекти, які до неї відносяться.
Sprint backlog
Sprint backlog — містить функціональність, обрану Product Owner із Product Backlog. Всі функції розбиті по задачах, кожна з яких оцінюється командою. Кожен день команда оцінює об'єм роботи, який необхідно провести для завершення задачі.
Burndown chart
Burndown chart — показує, скільки вже виконано і скільки ще залишається зробити.
Планування спринта (Sprint Planning Meeting)
Проходить на початку нової ітерації Спринта.
Із Product Backlog обираються задачі, зобов'язання по виконанню яких за спринт приймає на себе команда;
На основі обраних задач створюється Sprint Backlog. Кожна задача оцінюється у ідеальних людино-годинах;
Розв'язання задачі не повинне займати більше 12 годин або одного дня. За необхідності задачу розбивають на підзадачі;
Обговорюється та визначається, яким чином буде реалізовано цей об'єм робіт;
Тривалість наради обмежена зверху 4-8 годинами в залежності від тривалості ітерації, досвіду команди тощо;
(перша частина наради) Беруть участь Product Owner + Команда: обирають задачі із Product Backlog;
(друга частина наради) Бере участь лише команда: обговорюють технічні деталі реалізації, наповнюють Sprint Backlog
Щоденна нарада (Daily Scrum Meeting)
Відбувається кожен день протягом спринта. Є «пульсом» ходу спринта. Нараді властиві наступні обмеження:
починається точно вчасно;
всі можуть спостерігати, але говорять тільки «свині»;
триває не більш ніж 15 хвилин;
проводиться в одному і тому ж місці протягом одного спринта.
Протягом наради кожен член команди відповідає на 3 запитання:
Що зроблено з моменту попередньої щоденної наради?
Що буде зроблено з моменту поточної наради до наступної?
Які проблеми заважають досягненню цілей спринта? (Над рішенням цих проблем працює ScrumMaster. Зазвичай це рішення проходить за рамками щоденної наради і у складі осіб, що безпосередньо займаються даною перешкодою.)
Демонстрація (Sprint Review Meeting)
Проходить у кінці ітерації (спринта).
Команда демонструє внесок функціональності до продукту всім зацікавленим особам.
Залучається максимальна кількість глядачів.
Усі члени команди беруть участь у демонстрації (одна людина на демонстрацію або кожен показує, що зробив за спринт).
Обмежена 4-ма годинами в залежності від тривалості ітерації і змін у продукті.
Ретроспектива (Sprint Retrospective)
Члени команди висловлюють свою думку про минулий спринт.
Відповідають на два основних запитання:
Що було зроблено добре у минулому спринті?
Що потрібно покращити в наступному?
Виконують покращення процесу розробки (вирішують питання та фіксують вдалі рішення).
Обмежена 1-3ма годинами.
Засоби управління проектами, що підтримують Скрам:
Banana Scrum
CollabNet ScrumWorks Pro
Hansoft
IBM Rational Team Concert
Ice Scrum
Kunagi
JetBrains YouTrack
JIRA з використанням плагіну Green Hopper
Mingle, ThoughtWorks Studios
OneDesk
PangoScrum
Pivotal Tracker
Rally Software
Redmine та ChiliProject з використанням плагінів
ScrumDo
ScrumPad Pro
Scrumwise
Scrumy
Sprintometer
TargetProcess
Tinypm
VersionOne
Visual Studio, Microsoft Team Foundation Server
Yodiz

У відповідь на Видалений користувач

НА: Гнучкі Метедології Scrum

від Видалений користувач -

Agile (Гнучка модель). Scrum. Selenium

Agile – сімейство процесів розробки, а не єдиний підхід у розробці програмного забезпечення. Agile не включає практик, а визначає цінності і принципи, якими керуються успішні команди. Включає в себе наступні методології: наступних методологій Extreme programming, Scrum, DSDM, Adaptive software development, Crystal Clear, Feature-driven development, Pragmatic Programming.

Основні ідеї:

  • Особистості та їх взаємодія є важливішим, ніж процеси та інструменти;
  • Працююче програмне забезпечення є важливішим, ніж повна документація;
  • Співпраця з замовником важливіша, ніж контрактні зобов’язання;
  • Реакція на зміни є важливішим, ніж дотримання плану.

Принципи:

задоволення клієнта за рахунок ранньої та безперебійної поставки цінного програмного забезпечення;
можливість змін вимог навіть наприкінці розробки (це може підвищити • конкурентоспроможність отриманого продукту);

  • часта поставка робочого програмного забезпечення (кожен місяць або тиждень або ще частіше);
  • тісне, щоденне спілкування замовника з розробниками протягом всього проекту;
  • проектом займаються мотивовані особистості, які забезпечені потрібними умовами роботи, підтримкою і довірою;
  • рекомендований метод передачі інформації – особиста розмова (обличчям до обличчя);
  • працююче програмне забезпечення – кращий вимірювач прогресу;
  • спонсори, розробники і користувачі повинні мати можливість підтримувати постійний темп на невизначений термін;
  • постійна увага поліпшенню технічної майстерності і зручному дизайну;
  • простота – мистецтво не робити зайвої роботи;
  • кращі технічні вимоги, дизайн та архітектура виходять у самоорганізованої команди;
    постійна адаптація до мінливих обставин.

Скрам (Scrum) – одна з найпопулярніших методологій гнучкої розробки. Scrum простий у використанні і робить акцент на якісному контролі процесу розробки.
У методології Scrum всього три ролі:

  • Scrum Master
  • Product Owner
  • Team

Скрам Майстер (Scrum Master) – відповідає за успіх у проекті. По суті, Скрам Майстер є інтерфейсом між менеджментом і командою (менеджер проекту або тімліда). Важливо підкреслити, що Скрам Майстер не роздає завдання членам команди.

У Agile команда є самоорганізованою.
Основні обов’язки Скрам Майстра:

  • Створює атмосферу довіри
  • Бере участь у мітингах в якості фасилітатора
  • Усуває перешкоди
  • Робить проблеми і відкриті питання видимими
  • Відповідає за дотримання практик і процесу в команді
  • Скрам Майстер веде Daily Scrum Meeting і відстежує прогрес команди за допомогою Sprint Backlog, відзначаючи статус всіх завдань у спринті. ScrumMaster може також допомагати Product Owner створювати Backlog для команди.

Product Backlog – це пріоритезований список наявних на даний момент бізнес вимог і технічних вимог до системи. Product Backlog включає в себе use cases, defects, enhancements, technologies, stories, features, issues, і т.д .. Product backlog також включає завдання, важливі для команди, наприклад «провести тренінг», «додати всім пам’яті»
Product Backlog постійно переглядається і доповнюється – в нього включаються нові вимоги, видаляються непотрібні, переглядаються пріоритети. За Product Backlog відповідає Product Owner. Він також працює спільно з командою для того, щоб отримати наближену оцінку на виконання елементів Product Backlog для того, щоб більш точно розставляти пріоритети відповідно до необхідним часом на виконання.

Product Owner – це людина, яка відповідає за розробку продукту (представник замовника). Product Owner – це єдина точка прийняття остаточних рішень для команди в проекті.
Обов’язки Product Owner такі:

  • Управляє очікуваннями замовників і всіх зацікавлених осіб
  • Координує і пріорітизує Product backlog
  • Надає зрозумілі вимоги команді
  • Взаємодіє з командою і замовником
  • Відповідає за приймання коду в кінці кожної ітерації
  • Product Owner ставить завдання команді, але він не має права ставити завдання • конкретного члена проектної команди протягом спринту

Команда (Team). Команда бере на себе зобов’язання щодо виконання обсягу робіт на спринт перед Product Owner. Робота команди оцінюється як робота єдиної групи. У Scrum внесок окремих членів проектної команди не оцінюється, оскільки це розвалює самоорганізацію команди.
Обов’язки команди такі:

  • Відповідає за оцінку елементів backlog
  • Приймає рішення по дизайну
  • Розробляє софт і надає його замовнику
  • Відстежує власний прогрес (разом зі Скрам Майстром)
  • Відповідає за результат перед Product Owner

Selenium – це інструмент для тестування Web-додатків.
Офіційний сайт: http://seleniumhq.org
Selenium на даний момент є найпопулярнішим іструментом для автоматизації тестування web-додатків, оскільки він: безкоштовний, гнучкий, працює безпосередньо через браузер, доступний в різних мовах програмування. Важливим є те що тести Selenium виконуються безпосередньо в браузері як це роблять звичайні користувачі.

2 головні переваги Selenium:
Створення тестових сценаріїв Selenium відтворює дії користувача, тобто додаток тестується з точки зору кінцевого користувача.
Можливість запуску тестів в різних браузерах, що полегшує визначення несумісності браузера.
Selenium працює з:
Браузери: Internet Explorer, Mozilla Firefox, Safari, Chrome
Операційні системи: Microsoft Windows, Mac OS, Linux

У відповідь на Видалений користувач

НА: Гнучкі Метедології Scrum

від Видалений користувач -

Методологія SCRUM

Scrum - agile процес, який дозволяє зосередитися на забезпеченні ділової цінності за найкоротший час. Він швидко та неодноразово перевіряє фактичне робоче програмне забезпечення. Він підкреслює підзвітність, командну роботу та ітеративний прогрес до чітко визначеної мети.

Рамка Scrum, як правило, стосується того, що вимоги, ймовірно, можуть змінитися або більшість часу невідомі на початку проекту.

Scrum - одна з реалізацій методології agile, у якій додаткові надбудови доставляються замовнику кожні два-три тижні.

Scrum ідеально використовувати в проекті, де вимоги швидко змінюються.

Scrum сприяє самоорганізованій, багатофункціональній команді.

Найбільшою перевагою Scrum є його гнучкість, оскільки він швидко реагує на зміни.

У Scrum співпраця досягається в щоденних зустрічах із фіксованими ролями для scrum-майстра, власнику продукту та членів команди.

Не потрібно впроваджувати забагато змін під час виконання проекту.

У scrum після кожного спринту клієнту доставляється збірка для зворотного зв'язку.

Демонстрація функціональності надається в кінці кожного спринту. Таким чином, регулярні відгуки можна приймати до початку наступного спринту.

Немає керівника команди, тому питання та проблеми вирішуються всіма членами команди.

Щоденні спринт-зустрічі проводяться з метою огляду та зворотного зв’язку для вирішення подальшого прогресу проекту.

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

Дизайн та виконання можуть бути інноваційними та експериментальними.

Емпіричне управління процесом - це основна філософія процесу на основі Scrum.

Робоче програмне забезпечення - не елементарна міра.

Команда Scrum фокусується на забезпеченні максимальної ділової цінності, починаючи з початку проекту та до його заверешення.

Основні принципи методології scrum:

- Самоорганізація: це призводить до більш здорового спільного володіння поміж членами команди. Це також інноваційне та креативне середовище, яке сприяє зростанню.

-Співпраця: Співпраця - це ще один важливий принцип, на якому зосереджена робота. Він також розглядає управління проектами як спільний процес створення цінностей із командами, які працюють разом, щоб запропонувати найвищу якість.

-Тайм-менеджемент: Цей принцип визначає, як час є обмеженням у методі Scrum. Важливим елементом є щоденне планування спринту та оглядових зустрічей.

-Ітеративний розвиток: Цей принцип підкреслює, як краще керувати змінами та створювати продукти, що задовольняють потреби клієнта. Він також визначає обов'язки організації щодо ітеративного розвитку.

Долучення Scrum-Method-1024x751.jpg
У відповідь на Видалений користувач

НА: Гнучкі Метедології Scrum

від Видалений користувач -

Scrum - одна з найпопулярніших методолгій гнучкої розробки.  Одна з причин її популярності - простота.

ролі
У методології Scrum всього три ролі:

Scrum Master
Product Owner
Team
Скрам Майстер (Scrum Master) - найважливіша роль в методології. Скрам Майстер відповідає за успіх Scrum в проекті. По суті, Скрам Майстер є інтерфейсом між менеджментом і командою. Як правило, цю роль в проекті відіграє менеджер проекту або тімліда. Важливо підкреслити, що Скрам Майстер не роздає завдання членам команди. У Agile команда є самоорганізується і самоуправлямой. Основні обов'язки Скрам Майстра:

  • Створює атмосферу довіри
  • Бере участь в мітингах в якості фасилітатора
  • усуває перешкоди
  • Робить проблеми і відкриті питання видимими
  • Відповідає за дотримання практик і процесу в команді

 

У відповідь на Видалений користувач

НА: Гнучкі Метедології Scrum

від Видалений користувач -

Гнучка розробка програмного забезпечення (англ. Agile software development, agile-методи) — клас методологій розробки програмного забезпечення, що базується на ітеративній розробці, в якій вимоги та розв'язки еволюціонують через співпрацю між багатофункціональними командами здатними до самоорганізації. Гнучка розробка — засіб для підвищення продуктивності розробників програмного забезпечення.

Scrum (Скрам) - це не абревіатура, цей термін взятий з регбі, який позначає сутичку навколо м'яча.

Сам термін Scrum, - це методологія управління проектами, яка побудована на принципах тайм-менеджмета. Основною її особливістю є залученість в процес всіх учасників, причому у кожного учасника є своя певна роль. Суть в тому, що не тільки команда працює над вирішенням завдання, а й всі ті, кому цікаво рішення задачі, не просто поставили її і розслабилися, а постійно «працюють» з командою, і ця робота не означає тільки постійний контроль.

Основні терміни, які використовуються в методології:

Власник продукту (Product owner) - людина, яка має безпосередній інтерес в якісному кінцевому продукті, він розуміє, як цей продукт повинен виглядати / працювати. Ця людина не працює в команді, він працює на стороні замовника / клієнта (це може бути як інша компанія, так і інший відділ), але ця людина працює з командою. І це та людина, яка розставляє пріоритети для завдань.

Scrum-майстер - це людина, яку можна назвати керівником проекту, хоча це не зовсім так. Головне, що це людина, «заражений Scrum-бацилою» на стільки, що несе її як свою команду, так і замовнику, і відповідно стежить за тим, щоб всі принципи Scrum дотримувалися.

Scrum-команда - це команда, яка приймає всі принципи Scrum і готова з ними працювати.

Спринт - відрізок часу, який береться для виконання певного (обмеженого) списку завдань. Рекомендується брати 2-4 тижні (тривалість визначається командою один раз).

Беклог (backlog) - це список всіх робіт. Можна сказати, що це щоденник загального користування.

Розрізняють 2 види беклогов: Product-беклог і спринт-беклог.

Product-беклог - це повний список всіх робіт, при реалізації яких ми отримаємо кінцевий продукт.

Спринт-беклог - це список робіт, який визначила команда і погодила з Власником продукту, на найближчий звітний період (спринт). Завдання в спринт-беклог беруться з product-беклога.

Планування спринту - це нарада, на якому присутні всі (команда, Scrum-майстер, Власник продукту). Протягом цієї наради Власник продукту визначає пріоритети завдань, які він хотів би побачити виконаними після закінчення спринту. Команда оцінює за часом, скільки з бажаного вони можуть виконати. У підсумку виходить список завдань, який не може змінюватися протягом спринту і до кінця спринту повинен бути повністю виконаний.

Доступність

Шрифти Шрифти

Розмір шрифта Розмір шрифта

1

Колір тексту Колір тексту

Колір тла Колір тла

Кернінг шрифтів Кернінг шрифтів

Видимість картинок Видимість картинок

Інтервал між літерами Інтервал між літерами

0

Висота рядка Висота рядка

1.2

Виділити посилання Виділити посилання

Вирівнювання тексту Вирівнювання тексту

Ширина абзацу Ширина абзацу

0