Подготовка к контрольной 30 октября. Git, Waterfall, Scrum, Kanban, СУЗ

Контрольная 30 октября по ИСРПО — на 12 баллов, темы: Git, Waterfall, Scrum, Kanban и системы управления знаниями (СУЗ). Это материал первых трёх лекций: Git, методологии и документация и управление знаниями. Здесь всё сжато до того, что стоит знать наизусть, плюс сравнения, на которых обычно ловят, и вопросы для самопроверки.

1. Системы контроля версий

Определение 1. Система контроля версий (VCS, version control system) хранит историю изменений файлов: кто, когда и что поменял, — и позволяет вернуться к любой прошлой версии, не теряя остальных изменений.

Зачем: файлов в проекте много, меняются они несколько раз в день и разными людьми. «финал.docx», «финал-финал.docx» перестают работать уже на втором человеке.

1.1. Три поколения

1.2. Централизованная и распределённая модели

2. Как устроен Git

2.1. Хранилище объектов

• Всё, что знает Git, лежит в скрытой папке .git, объекты — в .git/objects.
• Каждый объект идентифицируется хэшем SHA-1 (40 шестнадцатеричных символов), содержимое сжато zlib. Имя файла объекта — его хэш.
• Одинаковое содержимое даёт одинаковый хэш, поэтому одинаковые файлы хранятся один раз, а любое изменение содержимого меняет хэш — историю незаметно подделать нельзя.

Дополнение. На слайде порядок такой: «сжимается zlib, результат хэшируется SHA-1». В действительности Git считает SHA-1 от несжатого содержимого с коротким заголовком, а уже потом сжимает. Для ответа на вопрос «какие алгоритмы» достаточно: сжатие — zlib, хэш — SHA-1. Новые версии Git умеют и SHA-256.

Дополнение. Четыре типа объектов:

Коммит хранит снимок всего проекта, а не разницу. Неизменившиеся файлы просто ссылаются на тот же blob, поэтому снимки дёшевы. Сжатие разницами Git делает отдельно, при упаковке объектов в pack-файлы (при git push и git gc).

2.2. Три области и состояния файлов

Состояния файла: untracked (Git о нём не знает) → staged (добавлен в индекс) → committed (зафиксирован) → modified (изменён после коммита, снова нужен add).

3. Основные команды Git

Типичный цикл работы:

git clone https://github.com/user/project.git
cd project
git checkout -b feature/login     # своя ветка под задачу
# …правим файлы…
git status
git add .
git commit -m "Добавить форму входа (TASK-42)"
git push -u origin feature/login  # дальше — pull request

3.1. Гигиена коммитов

• Сообщение коммита объясняет, что и зачем сделано: «Исправить падение при пустом списке», а не «fix», «asdf», «изменения».
• В корпоративной разработке в сообщение пишут номер задачи: по нему CI/CD подтягивает сценарий сборки, а трекер связывает задачу с кодом.
• Коммит подписан именем и email автора — по каждому багу можно найти, кто его внёс.
• Один коммит — одно логическое изменение.

3.2. .gitignore

Файл .gitignore перечисляет, что не должно попадать в репозиторий: артефакты сборки, бинарники, зависимости, локальные настройки IDE, секреты.

build/
*.o
*.exe
node_modules/
.idea/
.env

4. Ветки, слияние и конфликты

Определение 2. Ветка — подвижный указатель на коммит. При новом коммите указатель текущей ветки сдвигается на него. HEAD — указатель на то, где вы сейчас (обычно на текущую ветку).

• Ветки нужны, чтобы вести несколько задач параллельно и не ломать основную ветку. Основная ветка — main (раньше по умолчанию master).
• Удаление ветки (git branch -d) удаляет только указатель: коммиты остаются, и по хэшу на них можно вернуться.

4.1. Слияние

git checkout main
git merge feature/login

Дополнение. Два вида слияния:

4.2. Конфликт слияния

Возникает, когда в двух ветках по-разному изменили одно и то же место одного файла. Git останавливается и ставит в файле маркеры:

<<<<<<< HEAD
версия из текущей ветки
=======
версия из вливаемой ветки
>>>>>>> feature/login

Порядок разрешения: оставить нужный вариант (или объединить), удалить маркеры, затем git add и git commit. Коммит после разрешения сам не появится.

В командах слияние в основную ветку идёт через pull request (GitHub) / merge request (GitLab): вы предлагаете изменения, коллеги делают ревью, CI прогоняет проверки, потом ветку сливают.

5. Если что-то пошло не так

6. Git Flow

Git Flow — договорённость о ветках в команде (Винсент Дриссен, 2010).

Зачем держать старые версии: заказчики редко ставят последнюю, и исправление или новую функцию иногда нужно сделать именно в их версии — тогда от её тега делают ветку.

7. Каскадная модель (Waterfall)

Определение 3. Каскадная модель (водопад, Waterfall) — разработка последовательными этапами; следующий начинается только после завершения предыдущего, возврат назад не предусмотрен.

