Как вы возвращаете неудачный проект обратно?

Ответ 1

Вьяс, я чувствую, что мог бы написать этот вопрос. Моя предыдущая работа включала воскрешение проекта KVM, который провалился после развития года. Спецификации были в форме руководства пользователя и опыта разработчиков с подобными продуктами. Я закончил обучение программистов на C до 3 и перепроектировал с нуля. Мы вывели продукт на рынок через 4 месяца. (Тогда я ушел в отставку, иди цифрой.)

Некоторые из вещей, которые я буду делать снова, особенно с неопытной командой:

1. Команда неопытных программистов работает 24x7
10. Нет технического руководства или Ковбойского кодера, который может принять технические проблемы.

• Дайте им (короткий!) прорыв от проекта до "перезарядки". Может быть, день, может быть, день или, может быть, долгий обед. Это будет означать конец "старого" проекта и начало успеха.
• Получите свое согласие отработать свои приклады, когда они вернутся, и пообещайте, что вы станете их парнем, чирлидером и курткой. Вы, коллективно, являетесь командой, и ваша работа заключается в том, чтобы выстроить свой путь, устранить отвлечения и привести их.
• Планируйте немедленный успех, независимо от того, насколько он мал, и поддерживайте отношение "can-do".

8. Веха после пропущенного пробела
9. Команда не может придумать дату доставки, так как никто не согласен с тем, что на самом деле нужно делать квантовую работу
3. Клиент кричит, что не может даже сделать основной материал (сохранение/запрос) и т.д.

• Возьмите небольшие укусы! Разбивайте каждую кусочку как можно дальше, а затем обрабатывайте небольшие компоненты. Вы определите "gotchas" раньше и сможете лучше охватить весь проект.
• Определите свои интерфейсы. В любое время вы можете изолировать кусок, сделать это.. Это позволяет параллельно разрабатывать, потому что вы уже определили параметры, предпосылки, предположения, что происходит внутри и возвращает значения. Вы можете заглушить его и самостоятельно построить другие модули и тесты.
• Приоритет. Сосредоточьтесь на дефектах и ​​проблемах, которые влияют на клиента в первую очередь. Новые функции приходят последними. При необходимости отложить функции, а не доставлять неверный код.
• Назначить обязанности. Волонтеры предпочтительнее, каждый в своей области знаний, но один человек должен нести ответственность за каждую задачу.
• Отслеживать дефекты и записывать все, что поможет вам воспроизвести, найти и исправить их. Документируйте все, что осталось во время доставки, поэтому клиент не удивится.

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

• Вы создадите детали спецификации, когда будете идти, каждая часть, прежде чем она понадобится. Это не должно быть красивым, полным или даже написанным, если все понимают текущую задачу, и у вас есть общая картина.
• Обсудите реализацию, одну часть за раз, когда разработчик готов ее закодировать. В случае необходимости напишите скелет, и пусть команда заполнит "кишки". Вы хотите сосредоточить внимание на каждой задаче без "импровизации".
• Будьте готовы отвечать на вопросы по мере их возникновения. Ваша основная цель - поддерживать эффективность команды.

2. Ошибки фиксируются только для введения новых ошибок
5. Никакие автоматические модульные тесты не влияют на ситуацию.

• Планировать и запускать модульное тестирование как можно скорее. Если возможно, заручитесь ресурсами вне команды.
• Исправить небольшие проблемы, прежде чем они станут больше - или спрятаться. Уверенность в каждой маленькой части создает уверенность в целом.

7. Компоненты сторонних производителей становятся узкими местами, которые в первую очередь не были проверены на соответствие требованиям.

• Решения Brainstorm, когда вы не кодируете. Не позволяйте им прекратить ваш прогресс, если это вообще возможно. Можете ли вы инкапсулировать или кодировать их? Заменить их?

Общие рекомендации:

• Оставайтесь впереди команды. Предчувствуйте и попытайтесь решить проблемы, прежде чем ваша команда ударит их. Соберите необходимую информацию, прежде чем она понадобится.
• Постоянно общайтесь. Проясните, что вы не хотите никаких сюрпризов, а также задавайте вопросы, вопросы, статус, контрольно-пропускные пункты и т.д. в течение каждого дня. Поощряйте сотрудничество и делитесь "открытиями" по всей команде.
• Отмечайте каждый успех.Комплиментируйте умное решение, принесите пончики, когда проблема будет решена, продемонстрируйте новую рабочую функцию... все, что показывает команду, которую вы цените.
• Выполняйте каждую задачу, затем двигайтесь вперед. Не тратьте время на настройку, улучшение или переработку всего, что не является прямым препятствием для успеха.
• Сохраните promises для команды, клиента и вашего руководства.

