Как остановить изменение спецификаций разработки в середине разработки?

61

Проблема : Кажется, что почти со всеми усилиями по разработке, в которые я вовлечен, независимо от того, сколько времени потрачено на планирование до начала разработки, всегда есть большое количество изменений, необходимых либо в середине, либо в конце проекта. Это иногда большие изменения, которые требуют много перестройки.

Я не работаю с клиентами, которые платят деньги, это собственная команда разработчиков на собственных веб-сайтах разработчиков. Так что я не могу брать плату за это или что-то еще. И в конце дня мы должны попытаться уложиться в сроки.

Вопросы : Как вы, ребята, нашли лучший способ минимизировать и предотвратить появление изменений спецификации на полпути или после разработки?

— Дэвид
источник

9

установить веху Feature Freeze в разработке и организовать / согласовать вещи таким образом, чтобы все запросы функций, отправленные после этого этапа, переходили к следующему выпуску, а не к текущему. Ключевым моментом здесь, конечно, является планирование более чем одного релиза и обмен этим пониманием с клиентами

— комнат

4

@gnat Вы предполагаете, что ФП работает в организации, где внедрение этапа «замораживание функций» будет приемлемым для заинтересованных сторон. Основываясь на личном опыте работы в собственных командах разработчиков, если бы я предложил что-то подобное, заинтересованные стороны уставились бы на меня и сказали бы что-то вроде: «Какого черта, как вы думаете, вы говорите мне, когда я могу и не могу измениться?» мои пожелания по прихоти? Как вы думаете, за что я вам плачу? Знайте свое место. "

— maple_shaft

29

Вы пытались сохранить спецификацию в файле только для чтения?

— orlp

14

Конечно, вы взимаете их: каждое изменение в спецификации задерживает выпуск, поэтому ваш ответ на запрос на изменение должен быть оценкой новой даты выпуска, если изменение добавлено в спецификацию. Тот, кто просит об изменении, несет ответственность за задержку и должен объяснить ее точно так же, как можно было бы объяснить расходы.

— Саймон Рихтер

7

Разве не поэтому Agile существует? Вы не можете заморозить спецификацию, поэтому заставьте свой процесс справиться с изменяющейся спецификацией.

— Крейг

89

Есть известная военная поговорка, приписываемая Гельмуту фон Мольтке: «Ни один план сражения не выдерживает контакта с врагом». В том же духе, я не думаю, что возможно создать спецификацию, которую не нужно будет менять - если только вы не можете предсказать будущее и прочитать мнения заинтересованных сторон (даже тогда они, возможно, еще не приняли решение, даже если они утверждают, что они сделали). Я бы предложил вместо этого подойти к нему несколькими способами:

Проведите четкое различие между тем, что можно изменить, а что нельзя. Четко сообщите об этом заинтересованным сторонам, заставьте их как можно скорее подписать неизменяемые вещи.
Подготовьтесь к изменению заранее. Используйте методологии кода, которые позволяют легче менять заменяемые части, инвестировать в конфигурируемость, инкапсуляцию и понятные протоколы, которые позволят заменять и заменять детали независимо.
Часто говорите с заинтересованными сторонами, запрашивайте отзывы и одобрение. Это будет держать вас в синхронизации и избегать их заявления "о, это не то, что мы хотели", когда уже слишком поздно. Как отмечалось в других ответах, гибкие методологии и частые мини-релизы помогут вам в этом.
Внесите в график время, чтобы учесть неизбежные изменения. Не бойтесь говорить «нам понадобится больше времени» рано, если вы считаете, что вам это нужно - если график, который вы дали, нереалистичен, лучше знать это (и вы в протоколе говорите это) в начале, чем в конец.
Если изменения слишком велики и угрожают крайнему сроку - отодвиньтесь и скажите что-то вроде: «это изменение возможно, но оно сдвинет крайний срок к X разу, сделайте свой выбор».
Выполните формальный процесс запроса изменений, определения приоритетов изменений и назначения изменений в версиях или выпусках. Если бы вы могли сказать людям: «Я не могу сделать это в этом выпуске, но буду рад включить его в график следующего», это гораздо лучше, чем сказать им: «Вы опоздали, ваши изменения не могут войти , до свидания "и сделаю их своими друзьями - они будут рады, если вы выпустите их вовремя, так что вы сможете быстрее получить доступ к следующему выпуску, в котором будут их изменения - а не ваш враг.

