Комментарии 17
После прочтения статьи не складывается понимания, в чем заключается ИФ метод.
ИФ Метод основан в первую очередь на бритве Оккама, которая требует не плодить сущностей без необходимости. Метод заключается в итеративной разработке функционала с опорой на собственную систему визуализации (можно посмотреть на ru.ifmethod.com, пощупать в демо-режиме после регистрации на app.ifmethod.ru). Соответственно, метод предусматривает отказ от тяжеловесных практик Agile и Kanban, которые занимают время, которое можно потратить более эффективно, например, непосредственно на программирование или продуктовые исследования.
Как отвечать на вопросы "когда будет готово?" и "Что надо сделать раньше - А или Б?" в рамках методологии?
Когда будет готово – нужно договариваться с лидом итерации о конкретных датах, при этом важнее не конкретная дата плюс / минус несколько дней, а ответ на вопрос: "Какие есть факторы риска, что возникнут непредвиденные обстоятельства? Тяжелый рефакторинг, внешние проблемы, неправильная архитектура".
Что надо сделать раньше? Есть только два реальных приоритета – нужно сделать прямо сейчас (например, хотфикс на проде) и прямо сейчас делать не нужно (все остальное). Вся остальная приоритизация, как в Джире, "low - medium - high - critical", высосана из пальца. Реально приоритетные вещи всегда коммуницируются исполнителям напрямую, в системах управления продуктами они не нужны.
Не очень понимаю, почему тыканье по тикету это прям что-то радикально лучшее, чем перетаскивание тикета.
Вы экономите время – больше не нужно перетаскивать карточки между колонками и переназначать их. Меньше рутины, больше времени на код.
Если вам не нравится Agile, значит вы готовите его неправильно. Это логическая уловка, известная как "Ни один истинный шотландец".
Нет, не уловка – это действительно так. Ловушка тут в том, что весь смысл эджайла в повышении гибкости процессов разработки, мгновенной реакции на изменение внешних факторов. Бизнес аналитик ошибся в постановке задачи? Не беда, это выявится в конце короткой итерации и будет исправлено в следующей. Баг, который выявляется только на ограниченном подмножестве юзеров на проде? То же самое. И так далее. И тут возникает некий абсурд: гибкость пытаются получить, навязывая жесточайшим образом прописанные методологии (привет, SCRUM): шаг вправо, шаг влево, прыжок на месте.... ну, вы знаете. Так оно проще, да: думать не надо, кто-то за вас уже подумал и расписал, как надо, по пунктам. На самом деле каждая компания и каждый проект имеет индивидуальные черты, игнорирование которых приводит к снижению эффективности. "Правильно приготовленный" эджайл сохраняет гибкость и скорость реакции в условиях конкретной компании/проекта. Для чего его надо именно что "приготовить": взять наиболее подходящую методологию и адаптировать её под себя.
Вероятно, это то, с чем столкнулся автор, и к его чести, попытался найти собственное решение. Но сейчас он делает ту же самую ошибку, пропагандируя его как единственно верное. Это не говоря уж о том, что в статье полно ругани по адресу других методологий (иногда обоснованной, иногда не очень), а вот предлагаемое решение описано на уровне "подписывайтесь на мой канал, там всё узнаете". Нет, это так не работает. Возможно, у автора есть идеи, которые можно было бы позаимствовать – но для этого их нужно внятно изложить. Пока не получилось. Единственное, что понятно – это тот же эджайл, но реализованный по-своему. Поэтому критика эджайла в целом, как проектной философии, тоже выглядит несколько неуместной.
Конечно же, это всё сарказм ... в котором есть доля сарказма:
---
Интервью с издателем (сарказм):
Итак, сегодня на дворе 2004 год и мы обсуждаем слегка устаревшую книгу "Управление программными проектами" Роберта Фатрелла, издание 2002 года (перевод 2004). Я понимаю, что уже прошло 2 года с момента оригинального издания, но всё же, что вы можете рассказать интересного о ней? Полагаю нашим слушателям это будет интересно.
Это очень интересная книга, в которой описаны различные подходы к организации разработки ПО. Начинается всё, стандартно, с формализованного водопада (waterfall). Но есть и более современные методики.
Например, какие? Что вы можете посоветовать нашим слушателям?
Для начала можно рассмотреть "прототипирование" (для любопытных слушателей: глава 4, страница 144). В ней предлагается строить рабочую модель системы как макет или прототип. Сначала делается первая версия прототипа, потом она основании общего плана производится "доработка" макета: дорабатываются функции, базы данных и пользовательский интерфейс. Всё это основано на фазе "быстрого анализа", которая с учётом общего плана задаёт общий тон и направление разработки. Все доработки находятся на виду у "пользователя" и постоянно делается подгонка и утверждение решений с учётом эксплуатации.
Отличная схема разработки! Правда у неё есть одна существенная зависимость: нужно работать с пользователем, постоянно делать подгонку. Есть какие-то другие процессы, которые не такие старые, как водопад (всё таки уже 2004 год на дворе!)?
Конечно-конечно. Не всё же заканчивается на водопаде и прототипировании. Есть ещё такая хорошая модель: "инкрементная" (также для внимательных слушателей: глава 4, страница 155). В ней вы делаете небольшие доработки продукта. Каждая доработка это как обособленная функция: её может делать отдельный человек. Также допускается одновременная разработка нескольких "инкрементов". Естественно, это делается разными разработчиками. В целом, вся модель следует общему плану, по которому добавляется функционал - "инкремент". Причём в процессе нет явной связи с пользователем и можно создавать инкремент, который не будет законченным (готовым) решением, но позволит сделать другие, полезные пользователю функции.
Спасибо за интервью, вы рассказали об очень интересной и всеобъемлющей книги по управлению проектами. Надеюсь, наши слушатели смогут выбрать в ней подходящий для себя процесс.
---
Очевидно, сарказм: прошло больше 20 лет ... И?
Включите в телеге комментарии. Вы как клиентов/пользователей ищите?
Экскурс в историю Agile и Kanban, или Топ 10 причин перейти на итеративно-функциональный метод