Удачи - пожалуйста, держите нас в курсе!

Ответ 2

Забери или найди новую работу. Это марш смерти, и им нужен скин-коза.

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

Ответ 3

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

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

Ответ 4

Число 10, очевидно, является наихудшей проблемой, или, по крайней мере, корень всех остальных. Найдите кого-то с творчеством и способностью доставлять проект и дайте им свободное владение, чтобы что-либо сделать, включая начало.

Ответ 5

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

0) Прекратите добавлять функции или функции в команду. Разрешить ошибки, которые будут устранены, в то время как следующие шаги будут предприняты до шага 5, а затем прекратить исправление ошибок и возобновить разработку функции:

1) Примените то, что я называю Законом об обратном укомплектовании персоналом: более слабые члены команды замедляют работу лучших и более быстрых, и, как правило, поздний программный проект требует, чтобы люди были удалены, а не добавлены. Таким образом, вам необходимо оценить качество членов команды в качестве отдельных участников. Устраните слабых сотрудников из команды, потому что, по-видимому, есть некоторые. Это лучше всего сделать, просмотрев их код и проанализировав их исправления ошибок и выяснив, кто делает код хуже и лучше, и нарезать их для команды. Это не время для наставника, вам понадобятся лучшие люди, чтобы изменить "фиксацию" ситуации в оптимальный период времени. Если вы не можете их уволить или переназначить, попросите их получить кофе или что-то еще для всех остальных.

2) Оцените сам код. Определите области кода, которые не были построены хорошо и/или не были хорошо абстрагированы. Если код города не сконструирован хорошо и/или явно хрупкий на нем, что он должен делать, настройте его для повторной записи. В этот момент это становится болезненным, но это сэкономит вам время в долгосрочной перспективе. Повторяющиеся ошибки и/или история исправлений помогут идентифицировать код, который не может быть спасен. Если область кода или модуль основательно построены хорошо, но не хорошо отлажены на уровне интерфейса, он должен быть подходящим для повторного факторинга. Это сэкономит значительное время и станет полезным кодом. Сохраните список областей перезаписи, областей повторного использования и подходящих областей.

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

4) Поработайте с держателями акций, чтобы решить, что сделает приемлемый первый выпуск, пытаясь записать как можно больше функций для "более поздних" выпусков. Может быть, вы ничего не можете вырезать, но если можете, пришло время это сделать.

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

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

7) Удалите как можно больше барьеров, чтобы команда быстро свернула материал, как можно быстрее.

8) Следите за проблемами и помогайте, пытаясь вытащить руки, где бы вы ни были. Предложите взять на себя более неприятные проблемы в той мере, в какой вы можете помочь и по-прежнему держать всех членов команды в качестве продуктивной.

Удачи!

Ответ 6

Это уже не о техническом руководстве, а о менеджменте проекта.

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

1) Определите спонсоров проекта и заинтересованных сторон - как официальных, так и реальных.

2) Идите к ним и попросите, чтобы проект "потемнел" в течение недели.

3) Если они не согласны, уйдите от этого проекта.

4) Если они согласны, вызовите время ожидания проекта в течение недели - все останавливается.

5) Проведите целую неделю с важными людьми в проекте, чтобы определить реальное состояние проекта.

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

7) В конце недели решите, какие (если есть) возможные сценарии проекта возможны.

8) Воспользуйтесь лучшими из этих сценариев для спонсоров проекта и заинтересованных сторон и начните переговоры.

9) Когда будет согласован путь вперед, перезагрузите проект и молитесь - возможно, не в этом порядке.

Ответ 7

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

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

Проект был оставлен его создателями из-за ситуации с маршем смерти и ушел после удаления всех комментариев в коде и выполнения других обфускаций. Никто не знал об игре win32/MFC.

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

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

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

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

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

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

Для вас могут быть разные вещи, но для вас это нужно решить.

Удачи.

Ответ 8

• Убедитесь, что вы не козел отпущения
• Ползучесть разреза
• Требования к функциональности Trim
• Внедрение более быстрого цикла dev (возможно, Agile/Scrum/XP/whatever)

Ответ 9

Если можешь, убеги.

Если нет, вам необходимо остановить все действия, которые делают проект неустойчивым, включая ошибки в кодировании и исправлении.

Оцените, где вы находитесь

