Comments 35
Казалось бы, всё это хорошо известно любому, кто хоть раз пытался оценить время разработки...
Это всё хорошо известно разработчику, но очень часто не известно заказчику.
Такие статьи нужны, пусть они дублируют друг друга. Если есть шанс, что очередной менеджер прочитает и наконец поймёт как всё устроено «под капотом» процесса разработки, то я готов видеть подобные статьи хоть раз в неделю.
Такие статьи нужны, пусть они дублируют друг друга. Если есть шанс, что очередной менеджер прочитает и наконец поймёт как всё устроено «под капотом» процесса разработки, то я готов видеть подобные статьи хоть раз в неделю.
Менеджер… Самому бы понять. А то спросят тебя — когда сделаешь то-то — а ты бекаешь, мекаешь и ответить не можешь. И не сможешь, пока не спроектируешь систему — а это может быть половина работы.
Заметил, что с опытом развивается некоторая «чуйка», которая позволяет более-менее на глаз определять сколько займёт времени определённая задача. Даже с учётами возможных форс-мажоров.
Не могу это объяснить природу этого факта, но тем не менее — имеет место быть.
Не могу это объяснить природу этого факта, но тем не менее — имеет место быть.
Как показывает практика это даже не всегда знакомо тех-лиду
А как же быстрая и гибкая разработка? Как же «прототипы быстро, ещё быстрее»? Может, ещё и ТЗ надо писать? Собирать требования? IDEF0 и DFD разрисовывать, упаси боже?
Может, ещё и ТЗ надо писать? Собирать требования?
Конечно, надо! Или Вы столкнетесь с проблемами определения трудоемкости, т.е. вознаграждения разработчику.
Казалось бы, что там сделал программист? Ну, написал приложение, выполняющее (по первоначальному заданию), например, 2 функции. А то, что к завершению проекта приложение выполняет уже 32 функции, для реализации которых пришлось написать еще несколько библиотек, многие могут уже и забыть (или вообще не знать)…
Поэтому, чем более проработан проект, в смысле ТЗ и прочих «бумажек», тем проще его реализовать, да и добавлять новые функции для расширения области применения.
Кто-то не может в сарказм…
Добавлять новые функции как раз сложнее при наличии полного ТЗ на продукт. Рано или поздно при добавлении окажутся противоречащие друг другу пункты и хорошо, если разработчик это заметит и спросит а каким руководствоваться. А трудоемкость можно не оценивать, а вознаграждать по факту.
Чем-то напоминает сравнение Waterfall и Scrum :)
Скорее даже Waterfall и Agile. Причем, это первая статья, из тех, что я видел, где опускают Agile и превозносят Waterfall. Во всех остальных было наоборот.
Кто-то должен был :) Последнее время я склоняюсь к мысли, что если команда отличная, то какую методологию не выбери — результат будет хорошим. :)
И выбор методологии не должен быть не на основании ее «модности», а из расчета что больше подходит для конкретного проекта. Мне видится, что если есть конкретная цель, конечный набор функциональности, то можно работать по Waterfall. А если такого понимания нет или цель достигнута не может быть в принципе, то Agile. Хотя для получения минимальной рабочей версии продукта можно воспользоваться Waterfall.
Нужно быть гибкими и подстраивать процессы под текущие нужды, а не нужды под процессы. :)
P.S.
А еще мне кажется, что Agile/Scrum — это просто каскад маленьких Waterfall :)
И выбор методологии не должен быть не на основании ее «модности», а из расчета что больше подходит для конкретного проекта. Мне видится, что если есть конкретная цель, конечный набор функциональности, то можно работать по Waterfall. А если такого понимания нет или цель достигнута не может быть в принципе, то Agile. Хотя для получения минимальной рабочей версии продукта можно воспользоваться Waterfall.
Нужно быть гибкими и подстраивать процессы под текущие нужды, а не нужды под процессы. :)
P.S.
А еще мне кажется, что Agile/Scrum — это просто каскад маленьких Waterfall :)
А это мы еще даже не начали писать код. Ведь на техническом уровне каждая такая «функциональность» углубляется еще примерно на столько же: использовать библиотеку или самописный код? Какие классы, модули, функции у нас будут? Какую версию ОС мы планируем поддерживать? Храним на диске или в памяти? Что именно мы храним на диске, в каком формате и почему? Как реагирует сервер, если мы пришлем ему запрос на несуществующую книгу? Long, Int или GUID? Табы или пробелы…
А вот тут и проявляется технические экспертиза и опыт: Знать библиотеки под основные задачи, иметь навык проектирования api, знать стандартные протоколы и т.д.
А собственно что есть книга?
Что является идентификатором книги? Название? Но как быть с разными изданиями? (Пример — Люди как боги Сергея Снегова имеют минимум 2 официальных издания, старое советское без третьей части — ее еще не было). ISBN? А нет у многих старых книг его.
А ведь бывают книги у которых реально много редакций.
И где мы будем брать список книг? C Goodreads будете брать? Ну ну удачи — там хватает книг где не заполнено поле тип редакции:Paperback/Hardback а также есть книги у которых тип — ebook хотя с данным ISBN и названием есть печатная книга (за что надо сказать спасибо тем альтернативно-умным товарищам кто использует один ISBN и для печатной и для электронной версии).
И кстати мне как пользователю приложения скажут что речь именно про печатные книги? После того как возьмут деньги за подписку? А то ведь оно не очевидно. Если электронные книги поддерживаются то как именно? Просто игнорируем проблемы с авторскими правами? Используемую какую то особенность конкретной DRM-системы? Используем тот же способ который ReDigi пробовала для легального обмена MP3?
Что является идентификатором книги? Название? Но как быть с разными изданиями? (Пример — Люди как боги Сергея Снегова имеют минимум 2 официальных издания, старое советское без третьей части — ее еще не было). ISBN? А нет у многих старых книг его.
А ведь бывают книги у которых реально много редакций.
И где мы будем брать список книг? C Goodreads будете брать? Ну ну удачи — там хватает книг где не заполнено поле тип редакции:Paperback/Hardback а также есть книги у которых тип — ebook хотя с данным ISBN и названием есть печатная книга (за что надо сказать спасибо тем альтернативно-умным товарищам кто использует один ISBN и для печатной и для электронной версии).
И кстати мне как пользователю приложения скажут что речь именно про печатные книги? После того как возьмут деньги за подписку? А то ведь оно не очевидно. Если электронные книги поддерживаются то как именно? Просто игнорируем проблемы с авторскими правами? Используемую какую то особенность конкретной DRM-системы? Используем тот же способ который ReDigi пробовала для легального обмена MP3?
UFO just landed and posted this here
всякое приложение — это лук
Воняет?
Доводит до слез?
UML use case diagrams?
Про разработку ПО существует очень-очень много литературы. Ее было бы сильно меньше, если бы авторы новых, как им кажется, идей ссылались на предшествующие идеи. Хотя бы для того, чтобы показать новизну своей. Так читателю будет понятнее. А когда автор начинает с пустого места, будто до него ничего в этом плане не предлагалось, то мне, как читателю, начинает казаться, что автор просто заменил ранее предложенные термины на свои собственные. В частности, мне показалось, что сказанное в статье сильно напоминает классические методы разработки: разработку сверху вниз и разработку снизу вверх. Не нашел и привычного по классической литературе термина «детализация проекта». Возможно, мне только показалось, поэтому я не утверждаю, а задаю вопрос: что конкретно в предложенном подходе абсолютно новое, а что совпадает с предложенным ранее?
Если автор будет ссылаться на термины типа «разработка сверху вниз», заказчику или менеджеру все равно не станет понятнее «а почему так долго?». Нового здесь ничего нет, статья не для разработчиков ПО, а для тех, кто к ним обращается.
Вместо детализации часто используется понятие «декомпозиция» (те, кто использовал по учебе или работе IDEF, DFD и прочие нотации с ним знакомы).
Вот читаю ваши комменты и подташнивает. Вроде айтишная площадка, а такую тупую банальщину пишите..
Это может показаться банальщиной, если вы каждый день собираете требования и функции с заказчика. А если вы годами кодили по ТЗ, причем написанному уже в терминах эксплуатируемой ИС и в терминах разработки более старшими коллегами, и тут, по какой-либо причине, вышли на фриланс, то статья может оказаться разницей между первым положительным отзывом и первым отрицательным отзывом в профиле.
Хорошая статья, спасибо. Простыми словами для меня, как заказчика (пусть даже внутреннего, пусть даже на банальные доработки 1С) о важном. И для меня как для начинающего разработчика — тоже.
Хорошая аналогия! Повеселило :)
«Решение — гонять по циклу доработки не приложение, а техническое задание»
Правильная мысль, но возможно лучше после альфа-версии? Когда заказчик видит минимальное воплощение в интерфейсе — иначе — зачастую, это тестирование «коня в вакууме».
«Решение — гонять по циклу доработки не приложение, а техническое задание»
Правильная мысль, но возможно лучше после альфа-версии? Когда заказчик видит минимальное воплощение в интерфейсе — иначе — зачастую, это тестирование «коня в вакууме».
В принципе, интересная статься, особенно если хорошенько задуматься над темой:)
Классная статья! Прям напомнило первых заказчиков, которым нужна была «простейшая программа» по учёту фотобумаги и плёнки )
Проблема в том, что менеджеры хотят пощупать реализацию руками.
И они правы. Фичи прекрасно выглядят в ТЗ, но к моменту выхода приложения менеджмент понимает что хочет другое.
Только реальное приложение можно показать тестовой группе и получить отзывы.
И они правы. Фичи прекрасно выглядят в ТЗ, но к моменту выхода приложения менеджмент понимает что хочет другое.
Только реальное приложение можно показать тестовой группе и получить отзывы.
К сожалению у разработки ПО есть один довольно значительный аспект. Обычно за его разработку нужно платить деньги разработчику, а эти деньги нужно взять у заказчика.
А заказчика меньше всего волнует процесс, его волнует результат. Поэтому на рынке будет выигрывать тот, кто покажет заказчику костыльное приложение вместо прилизанного ТЗ.
А заказчика меньше всего волнует процесс, его волнует результат. Поэтому на рынке будет выигрывать тот, кто покажет заказчику костыльное приложение вместо прилизанного ТЗ.
Предложение гонять ТЗ теоретически хорошее, но не всегда практически реализуемое. Заказчики разные бывают и не всех хотят и умеют думать, да еще тратить на обдумывание свое время.
Реальность сильно отличается от идеала. Последний наш прислал свой брифинг типа ТЗ, а дизайн скриншотов заказал в студии дизайна. Функционал в ТЗ один, а на скриншотах дизайнеров совсем другой, потому что дизайнерам ТЗ тоже лениво и некогда читать было. И нам пришлось сидеть и все эти расхождения отлавливать. Плюс реально скринов нужно было под сотню, а прислали десяток, типа а что там непонятного, все остальное по аналогии. А там поля другие, опции другие, функции другие и т.д. и т.п.
Если бы мы ТЗ заказчику назад отфутболили — давай дорабатывай, то проекта и до сих пор бы не сделали. А так побубнили про себя, поскрипели и начали делать. И сделали, конечно. Потом местами переделывали за деньги заказчика.
Реальность сильно отличается от идеала. Последний наш прислал свой брифинг типа ТЗ, а дизайн скриншотов заказал в студии дизайна. Функционал в ТЗ один, а на скриншотах дизайнеров совсем другой, потому что дизайнерам ТЗ тоже лениво и некогда читать было. И нам пришлось сидеть и все эти расхождения отлавливать. Плюс реально скринов нужно было под сотню, а прислали десяток, типа а что там непонятного, все остальное по аналогии. А там поля другие, опции другие, функции другие и т.д. и т.п.
Если бы мы ТЗ заказчику назад отфутболили — давай дорабатывай, то проекта и до сих пор бы не сделали. А так побубнили про себя, поскрипели и начали делать. И сделали, конечно. Потом местами переделывали за деньги заказчика.
Sign up to leave a comment.
Как правильно чистить лук, или Почему разработка ПО выходит из-под контроля