— StasM
источник

3

Вы также можете «заморозить» их поэтапно и перенести изменения в «следующую версию» .

— Грант Томас

3

Формализация процесса изменений и четкое определение области применения - отличный совет, если вы выполняете контрактную работу с фиксированной областью действия / ценой. В других условиях этот подход размалывает, так как он дает график и ценовое преимущество над объемом и качеством. Может быть, это то, что вам нужно в данной ситуации. Но опять же, может быть, это не ...

— '15

3

+1 за номер 6. У меня был отличный опыт, когда премьер-министр реализовывал только это требование.

— Джошуа Дрейк

3

Короткие циклы являются ключевыми. Люди гораздо меньше расстраиваются из-за того, что что-то толкает в следующий двухнедельный спринт, чем когда через шесть месяцев выйдет «следующий релиз».

— Адам Яскевич

1

«вкладывать деньги в конфигурируемость, инкапсуляцию» очень, меняются опасные советы. Это может слишком легко привести к эффекту внутренней платформы и пустым слоям абстракции, которые фактически усложняют процесс изменения системы. Наиболее легко изменяемая система - самая простая.

— Майкл Боргвардт

40

Доставить что-нибудь (я затрудняюсь использовать слово что-нибудь) рано и доставить часто. То есть - использовать какую-то методологию итеративной разработки.

Это основа гибкой разработки, но может использоваться (практически) с любой методологией.

Разбивая проект на серию мини-проектов, вы получаете больший контроль, поскольку вы можете поставить что-то перед клиентом раньше, вы не привязаны к длинному графику разработки, который устареет, когда клиент передумает (как они будут).

Когда они увидят, что система развивается, некоторые требования изменятся, некоторые станут избыточными, а другие увеличат приоритет. Однако, имея короткий жизненный цикл проекта, вы сможете справиться с этими изменениями.

— ChrisF
источник

22

Теория о том, что можно полностью определить программный проект любого значительного размера, является полной фантазией. Эта теория не работает в организациях от больших до малых в течение почти всей истории разработки программного обеспечения.

Вы ДОЛЖНЫ найти какой-то способ приспособиться к изменениям по ходу дела! Это произойдет, потому что большинство заинтересованных сторон, даже если они говорят «да, это то, чего я хочу», на самом деле не имеют представления о том, чего они хотят, пока они не окажутся перед ними. Вот почему у нас так много людей, принимающих итеративные методы.

Независимо от того, используете ли вы продукт или что-то в этом роде, вы ДОЛЖНЫ найти какой-то способ приспособиться к этим изменениям, потому что попытка найти способы, чтобы не иметь изменений, просто не требует, чтобы гравитация отключилась на несколько минут, чтобы вы могли летать.

— Майкл Кон
источник

2

НАСА делает это с помощью своего программного обеспечения или, по крайней мере, достаточно хорошо, чтобы отправлять шаттлы в космос. Дело в том, что они действительно следуют модели водопада. Спецификация фактически заморожена. По крайней мере, это мое понимание со стороны организации.

— Джошуа Дрейк

5

Я работал над несколькими проектами, где мы смогли полностью определить довольно важные системы (телефонные коммутаторы). Ключевым во всех этих случаях является то, что мы нацеливались на оборудование, которое уже было разработано и разрабатывалось для опубликованных (МСЭ) спецификаций, поэтому ни одно из них не могло измениться. Таким образом, ваш аргумент не подходит для всех проектов - только 99% из них! ;)

— TMN

@ TMN: я бы тоже не согласился с 99%. Я думаю, что развитие, похожее на водопад, намного, намного успешнее, чем считают агилисты. В противном случае, он не будет использоваться больше. Большинство проектов, над которыми я работал, были похожи на водопад. Ключом является установление базовой линии, тогда любые изменения, которые происходят, оцениваются как дополнительное время и деньги. Затем клиент решает, включать ли изменение или нет, и график и доллары снижаются соответственно.

— Данк

1

@Dunk: Я знаю, что большая часть нашего успеха заключалась в нашей приверженности методологии, разработанной в Bell Labs. Это был настоящий инжиниринг с полной прослеживаемостью от требований к спецификациям до проектов, планов тестирования, кодирования результатов тестирования и результатов. Когда тест не удался, вы могли точно увидеть , какие требования не были выполнены, и точно знали, где искать ошибочный код (или неудачный дизайн). Требуется много дисциплины и контроля, чтобы заставить водопад работать, но вы правы, это может работать хорошо.

