Комментарии 35
Казалось бы, всё это хорошо известно любому, кто хоть раз пытался оценить время разработки...
Такие статьи нужны, пусть они дублируют друг друга. Если есть шанс, что очередной менеджер прочитает и наконец поймёт как всё устроено «под капотом» процесса разработки, то я готов видеть подобные статьи хоть раз в неделю.
Менеджер… Самому бы понять. А то спросят тебя — когда сделаешь то-то — а ты бекаешь, мекаешь и ответить не можешь. И не сможешь, пока не спроектируешь систему — а это может быть половина работы.
Не могу это объяснить природу этого факта, но тем не менее — имеет место быть.
Природа-то понятна — "с опытом".
Но для компенсации — достаются более сложные задачи, которые и оценивать сложнее :-)
Может, ещё и ТЗ надо писать? Собирать требования?
Конечно, надо! Или Вы столкнетесь с проблемами определения трудоемкости, т.е. вознаграждения разработчику.
Казалось бы, что там сделал программист? Ну, написал приложение, выполняющее (по первоначальному заданию), например, 2 функции. А то, что к завершению проекта приложение выполняет уже 32 функции, для реализации которых пришлось написать еще несколько библиотек, многие могут уже и забыть (или вообще не знать)…
Поэтому, чем более проработан проект, в смысле ТЗ и прочих «бумажек», тем проще его реализовать, да и добавлять новые функции для расширения области применения.
Добавлять новые функции как раз сложнее при наличии полного ТЗ на продукт. Рано или поздно при добавлении окажутся противоречащие друг другу пункты и хорошо, если разработчик это заметит и спросит а каким руководствоваться. А трудоемкость можно не оценивать, а вознаграждать по факту.
И выбор методологии не должен быть не на основании ее «модности», а из расчета что больше подходит для конкретного проекта. Мне видится, что если есть конкретная цель, конечный набор функциональности, то можно работать по Waterfall. А если такого понимания нет или цель достигнута не может быть в принципе, то Agile. Хотя для получения минимальной рабочей версии продукта можно воспользоваться Waterfall.
Нужно быть гибкими и подстраивать процессы под текущие нужды, а не нужды под процессы. :)
P.S.
А еще мне кажется, что Agile/Scrum — это просто каскад маленьких Waterfall :)
А вот тут и проявляется технические экспертиза и опыт: Знать библиотеки под основные задачи, иметь навык проектирования api, знать стандартные протоколы и т.д.
Что является идентификатором книги? Название? Но как быть с разными изданиями? (Пример — Люди как боги Сергея Снегова имеют минимум 2 официальных издания, старое советское без третьей части — ее еще не было). ISBN? А нет у многих старых книг его.
А ведь бывают книги у которых реально много редакций.
И где мы будем брать список книг? C Goodreads будете брать? Ну ну удачи — там хватает книг где не заполнено поле тип редакции:Paperback/Hardback а также есть книги у которых тип — ebook хотя с данным ISBN и названием есть печатная книга (за что надо сказать спасибо тем альтернативно-умным товарищам кто использует один ISBN и для печатной и для электронной версии).
И кстати мне как пользователю приложения скажут что речь именно про печатные книги? После того как возьмут деньги за подписку? А то ведь оно не очевидно. Если электронные книги поддерживаются то как именно? Просто игнорируем проблемы с авторскими правами? Используемую какую то особенность конкретной DRM-системы? Используем тот же способ который ReDigi пробовала для легального обмена MP3?
всякое приложение — это лук
Воняет?
Доводит до слез?
Вот читаю ваши комменты и подташнивает. Вроде айтишная площадка, а такую тупую банальщину пишите..
Хорошая статья, спасибо. Простыми словами для меня, как заказчика (пусть даже внутреннего, пусть даже на банальные доработки 1С) о важном. И для меня как для начинающего разработчика — тоже.
«Решение — гонять по циклу доработки не приложение, а техническое задание»
Правильная мысль, но возможно лучше после альфа-версии? Когда заказчик видит минимальное воплощение в интерфейсе — иначе — зачастую, это тестирование «коня в вакууме».
И они правы. Фичи прекрасно выглядят в ТЗ, но к моменту выхода приложения менеджмент понимает что хочет другое.
Только реальное приложение можно показать тестовой группе и получить отзывы.
А заказчика меньше всего волнует процесс, его волнует результат. Поэтому на рынке будет выигрывать тот, кто покажет заказчику костыльное приложение вместо прилизанного ТЗ.
Реальность сильно отличается от идеала. Последний наш прислал свой брифинг типа ТЗ, а дизайн скриншотов заказал в студии дизайна. Функционал в ТЗ один, а на скриншотах дизайнеров совсем другой, потому что дизайнерам ТЗ тоже лениво и некогда читать было. И нам пришлось сидеть и все эти расхождения отлавливать. Плюс реально скринов нужно было под сотню, а прислали десяток, типа а что там непонятного, все остальное по аналогии. А там поля другие, опции другие, функции другие и т.д. и т.п.
Если бы мы ТЗ заказчику назад отфутболили — давай дорабатывай, то проекта и до сих пор бы не сделали. А так побубнили про себя, поскрипели и начали делать. И сделали, конечно. Потом местами переделывали за деньги заказчика.
Как правильно чистить лук, или Почему разработка ПО выходит из-под контроля