XP vs Традиционное хорошее управление проектами

Question

Я уже 10 лет работаю в ИТ-индустрии, но работал в «традиционно» управляемых проектных командах (как хорошо управляемых, так и плохо управляемых).

Я слышал о «новом» сценарии управления проектами или типа XP и хотел быть частью одного (как люди с s/w, мы всегда любим что-то новое, я думаю), но у меня нет возможности.

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

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

Заранее спасибо

Answer 1

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

• Met со всеми, по крайней мере один раз в день, но дал нам пространство для работы
• Пользовалась доску с двумя колонками, люди работают, и то, что они работают на тех, кто мог бы смотреть на эту доску и посмотреть, если что-то было сделано или было сделано
• Имел ли каждый кросс-поезд. Я узнал rcs, а затем cvs там и как использовать make-файлы
• Ran продуктивный «post mortum», когда задача была завершена. Он задал бы вопрос: «Помогло бы это, если бы Х?» или «в следующий раз, мы можем попытаться ...»
• Хранится все работающим на короткие задачи и управлять наше время, поэтому мы постоянно работаем над чем-то, но никогда не был тонна материала накопилась

Майк сделал все, на бумаге. Он будет держать с собой записные книжки и картотеки. Он настаивал на том, чтобы все, что его попросил руководство, превратилось в управляемые задачи, часто написанные на карточках заметок. Он отказался никому работать над тем, что не может быть четко объяснено или имеет четкую цель. Он спросил у вице-президентов: «Что ты хочешь сказать быстрее?» «Какими метриками являются отчеты, предназначенные для показа?» «Почему это должно быть приоритетом?«У него, казалось, было почти бесконечное терпение, когда вы писали, что нужно сделать, и что означало« сделано »

Когда я впервые прочитал книгу XP, я был поражен тем, насколько это было знакомо как« способ, которым Майк работал "

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

Я думаю, что реальная проблема с традиционным управлением проектами заключается в том, что чаще всего это не реально. Я поражен тем, сколько магазинов заявляют, что используют RUP или Code Complete или даже Agile и на самом деле не имеют ничего узнаваемого, как управление проектом. Конечно, встречаются. И люди называли менеджеров проектов. Но задайте простой вопрос, как «что было сделано для проекта X» или «что нужно делать для проекта Y», и никто не имеет ответа. Они должны копать, хотя письма или указывают на комически неточный файл проекта MS.

Если человек утверждал, что находится на диете и не мог ответить на вопросы о том, что они ели или как они тренировались; вы согласитесь, что они действительно были на диете?

Answer 2

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

Однако я скажу, что ситуация значительно улучшилась, когда мы начали закрывать цикл между нами и клиентом. Большая и более частая обратная связь и прототипирование с клиентом означает гораздо меньше моментов, когда клиент говорит: «Это не то, что я хотел».

Answer 3

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

Answer 4

Я использовал (слегка измененный) Scrum, прежде чем на работе, а вот мои мысли:

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

Answer 5

Я нашел, что общий переход к практике Agile/XP очень позитивен, во многих отношениях он загружает качество в проект/процесс разработки. Вам нужно купить в от руководства и команд, чтобы действительно видеть успех ... несколько предложений:

• испытаний любого изменения с небольшим проектом (2-3 человека)
• понять, какие области вашего текущая команда может улучшить (качество? производительность? время выхода на рынок?) и включить несколько Agile/XP/Scrum (что когда-либо) процессы в ...не включайте их все в одно и то же время и понимайте, какие процессы адресовывают какие вопросы до любых изменений.
• если возможно - отслеживайте те области, которые вы хотите изменить, и сравнивайте их с другим проектом, запущенным в одно и то же время (простое фокус улучшения чего-то часто достаточно, чтобы улучшить его, есть исследование/срок для этого, но я забыл, что это такое)
• иногда вы увидите падение производительности при начале нового процесса, это часть кривая обучения
• никогда не предполагают, что хорошие изменения сегодня останутся хорошими изменениями завтра, всегда просматривайте свои проектные области и будьте готовы изменить любой процесс в любое время
• Никаких изменений не остается навсегда, как и refac toring кода, реорганизовать свои процессы
• обеспечить Вам купить команды и управления, вы не можете заставить успех

Answer 6

Мне нравятся некоторые из вещей ловких подходы делают, но я также ценю некоторые из что делают традиционные подходы.

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

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

Answer 7

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

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

---

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

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

Answer 8

Это прекрасные ответы, но я думаю, что все запутывают управление проектами с помощью методологий разработки/дизайна.

Answer 9

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

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

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