— TMN

1

@ TMN Интересно, что является ключом к успеху? Использование модели водопада или ваш дисциплинированный подход? Я думаю, что позже будет более важным из двух.

— Росс Годдард

19

Не пытайтесь предотвратить изменения, примите их. Чем больше вы планируете заранее, тем больше вероятность того, что ваш план изменится. Так что планируйте меньше , не больше. Примите методологию гибкой разработки, в которой вы часто предоставляете небольшие порции рабочего кода, что дает заказчику возможность изменять спецификации каждые пару недель.

— Брайан Оукли
источник

Я не знаю, почему это не пришло мне в голову раньше, но идея о том, что наличие кода позволяет легче воспринимать изменения, не может быть правильной. Это проще и меньше времени, чтобы изменить некоторые диаграммы или изменить код? Особенно, когда изменения большие. Я согласен, что вы не пытаетесь предотвратить изменения, вам просто нужно указать на последствия и применить их в соответствии с графиком. Гибкие объятия меняются не более, чем водопадоподобные методы. Я даже думаю, что он обрабатывает изменения хуже, чем водопад, так как вносить изменения может быть немного дороже (в зависимости от того, когда это изменение произойдет).

— Данк

6

@ Dunk Вы правы в том, что дешевле изменить диаграмму, чем код, но как вы узнаете, что изменение должно произойти? Зачастую это происходит только после того, как вы дали пользователю что-то использовать, и он понимает, что он либо высказал неверную идею, это не то, что он хотел, или есть и другие вещи, которые он хотел. Хитрость заключается в том, чтобы выяснить, как обнаружить эти изменения как можно скорее.

— Росс Годдард

@Ross: Это одна из причин создания прототипов. Вы макете своего рода рабочую систему и получаете обратную связь. Это миф, что в водопаде клиент не знает, что он получает, пока это не будет сделано. Я принимал участие в проектах, которые были достаточно крупными, в течение которых первые несколько месяцев пользователь UI макетировал типичный прототип, чтобы гарантировать, что клиент получает то, что хочет. Кто-то может утверждать, что лучше использовать реальную систему, но если в итоге требуется гораздо больше времени, чтобы закончить, потому что код должен часто пересматриваться, то это не очень хороший компромисс.

— Данк

12

Вы задаете не тот вопрос. Изменения спецификаций всегда будут происходить в проектах по разработке программного обеспечения любого размера.

Часто это происходит из-за того, что меняются бизнес-требования, но я также видел, как это происходит, потому что клиентам (внутренним или внешним) может быть трудно визуализировать то, что возможно, не видя чего-то, что можно повторить, поэтому у них есть видение, которое медленно меняется, когда они взаимодействуют с Развивающее решение.

Вопрос, который вы должны задать, заключается не в том, «как я могу заблокировать спецификацию», а в том, «как я могу структурировать свой код и процессы, чтобы реагировать на изменяющуюся среду, не выбрасывая все, что я уже написал?»

Затем это приводит вас на арену бинго модного слова: гибкие методологии, итеративная разработка и технические решения, такие как модульное / модульное кодирование, непрерывная интеграция ... этот список можно продолжить.

Я не говорю, что это серебряная пуля для всех ваших проблем, но все они возникли из-за желания справиться с той самой ситуацией, которую вы описываете, поэтому, по крайней мере, они заслуживают некоторого исследования.

Извините, если это не предлагает конкретных решений, но я склонен думать, что изменение мышления в принятии и управлении изменениями принесет большие дивиденды, чем попытка избежать этого.

— Marce
источник

Ага. Перефразируя первоначальный вопрос: «Как мы можем гарантировать, что мы обеспечим то, что клиент хотел в начале проекта, а не то, что он хотел в конце?»

— Стив Беннетт

5

Изменение это только сюрприз ... если это сюрприз!

Я бы предложил подумать о:

откуда вообще эти перемены?
почему вы не знаете о них раньше?
почему вы не участвуете в этих изменениях (и, возможно, делаете их еще больше)?

Изменение - это природа того, что мы делаем. С каких это пор вы написали алгоритм точно так, как предполагалось в первый день?

Но если вы хотите избежать того, чтобы разочарованный разработчик постоянно «удивлялся» изменениям, я думаю, вам нужно найти себя ближе к действию, в котором принимаются решения. В конце концов, я уверен, у вас есть множество идей о том, как вы могли бы сделать продукт лучше. Займите место за столом или навсегда признайте, что вам просто придется иметь дело с этими «неожиданными изменениями».