Концепцию описал Уинстон Ройс в 1970 году в статье «Managing the Development of Large Software Systems» — и в той же статье разбирал её недостатки. Остальные методологии возникли во многом как ответ на проблемы водопада.

Этапы по слайду: определение требований → проектирование → конструирование (реализация, кодирование) → воплощение (интеграция) → тестирование и отладка (верификация) → инсталляция (внедрение) → поддержка. На лекции их сжимали до шести: требования, проектирование, разработка, тестирование, внедрение, поддержка.

Когда уместен: требования известны заранее и не поменяются, фиксированный бюджет, госзаказ, высокая цена ошибки (медицина, авиация, строительство).

8. Scrum

Определение 4. Scrum — фреймворк гибкой разработки: небольшая самоорганизующаяся кросс-функциональная команда выпускает продукт короткими итерациями — спринтами — и после каждой получает обратную связь.

Название — схватка из регби: вся команда вместе продавливает мяч к цели. Термин в разработку продуктов ввели Такеути и Нонака (1986), как фреймворк Scrum оформили Джефф Сазерленд и Кен Швабер (1995), правила описаны в Scrum Guide.

8.1. Базовые принципы со слайда

1. Работа короткими циклами (спринтами) — проект делится на части и делается поэтапно.
2. Гибкость — после каждого спринта проверка; при ошибках меняют стратегию или пересматривают бэклог.
3. Заказчик участвует в разработке — через владельца продукта, который собирает обратную связь пользователей.
4. Взаимодействие команды — несколько человек с общей целью.

Принципы работы команды: постоянное самосовершенствование, автономность (каждый отвечает и за общий результат, и за свою часть), кросс-функциональность (в команде есть все нужные навыки, она самодостаточна).

8.2. Роли

Размер команды на лекции — 5–7 человек; по Scrum Guide 2020 — обычно не больше 10.

8.3. События (ритуалы)

На ритуалы уходит примерно 2,5–3 часа из 40-часовой недели.

8.4. Артефакты

MVP (minimum viable product) — минимальный работающий продукт. Пример с лекции: калькулятор, который умеет только складывать, уже можно продать и получить обратную связь, а дальше развивать за деньги заказчика.

9. Kanban

Определение 5. Kanban (яп. «карточка», «вывеска») — метод управления потоком задач: работа визуализируется на доске, число задач в работе ограничивается, поток постоянно улучшается.

Происхождение — производственная система Toyota (Тайити Оно, конец 1940-х — 1950-е), часть бережливого производства. В разработку перенёс Дэвид Андерсон (2000-е).

Ключевые практики:

1. Визуализация — доска с колонками этапов («Бэклог → В работе → Ревью → Готово»), каждая задача — карточка.
2. Ограничение WIP (work in progress) — лимит задач в колонке: новую задачу берут, только когда закончили текущую («меньше начинай, больше заканчивай»).
3. Управление потоком — следят за временем прохождения задачи (lead time — от появления до готовности, cycle time — от начала работы до готовности).
4. Явные правила — всем понятно, когда карточка переходит в следующую колонку.
5. Непрерывное улучшение — по доске видно узкие места и запас, процесс постепенно подстраивают.

Где особенно уместен: поддержка и эксплуатация, где задачи приходят непрерывно и есть SLA — соглашение об уровне сервиса, например «обращение обрабатывается за два часа». Карточка в трекере хранит ответственного, дедлайн, потраченное время и текст задачи.

9.1. Scrum и Kanban

10. Agile, Lean и инкрементальная модель

10.1. Agile-манифест

Agile — не методология, а манифест, набор ценностей и принципов (2001, 17 авторов, среди них Швабер и Сазерленд). Scrum и Kanban — конкретные подходы, построенные на этих ценностях.

Четыре ценности:

1. Люди и взаимодействие важнее процессов и инструментов.
2. Работающий продукт важнее исчерпывающей документации.
3. Сотрудничество с заказчиком важнее согласования условий контракта.
4. Готовность к изменениям важнее следования первоначальному плану.

«Не отрицая важности того, что справа, мы всё-таки больше ценим то, что слева». К ценностям прилагаются 12 принципов.

10.2. Бережливое производство (Lean)

Бережливое производство — концепция управления, основанная на постоянном устранении всех видов потерь: всего, что не создаёт ценности для потребителя. Каждый сотрудник участвует в оптимизации, максимальная ориентация на потребителя. Пример с лекции: станочник тратил время на ходьбу за деталями — ящик поставили рядом, и производительность выросла без доплаты. Kanban — инструмент из Lean.

10.3. Инкрементальная модель

Продукт делается по частям (инкрементам): каждая часть проходит свой маленький цикл требования → проектирование → реализация → тестирование и добавляет функциональность к уже работающей версии. Компромисс между водопадом (план и этапы) и гибкими подходами (ранний работающий продукт). Живуча в корпоративном секторе, часто в виде гибридов.

10.4. Сводное сравнение

11. Системы управления знаниями

11.1. Определение и задачи

