В блоге уже несколько раз поднималась тема предсказания сроков разработки. И хоть тема эта уже избитая, привести свежий пример будет не лишним :)
В разработке софта задачи бывают разные. Бывает, что нужно поправить какую-то мелкую проблему. Бывает, что нужно повторить то, что уже делалось ранее, но для чуть-чуть других условий. Это ситуации, когда у разработчика есть какое-то представление об объеме работы (как проделанной, так и предстоящей). И оценка сроков, пусть даже слишком оптимистическая, все-таки будет базироваться хоть на какой-то актуальной информации.
А бывают ситуации, когда решение задачи нужно еще придумать. Хотя это не самый плохой вариант, хуже, когда саму задачу еще нужно выяснить и хоть как-то формализовать, и лишь после этого приступать к придумыванию решения. Ну да не суть. Важно другое: бывают случаи, когда нужно оценить, сколько времени потребуется на придумывание. Бывает, что нужно в буквальном смысле оценить, сколько времени потребуется на изобретение велосипеда. Мой сегодняшний пример как раз иллюстрирует эту ситуацию.
Прошу прощения у читателей, что опять речь о SObjectizer-е, но поскольку сейчас занимаюсь только этим, то и другим примерам неоткуда взяться. Тем не менее, есть вполне конкретная цель: к концу августа представить новую версию, в которой должны быть реализованы две принципиально важные вещи:
- Приоритеты доставки сообщений. Т.е. сообщения, приоритет которых выше, должны быть обработаны раньше менее приоритетных сообщений.
- Еще одна реакция на превышение лимита количества сообщений заданного типа: автоматическое выбрасывание наиболее старого сообщения этого типа из очереди. Т.е., допустим, есть лимит на 100 сообщений типа mouse_move. При поступлении 101-го сообщения mouse_move самое старое из стоящих в очереди должно быть выброшено.
Причем, в лучших традициях разработки ПО, цели эти являются бизнес-целями (в крайнем случае маркетинговыми). То бишь сначала эти цели озвучиваются, а уже затем ищутся способы их технического воплощения.
Как обычно в таких случаях большая шишка из бизнес-департамента спрашивает у кого-нибудь из ведущих разработчиков: "Нам нужно то-то и то-то, мы это сможем?" На что ведущий разработчик может ответить разве что "Ну, в принципе, сможем". После чего бизнес-шишка задает следующий вопрос: "А к концу августа запустить сможем?". На что разрешается ответить только "Да, сможем", т.к. отговорки вроде "нужна неделя на предварительную проработку, потом несколько дней на уточнение деталей с бизнесом и техподдержкой, затем можно будет более точно сказать, сколько потребуется на проектирование..." -- это технические частности, которые бизнес совершенно не интересуют. Что правильно, по большому-то счету.
В общем, в таких ситуациях я оказывался неоднократно. Сейчас в чем-то даже проще, т.к. в одном лице являюсь и бизнес-шишкой и ведущим разработчиком, хотя шизофреничность ситуации наверняка еще даст о себе знать ;)
Итак, есть цели, есть приблизительные дедлайны. Можно попробовать разработать черновой план работ, идя от часа Ч в обратную сторону. Есть только маленькая проблемка -- нет совершенно никакого понятия о том, когда же в голове сформируется подходящее решение. Т.е. когда именно будет придуман тот вариант реализации, который позволит достичь поставленных целей, но при этом не сильно поломает совместимость, не ухудшит значительно производительность и не усложнит использование инструмента.
Получается чистой воды творческая работа, когда целыми днями плюешь в потолок перебираешь разные варианты, пытаясь если и не выдумать что-то, то хотя бы собрать хоть что-нибудь из разных кусков. И когда хоть какие-то контуры будущего решению начинают брезжить на горизонте и кажется, что вот, вот же оно... Как бац! Всплывает какой-нибудь вопрос, ответа на который нет, а поиски оного могут затянуться непонятно на сколько.
Вот тот вопрос, который подтолкнул к написанию этого поста (т.к. ну очень задолбало вновь и вновь прокручивать в голове разные варианты одного и того же):
В ситуации, когда агент имеет всего один приоритет доставки, общий для всех типов сообщений, нет никаких проблем с выбрасыванием самого старого сообщения из очереди. Но что, если сообщения типа M доставляются до агента из разных источников с разными приоритетами? Какое из сообщений типа M считать самым старым? Наиболее приоритетное? Наименее приоритетное? Учитывать ли при этом источник или это не важно?
Вот так, думаешь, думаешь, кажущееся работоспособным решение начинает обрастать мелкими подробностями и уже просится быть воплощенным хотя бы в виде прототипа. А потом раз, и вся библия нафиг! :)
Может это мне так везло в профессиональной жизни, но задачи на выдумывание чего-то такого-этакого встречались регулярно. И постоянно приходилось признавать, что нет способа заранее предсказать, сколько времени нужно будет на изобретение велосипеда придумывание решения. Можно только жестко ограничить это время. Типа: "Решение должно быть предложено к понедельнику. В понедельник подводим итог и приступаем к реализации того, что удалось выдумать. И не важно, будет ли придумано что-то хорошее. Что будет, то и реализуем!"
Собственно, время до истечения дедлайна превращается в постоянное насилование собственных мозгов. И озарение, если такое случается, происходит, как правило, опасно близко к окончанию отведенного времени. Помню случай, когда такое случилось буквально за пару часов до решающего совещания у заказчика, где нам предстояло представлять итоговое решение, на поиск которого мы брали несколько безрезультатно потраченных дней :)
После довольно пространного текста про предсказание сроков можно уделить несколько слов процессам разработки. Не смотря на то, что мне ближе итеративные процессы, когда после завершения каждой итерации в продукте появляется новая функциональность (полностью протестированная и задокументированная), к Agile-методикам вроде XP или SCRUM я отношусь хуже, чем к старому и много ругаемому "водопаду". Потому, что модель Waterfall легко заставить работать в режиме последовательных итераций. А вот браться со SCRUM-а за что-то большое и новое, где нужно что-то изобретать, с чем-то экспериментировать, создавать и выбрасывать прототипы... Крайне сомнительно это, на мой взгляд. Слишком уж распиаренный Agile пронизан принципами "некогда тут думать, бежать нужно" и "фигак-фигак и в продакшен". Слишком уязвим Agile к возникновению таких show-stopper вопросов, с одним из которых я сегодня столкнулся.
Это, конечно, мое личное мнение. Но Waterfall позволяет "день потерять, затем за час долететь", а вот Agile такого запаса прочности не имеет.
Комментариев нет:
Отправить комментарий