— tardate
источник

+1 «Изменение - это природа того, что мы делаем» - мне нравится изменение. Изменение может быть хорошей вещью. Это дает мне возможность увидеть, были ли мои дизайнерские навыки или нет. Если изменение вызывает много переделок, то я сделал плохой дизайн. Это также дает возможность сделать дизайн более общим. Это дает оправдание, чтобы исправить то, что вы бросились через, чтобы соответствовать графику. Это позволяет мне вернуться и исправить мусор других людей. Просто отслеживайте запросы на изменения и включайте их в расписание, чтобы при выполнении заказа позже, чем исходное расписание, у вас были доказательства того, почему.

— Данк

4

Ну, это хотя вызов, клиенты всегда хотят больше, но вот несколько моментов, которые вы должны рассмотреть:

Макеты HTML: всегда создавайте макеты HTML, чтобы определить часть пользовательского интерфейса приложения, покажите им, как это будет выглядеть и спросите их мнение. Если вы найдете что-то разумное для изменения, сделайте это в прототипе HTML. Используя это, вы разберетесь со многими вещами, такими как проблемы пользовательского интерфейса, основной поток и некоторые дополнения (такие как сортировка, разбиение на страницы, количество записей для отображения и т. Д.)

Активное участие с другой стороны: это очень важно, если вы разрабатываете для бизнес-организации, займитесь их бизнесом, попросите их прояснить ваши сомнения и непременно спросите их, какие изменения они хотят в своем потоке (при необходимости).

Модульная версия. Выпуск кода в модульной форме, выпуск, тестирование, получение обратной связи и выпуск снова.

— CodeCracker
источник

4

Вот почему почти невозможно планировать слишком далеко заранее, но это не повод вообще не планировать. Не влюбляйтесь слишком глубоко в свои планы, и вам не придется беспокоиться о том, что они разбивают ваше сердце.

Внутри вашей компании есть затраты на использование ИТ-ресурсов, независимо от того, признает ли это кто-то, отслеживает ли это или имеет для этого бюджет или нет. Реальность такова, что ваша команда может создать столько кода только за определенное время. Все отделы и проекты делятся в этом бюджете.

Вы не можете помешать кому-либо изменить требования, но они не могут избежать последствий. Изменения могут значительно увеличить время разработки. Это факт, с которым им приходится иметь дело или принимать решение не вносить изменения. Влияет ли запрос одного отдела на другой? Возможно, вам придется полностью переместить их проект за другие отделы, потому что запрос на изменение будет нарушать расписание другой группы.

— JeffO
источник

4

Активное участие пользователей на протяжении всего цикла разработки и использование как можно большего количества методологий Agile действительно помогают нам с нашими продуктами.

Изменения спецификаций неизбежны, но, будучи прозрачными для пользователей и, прежде всего, их частое обращение означает, что большинство изменений фиксируются как можно раньше.

— оборота SkeetJon
источник

3

Для меня это довольно просто.
Скажите одному, «Владельцу продукта» , который заказал функции, это нормально, но он должен выбрать пару запланированных функций, без которых он может быть на этот срок.
Думайте об этом как о встрече в пол-спринте с ПО, где вы говорите ему, что спринт не сгорит до 0.

Ps. Если это не «ПО», я бы сказал, не говорите со мной через «ПО»

— Farmor
источник

1

Как вы, ребята, нашли лучший способ минимизировать и предотвратить появление изменений в спецификации на полпути или после разработки?

Там нет лучших способов. Руководство должно ограничить изменения спецификаций на определенном этапе разработки.

Однако вы должны разработать свое программное обеспечение таким образом, чтобы ожидать изменения. Тогда влияние изменений будет намного меньше. Итеративное и поэтапное развитие - хорошее начало.

— BЈовић
источник

1

Я обнаружил, что клиенты прямо или косвенно являются причиной большинства изменений (а также наиболее критических ошибок, кстати). Таким образом, очевидным решением является устранение клиентов. (Чем они вообще хороши?)

— Даниэль Р Хикс
источник

:) Если клиенты хотят сумасшедшей настройки, они должны заплатить за это деньгами и временем. Если продавцы абсолютно ДОЛЖНЫ давать обещания предоставлять функции, которых еще нет, большую часть времени они совершают продажи, то у компании в целом возникает большая проблема: у нее много конкурентов и она не находится на вершине своей игры, например Поставщик базы данных SyBase. Она либо станет неактуальной как компания, либо ей понадобится революционный генеральный директор и заместители.

