Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 121
И как люди жили до Getting Real?..
Есть-же полный перевод — gettingreal.37signals.com/GR_rus.php
Когда делаешь проект «для себя» — возможно так оно и лучше, хотя довольно спорно. А как быть с разработкой на заказ? По чему делать предвартельную оценку проекта? Как доказать заказчику что проект выполнен, либо исполнителю, что проект еще не завершен?
В условиях постоянной стабильной команды, работающей над «своими» проектами многие инструменты оказываются абузой, но каков процент таких команд?
В условиях постоянной стабильной команды, работающей над «своими» проектами многие инструменты оказываются абузой, но каков процент таких команд?
Если проект для вас очевиден, вы уже разрабатывали подобные вещи (книга про сайты — принципиально новые сайты делаются редко), вы хорошо знаете предметную область — наверное все получится и без всяких спецификаций.
Если же предметная область команде незнакома, проект хоть немного сложен, раньше никто подобных вещей не делал (или, что тоже самое, вы не смогли найти работающий прототип), объем работ и сроки исполнения нужно сгласовывать с руководством — без предварительного изучения темы, проектирования и спецификаций просто никуда.
Авторы книги правы в том, что чем раньше перейти к прототипам пользовательского интерфейса — тем лучше. Но если в проекте есть много «белых пятен», он сложен технически или в нем просто нет пользовательского интерефейса хорошая спецификация необходима.
Если же предметная область команде незнакома, проект хоть немного сложен, раньше никто подобных вещей не делал (или, что тоже самое, вы не смогли найти работающий прототип), объем работ и сроки исполнения нужно сгласовывать с руководством — без предварительного изучения темы, проектирования и спецификаций просто никуда.
Авторы книги правы в том, что чем раньше перейти к прототипам пользовательского интерфейса — тем лучше. Но если в проекте есть много «белых пятен», он сложен технически или в нем просто нет пользовательского интерефейса хорошая спецификация необходима.
> Если же предметная область команде незнакома
Вот это ключевая фраза, как только она появляется, качественных спецификаций не будет. Спецификации можно писать только на мелкие компоненты, где можно достаточно уверенно представлять процесс разработки. Ну то есть спецификации рулят в тактике и сосут в стратегии.
Вот это ключевая фраза, как только она появляется, качественных спецификаций не будет. Спецификации можно писать только на мелкие компоненты, где можно достаточно уверенно представлять процесс разработки. Ну то есть спецификации рулят в тактике и сосут в стратегии.
Если предметная область команде незнакома, то команда садится изучать предметную область и описывать свое понимание будущего проекта. В модели «водопад» это будет то, что называют аван-проектированием или эскизным проектированием. На выходе получится обобщенная спецификация (концепция) продукта и, может быть, какие-то макеты.
Из этой спецификации станет понятно, какие же компоненты нужны для оптимального решения задачи и уже эти компоненты (и связи между ними) можно будет специфицировать подробно.
А если нет концепции и общей спецификации, откуда возьмется список компонентов? Если задача тривиальная (очередной web-форум или сайт-визитка), то исходя из опыта. Если же задача новая и опыта в ее решении нет, лучше потрудиться и написать спецификацию, исходя из которой и двигаться дальше.
Из этой спецификации станет понятно, какие же компоненты нужны для оптимального решения задачи и уже эти компоненты (и связи между ними) можно будет специфицировать подробно.
А если нет концепции и общей спецификации, откуда возьмется список компонентов? Если задача тривиальная (очередной web-форум или сайт-визитка), то исходя из опыта. Если же задача новая и опыта в ее решении нет, лучше потрудиться и написать спецификацию, исходя из которой и двигаться дальше.
Да ничего команда не наизучает, единственный работающий здесь метод (для сложных систем) — это одна-две нерабочие итерации продукта. Либо полное погружение в предметную область, что малореально и обычно бывает только если разработчики трудятся над внутренним проектом компании.
Не единственный.
А что вы будете делать, если даже по предварительной оценке трудоемкость проекта — много человеко-лет, соответствующая стоимость разработки и цена ошибки?
Нерабочие прототипы в натуральную величину станете выпускать или потратите пару лет на изучение предметной области? Это не отменяет прототипирования, но приступая к изготовлению прототипа уже надо понимать, чего нужно получить в идеале. Иначе такой прототип — бесполезный расход ресурсов.
Нерабочие прототипы в натуральную величину станете выпускать или потратите пару лет на изучение предметной области? Это не отменяет прототипирования, но приступая к изготовлению прототипа уже надо понимать, чего нужно получить в идеале. Иначе такой прототип — бесполезный расход ресурсов.
russian.joelonsoftware.com/PainlessSpecs/1.html
Не раз выручало при написании спецификации…
Не раз выручало при написании спецификации…
Вам бы могла помочь не спецификация а разработка ux.
Как и большинство общих фраза, фраза «спецификация — бесполезна» неверна. Ведь в момент написания спецификации ты задумываешься, а что вообще будет делать софт, кому это нужно, зачем это нужно и пр.
При этом конечный софт, скорее всего, будет отличаться от исходной спецификации, но не во всем же.
Разработка софта — процесс итеративный, и это нормально, когда ты допиливаешь спецификации и уточняешь требования по ходу выполнения. И я согласен с Линусом — слепое следование спецификации вряд ли позволит сделать лучший продукт.
При этом конечный софт, скорее всего, будет отличаться от исходной спецификации, но не во всем же.
Разработка софта — процесс итеративный, и это нормально, когда ты допиливаешь спецификации и уточняешь требования по ходу выполнения. И я согласен с Линусом — слепое следование спецификации вряд ли позволит сделать лучший продукт.
Если конечно, в качестве модели жизненного цикла ПО не была выбрана каскадная =)
Не соглашусь. Автор говорит о том, что спецификации — зло, в традиционном их понимании. Тоесть он понимает спецификацию как документ, который утверждается один раз и описывает все функциональные требования, требования к дизайну и т д. С тем, что такой подход — зло, я полность согласен. Объясню почему (возможно я идеалист, но все же). Конечной целью и заказчика софта, и разработчика — является завершение проекта в срок и на достойном уровне (чтобы он обладал всеми нужными функциями). Спецификация, как и макет интерфейса, и просто список основных задач разрабатываемой системы на клочке бумаги — служат для того, чтобы разработчик и\или заказчик понимал, что нужно сделать и\или что уже сделано в проекте. Зачем же тогда закреплять эти «документы» подписями или строить точки невозвращения. Вот хороший подход (на мой взгляд) к разработке проекта (своего или на заказ не важно):
Во-первых, пообщаться с заказчиком и постараться вникнуть в предметную область. При этом нужно спрашивать все, что придет в голову (это иногда помогает выйти на сложные места или увидеть подводные камни).
Во-вторых, хорошенько обдумать услышанное (или записанное). Не надо садится за компьютер и писать драфты ФТ. Просто обдумайте все досканально (на это боычно у меня уходит от 3х дней до недели).
В-третьих, зарисовать самую базовую функциональную схему продукта. Пусть она будет совершенно абстрактной и нелепой, главное, чтобы отражала суть. По схеме можно продумать как будет работать (и из чего состоять в реальном проекте) тот или иной нарисованный вами квадратик на схеме.
И на конец можно приступать к написанию архитектуры и рисовтаь прототипы интерфейсов (которые и надо показывать заказчику как можно чаще, чтобы не уйти в дебри).
Я это все к тому, что понимание и структура системы хранится всегда в голове. Как ни крути. Если нет хорошего понимания (а без длительного обдумывания его не будет) — никакая спецификация не поможет.
Во-первых, пообщаться с заказчиком и постараться вникнуть в предметную область. При этом нужно спрашивать все, что придет в голову (это иногда помогает выйти на сложные места или увидеть подводные камни).
Во-вторых, хорошенько обдумать услышанное (или записанное). Не надо садится за компьютер и писать драфты ФТ. Просто обдумайте все досканально (на это боычно у меня уходит от 3х дней до недели).
В-третьих, зарисовать самую базовую функциональную схему продукта. Пусть она будет совершенно абстрактной и нелепой, главное, чтобы отражала суть. По схеме можно продумать как будет работать (и из чего состоять в реальном проекте) тот или иной нарисованный вами квадратик на схеме.
И на конец можно приступать к написанию архитектуры и рисовтаь прототипы интерфейсов (которые и надо показывать заказчику как можно чаще, чтобы не уйти в дебри).
Я это все к тому, что понимание и структура системы хранится всегда в голове. Как ни крути. Если нет хорошего понимания (а без длительного обдумывания его не будет) — никакая спецификация не поможет.
А если конкретно взятую голову переехало трактором — капец проекту?
Да, конечно. Если кого-то переедет трактор — стартап развалится, хоть со спекой, хоть без. На то он и стартап.
Я вообще-то не про стартап речь веду, а про проект. Или у вас в компании на каждый новый проект создают отдельную фирму/стартап?
Проект должен быть документирован настолько, чтоб переезд отдельно взятой головы на успех проекта не оказывал критического влияния. Да, возникнут задержки, но проект продолжится и успешно завершится.
А значит и спецификация должна быть.
Проект должен быть документирован настолько, чтоб переезд отдельно взятой головы на успех проекта не оказывал критического влияния. Да, возникнут задержки, но проект продолжится и успешно завершится.
А значит и спецификация должна быть.
«6 причин, по которым вам не стоит писать плохие функциональные спецификации»
Ага, а вы позовите, пожалуйста, меня, как встретите хорошую спецификацию на крупнуюсистему.
А это как бы другая проблема — не стоит сразу описывать всё глобально и на века. Есть общая идеология, а есть частные моменты реализации отдельных частей. И то, и другое может со временем поменяться — но изначально должно быть как-то описано и продумано. Но не целиком от первой строки до 100000 клиентов, конечно.
Мне труднее привести пример большой системы (>1 программиста), написанной без спецификаций.
О, это легко.
Система онлайн-торгов, интегрированная с парой подсистем SAP для внутреннего документооборота одной из крупнейших корпораций России. Восемь программистов со стороны торгов (на пике разработки), еще несколько — со стороны SAP.
""«find. -name „*.py“ | xargs wc -l»"" говорит, что это 130 тыс строк кода на питоне и там еще примерно 20-30 тыс на sql и pl/sql. Это чисто со стороны торгов, не знаю уж, что там в SAP.
Проект длился год, перешел в проект-продолжение и длится до сих пор.
Плюс армия менеджеров с обеих сторон (заказчика и исполнителя), которые пытались что-то там специфицировать иной раз с нашей помощью. В итоге мы задолбались ждать, начали делать как делается, демонстрировать, исправляли уже по ходу процесса, а заветная спецификация (которая формально должна была опережать работы) подтягивалась с отставанием на месяц-полтора.
Ибо сам заказчик не слишком твердо представлял, чего мы хотим добиться.
Система онлайн-торгов, интегрированная с парой подсистем SAP для внутреннего документооборота одной из крупнейших корпораций России. Восемь программистов со стороны торгов (на пике разработки), еще несколько — со стороны SAP.
""«find. -name „*.py“ | xargs wc -l»"" говорит, что это 130 тыс строк кода на питоне и там еще примерно 20-30 тыс на sql и pl/sql. Это чисто со стороны торгов, не знаю уж, что там в SAP.
Проект длился год, перешел в проект-продолжение и длится до сих пор.
Плюс армия менеджеров с обеих сторон (заказчика и исполнителя), которые пытались что-то там специфицировать иной раз с нашей помощью. В итоге мы задолбались ждать, начали делать как делается, демонстрировать, исправляли уже по ходу процесса, а заветная спецификация (которая формально должна была опережать работы) подтягивалась с отставанием на месяц-полтора.
Ибо сам заказчик не слишком твердо представлял, чего мы хотим добиться.
Система, в общем-то, умеренно крупная, но суть дела отражает.
Заранее всего описать нельзя!
Заранее всего описать нельзя!
Я как-то раз работал в проекте, в котором действительно не было спецификаций. И каждай раз уже после этапа программирования и отладки у заказкика всплывала «деталь», из-за которой многое приходилось переделывать.
Конечно, переписывать программы — неотъемлемая часть жизни программиста. Но спецификации позволяют все же повысить эффективность и качестко выходного продукта.
Спасибо за интересынй пример, думаю мы согласны в сути вопроса, а спорим о частностаях.
Конечно, переписывать программы — неотъемлемая часть жизни программиста. Но спецификации позволяют все же повысить эффективность и качестко выходного продукта.
Спасибо за интересынй пример, думаю мы согласны в сути вопроса, а спорим о частностаях.
Думаете, при наличии спецификаций деталей бы не возникло? :) Ну-ну. И в любом случае фиг докажешь, что не дожен был что-то делать!
Даже самый банальный сайтик типа «новости-контакты-о нас-товары» после подробнейшего обсуждения и реализации не обойдется без функциональных правок, чего уж говорить о системах, реализующих нетривиальные бизнес-процессы!
Даже самый банальный сайтик типа «новости-контакты-о нас-товары» после подробнейшего обсуждения и реализации не обойдется без функциональных правок, чего уж говорить о системах, реализующих нетривиальные бизнес-процессы!
«Ибо сам заказчик не слишком твердо представлял, чего мы хотим добиться.»
Так кто на кого работал в итоге? Вы делали что-то свое, а заказчик пытался понять, сможет ли он это применить на практике? Бардак какой-то, простите за выражение :)
Так кто на кого работал в итоге? Вы делали что-то свое, а заказчик пытался понять, сможет ли он это применить на практике? Бардак какой-то, простите за выражение :)
А удачно ли использовать слово «спецификация»? В моей практике его использования — это некий документ, описывающий готовый продукт.
Классический контр-пример: ситуация из книги «Deadline» Тома Демарко. Простите, не буду объяснять, что к чему. Кто читал, тот понял.
Без спецификации никак не прожить в мире промышленного программирования. Перед тем, как браться за разработку сложной системы, нужно сначала детальнейше её описать. Это и называется спецификацией. Подходы любимых мною 37signals здесь не работают.
Без спецификации никак не прожить в мире промышленного программирования. Перед тем, как браться за разработку сложной системы, нужно сначала детальнейше её описать. Это и называется спецификацией. Подходы любимых мною 37signals здесь не работают.
Спецификация — очень подробное описание. В системах, тем более — сложных, очень много нюансов, и ни один разработчик и/или потенциальный пользователь не способен их предусмотреть.
Если специфицирование небольших этапов представить возможно, то делать полномасштабный «водопад» — смерти подобно.
Лучшее, на что можно расчитывать — обобщенное ТЗ на весь срок разработки и подробное планирование результатов двух-трех недельной работы.
Либо разработчики просто плюнут в какой-то момент на менеджерские заморочки — и будут делать как делается.
Как раз таки в масштабах 37signals планирование возможно, а вот в действительно больших — это проблема.
Если специфицирование небольших этапов представить возможно, то делать полномасштабный «водопад» — смерти подобно.
Лучшее, на что можно расчитывать — обобщенное ТЗ на весь срок разработки и подробное планирование результатов двух-трех недельной работы.
Либо разработчики просто плюнут в какой-то момент на менеджерские заморочки — и будут делать как делается.
Как раз таки в масштабах 37signals планирование возможно, а вот в действительно больших — это проблема.
Ага, у нас ТЗ улетело в мусорку после второго показа заказчику и получения ответа: «Да, все как тут написано, но не то, что надо»
Я понимаю ваше неприятие «полномасштабной» спецификации. =) Но иногда людям приходится делать, казалось бы, невозможное!
К примеру, давайте представим, что нам нужно разработать национальную медицинскую информационную систему. Или, раз уж заговорили о Deadline, национальную систему управления аэропортами и авиаперелётами.
В обоих этих примерах не обойтись без серьёзного планирования и продумывания каждой детали. Сначала детальное планирование, потом код. В книге, кстати, на код отводится лишь шестая часть времени разработки, остальное — написание спецификации.
К примеру, давайте представим, что нам нужно разработать национальную медицинскую информационную систему. Или, раз уж заговорили о Deadline, национальную систему управления аэропортами и авиаперелётами.
В обоих этих примерах не обойтись без серьёзного планирования и продумывания каждой детали. Сначала детальное планирование, потом код. В книге, кстати, на код отводится лишь шестая часть времени разработки, остальное — написание спецификации.
Да, знаю такой подход, за такие принципы очень любят явистов подкалывать..! Полгода проектируют, три месяца пишут, год поддерживают исправлениями :)
Если серьезней. Ну не верю в полное планирование, не верю. Понимаю, что можно примерно прикинуть какие-то подсистемы, ориентировочно интерфейсы взамодействия, но все… Ну нет — и все тут :)
Это возможно только если в наличии реальный многолетний опыт построения аналогичных в функционале систем — когда наперед известны все потенциальные проблемы :)
Если серьезней. Ну не верю в полное планирование, не верю. Понимаю, что можно примерно прикинуть какие-то подсистемы, ориентировочно интерфейсы взамодействия, но все… Ну нет — и все тут :)
Это возможно только если в наличии реальный многолетний опыт построения аналогичных в функционале систем — когда наперед известны все потенциальные проблемы :)
Ну как же разработка через тестирование? Вы тоже считаете, что невозможно сначала написать тест-скрипты, тест-кейсы перед тем как не написан код?
А при чем здесь TDD? тесты есть тесты, они сами по себе важны и полезны.
Это совсем уж локальный инструмент, при помощи которого разработчик поддерживает работоспособность кода. TDD — подход к написанию программ; никак не планированию.
Это совсем уж локальный инструмент, при помощи которого разработчик поддерживает работоспособность кода. TDD — подход к написанию программ; никак не планированию.
Ну как… на чем будет основываться тесты если у вас нет ни спецификации ни кода, а только общее понимание и представление того, что будет?
P.S. Не холивара и тролинга ради, а понять суть для.
P.S. Не холивара и тролинга ради, а понять суть для.
Я вижу это так.
Реально возможно более-менее подробно определить очень локальные задачки на неделю-две-три вперед, сформулировать их в каких-то узких документах.
Под это и пишутся тесты, юнит- и функциональные.
Более того, совершенно не представляю, как можно писать какие-то тесты наперед, когда системы еще нет..!
Реально возможно более-менее подробно определить очень локальные задачки на неделю-две-три вперед, сформулировать их в каких-то узких документах.
Под это и пишутся тесты, юнит- и функциональные.
Более того, совершенно не представляю, как можно писать какие-то тесты наперед, когда системы еще нет..!
Системы нет, но есть хоть какие-то требования (вход, выход, алгоритмы преобразования). Пишем тест, что алгоритм (тестируемый код), примененный к входным данным даёт выходные данные. Реализуем, чтобы тест выполнился, показываем заказчику, он говорит что не так и/или что ещё хочет. В теории так можно сделать систему полностью устраивающую заказчика, хотя первоначальные требования были «шоб компутер сделал всё пи… то»
Сильное упрощение!
Вход, выход, скорость работы и другие внешние параметры алгоритма — это характеризует очень небольшой отдельный участок работы. Скажем, недельный.
Но мы-то, разработчики понимаем, что подход к написанию ста строк кода не масштабируется на сто тысяч или миллион!
Вход, выход, скорость работы и другие внешние параметры алгоритма — это характеризует очень небольшой отдельный участок работы. Скажем, недельный.
Но мы-то, разработчики понимаем, что подход к написанию ста строк кода не масштабируется на сто тысяч или миллион!
Может и масштабироваться. Главный недостаток такого подхода, по-моему, невозможность даже приблизительно оценить время на разработку (если аналогичных разработок не делалось), но вовсе не невозможность его применени в принципе на проекты из миллиона строк кода. С другой стороны — написать спецификацию, которая опишет всё и вся, на этот же миллион строк в реальных проектах, имхо, не реально. Вывод: нужно искать золотую середину, скажем набирать спецификаций на пару месяцев вперёд, реализовывать их, набирать новые и менять уже реализованные. Главное изначально объяснить заказчику, что очередное его «хочу» может вылиться в переписывание чуть ли не всего проекта.
На всякий случай приведу записки мистера Томпкинса по этому поводу:
Туманные спецификации
• Неясность спецификации говорит о том, что между участниками проекта есть неразрешенные конфликты.
• Спецификация, в которой нет списка типов входящей и исходящей информации, не должна даже приниматься к рассмотрению. Это значит, что она попросту ничего не специфицирует.
• Никто никогда не скажет вам, что спецификация плоха. Люди скорее будут обвинять себя в неспособности понять написанное, чем ругать авторов спецификации.
• Неясность спецификации говорит о том, что между участниками проекта есть неразрешенные конфликты.
• Спецификация, в которой нет списка типов входящей и исходящей информации, не должна даже приниматься к рассмотрению. Это значит, что она попросту ничего не специфицирует.
• Никто никогда не скажет вам, что спецификация плоха. Люди скорее будут обвинять себя в неспособности понять написанное, чем ругать авторов спецификации.
Как же «надо» работать? По четкой спецификации или без нее? Думаю, что все зависит от характера команды и каждого человека в нее входящего. Лично я (в моей нынешней команде) НЕ МОГУ работать по спецификации. Я стараюсь досканально понять нужны конечного заказчика и делать все по своему здравому смыслу, часто показывая промежуточный результат.
Кстати как пример — система с немколькими медиасерверами, биллингом, сервером отчетов клиентам, мервером рассылок и интегрированныя с вКонтакте, Facebook (я о глубокой интеграции). Была сделана 4мя программистами БЕЗ спецификации вообще. Работает как часы (тьфу-тьфу).
Кстати как пример — система с немколькими медиасерверами, биллингом, сервером отчетов клиентам, мервером рассылок и интегрированныя с вКонтакте, Facebook (я о глубокой интеграции). Была сделана 4мя программистами БЕЗ спецификации вообще. Работает как часы (тьфу-тьфу).
1. а что будет, если эту систему отдадут на поддержку другой команде?
2. сколько времени эти 4 программиста потратили на согласование всех работ между собой?
3. взаимодействие частей системы друг с другом описаны в каком-то документе? если да, то не в спецификации ли?
2. сколько времени эти 4 программиста потратили на согласование всех работ между собой?
3. взаимодействие частей системы друг с другом описаны в каком-то документе? если да, то не в спецификации ли?
1. Эта система наш личный проект — не отдадут (если отдадут, придется документировать, но делать это заранее считаю глупостью запредельной)
2. В сумме (проект длился около года) часов 10-15
3. Нет. Скажу даже больше. По всей системе нет ни одного документа вообще
Дело в том, что каждый программист пишет свой, совершенно автономный модуль (я писал биллинговую систему). При таком подходе, все, что нужно знать о других частях системы — это интерфейс взаимодействия. На его обсуждение (и запись на бумажке, которую повесил над ноутом на стенке) мы потратили 10-15 часов.
2. В сумме (проект длился около года) часов 10-15
3. Нет. Скажу даже больше. По всей системе нет ни одного документа вообще
Дело в том, что каждый программист пишет свой, совершенно автономный модуль (я писал биллинговую систему). При таком подходе, все, что нужно знать о других частях системы — это интерфейс взаимодействия. На его обсуждение (и запись на бумажке, которую повесил над ноутом на стенке) мы потратили 10-15 часов.
Вообще такого рода дискуссии — типичный «holy war». Все зависит от задачи и от команды в целом. Главное — здравый смысл в подходе к задаче — все остальное блаж.
А каков протокол в случае нахождения в работе вашей системы аномального поведения?
Протокол следующий.
1). Андрюха говорит — «что за ересь происходит, звонки не проходят на американские номера».
2). Я — «Хм… Ща посмотрю (смотрю БД, логи). Ааа понятно короче, ща починю (чиню). Пробуй»
3). Андрюха — «Нормал — терь работает»
Вот примерно такой. Такая система жизнеспособна на 100%.
1). Андрюха говорит — «что за ересь происходит, звонки не проходят на американские номера».
2). Я — «Хм… Ща посмотрю (смотрю БД, логи). Ааа понятно короче, ща починю (чиню). Пробуй»
3). Андрюха — «Нормал — терь работает»
Вот примерно такой. Такая система жизнеспособна на 100%.
Я искренне рад за вашу жизнеспособную систему. =) Это прекрасно, когда 4 увлечённых одним делом человека так хорошо срабатываются. Этакий маленький уютный междусобойчик.
А управление рисками, планирование, оценку качества оставьте другим, у вас и без них, судя по всему, всё хорошо получается.
Все эти понятия, которые я упомянул, не являются вещами в себе. Все они были придуманы и предназначены для решения какого-то круга задач. Если эти задачи не встают перед коллективом, то и нечего себя ими перегружать.
А управление рисками, планирование, оценку качества оставьте другим, у вас и без них, судя по всему, всё хорошо получается.
Все эти понятия, которые я упомянул, не являются вещами в себе. Все они были придуманы и предназначены для решения какого-то круга задач. Если эти задачи не встают перед коллективом, то и нечего себя ими перегружать.
Авторы Getting Real приводят примеры только исходя из опыта веб-разработки где такой подход работает, но сама индустрия разработки ПО существует уже около 50-60 и поверьте спецификации появились не от лёгкой жизни. Попробуйте реализировать протокол LIN где только основные части протокола на 500 страниц без спецификации.
Where is no silver bullet.
Где-то подход Agile работает, а где-то более уместен waterfall.
Where is no silver bullet.
Где-то подход Agile работает, а где-то более уместен waterfall.
=) Спасибо. Я прекрасно на своём опыте знаком с некоторым количеством методик по управлению разработкой ПО. Не одним Agile индустрия живёт.
А вы в курсе, что сейчас Agile в западных менеджерских кругах уже считается не до конца верным? Я последнее время часто вижу критические статьи на данную тему.
То есть предпочтение отдается вечной золотой середине, не полному планированию, но и не супергибкому недельному планированию.
То есть предпочтение отдается вечной золотой середине, не полному планированию, но и не супергибкому недельному планированию.
Классический контр-пример: ситуация из книги «Deadline» Тома Демарко. Простите, не буду объяснять, что к чему. Кто читал, тот понял.А кто не читал, тот не понял.
Тут скорей описаны проблемы бездумного следования написанному и, прежде всего, необдуманное написание написание спецификаций. Собственно что есть спека? Ну, в правильном варианте. Продуманный, основывающийся на определённом знании/изучении предмета документ, задающий направление разработки и указывающий основные проблемные моменты задачи. Если спекописец уверен в том что он описывает и как должно работать, он укажет ещё и как обойти проблему. Но это не значит что вот мы положили рельсы и никуда с них не съехать, нет. Если разработчик видит что описанное решение проблемы не оптимально или не работает, он должен сказать об этом (но не сразу сделать, а именно вынести на обсуждение). Если автор спеки сам вдруг понял что был не прав — он тоже должен об этом во всеуслышание заявить.
По опыту, спеки есть изрядно полезная вещь и, если они обдуманы а не так, «вот бы клёво как-то сделать эдакую штуку», то обычно не меняются кардинально. Да, некоторые моменты меняются, но это неизбежно и лучше когда изменения задокументированы — можно легко вспомнить почему и когда произошли изменения и от чего отказались, чтобы не повторить то же самое (в некотором роде) снова.
По опыту, спеки есть изрядно полезная вещь и, если они обдуманы а не так, «вот бы клёво как-то сделать эдакую штуку», то обычно не меняются кардинально. Да, некоторые моменты меняются, но это неизбежно и лучше когда изменения задокументированы — можно легко вспомнить почему и когда произошли изменения и от чего отказались, чтобы не повторить то же самое (в некотором роде) снова.
Совершенно не согласен. Пример: огромная информационная система, проект развивается 6 лет, постоянные изменения, подстраивание под меняющиеся бизнес-процессы заказчика.
Как обеспечить «включени» в команду новых людей и передачу знаний?
Далее: как без спецификаций (хоть каких-то) формализировать и выяснять требования, когда заказчик — компания с 20000+ работниками, и информацию получаешь от десятков из них? Которая, к тому же, еще и бывает часто противоречива.
Как обеспечить «включени» в команду новых людей и передачу знаний?
Далее: как без спецификаций (хоть каких-то) формализировать и выяснять требования, когда заказчик — компания с 20000+ работниками, и информацию получаешь от десятков из них? Которая, к тому же, еще и бывает часто противоречива.
Не забывайте что 37Signals работают над веб-приложениями. И книги свои они пишут именно для веб-приложения. И сами же указывают что этот подход работает у них, но не факт что он хорош в других областях. При этом для веб-приложение перечисление функций системы и макет интерфейса фактически и будет являться функциональной спецификацией.
Вы говорите о специфицировании того, что уже имеется. Конечно, это может быть полезно.
Здесь же предварительное функциональное специфицирование вперед.
Здесь же предварительное функциональное специфицирование вперед.
Про требования я тоже писал :-)
mrFox пишет, на мой взгляд, правильные вещи: если система простая, ее специфицировать незачем. Если сложная — ее специфицировать обязательно.
mrFox пишет, на мой взгляд, правильные вещи: если система простая, ее специфицировать незачем. Если сложная — ее специфицировать обязательно.
априори или постериорно? :)
Это две большие разницы.
Если заранее. Садитесь вы писать что-то, что будет разрабатываться год или два. Или пять лет. Скажем, Frontier: Elite 2. Там был один разработчик, который родил аж 260 000 строк кода на ассемблере.
Как думаете, была у него спецификация? :) А вот после разработки игры, или примерно с середины, уже, полагаю, можно и спецификацию писать.
Это две большие разницы.
Если заранее. Садитесь вы писать что-то, что будет разрабатываться год или два. Или пять лет. Скажем, Frontier: Elite 2. Там был один разработчик, который родил аж 260 000 строк кода на ассемблере.
Как думаете, была у него спецификация? :) А вот после разработки игры, или примерно с середины, уже, полагаю, можно и спецификацию писать.
С начала, разумеется.
Нужны бизнес-требования и фукнциональные требования. Проект разбивается на фазы, требования ко всему шестилетнему, разумеется, никто не пишет.
Просто оно в работе с реальным бизнес-заказчиком слегко по-другому, чем при написании игры :-)
Надо, чтобы заказчик был уверен, что вы понимаете, чего они хочет. Что вы разобрались в специфике его предметной области (как думаете, доверят вам писать систему управления цисками, например, без спецификации, где вы детально расскажете, что вы с ними будете делать, и как?). Спецификации — средство коммуникации с заказчиком.
Спецификация также — продукт работы аналитика. Кодер не будет разбираться, можно ли в циске присваивать двум интерфейсам IP адреса из одной сети, а аналитик, в свою очередь, не будет разбираться, как это реализовать программно. Спецификации — средство коммуникации внутри команды.
Кроме того, чтобы продукт приносил выгоду обеим стороным, он должен быть закончен в срок и в каких-то пределах. Неправильно бесконечно «размывать» проект, требуя от производителя добавлять все новую и новую функциональность, которую не предусмотрели заранее, это затягивает сроки. Неправильно и «золотить» продукт, вкладывая время и ресурсы в фичи, которых не просил заказчик. Спецификация — средство определения границ проекта.
Вот, думаю, может, напишу статью про UML и спецификации как-нибудь :-)
Нужны бизнес-требования и фукнциональные требования. Проект разбивается на фазы, требования ко всему шестилетнему, разумеется, никто не пишет.
Просто оно в работе с реальным бизнес-заказчиком слегко по-другому, чем при написании игры :-)
Надо, чтобы заказчик был уверен, что вы понимаете, чего они хочет. Что вы разобрались в специфике его предметной области (как думаете, доверят вам писать систему управления цисками, например, без спецификации, где вы детально расскажете, что вы с ними будете делать, и как?). Спецификации — средство коммуникации с заказчиком.
Спецификация также — продукт работы аналитика. Кодер не будет разбираться, можно ли в циске присваивать двум интерфейсам IP адреса из одной сети, а аналитик, в свою очередь, не будет разбираться, как это реализовать программно. Спецификации — средство коммуникации внутри команды.
Кроме того, чтобы продукт приносил выгоду обеим стороным, он должен быть закончен в срок и в каких-то пределах. Неправильно бесконечно «размывать» проект, требуя от производителя добавлять все новую и новую функциональность, которую не предусмотрели заранее, это затягивает сроки. Неправильно и «золотить» продукт, вкладывая время и ресурсы в фичи, которых не просил заказчик. Спецификация — средство определения границ проекта.
Вот, думаю, может, напишу статью про UML и спецификации как-нибудь :-)
Наверно заказчик должен иметь внутренний механизм, позволяющий выяснить (у 20к+ работников) требуемые функции и передать их «единым куском» разработчику. Вообще заказчик должен иметь четкое представление о том, что ему нужно.
Нет, это задача разработчика и его аналитиков (как правило). Заказчик не будет прерывать производственный процесс. Он платит деньги производителю, дальше, как правило, начинается его работа.
Вообще, методологий есть много, и каждый проект по-своему уникален, но надо учитывать, что заказчик может не уметь (и как правило не умеет) формировать требования. А разработчик может не знать (и как правило не знает) специфики бизнеса заказчика. Потому между ними есть промежуточное звено — аналитики.
Вообще, методологий есть много, и каждый проект по-своему уникален, но надо учитывать, что заказчик может не уметь (и как правило не умеет) формировать требования. А разработчик может не знать (и как правило не знает) специфики бизнеса заказчика. Потому между ними есть промежуточное звено — аналитики.
Так или иначе — есть звено, которое дает конечному программисту возможность узнавать требования и задачи, то же аналитик.
Главное различие в подходах видимо в том — есть ли возможность разработчику погрузится в специфику бизнеса и понять задачу самостоятельно.
Главное различие в подходах видимо в том — есть ли возможность разработчику погрузится в специфику бизнеса и понять задачу самостоятельно.
Полностью подписываюсь по этими словами.
До недавнего времени сам придерживался позиции «заказчик должен знать чего хочет!». И всегда спрашивал начальника: «почему наш маркетинг тим не вытянет из заказчика полный список требований, ведь сейчас только они с ним и общаются?»
Для меня было откровением узнать, что заказчик часто сам не знает чего хочет до конца, и как раз задача разработчика напрячь извилины и показать заказчику спецификации, которые он одобрит или нет.
В идеале да — это работа для аналитика, но в нашем случае, к сожалению, нет такого четкого разделения обязанностей, и кто только не занимается созданием спецификаций.
Да, речь идет о проектах с «железной» частьюе, т.е. не просто чистый софт.
До недавнего времени сам придерживался позиции «заказчик должен знать чего хочет!». И всегда спрашивал начальника: «почему наш маркетинг тим не вытянет из заказчика полный список требований, ведь сейчас только они с ним и общаются?»
Для меня было откровением узнать, что заказчик часто сам не знает чего хочет до конца, и как раз задача разработчика напрячь извилины и показать заказчику спецификации, которые он одобрит или нет.
В идеале да — это работа для аналитика, но в нашем случае, к сожалению, нет такого четкого разделения обязанностей, и кто только не занимается созданием спецификаций.
Да, речь идет о проектах с «железной» частьюе, т.е. не просто чистый софт.
Пардон, а под чем тогда автор подписывается как разработчик? Под мегасуперпуперпрограммойкотораярешитвсепотребностиклиентаисделаетегодовольным?
Да, нормальный анализ — это уже полпроекта. И на западе для этого нанимают специальных людей, которые стоят дорого, и которые пишут функциональные реквизиты. И надо сказать, это того стоит. Затем в дело вступают менеджеры, назначая цену на проект, а уже потом разработчики.
Другое дело, что клиент не хочет платить за спецификацию (и зачастую сам не знает что хочет), но уже просит назвать цену. В этом случае вкладываться можно использовать метод пошаговой детализации (или прогрессивного jpeg-а как его назвал Лебедев). Делается общий набросок проекта примерно что хочет клиент. Затем уточняются детали первого уровня, создается модель функционального core, и каждая из задач оценивается в минимаксных рамках. По завершении работы должен быть создан рабочий прототип системы. Общая проработка задач должна быть ровно настолько, чтобы с одной стороны быть функциональным, а с другой не превышать баланс. Дальнейшая детализация, второстепенный функционал и пожелания клиента откладывается на вторую фазу, которая оценивается отдельно.
Да, нормальный анализ — это уже полпроекта. И на западе для этого нанимают специальных людей, которые стоят дорого, и которые пишут функциональные реквизиты. И надо сказать, это того стоит. Затем в дело вступают менеджеры, назначая цену на проект, а уже потом разработчики.
Другое дело, что клиент не хочет платить за спецификацию (и зачастую сам не знает что хочет), но уже просит назвать цену. В этом случае вкладываться можно использовать метод пошаговой детализации (или прогрессивного jpeg-а как его назвал Лебедев). Делается общий набросок проекта примерно что хочет клиент. Затем уточняются детали первого уровня, создается модель функционального core, и каждая из задач оценивается в минимаксных рамках. По завершении работы должен быть создан рабочий прототип системы. Общая проработка задач должна быть ровно настолько, чтобы с одной стороны быть функциональным, а с другой не превышать баланс. Дальнейшая детализация, второстепенный функционал и пожелания клиента откладывается на вторую фазу, которая оценивается отдельно.
Совершенно несогласен.
«Работать без последнего равносильно самоубийству».
А вы не учитываете, что проекты бывают разными и по длительности и по функционалу. Лично я написал не одну биллинговую систему БЕЗ спецификации вооюще. Мне удобней пользоваться другми вещами в процессе разработки.
«Работать без последнего равносильно самоубийству».
А вы не учитываете, что проекты бывают разными и по длительности и по функционалу. Лично я написал не одну биллинговую систему БЕЗ спецификации вооюще. Мне удобней пользоваться другми вещами в процессе разработки.
Вообще я частично объяснил как происходит работа у нас.
В общем система, которую надо сделать, делится на N частей, минимально друг с другом взаимодействующих. В нашем случае — медиасервер, биллинг, пользовательское приложение (web-сайт), система отчетов. Каждый разработчик вникает в задачу и делает ее не обращая внимание на остальные модули (принимает их за черные ящики). В целом можно описать документально протоколы взаимодействия модулей, но у мы этого не делали. Просто когда пришло время интеграции — сели и продумали формат взаимодействия (написав карандашиком на бумажке). Потом кивнули друг другу и сели писать. Потом интеграция в кежиме extreme-debugging. Пара дней отладки + пару недель тестирования (кстати модульное тестирование тоже не является у нас частью процесса. Каждый тестит свою часть как считает нужным). И собственно продукт готов. Конечно — такой подход довольно негибок в том смысле, что подойдет не любой команде, однако у нас он работает на ура. Можете убедиться zingaya.com
В общем система, которую надо сделать, делится на N частей, минимально друг с другом взаимодействующих. В нашем случае — медиасервер, биллинг, пользовательское приложение (web-сайт), система отчетов. Каждый разработчик вникает в задачу и делает ее не обращая внимание на остальные модули (принимает их за черные ящики). В целом можно описать документально протоколы взаимодействия модулей, но у мы этого не делали. Просто когда пришло время интеграции — сели и продумали формат взаимодействия (написав карандашиком на бумажке). Потом кивнули друг другу и сели писать. Потом интеграция в кежиме extreme-debugging. Пара дней отладки + пару недель тестирования (кстати модульное тестирование тоже не является у нас частью процесса. Каждый тестит свою часть как считает нужным). И собственно продукт готов. Конечно — такой подход довольно негибок в том смысле, что подойдет не любой команде, однако у нас он работает на ура. Можете убедиться zingaya.com
Дело в том, что продукт, который мы делаем — наш личный. Это стартап, выигравший ни один конкурс. Функционал мы сами себе устанавливаем необходимый. Что получается — совершенно очевидно. Мы же не сходу садимся писать систему, а обговариваем все и обдумываем. Мы знаем, что должно получиться. Сроки прогнозируются вполне простым способом — каждый просто расчитывает срок своей части (+время на интеграцию и отладку\правку). Спецификация НИКАК не помогает определиться со сроками. В любом случае конечный программист говорит сколько ему надо на решение его задачи (в случае со спекой тоже).
Так клиент у нас мы сами — то «платим» мы себе именно за то, что получается. Ведь результат виден. В конечном итоге нет разницы со спекой пишешь или без нее.
Так клиент у нас мы сами — то «платим» мы себе именно за то, что получается. Ведь результат виден. В конечном итоге нет разницы со спекой пишешь или без нее.
Вот представляю работу без спецификации в сфере, например, построения космического корабля или там атомного реатора (ну или софта для них). Давайте, мол, напишем словами как красиво наш кораблик будет летать, как за ним будет развиваться шлейф огня, а космонавты, пролетая над родным домом будут махать ручкой. Потом нарисуем рисунок корабля на бумаге, потом из фанеры модель сваяем — а там, глядишь, уже и корабль почти готов!
Спецификация — это просто инструмент, который, как и любой инструмент, иногда подходит для решения задачи, а иногда — нет.
Спецификация — это просто инструмент, который, как и любой инструмент, иногда подходит для решения задачи, а иногда — нет.
Это статья о том, как НЕ надо делать.
А вообще спецификации бывают разные, бизнес, функциональные, технические, о какой идет здесь непонятно.
Без спецификаций невозможно работать в команде, потому если человек, который должен был реализовать тот или иной функционал заболел, то кто будет делать? А если есть детальный анализ, где прописано все, как и что должно быть реализовано, то это сможет сдлеать любой компетентный участник проекта.
В общем, то, что описано в статье прекрасно подойдет к проектам написаным на коленке или в одиночку, в больших же проектах (особенно, где функциональность описывается аналитиками, которые описывают её на основании требований, которые собрали консультанты и тп.) невозможно.
А вообще спецификации бывают разные, бизнес, функциональные, технические, о какой идет здесь непонятно.
Без спецификаций невозможно работать в команде, потому если человек, который должен был реализовать тот или иной функционал заболел, то кто будет делать? А если есть детальный анализ, где прописано все, как и что должно быть реализовано, то это сможет сдлеать любой компетентный участник проекта.
В общем, то, что описано в статье прекрасно подойдет к проектам написаным на коленке или в одиночку, в больших же проектах (особенно, где функциональность описывается аналитиками, которые описывают её на основании требований, которые собрали консультанты и тп.) невозможно.
Не надо забывать о том, что спецификация тоже может изменяться при «столкновении с реальностью». Если ее гвоздиком прибить — тогда да, тогда беда.
Ну и как по этому описанию представляется процесс разработки:
1) один человек подумал
2) один человек набросал идеи и договорился с заказчиком
3) один человек набросал прототип
4) а потом много программистов, обсудив прототип, начинают писать код
В реальности большие приложения сразу начинают писать несколько человек. И как им организовать коммункацию без спецификации — очень большой вопрос.
Ну и как по этому описанию представляется процесс разработки:
1) один человек подумал
2) один человек набросал идеи и договорился с заказчиком
3) один человек набросал прототип
4) а потом много программистов, обсудив прототип, начинают писать код
В реальности большие приложения сразу начинают писать несколько человек. И как им организовать коммункацию без спецификации — очень большой вопрос.
По-моему, у автора неверный подход к спецификациям: «На момент написания спецификации вас ничего не ограничивает, кроме вашей фантазии».
На мой взгляд, написание «спецификации», чтобы не понимал под этим термином автор — это не написанный кровью договор, который нельзя нарушить, а скорее процесс вхождения в предметную область и согласования взглядов множества лиц. Чтобы все заинтересованные могли понять, что же мы в конечном итоге предполагаем получить.
Т.к. 37signals делают простые проекты, simple stupid, то им можно не писать спецификацию. Представляю разработчики Windows решили не писать спецификацию.
Вы сделали мой день.
Если бы разработчики Windows решили не писать спецификацию а вместо этого профессиональная команда разработала бы взаимодействие с пользователем, то денег у Стива и Била было бы намного больше.
Если бы разработчики Windows решили не писать спецификацию а вместо этого профессиональная команда разработала бы взаимодействие с пользователем, то денег у Стива и Била было бы намного больше.
[то денег у Стива и Била было бы намного больше.]
Сомнительное утверждение. На чем оно основывается?
Сомнительное утверждение. На чем оно основывается?
На том что в Microsoft рулят программисты и людей которые умеют (и специализируются) делать удобные удобные интерфейсы там не так ценят как технарей.
Удобство и простота использования == пользователи == деньги.
Удобство и простота использования == пользователи == деньги.
А я сразу вспомнил как теже ребята в майкрософт, когда создавали офисный пакет, для GUI проводили тестирование пользователями, они просто и сажали за компы и давали указания (например отформатировать текст, создать таблицу и тп.) при этом на каждом компе был запущен скрипт, который отслеживал пути мыши, время сколько понадобилось пользователю на то, чтобы выполнить то или иной действие, а после анализировали полученные результаты.
Корректировка того что сделали программисты (юзабилити тестирование) и предварительная (разработке) проектирование интерфейсов это совсем разные вещи.
Я могу провести юзабилити тестирование холодильника в качестве транспортного средства в процессе которого выяснится что не хватает колес. Прикрутить их и сказать что работа сделана и прошла тестирование пользователями.
Я могу провести юзабилити тестирование холодильника в качестве транспортного средства в процессе которого выяснится что не хватает колес. Прикрутить их и сказать что работа сделана и прошла тестирование пользователями.
Вы приводите утверждения, но не приводите факты. Разработка Office 2007 Ribbon (в инете есть презентации) была сделана непрофессионально? Тогда в чем это выразилось?
p.s.
«Вы сделали мой день.» — это что значит?
p.s.
«Вы сделали мой день.» — это что значит?
Фокус в том, что в проектах типа Windows ВООБЩЕ лучше не специфировать ничего, кроме ограниченных подсистем типа интерфейсов.
Такие проекты тянутся десятилетиями, предсказать можно только самые общие вещи типа «все должно быть быстро» или «надо бы модульность обеспечить».
Такие проекты тянутся десятилетиями, предсказать можно только самые общие вещи типа «все должно быть быстро» или «надо бы модульность обеспечить».
Да-да, а потом, через 10 лет, фиг поймешь, что там напридумала команда, которая лет 5 уже как уволилась :)
Думаете, сейчас дело обстоит иначе? :)
Там ж сотни разработчиков! Пишется подсистема, после — описывается в доках, после — приходят новые люди, разбираются в доках, дописывают надстройку…
Там ж сотни разработчиков! Пишется подсистема, после — описывается в доках, после — приходят новые люди, разбираются в доках, дописывают надстройку…
Как в Майкрософте — не знаю, но у нас — иначе :)
Ошибочность описанного в статье подхода и Вашего понимания: вы понимаете подразработкой исключительно написание кода. Ну, и минимально — алгоритмику на уровне ООП.
Но даже самые крутые программисты не смогут написать информационную систему, если не разберутся в том, что же, собственно, она автоматизирует.
Интернет-магазин — это ерунда. Все мы имеем какой-ни-какой опыт работы с ними. А вот попробуйте без предварительной спецификации автоматизировать управление IP сетью. Или автоматизации финансовой деятельности.
И попробуйте без специйикации убедить оператора связи/финансовое учреждение, что вы вообще понимаете, что будете делать, и что оно сможет решить их проблемы.
Ошибочность описанного в статье подхода и Вашего понимания: вы понимаете подразработкой исключительно написание кода. Ну, и минимально — алгоритмику на уровне ООП.
Но даже самые крутые программисты не смогут написать информационную систему, если не разберутся в том, что же, собственно, она автоматизирует.
Интернет-магазин — это ерунда. Все мы имеем какой-ни-какой опыт работы с ними. А вот попробуйте без предварительной спецификации автоматизировать управление IP сетью. Или автоматизации финансовой деятельности.
И попробуйте без специйикации убедить оператора связи/финансовое учреждение, что вы вообще понимаете, что будете делать, и что оно сможет решить их проблемы.
Собственно говоря, я ж не Интернет-магазинами занимаюсь, а той самойавтоматизацией финансовой деятельности, корпоративным документооборотом и прочими малоприятными для технаря вещами.
И знаю, что крупные контракты получают не технари, не аналитики и даже не руководители проектов, а дядьки, которые нифига не рубят ни в технологиях, ни в нюансах чужих бизнесов.
Работа же начинается уже после рукопожатий, договоренности и еще черт знает каких подковерных штучек.
И знаю, что крупные контракты получают не технари, не аналитики и даже не руководители проектов, а дядьки, которые нифига не рубят ни в технологиях, ни в нюансах чужих бизнесов.
Работа же начинается уже после рукопожатий, договоренности и еще черт знает каких подковерных штучек.
Так спецификация ограниченных подсистем в целом и создает спецификацию всей системы :)
Скажу относительно веб-проектов, т.к. с разработкой других приложений не знаком. Так вот, готов подписаться под каждым из пунктов.
Когда к нам пришел заказчик, у него было 6-8 страниц в ворде, того, чтобы он примерно хотел видеть (он и сам понимал, что у него только примерное понимание проекта).
Мы взяли эти 6-8 страниц и переложили на более технический и структурированный, но что важно, свободный вид. Согласовали с заказчиком тот момент, что мы одинаково понимаем друг друга. И далее начался итеративный процесс разработки, выглядело это примерно так.
Итерация 1:
а) через неделю, хочу видеть Пользователей (регистрация, подтверждение, вход)
б) хочу чтобы у пользователей был «личный кабинет»
Итерация 2:
a) хочу то и то
и так далее, в результате через 3 месяца мы выкатываем первое работоспособное приближение проекта, которое уже начинает привлекать пользователей, заказчик начинает СЕО, а также не много ни мало проект по-тихоньку «отбивается» заказчику по деньгам.
Далее в спокойном режиме продолжается разработка того, что не сделано, и что самое важное уже с учетом фидбэков полученных от пользователей.
Буть у нас четкая спека, с подписями, согласованием и прочей бюрократией, изменение требований уже на втором этапе (после того, как выкатили первое приближение), порадило бы массу проблем.
Когда к нам пришел заказчик, у него было 6-8 страниц в ворде, того, чтобы он примерно хотел видеть (он и сам понимал, что у него только примерное понимание проекта).
Мы взяли эти 6-8 страниц и переложили на более технический и структурированный, но что важно, свободный вид. Согласовали с заказчиком тот момент, что мы одинаково понимаем друг друга. И далее начался итеративный процесс разработки, выглядело это примерно так.
Итерация 1:
а) через неделю, хочу видеть Пользователей (регистрация, подтверждение, вход)
б) хочу чтобы у пользователей был «личный кабинет»
Итерация 2:
a) хочу то и то
и так далее, в результате через 3 месяца мы выкатываем первое работоспособное приближение проекта, которое уже начинает привлекать пользователей, заказчик начинает СЕО, а также не много ни мало проект по-тихоньку «отбивается» заказчику по деньгам.
Далее в спокойном режиме продолжается разработка того, что не сделано, и что самое важное уже с учетом фидбэков полученных от пользователей.
Буть у нас четкая спека, с подписями, согласованием и прочей бюрократией, изменение требований уже на втором этапе (после того, как выкатили первое приближение), порадило бы массу проблем.
Замечательная рекомендация для команды из 2-3 разработчиков. Вредный и опасный совет для более-менее крупных проектов.
Спецификации необходимы для определения объема работ («система предназначена для работы с одной базовой валютой»), для определения общего языка и терминов («пользователи делятся на индивидуальных и корпоративных»), да и просто для понимания, что же вообще будет делаться.
Другое дело, что нельзя превращать спецификацию в фетиш. Да, на 100% специфицировать задание не удастся; да, возможно, спецификация будет несколько меняться; да, подпись заказчика, как правило, бесполезна.
На мой взгляд, самый правильный подход — разработать спецификацию до определенного уровня, оговорив наиболее важные элементы системы. Остальное можно уже решать по ходу разработки.
Спецификации необходимы для определения объема работ («система предназначена для работы с одной базовой валютой»), для определения общего языка и терминов («пользователи делятся на индивидуальных и корпоративных»), да и просто для понимания, что же вообще будет делаться.
Другое дело, что нельзя превращать спецификацию в фетиш. Да, на 100% специфицировать задание не удастся; да, возможно, спецификация будет несколько меняться; да, подпись заказчика, как правило, бесполезна.
На мой взгляд, самый правильный подход — разработать спецификацию до определенного уровня, оговорив наиболее важные элементы системы. Остальное можно уже решать по ходу разработки.
37сигналс, такие 37сигналс :)
На самом деле это просто лень. Лень работать свою работу у ПМа, а чисто «поуправлять».
Спецификация нужна и важна. Можно сделать вид что она не нужна и иметь мозг тому кто держит ее в голове. Можно этот мозг проипать и радостно встречать изменения толпой архитектурных багов, делающих любой код говном. Можно радостно курить модные методики и проедать бабло проекта, честно готовя резюме для следующего.
Но если нужно делать что-то не банальное и не в одиночку, то спецификации — хребет проекта. Естественно их создание и поддержка — труд. Естественно что писать их не учат и толковая получается на 3-4 проекте. И часто бывает что сработанная команда может в какой-то мере обходиться без лишнего формализма. Но на десяток раз, когда изменения вносятся для проформы, один раз случается нормальная эскалация проблем, которая окупит все труды.
На самом деле это просто лень. Лень работать свою работу у ПМа, а чисто «поуправлять».
Спецификация нужна и важна. Можно сделать вид что она не нужна и иметь мозг тому кто держит ее в голове. Можно этот мозг проипать и радостно встречать изменения толпой архитектурных багов, делающих любой код говном. Можно радостно курить модные методики и проедать бабло проекта, честно готовя резюме для следующего.
Но если нужно делать что-то не банальное и не в одиночку, то спецификации — хребет проекта. Естественно их создание и поддержка — труд. Естественно что писать их не учат и толковая получается на 3-4 проекте. И часто бывает что сработанная команда может в какой-то мере обходиться без лишнего формализма. Но на десяток раз, когда изменения вносятся для проформы, один раз случается нормальная эскалация проблем, которая окупит все труды.
Замечательнейшая статья! Вы буквально открыли мне глаза.
Лично я считаю, что спецификация начисто убивает оригинальность и то, что заставляет принимать самые серьёзные решения уже на ранних этапах, это чистая правда. Особенно это касается больших проектов.
Лично я считаю, что спецификация начисто убивает оригинальность и то, что заставляет принимать самые серьёзные решения уже на ранних этапах, это чистая правда. Особенно это касается больших проектов.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
6 причин, по которым вам не стоит писать функциональные спецификации