Есть ли такая вещь, как процесс запаха?

Ответ 1

Книга " Антипаттерны" Уильяма Дж. Брауна и др. и др. имеет кучу связанных с проектом запахов. Они не всегда идут в беду; смягчающие обстоятельства существуют практически для любого запаха.

В репозитории шаблонов Portland также есть страница об Антипаттернах, охватывающая многие те же темы, что и книга "Антипаттерны". Перейдите на страницу http://c2.com/cgi/wiki?AntiPatternsCatalog и прокрутите страницу вниз до "Control Antipatterns". Несколько примеров:

• Анализ паралича - команда аналитиков, которые в тоже время являются разумными и здравомыслящими, входят в фазу анализа, которая заканчивается только после отмены проекта.
• Дайте мне оценки сейчас - клиент (или PointyHairedBoss) требует оценок, прежде чем у вас будет достаточно данных для его доставки. Вы принимаете "вызов" и выдаете из головы оценки (т.е. Догадки). Затем клиент/босс рассматривает эту оценку как обязательство, одетые в железо.
• Проект Ground Hog Day - проводятся встречи, которые, похоже, снова и снова обсуждают одни и те же вещи. В конце этих встреч принимаются решения о том, что "что-то нужно делать".
• Дизайн по комитету - Учитывая политическую обстановку, в которой никто не имеет достаточного влияния, чтобы представить дизайн системы и утвердить ее, как вы получаете дизайн? Составьте вместе большой комитет для решения проблемы. Дайте им сразиться между собой и, наконец, возьмите все, что выйдет.

Соберите их все!: -)

Ответ 2

• Назад Знакомства - дается дата окончания, а затем рассказывается, что нужно сделать.
• Обратное QA-покрытие - QA фокусируется на несущественных элементах (потому что все они знают, как тестировать)
• Проблемы экологического выравнивания - различные среды (Dev, Test, Staging, Production) не синхронизируются для кода и данных - поэтому любое тестирование до производства недопустимо
• Отгрузка отгрузки - никто не верит в конечную дату, потому что: она была составлена ​​для начала, и 100% предыдущих проектов никогда не отвечали их датам поставки.
• Старый код Grumpy - старый код опасается, потому что нет желания рефакторировать
• злой квадрат треугольника (объем, стоимость, ресурсы и/или качество) - для корректировки проекта вам нужно добавить людей, снизить качество, уменьшить область и т.д.... как только проект движется, большинство изменений ( даже уменьшение масштаба) будет увеличивать время и стоимость и снижать качество.... следы поездов не работают, он просто висит на повороте влево.

Ответ 3

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

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

Изменить: это также распространяется на машины и другую инфраструктуру (примеры: сервер сборки, на который требуется час, чтобы сделать двухминутную сборку или систему управления версиями - ahem CVS), которая занимает 15 минут, чтобы узнать, есть ли были какие-либо обновления в исходном дереве 50 МБ).

Ответ 4

• Доставка прототипа - "мы будем производить его позже"

Ответ 5

Я предлагаю проверить Organizational раздел wikipedia на антишаблоны. Мне приходилось иметь дело с "Кризисным режимом" и "оценками на лету", о которых вы говорили.

Ответ 6

У вас не было обзора проектов после проекта.... когда проект закончился 6 месяцев назад.

Ответ 7

Некоторые запахи, которые я видел:

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

Больше, но я не буду испортить удовольствие другим.

Ответ 8

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

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

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

Доставка необходимых файлов (например, для импорта данных) или информации за считанные минуты до истечения срока, а затем обвинения разработчиков в том, что срок выполнения не выполнен.

Ответ 9

То, что я называю: NIH (Process edition), a.k.a. Выберите свое приключение.

Доказательства этого:

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

Я думаю, что это антипаттерн, а не запах.

Ответ 10

Интересный вопрос и еще более интересные ответы. Спасибо за это.

Я занимался практически всеми ролями разработки программного обеспечения (разработчик, QA, Tech Lead, Project Manager - даже клиент), и я могу смело перечислять следующие запахи

• Как быстро команда реагирует на новые входы (и как они принимают изменения)
• Сколько слоев он проходит, чтобы добиться успеха (beaurucracy).
• Насколько ясны функции/задачи - и это цели SMART, и у нас есть какие-то KPI.
• Насколько серьезной является команда, работающая над проектом об этом.
• Регулярно ли встречается команда (ежедневно читает), чтобы обсудить достижения, цели и проблемы.

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

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

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