— Работа

1

Поскольку вы не можете предотвратить изменения, вы должны принять их. Я думаю, что самое важное, что вы можете сделать, - это попытаться получить запросы на изменение от клиента как можно раньше , потому что дешевле всего что-то менять, когда кода мало. Поэтому вам нужно как можно раньше представить свой дизайн заказчику, используя прототипы (возможно, даже бумажный прототип), используя гибкие методы и так далее.

— Ханс-Петер Стёрр
источник

1

Вы можете рассмотреть вопрос о введении некоторой дисциплины в процесс разработки с использованием методологии, подобной SCRUM. В SCRUM команда разрабатывает первоначальный план, разделяя реализацию функций на истории и назначая каждой истории оценку усилий (количество рабочих часов или дней, необходимых для реализации этой истории).

Если запрошено позднее изменение (для уже внедренной истории), вам необходимо создать новую историю и оценить для нее усилия по внедрению. Затем вы можете обратиться к своему менеджеру ( владельцу продукта ) и просто объяснить, что новая функция будет стоить этого дополнительного времени. Затем менеджер проекта несет ответственность за принятие дополнительных усилий и корректировку графика (возможно, отмена других, еще не реализованных историй).

Даже если ваша команда не собирается полностью внедрять SCRUM или другой процесс разработки, вы можете, по крайней мере, представить планирование на основе историй , оценить усилия по разработке для каждой истории и скорректировать график по мере поступления новых историй.

— Джорджио
источник

0

http://teddziuba.com/2010/05/why-engineers-hop-jobs.html

Я провел слишком много вечеров после работы в стрессе и несчастье, потому что еще один парень не понимает и не заботится о том, как работает бизнес программного обеспечения. У меня нет проблем с кем-либо наверху, но я не поддерживаю своих собратьев. Иметь детей - это сука, а? Я, скорее всего, скоро уйду.

Честно говоря, хотелось бы, чтобы у программистов вообще было больше шаров. Давайте посмотрим на это:

«Я не работаю с клиентами, которые платят деньги, это внутренняя команда разработчиков на собственных веб-сайтах разработки. Так что я не могу платить за это или что-то еще. И в конце дня, мы должны попытаться уложиться в сроки. "" "

Если вы имели дело с клиентом с $ -оплатой и если вы покрыли свою задницу заключением контракта (http://vimeo.com/22053820?utm_source=swissmiss), то изменения в спецификациях будут стоить этому клиенту больше времени и больше денег ( или потенциально то же самое или меньшее время, но экспоненциально больше денег). Ваша компания пытается изменить спецификацию, не тратя на это больше времени и денег.

Между тем, попытки уложиться в сроки приводят к тому, что вы и ваши коллеги НЕОБХОДИМЫЙ стресс Вы не можете провести качественные выходные с друзьями / семьей. Это действительно не нужно, потому что тот, кто бросает работу на вас, вероятно, даже не знает об этом, что печально.

Мое предлагаемое решение: собрать вместе шары, чтобы противостоять им и объяснить, что бесплатного обеда не существует и все стоит того, что автомеханику потребуется больше времени и будет взиматься дополнительная плата, если спецификации будут изменены в середине работы, что агентству-подрядчику потребуется больше времени и взимать больше, если спецификации были изменены в середине работы, и для этого есть веская причина. Если они не хотят работать с вами разумным образом, то вы, как группа, встанете и уйдете, и им придется нанять разработчиков, которые смогут забрать проект, с которого он был остановлен, и выполнить его вовремя.

Тогда есть также обещание гибкого развития, которое не подразумевает жестких сроков.

Я еще не видел, как программисты бастуют, но это было бы что-то. Некомпетентных менеджеров слишком много в компаниях-разработчиках. Слишком много людей хотят получить что-то даром, в Craigslist или в реальной компании. http://teddziuba.com/2011/07/the-craigslist-reverse-programmer-troll.html

Программисты должны иметь больше шаров.

— Работа
источник

0

Подход, который я нашел, работает вроде нормально (не со всеми менеджерами, очевидно): «Думаю, я могу это сделать, да. Это зависит от того, сколько дополнительного времени вы отводите этому проекту? с просьбой «.

— Медивх
источник