Разбить требования на гораздо меньшие "вехи"

Прочитайте некоторые практические книги (Mcconnell "Руководство по выживанию программного обеспечения для программного обеспечения" ).

Определите все проблемы и риски. Общайтесь со всеми этими участниками.

Работайте по каждой части по одному.

Отмечайте улучшения и контрольные точки по мере их достижения.

Удачи. Ваш сценарий звучит довольно плохо. Это не может быть спасено - и все должно измениться, чтобы поправиться.

Ответ 10

Если вам действительно нужно было его отслеживать (если поручение не является вариантом)

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

Я бы предложил какую-то форму Agile, так как она проще всего реализовать без GURU, но вы должны быть ОЧЕНЬ строгими, включая Pairing, Ruthless Refactoring, Reviews, Spiking, Visibility, TDD, недельные циклы, 8-часовые рабочие дни (да, более 8, как правило, вредят производительности больше, чем помогают, как вы, кажется, заметили)...

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

Не забывайте о его стороне управления. Через неделю начинаются итерации (демо ЕСТЬ неделя). Постоянная адаптация. Очень короткие стойки каждый день для решения проблем. (Держите до 15 минут макс, стол больше вопросов и т.д.) Графики Burndown, основная команда с клиентом на нем.

Вы не можете просто проводить 15-минутную встречу каждую неделю и 2-недельные итерации и называть ее Agile, но если вы это сделаете правильно, это просто МОЖЕТ дать вам шанс. Вы можете получить ХОРОШЕГО гибкого консультанта, чтобы обучить вас при запуске.

Также, постоянно оценивайте, что работает, а что нет. Будьте готовы исправить то, что не работает. Еженедельные встречи для анализа успехов и неудач в развитии недель.

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

Ответ 11

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

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

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

Отслеживайте все достижения и следите за тем, чтобы вся команда и клиент знали, где вы находитесь на новом графике.

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

Ответ 12

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

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

Мне очень жаль это говорить, но вам нужно остановить развитие и потратить месяц на разработку того, что пошло не так...

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

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

Ответ 13

Вот краткое изложение ключевого обучения после прочтения ваших впечатлений:

Максим
1: Убедитесь, что это не "Марш смерти"

Ellie
2: Убедитесь, что выполняемые работы 3: Рефактор и база данных Realgin для архитектуры/Лучшие практики 4: Посмотрите, каковы реальные проблемы: технически ли команда готова предоставить?

Kendall
5: Обеспечение доступности технического руководства

Билл К
6: Реализация Agile Processes (по крайней мере, автоматические модульные тесты, если не TDD, короткие итерации, которые делают прогресс видимым) 7: Получить доступ к клиенту 8: будьте готовы выбросить то, что не может работать (в желании думать в стороне)

Уоррен
9: Удостоверьтесь, что оставшиеся члены команды оставили шанс начать более

Тим
10: Мотивировать команду и как улучшение становится видимым наградить их

jsl4980
11: вам необходимо купить бай-ин по расписанию из вашей команды (большинство участников) и клиента [Это вызывает больше вопросов. Что делать, если ваш клиент спрашивает, достаточно ли компетентна команда, чтобы придерживаться вашего графика? Что, если вы сами знаете, что сроки, предлагаемые командой, просто показывают их непонимание]

Ather
12: Завершена ли команда?
13: Вы формально QA?

Патрик
14: Начните, перепроектируйте и переконфигурируйте в соответствии с рекомендациями по архитектуре/дизайну для модулей, которые еще не разработаны.

Ответ 14

Сводка содержит 14 элементов. Вы не можете делать все. Итак, что первый шаг?

Здесь то, что вам нужно сделать в первую очередь - улучшилось one.

