Каждый программист мечтает о стартапе - о проекте, где будет оригинальная идея для решения нестандартной задачи. А это уже не только галочка в портфолио, но и возможность существенно подняться, если идея будет удачная. Предлагаю поговорить о реализации такого проекта, и почему это может быть важнее самой идеи.
Не важно, проект выполняется командой из четырех человек или компанией гигантом, в которой работает много людей - работу нужно уметь правильно организовывать. Например, разработка приложений сегодня поставлена на поток. Существуют целые компании, которые занимаются разработкой и поддержанием программных решений. Поэтому существуют различные методы управления проектами.
Давайте познакомимся с некоторыми из них.
«ВОДОПАД» (WATERFALL MODEL)
Это первый метод, который интуитивно понятен, т.к. он имеет каскадный вид.
Основный принцип - чтобы перейти к следующему, необходимо завершить предыдущий этап.
С одной стороны радует простота распределения и организация работы, но огорчает невозможность вернуться назад в случае ошибки, придется все начинать сначала. Это все происходит из-за того, что мы сразу же прорабатываем структуру проекта и продумываем этапы реализации.
Из плюсов можно выделить следующее:
- Надежность разработки, каждый этап тщательно прорабатывается, полируется.
- Проект прозрачен, полностью отслеживается его разработка.
Из минусов:
- Порой такой подход идет скорее во вред из-за своей длительности, а рынок сегодня развивается очень быстро, и нет возможности разрабатывать свой проект очень долго.
Всплывает очевидный вопрос: «Что выбрать вместо каскадного проектирования?»
КАНБАН (KANBAN)
Это чисто японская история. Впервые этот метод был задействован в стенах «Toyota», где он использовался с 1962 года. Канбан с японского переводится как рекламный щит, вывеска.
Слоган этого метода – «точно в срок».
Для Канбана важно:
- Визуализация все этапов разработки. Для этого используют специальную доску и карточки.
У вас постоянно есть три колонки: todo, Inprogress, done. Каждый в команде может видеть, на каком этапе находится команда.
- Гибкое планирование. Команда решает задачи, приоритет которых определяет менеджер.
- Все участники проекта в курсе, что изменения – это ключ к прогрессу. Поощряется инициатива и мелкие изменения.
- Уменьшение продолжительности выполнения задач за счет обмена знаниями между участниками команды. Это позволяет не «пробуксовывать» в работе.
- Превыше всего уважение к порядку, ролям и обязанностям. Во главе всего – внимание к участникам команды.
СКРАМ (SCRUM)
Казалось бы, Канбан – лучшее решение из всех для реализации проекта, но есть более быстрые варианты - СКРАМ. Так же, как и для Канбан, важно наличие доски, где можно узнать о текущих задачах, исполнителях и статусе каждой задачи.
Но есть и существенные отличия:
- Основную задачу проекта сильно дробят на подзадачи, что позволяет вносить изменения, улучшая продукт по желанию заказчика.
- Важной фигурой для того процесса является скрам-куратор, который позволяет связать заказчика с разработчиками оптимальным способом.
- Главный показатель при Скрам подходе – это скорость команды. Темп работы определяется спринтами - отрезками времени. При таком способе очень удобно сравнивать спринты, и делать выводы об эффективности.
Хочу заметить, что на практике разработчики ПО иногда используют нестандартные методы управления. Например, когда я работал на одном проекте, мы использовали спринты(Скрам), но для себя также выделяли этапы разработки, то есть это был некий симбиоз Скрам-Канбан ценностей.
Выше перечисленные методологии управления проектами – это не все подходы, их куда больше. Некоторые компании вообще придумывают свои решения. Например, известная компания Valve Corporation использует метод разработки Cabal.
И это круто и удобно! Вы просто можете взять ключевые моменты того метода управления, которые подходят Вам, интегрировать его и использовать. Думаю, когда перед тобой доска с заданиями, а в конце – готовый проект, будет достаточно мотивации доделать работу.
Данил Гречишкин
