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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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