В теме 19 ответов, и 10 участников, последнее обновление сделано пользователем 
tilya 13 г, 1 мес. назад.
-
Сообщения
-
Всем привет,
Хочу обсудить статью "6 причин, по которым вам не стоит писать функциональные спецификации" (http://habrahabr.ru/blogs/htranslations/113077/#habracut). Лично у меня она вызвала много эмоций и желание поспорить
Какие у кого будут мысли на сей счет?
Будь здесь кодеры, они бы набежали с возгласами вида "да-да, аналитики- бездельники!"
Глядя с невысокой колокольни джуниора, это написали именно программисты.Будь здесь кодеры, они бы набежали с возгласами вида "да-да, аналитики- бездельники!"
Глядя с невысокой колокольни джуниора, это написали именно программисты.Рекомендую почитать про то, кто такие 37signals, что они проповедуют, какую методологию используют и насколько они известны и почему. Это поможет в понимании того, почему они приводят такие причины.
По причинам пока комментариев нет, т.к. просмотрел вскользь. Почитаю, отпишусь. Но тема интересная (;
Имхо в статье представлено однобокое и бескомпромиссное суждение. Все описанное верно лишь при определенном сочетании размера проекта, отношений с заказчиком, уровня команды и аналитиков в частности и специфики процесса разработки. Выскажу вкратце свои мысли по всем пунктам:Спецификация никак не приближает проект к завершению — ведь это не более чем слова на бумаге.
А вот креатив девелоперов в условиях аутсорсинга, которые вряд ли смогут мало того, что понять, так хотя бы и поговорить с заказчиком, несомненно приближает проект к завершению… особенно когда последующие переделки займут столько же времени, сколько и проект. Опять же — все зависит от условий работы. Кучка внятных сеньеров на небольшом проекте вполне обойдется без спецификации. Сложное же бизнес-решение на одном креативе разработчиков не выживет.В спецификации никогда не идет речь о нахождении сложных компромиссов и выборе оптимальных вариантов, а при разработке приложений без этого не обойтись.
Хороший аналитик решит эти вопросы еще на этапе написания документа. К тому же, кто сказал, что спецификация не может быть гибкой? Суть ее, скорее, не в том, чтобы иметь неизменный бейзлайн требований (хотя, все-таки, и в этом суть тоже, если для проекта это важно), а в том, чтобы все требования были где-то записаны.Множество заверяющих подписей под несколькими страницами спецификации — это не соглашение. Ваша команда прочитала один и тот же текст, но скорее всего каждый понял его по-своему.
Ну.. смотря кто писал Меньше всего о проекте известно в самом начале работы над ним. Чем дольше длится проект, тем больше вы узнаете о нем. Так почему вы должны принимать самые важные решения, даже не приступив к работе?
Опять же — кто сказал, что спецификация не может быть гибкой? Хотя стоить признать, что проблема в целом затронута верная.На момент написания спецификации вас ничего не ограничивает, кроме вашей фантазии. Нет ничего легче, чем дописать абзац текста или добавить еще один пункт в список.
Если ее пишет креативщик, не осознающий, что проект имеет ресурсные ограничения, то да. Но даже в этом случае есть манагеры и вся остальная команда для валидации требований.Любой пункт спецификации трижды обсужден и закреплен кучей подписей. Даже если в процессе разработки вы поймете, что какая-то из фич бесполезна, у вас не будет пути назад.
Это всего лишь один путь построения взаимоотношений с клиентом и процесса разработки. Есть альтернативы.Напишите небольшой текст, рассказывающий о том, что делает ваш продукт. Изложите свои мысли в свободной форме, не придерживаясь каких-либо шаблонов.
А вот это, несомненно, не будет источником проблемы "Ваша команда прочитала один и тот же текст, но скорее всего каждый понял его по-своему".. В общем, я со статьей в корне не согласен по причине того, что все должна определять каждая конкретная ситуация. Безапеляционно заявлять, что спеки — это глупость, имхо и есть глупо.
И вдогонку ссылка на другую статью, которая приведена в комментах к обсуждаемой: http://russian.joelonsoftware.com/PainlessSpecs/1.html
Кардинально противоположное мнение, которое нам, наверное, гораздо ближе.
Ох жесть! Даже не будучи аналитиком, я возмутилась прямо до глубины души, прочитав ЭТО ) Скажу только одно. Лично на мой взгляд, статья высосана из пальца и автор вообще не понимает, как в реале должен работать проект. Более того, он путает причины и следствия и не понимает, что не может быть проблемы в подробной документации, она может быть либо в неадекватном исполнителе/менеджере, либо в отсутствии документации, либо и в том, и в другом.
Я вообще не представляю, это же как не повезло человеку с менеджером, если он всерьез заявляет что "Использование спецификаций приводит к обрастанию ненужной функциональностью"… "Спецификация не позволяет вам развиваться, меняться и оценивать пройденный путь"….
Мне кажется, что тут даже оспаривать что-то бесполезно… Ибо это очевидно..
Еще предположу, что человек из отряда вечных и принципиальных фрилансеров…Прочел. Мое лично мнение:
Кратко: статья справедлива для 90% современных аутсортинговых проектов.Развернуто:
- 37signals никак не говнодевелоперы ни разу, и уж тем более не фрилансеры. Их мнение подкреплено бизнесом. Т.е. тем, что является движущей силой всех без исключения проектов.
- То, что целевой смысл статьи не может понравится большинству аналитикам, это очевидно. Аналогично как статьи в стиле "девелоперы пишут говнокод" не может понравится по определению разработчикам. Задевает профессиональное самолюбие. Это психология. И она не мешает обоим утверждениям быть в равных долях справедливыми.
- Статья является истиной для 90% аутсортинговых проектов. 10% можно отнести на высокотехнологические проекты, либо проекты где спецификация играет не традиционную роль.
- Статья Спольски приведена к данной статье не совсем корректно по двум причинам:
1. Статья Спольски значительно старее. В 2000 году гибкие методологии только только перетекали из бывшего совка в штаты.
2. Статья весьма завязана на специфику автора. Спольского тоже аккуратно читать надо, он прежде всего архитектор и большую часть жизнь проработал на монстроидальных проектах.
- Для тех, кто поспешил ужаснуться "как так совсем без спецификации?!" совет прочитать статью до конца и прочитать выводы. Читайте внимательно и старайтесь отложить в сторону личные эмоции.Спорить за конкретные пункты не стану. Лично я, с полки лично своего опыта, согласен как со всей статьей в целом, так и с каждым пунктом отдельно.
p.s. И да, если есть желание подвинуть вентилятор и перейти на личности, мое мнение основано на: 11 лет в индустрии, из них 8 лет разработчиком, из которых 5 в принципе счастливо жил без каких либо спецификаций. Слов таких страшных даже не знал. Написанный софт на вполне реальных предприятиях работал, работает и будет еще лет 10 работать без проблем. Аналитиком также был, и эпизодически являюсь сейчас.
Меня наверное сейчас закидают камнями, но я согласна с авторами статьи. А т.к. пятница, вечер и начата бутылка Розе, то подробно напишу почему.У меня сложилось впечатление, что Вы не дочитали статью до конца, без обид
.В начале предлагаю обратить внимание на заголовок, в котором фигурирует "функциональная спецификация", и резюме статьи, где упоминается таки, что какой-то документ написать стоит, только не функциональную спецификацию
. Держим это в уме и начнем разбор.1. Спецификация — это фикция
Она не имеет никакого отношения к реальности. Приложение становится реальным, когда разработчики пишут код, дизайнеры рисуют интерфейс, а люди начинают пользоваться готовым продуктом. Спецификация никак не приближает проект к завершению — ведь это не более чем слова на бумаге.
Тут, думаю, основная мысль в том, что спецификация не приносит никакого ощутимого/видимого результата для конечных пользователей или представителей заказчика. Вроде работа может быть проделана большая, но она вся на бумаге и потрогать ее нельзя. Соответственно очень легко ее не заметить. Так же не у всех людей хорошо развито визуальное воображение и может быть сложно переводить текст в визуальные образы.
2. Задача спецификации — угодить всем
Любая спецификация обещает всё и сразу, и старается осчастливить всех. Это похвальный, но совершенно бесполезный подход. В спецификации никогда не идет речь о нахождении сложных компромиссов и выборе оптимальных вариантов, а при разработке приложений без этого не обойтись.
Это правда, ведь сложные компромиссы и выборы оптимальных вариантов обычно находятся путем долгих дебатов или размышлений. Функциональная спецификация лишь фиксирует результат, но не отражает процесс выбора решения и отброшенные варианты. Проблемы могут возникнуть, если до написания функциональной спецификации не было этапа проектирования и весь дизайн системы заключался лишь в процессе написания спеки.
3. Спецификация — лишь иллюзия соглашения
Множество заверяющих подписей под несколькими страницами спецификации — это не соглашение. Ваша команда прочитала один и тот же текст, но скорее всего каждый понял его по-своему. И это обязательно всплывет в дальнейшей работе. «Подожди-ка, я вовсе не это имел в виду!», «Стоп, я понимал это совершенно по-другому!», «Нет-нет, всё именно так, и вы все под этим подписались». Вы прекрасно знаете, как это бывает.
Вот это, ИМХО, истина в первой инстанции. Не скорее всего, а точно каждый поймет спецификацию по-своему — и разработчики, и менеджер, и заказчик. Доходило до того, что при реализации требования аля "ширина элемента должна быть У px" разработчик увеличивал высоту элемента.
4. Спецификация заставляет вас принимать самые важные решения тогда, когда вы меньше всего знаете о проекте
Меньше всего о проекте известно в самом начале работы над ним. Чем дольше длится проект, тем больше вы узнаете о нем. Так почему вы должны принимать самые важные решения, даже не приступив к работе?
Ну тоже ведь правда. Если есть неопределенность, то лучше ее сначала проанализировать, спроектировать, уточнить и согласовать. И только потом описать в функциональной спеке.
5. Использование спецификаций приводит к обрастанию ненужной функциональностью
На момент написания спецификации вас ничего не ограничивает, кроме вашей фантазии. Нет ничего легче, чем дописать абзац текста или добавить еще один пункт в список. Вам ничего не стоит добавить в проект чью-то идею, просто чтобы сделать её автору приятное. Что мы имеем в итоге? Вашим проектом начинает руководить не здравый смысл, а абзацы текста и нумерованные списки. Именно так на свет и рождаются сайты с тридцатью горизонтальными табами в панели навигации.
Этот абзац на мой взгляд иллюстрирует очень прикольное свойство человеческой натуры. За деталями люди часто не видят целого и, соответственно, не могут это целое здраво оценить. Функциональная (обратите внимание на это слово
) спецификация описывает именно детали. 6. Спецификация не позволяет вам развиваться, меняться и оценивать пройденный путь
Любой пункт спецификации трижды обсужден и закреплен кучей подписей. Даже если в процессе разработки вы поймете, что какая-то из фич бесполезна, у вас не будет пути назад. Само существование фиксированной спецификации противоречит тому факту, что требования могут меняться в процессе создания приложения.
Тут по-моему вообще спорить бесполезно. Если есть согласованная спецификация и процесс изменения требований сложен, то 100%, что конечный продукт не будет соответствовать реалиям и текущим потребностям. Ну, если только разработка заняла не более 40 часов
.А теперь обратимся к резюме статьи. Авторы предлагают описать видение и границы системы, которые вполне могут включать в себя различные модели (например, вариантов использования
), создать прототип — т.е. спроектировать систему, выяснить все неопределенные моменты. Прототип, действительно, заменяет спецификацию, на мой взгляд, это фактически визуальная инкарнация функциональной спецификации. Кто сказал, что спека — это обязательно текстовый документ? Писать по прототипу спеку, думаю это двойная работа, т.к. в будущем, при изменениях, придется сапортить и спеку и прототип.Ого. Как вы тут это всё красиво и много понаписывали (некоторые даже писали громадные сообщения с разницей всего лишь в 1 минуту (; ). Я вот думал статьи перечитать и потом написать своё мнение, а теперь вижу, что большинство моих мыслей уже высказано. Что мне, конечно же, очень нравится (:Но всё же хочу добавить от себя 2 небольшие вещи автору первоначального перевода (не статьи / вырезки из книги, а именно перевода):
1. Стоит не просто давать ссылку на переводимый / цитируемый источник, но и давать некоторую вводную о том, кто такой автор, чем занимается и т.д. Ведь расскажи автор (не предполагая, что все остальные знают) хотя бы вкратце вначале о том, что это написали дядьки из 37signals, которые мега-гуру в том-то и том-то, которые проповедают аджайл и скрам и т.д. [и не надо говорить, что их все должны знать.. считайте, что рассказывать про автора статьи - это просто правило хорошего тона, которое, в том числе, помогает избегать лишних недоразумений]
2. Перед использованием важных / ключевых для обсуждения терминов необходимо сперва (можно и в конце) их объяснять, т.е. сопровождать текст Глоссарием. В данном случае речь про термин "Функциональная спецификация", который многими понимается по-разному, как это было верно подмечено Юлей.А вообще — класс! Спасибо 37signals, челу из Хабра и Асе за возможность взглянуть на вещи с разных сторон (;
И здесь, и на Хабре статья отлично продемонстрировала, как однобоко могут смотреть аналитики.
Статья показывает проблемы, которые на самом деле гораздо шире "функциональных" или любых других спецификаций. И если вы считаете, что там написана чушь — расслабьтесь и перечитайте.Спасибо essence, которая достаточно грамотно рзобрала, что же надо вынести из статьи.
Про однобокость мышления абсолютно согласен. Но как раз, на мой взгляд, статья и отражает именно однобокое мышление. Никаких компромиссов, допущений и т.д. — абсолютно прямые и не допускающие иных суждений тезисы. Расслабился и перечитал — нового для себя ничего не открыл. Фабрика софта чуточку сложнее, чем кажется, чтобы приводить свои мысли в такой манере…Про однобокость мышления абсолютно согласен. Но как раз, на мой взгляд, статья и отражает именно однобокое мышление. Никаких компромиссов, допущений и т.д. — абсолютно прямые и не допускающие иных суждений тезисы. Расслабился и перечитал — нового для себя ничего не открыл. Фабрика софта чуточку сложнее, чем кажется, чтобы приводить свои мысли в такой манере…
Я, на самом деле, не читала еще не одной статьи про разработку ПО, в которой не было бы допущений, компромиссов и однобокости. Всегда есть НО. Даже наверное ни одного тренинга практического не видела/не проходила, в котором бы не было обобщений. Практически всегда можно сказать: "Да, для Вас вот это так, но в другой ситуации это может быть кардинально по-другому". Так что это все споры, ради споров и приятного общения
На мой взгляд, гибкая спецификация и проектирование от пользовательского интерфейса (прототипов) это самый грамотный подход, который ориентирован именно на конечных пользователей. Правда, наверное не все компании могут себе позволить динамическую спеку (т.к. есть заказчики и сроки).В нашей компании например, используется спека в WIKI и она вся строится на базе спроектированных прототипов пользовательского интерфейса и описания требований к ним. Причем, наша спека очень динамичная, в том смысле, что часто дополняются требования или вносятся изменения. Правда есть один момент, мы разрабатываем собственный продукт, ориентированный на массового пользователя, поэтому это тоже влияет на то, что все наше проектирование очень сильно ориентировано на пользователя. Также мы чуть свободнее в сроках, чем компании, которые занимаются заказной разработкой.
В нашей компании например, используется спека в WIKI и она вся строится на базе спроектированных прототипов пользовательского интерфейса и описания требований к ним. Причем, наша спека очень динамичная, в том смысле, что часто дополняются требования или вносятся изменения. Правда есть один момент, мы разрабатываем собственный продукт, ориентированный на массового пользователя, поэтому это тоже влияет на то, что все наше проектирование очень сильно ориентировано на пользователя. Также мы чуть свободнее в сроках, чем компании, которые занимаются заказной разработкой.
А как отслеживать статусы требований?
[quote="tilya"]
В нашей компании например, используется спека в WIKI и она вся строится на базе спроектированных прототипов пользовательского интерфейса и описания требований к ним. Причем, наша спека очень динамичная, в том смысле, что часто дополняются требования или вносятся изменения. Правда есть один момент, мы разрабатываем собственный продукт, ориентированный на массового пользователя, поэтому это тоже влияет на то, что все наше проектирование очень сильно ориентировано на пользователя. Также мы чуть свободнее в сроках, чем компании, которые занимаются заказной разработкой.А как отслеживать статусы требований?[/quote]
Это не ответ, а просьба уточнить вопрос:
а какие статусы вы бы хотели отслеживать и зачем?
Вы должны авторизироваться для ответа в этой теме.
