XP против традиционного хорошего управления проектами [закрыто]

Question

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

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

Мой вопрос заключается в следующем: каков ваш опыт перехода на "новый" путь - был ли он значительно лучше, хуже или ничем не отличался?Улучшился ли какой-либо показатель успешности проекта при использовании способа разработки XP или он такой же, как у любых хорошо управляемых традиционных проектов?

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

Заранее благодарю

Answer 1

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

• Встречался со всеми по крайней мере раз в день, но давал нам возможность поработать
• Использовал белую доску с двумя столбцами, изображающими работающих людей и то, над чем они работают, любой мог взглянуть на эту доску и увидеть, было ли что-то сделано или делается в настоящее время
• Заставил всех пересесть на другой поезд.Там я изучил rcs, а затем cvs и как использовать make files
• Запускал продуктивный "post mortum", когда задача была выполнена.Он задавал вопросы типа "помогло бы, если бы X?" или "в следующий раз, может, попробуем ..."
• Заставлял всех работать над короткими задачами и распределял наше время, поэтому мы всегда над чем-то работали, но никогда не накапливали кучу материала

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

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

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

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

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

Answer 2

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

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

Answer 3

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

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

Answer 4

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

Answer 5

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

Answer 6

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

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

Answer 7

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

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

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

Answer 8

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

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

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

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

Answer 9

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

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

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