Google Drive
Gist
Clipboard
✅ — готов
🔄 — не совсем готов
🔴 — совсем не готов
Проект — это деятельность, направленная на достижение уникальной цели.
Проект характеризуется тремя главными свойствами:
Проект — не план действий, а деятельность для реализации такого плана.
Продукт — это результат деятельности, который продается, покупается и используется.
Проще говоря: проект — это процесс, продукт это результат.
Управление продуктом — определение свойств и характеристик продукта.
Управление проектом — контроль процессов, решение сложностей на этапе реализации плана.
Варианты решения проблем:
Использование крутых инструментов (Git, VSCode, …)
1 — Обнуляется накопленный опыт
2 — Увеличивается глубина виртуализации
5 — Задержка на изучение инструментов
6 — Меньше людей умеют пользоваться
7 — Менеджеры не умеют пользоваться
Ковбойское программирование ("лучше кодить, а не управлять")
Иногда работает, иногда нет
Условия для успеха:
Хватает, чтобы проскочить до первой версии, дальше становится сложнее.
Формализация
1 — детальная архитектура на UML, но возникает конфликт между разработчиками и архитекторами
2 — не зависим от ОС, СУБД, виртуального мира, но тонем в абстракциях
3 — подробные ТЗ + запрет изменений, но избыточные и абстрактные требования
4 — подробный ежедневный отчёт, но программисты ненавидят отчёты
5 — подробная документация, но проблемы с её обновлением и синхронизацией
7 — опционы и акции за хорошую работу
Waterfall — модель процесса разработки программного обеспечения, жизненный цикл которой выглядит как поток, последовательно проходящий фазы анализа требований, проектирования, реализации, тестирования, внедрения и сопровождения. Каскадная модель хорошо зарекомендовала себя при построении относительно простых ПО, когда в самом начале разработки можно достаточно точно и полно сформулировать все требования к продукту.
Agile — гибкие методологии, нацелены на минимизацию рисков путём сведения разработки к серии коротких циклов, называемых итерациями, которые обычно длятся две-три недели. Каждая итерация сама по себе выглядит как программный проект в миниатюре и включает все задачи, необходимые для выдачи мини-прироста по функциональности: планирование, анализ требований, проектирование, программирование, тестирование и документирование. Хотя отдельная итерация, как правило, недостаточна для выпуска новой версии продукта, подразумевается, что гибкий программный проект готов к выпуску в конце каждой итерации. По окончании каждой итерации команда выполняет переоценку приоритетов разработки.
Манифест Agile:
Мы постоянно открываем для себя более совершенные методы разработки программного обеспечения, занимаясь разработкой непосредственно и помогая в этом другим. Благодаря проделанной работе мы смогли осознать, что:
Люди и взаимодействие важнее процессов и инструментов
Работающий продукт важнее исчерпывающей документации
Сотрудничество с заказчиком важнее согласования условий контракта
Готовность к изменениям важнее следования первоначальному плану
То есть, не отрицая важности того, что справа, мы всё-таки больше ценим то, что слева.
Принципы:
Пользовательские истории (user stories) — способ описания требований к разрабатываемой системе, сформулированных в виде нескольких предложений на языке пользователя.
Критерии:
Пользовательские истории vs Техническое задание:
Инкрементальная разработка:
Итеративная разработка:
Agile является и итеративным, и инкрементальным:
"Обычный" дизайн
Проблемы "обычного" дизайна:
Итог: задел на будущее с первой итерации оказался бесполезным или даже добавил проблем.
"Простой" дизайн — одна из трёх ключевых Agile практик, которая призвана решить обозначенные проблемы.
В "простом" дизайне мы на каждой итерации делаем только те User Stories, которые запланированы на эту итерацию, как будто следующих итераций не будет вообще. Иначе говоря, решаем задачи по мере их поступления, не забегая вперед. Код при этом должен быть минимальным, не содержать дублирования и чётко выражать мысли разработчика.
Особенности "простого" дизайна:
На второй итерации "простого" дизайна мы решаем задачи самым простым образом (напролом). Это приводит к таким проблемам как:
Рефакторинг — изменение структуры кода без изменения поведения программы. Позволяет избавиться от bad smells, описанных выше.
Под рефакторингом понимаются следующие небольшие изменения кода:
Цикл разработки с рефакторингом:
Рефакторить нужно без фанатизма, ровно до того момента, пока не вернёмся к "простому" дизайну. С каждой следующей задачей дизайн испортится и нужно будет снова рефакторить.
Традиционный подход к тестированию:
На практике:
Разработка через тестирование (TDD) — один из ключевых принципов Agile, решающий обозначенные проблемы.
Принципы TDD:
В TDD выделяют два типа тестов:
Основной цикл TDD:
Требования к коду:
Преимущества TDD:
Стоит помнить, что тесты не равны верификации, то есть:
Также наличие тестов не равно TDD: в TDD тесты пишутся до написания кода, а не после. При этом можно сказать, что если нет TDD, то и тестов не будет, так как:
При этом если нет тестов, то нет Agile:
Несмотря на то, что тесты не упоминаются ни в Scrum, ни в Kanban, их также нельзя реализовать без тестов. Владелец продукта может вносить новые user stories на любой стадии, что вызовет каскадные изменения в коде и при отсутствии тестов приведёт к багам.
Недостатки TDD:
Scrum — наиболее популярный метод управления проектами, подмножество Agile.
Шесть характеристик:
Ограничения:
Участники проектов:
Решает, как делать
От трёх до девяти человек. Каждый член команды работает сам по себе, но у всех общая цель и общий результат.
Обязанности команды:
Отвечает за соблюдение процесса.
Scrum-мастер является посредником между всеми участниками scrum'а. Он эксперт по scrum'у (следит за соблюдением правил scrum). Обычно является членом Команды (возможно, что эта должность ходит "по кругу").
Обязанности scrum-мастера:
Сложная для понимания и исполнения роль.
Scrum-мастер не отвечает за успешность итераций. Если команда работала эффективно, но итерация не завершилась успешно, то это не проблема Scrum-мастера. Но если в команде ежедневные скандалы (даже при условии успешных исходов итераций), то это проблема Scrum-мастера. То есть, следим не за результатом, а за качеством процесса достижения результата.
Scrum-мастер не отвечает за успешность продукта. В провале продукта на рынке виноват Владелец продукта.
Решает, что делать.
Владелец продукта отвечает за успех продукта. Желательно, чтобы он разбирался в предметной области продукта. Часто является представителем заказчика.
Обязанности:
Владелец продукта имеет право "последнего слова". Он может принимать продуктовое решение, даже если все остальные участники против, но несёт полную ответственность за такие решения.
Спринты - итерации в стиле Agile
Стандартный спринт: 4 недели, но можно меньше или больше
Достаточно короткие, чтобы не было нужды в планировании
Достаточно длинные, чтобы можно было сделать что-то ценное
Состав спринта:
Административные обязанности команды:
Спринт может завершиться следующим образом:
Участники:
Первый сегмент сессии планирования:
Второй сегмент сессии планирования:
Участники:
Три вопроса к каждому участнику:
Участники:
Разрешено демонстрировать только готовую функциональность (потому что присутствуют люди, не участвующие в процессе разработки):
После демонстрационной сессии:
Участники:
Вопросы:
Журнал продукта (product backlog) — список user stories с расставленными приоритетами. Наиболее приоритетные истории могут быть детализированы.
Журнал спринта (sprint backlog) — список технических задач на текущий спринт. Задачи небольшие - выполняются не более чем за два дня (если задача больше - декомпозируем).
Размещается на видном месте, чтобы команда всегда его видела.
По оси Y - оставшийся объём работ, по оси X - время.
Рисуем идеальную прямую - в которой в последний день объём работ = 0, и затем каждый день отмечаем точку - сколько ещё не сделано. Таким образом если наш спринт идёт хорошо - наш график похож на идеальную прямую.
Если не успеваем что-то сделать, то выкидываем из спринта и переносим на следующий. Это позволяет не увеличить затраты и не ухудшить качество.
Вкратце: программисты не работают больше 40 часов в неделю. Вообще.
Мотивация:
Стандартный программист стремится первые 80% времени работать на расслабоне. Из-за этого на последних 20% начинается аврал. Аврал - это плохо: из-за повышенной нагрузки ухудшается качество кода, производительность падает, возникают конфликты (кто-то не может работать дольше, и на него все злятся).
Практика:
Авралы запрещаются, и программистам запрещается работать больше 40 часов в неделю (или сколько полагается по трудовому законодательству страны) независимо от фазы проекта. Таким образом, сами программисты не беспокоятся о том, что через полгода придётся кранчить, а проджект овнер и скрам мастер мотивированы организовывать работу сразу правильно, потому что переработка в конце не спасёт.
Естественно, недопустимо от этого правила отказываться. Если "на берегу" договорились, что авралов не будет, но в конце проекта они таки случились, это нехорошо.
Вкратце: все пишут код по одному стандарту, есть code style, best practices, комментарии.
Практика:
Код читают намного чаще, чем пишут - когда ищут баги, когда добавляют фичи, когда его копируют в другое место. Поэтому очень полезно иметь стандарты кодирования, чтобы во всём проекте код был одинаковый и его было легко читать. Стандарты могут быть хоть какие, главное - одинаковые везде (внутри одной системы. Стандарт может быть разным для базы данных и фронтенда, например). Помимо самого удобства существования стандартов, они практически необходимы для следующих двух практик.
Вкратце: всю кодовую базу могут читать и улучшать все члены проекта.
Мотивация:
Если в каком-то модуле работает только один человек (Иванов), он может в нём творить что угодно для своего удобства. И если Иванов занят/заболел/уволился (bus factor), а этот код надо поддерживать, то это будет больно - даже если Иванов писал код нормально, остальным придётся с нуля вникать.
Практика:
Любой код может читать и улучшать (делать туда pull request) любой член команды. За счёт этого, если Иванов недоступен, код может поправить Петров, который его читал и делал поправки, то есть как-то разбирается. Понятно, что без стандартов кодирования разбираться в чужом коде намного сложнее.
Вкратце: особо важное пишут два программиста за одним компьютером.
Практика:
Если есть два программиста одна клавиатура, то один ("ведущий", driver) пишет, а другой ("штурман", observer) думает над задачей и смотрит, как первый пишет. И они периодически меняются. Как олимпиадники на ICPC.
За счёт того, что "штурман" прямо смотрит на выдаваемый код, он может сразу замечать ошибки, который пишущий не видит. Заодно он не так сфокусирован на собственно коде и может предлагать решения.
При правильной организации при этом методе получается прирост качества, оправдывающий двойную трату времени программистов. Поэтому используется для особо важного кода, формочки клепать и поодиночке можно. Также при парном программировании хорошо идёт передача знаний.
Однако, эта практика зачастую саботируется самими программистами. Кто-то просто предпочитает работать соло, особенно опытные программисты, кто-то не хочет перенапрягаться, потому что расслабиться как наедине не получится. Или может получиться, что пара программистов заболтается и производительность упадёт.
-
Any changes
Be notified of any changes
-
Mention me
Be notified of mention me
-
Unsubscribe
Subscribe