• У вас есть фундаментальные проблемы с качеством. (# 2-5)
• У вас проблемы с архитектурой и компонентами. (# 6, 7)
• У вас проблемы с расписанием. (# 1, 8, 9)

Вы можете справиться с качеством. Формальное модульное тестирование, ориентирующееся на TDD, может помочь. Это может быть сложно, потому что архитектура замедляет тестирование.

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

Вы можете заняться расписанием. Без других исправлений (т.е. Качества или архитектуры) вы не сможете получить какое-либо отношение к проблемам расписания фиксации.

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

• Одна давняя ошибка? Один unit test набор, чтобы найти и исправить эту ошибку?
• Одна из основных архитектурных особенностей? Будет ли диаграмма, которую каждый может опубликовать в кубе, поможет? Как насчет презентации прояснить ситуацию?
• Один новый вариант использования? Одна новая функция, которая действительно работает?

Ответ 15

Прежде всего, решите, что вы можете потерпеть неудачу - если вы не можете принять это, не принимайте вызов. И это включает в себя быть козлом отпущения (это действительно так). Менеджмент не будет смотреть на него в этих терминах (т.е. Они не намеренно/сознательно "настраивают вас" ). Но это реальность корпоративной среды; если вы берете на себя ответственность (часто с большей оплатой, чем те, которые этого не делают), тогда ваша голова предназначена для блока, если все не получится. Вы должны быть готовы придерживаться его и для долгого пути. Я был однажды размещен на клиентском сайте в течение 8 месяцев, чтобы исправить убывающий проект. И, как вы видели, один из других блог-плакатов здесь провел 9 месяцев до того, как была выпущена версия выпуска.

Теперь, предполагая, что вы в порядке с возможностью этого сделать все грушевидные, несмотря на ваши усилия, вот что я предлагаю:

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

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

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

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

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

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

• Я бы порекомендовал вам или вашей команде по кодированию работать смешные часы, чтобы доставить. если вы обычно уезжаете в 5 часов вечера, уходите в 18:30 или 19:00 вместо этого. вы и ваши мальчики-программисты могут постоянно поддерживать час или два дополнительных занятий в течение многих недель подряд и, возможно, 4-5 часов в выходные. работа до 9 вечера или 10 вечера каждую ночь приведет к выгоранию примерно через 2 недели (некоторые могут идти дольше). после этого момента ваше дополнительное время в проекте приносит больше вреда, а затем хорошее. в маловероятном случае, когда ваш босс будет разбираться с этим, сделайте выбор; делать то, что они просят (т.е. работать больше часов), или сказать: "Я уже выделил дополнительные часы для работы над этим проектом. Я здесь надолго, и я собираюсь сделать этот проект, если его смерть. но это предел того, сколько времени я готов вложить. У меня есть другие обязательства держать за пределами работы", - но будьте готовы к последствиям (помните, политическая ситуация, как техническая).

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

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

• встроенные утилиты для восстановления, особенно если у программного обеспечения есть повторяющиеся проблемы, которые трудно отменить. например; это может занять 12 часов, чтобы отследить ошибку и исправить ее, может потребоваться 2 часа для включения утилиты (см. "взломать" ), чтобы исправить проблему для времени. время и импульс относятся к essessen, и, к сожалению, исправления для бандажей могут потребоваться.

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

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

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

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

Ответ 16

Вот хорошая книга по теме:

Disentanglement от катастрофы: получение программных проектов в фоновом режиме

Ответ 17

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

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

Ни один из исходных кодеров не должен работать над "новым проектом" для его сохранения. Они могут перейти к другим проектам (их не нужно увольнять), но чтобы получить свежий взгляд на проект, все должны быть заменены.

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

Ответ 18

1) Первое, что я буду оценивать, заключается в том, привержены ли люди в команде проекту или нет? Если нет, бесполезно делать что-либо другое. Ничто не может предотвратить катастрофу, если я не получу целеустремленную команду. 2) Я буду уверен, что в команде есть QA. 3) Придумайте разумный план итеративных и инкрементных выпусков для клиента. С беспорядком, в котором мы находимся, нет никакого способа, которым клиент может получить все в ближайшее время. Основываясь на приоритетах клиента, мы часто доставляем ему небольшие возможности. Это заставит клиента заниматься, немного менее резким, так как он видит что-то происходящее.

Ответ 19

Что бы вы ни делали, делайте это шаг за шагом.

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

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

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

Итак, вот дорожная карта:

• Определите критическую часть, которую вам нужно изменить
• Изолировать код, который подразумевает это поведение
• Найти любое появление этого кода в остальной части кода
• Рефакторинг, использующий эти знания и массивный TDD
• Интегрируйте, протестируйте и исправьте, пока эта конкретная часть не будет работать
• Вернитесь к шагу

Сделайте ситуацию понятной для вашего босса: это займет время, деньги и будет болезненным. Объясните, почему, что вы будете делать, и что у вас нет другого пути, иначе он не сработает.

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

Никакого чуда. Просто метод и терпение.

Ответ 20

Был там, выполнил следующие шаги:

Стабилизировать

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

Control

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

Перемещение вперед

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

Ответ 21

Агитационный рефакторинг. Определите и определите приоритет, что хочет клиент, а затем создайте наиболее важные материалы в коротких спринтах из существующего кода. Удачи человеку:)