Определение 6. Система управления знаниями (СУЗ) — совокупность технологических и организационных инструментов, методов и решений, обеспечивающих процесс генерации, поиска, отбора, систематизации и распространения знаний в организации.

СУЗ — это не только программа: без процессов (кто пишет, кто обновляет, где искать) вики быстро превращается в свалку устаревших страниц.

Шесть задач СУЗ (со слайда):

1. Организация и обеспечение генерации новых знаний внутри организации.
2. Поиск новых знаний и мониторинг эволюции существующих.
3. Идентификация, систематизация и хранение текущих знаний.
4. Целенаправленное распространение знаний внутри организации.
5. Создание инфраструктуры для генерации, хранения и распространения.
6. Утилизация знаний — удаление устаревшего.

Зачем компании: bus factor (сколько людей должно выпасть, чтобы проект встал — при единице всё держится на одном человеке) и быстрый онбординг новичков.

11.2. Виды знаний и модель SECI

Модель SECI (Нонака и Такеути, 1995) — четыре перехода знания:

11.3. Поиск, генерация, хранение, распространение

Хранение в чате — худший вариант: через месяц ничего не найти. В Git документация версионируется и проходит ревью вместе с кодом.

11.4. Виды документации

11.5. Инструменты и языки разметки

Базы знаний и вики: Confluence (Atlassian, в паре с Jira), DokuWiki (открытая, страницы в текстовых файлах без БД), MadCap Flare (инструмент техписателей: из одного источника — справка, PDF, сайт), Yonote (российская), а также Notion, GitHub Wiki, Markdown в репозитории.

Языки разметки текста со слайда:

PlantUML и Mermaid — не языки разметки текста, а языки описания диаграмм текстом: схема хранится в репозитории и меняется в одном коммите с кодом.

11.6. Системы трекинга задач

Трекер задач — система, где задачи заводят, назначают, ведут по статусам и обсуждают. Тоже хранилище знаний: история задачи показывает, кто, что, когда и почему делал.

Примеры: Jira, YouTrack, Redmine, Яндекс Трекер, GitHub Issues / Projects, GitLab Issues, Trello.

Типичные поля задачи: название и описание, исполнитель, автор, статус (колонка доски), приоритет, дедлайн, оценка и потраченное время, метки, связи с другими задачами, ссылки на коммиты и pull request. Если в коммите или PR на GitHub написать Closes #12, задача 12 закроется после слияния.

Частые ошибки

1. «Git — централизованная система». Распределённая: у каждого полная копия с историей. Централизованные — CVS и SVN.
2. Путать поколения. SCCS и RCS — локальные, по файлам; CVS и SVN — сетевые централизованные; Git — распределённый.
3. Считать add и commit одним действием. Сначала индекс, потом фиксация.
4. Делать reset после push. Отправленную историю не переписывают — для неё есть revert.
5. Забыть коммит после разрешения конфликта. Убрать маркеры мало: нужны git add и git commit.
6. Класть бинарники и сборку в Git. Для них .gitignore.
7. Считать Agile методологией. Это манифест: 4 ценности и 12 принципов.
8. Путать Scrum и Kanban. Спринты и роли против непрерывного потока и лимитов WIP.
9. Обсуждать на стендапе технические детали. 15 минут, только статус задач.
10. Путать обзор и ретроспективу. Обзор — о продукте с владельцем продукта, ретроспектива — о процессе внутри команды.
11. Думать, что в водопаде можно вернуться на этап назад. Нельзя, поэтому ошибка в требованиях так дорога.
12. Путать направления в SECI. Экстернализация — записать (неявное → явное), интернализация — научиться по записанному (явное → неявное).
13. Считать СУЗ просто программой. Это инструменты плюс организационные процессы.

Мини-тренажёр

1. Назовите системы контроля версий трёх поколений и чем поколения различаются.
2. Кто и когда создал Git и для чего?
3. Какие алгоритмы Git использует для хэширования и сжатия объектов? Где лежат объекты?
4. Назовите три области Git и команды перехода между ними.
5. Чем git pull отличается от git push? Из каких двух команд состоит pull?
6. В чём разница между git reset --hard HEAD~1 и git revert <хэш>? Что выбрать, если коммит уже отправлен?
7. Что показывает git reflog и когда он спасает?
8. Как разрешить конфликт слияния по шагам?
9. Какие ветки есть в Git Flow и откуда создаётся hotfix?
10. Перечислите этапы каскадной модели. Кто и когда её описал?
11. Назовите роли Scrum и чем занимается каждая.
12. Перечислите события Scrum и их назначение. Сколько длится стендап?
13. Назовите три артефакта Scrum.
14. Что такое WIP-лимит и зачем он нужен?
15. Назовите три отличия Scrum от Kanban.
16. Перечислите четыре ценности Agile-манифеста.
17. Дайте определение СУЗ и назовите её задачи.
18. Назовите переходы SECI с примерами.
19. Какие виды документации бывают и для кого каждый?
20. Какие поля обычно есть у задачи в трекере? Назовите три трекера.

Шпаргалка