Как внедрить стандарты и усовершенствования процессов в организацию без них?

10

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

standards cmmi process-improvement

— rjzii
источник

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

— Крис Питман

2

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

— Буровая установка

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

— S.Lott

@Robz: «Стандарты кодирования» - это не «Формальные стандарты». Это прояснит вопрос. Снова. «Формальными стандартами» являются стандарты W3C, Posix, ISO, IEEE, ANSI. Разработан и утвержден признанной организацией, занимающейся установкой стендов. Если вы говорите о стандартах кодирования, обновите вопрос, чтобы удалить слово «Формальный» и использовать слово «Кодирование». С этим изменением ваш вопрос имеет смысл. И это дубликат.

— S.Lott

«Что касается слов« стандарты »в названии в связи с улучшениями процесса, то слово« стандарты »относится не только к коду, который кто-то пишет»? Какая? Вот подсказка. Пожалуйста, не используйте слово «стандарт» без какого-либо уточнения; это сбивает с толку. Если вы имеете в виду «стандарты кодирования», используйте эту фразу. Если вы имеете в виду какой-то другой «стандарт», уточните слово «стандарт» с помощью уточняющей фразы, чтобы уточнить, о чем вы говорите. «Стандарт» является расплывчатым и запутанным.

— S.Lott

2

Начать проект улучшения программного обеспечения (SPI) . Определите его объем и цели. Это определенно поможет, если у стандартизации есть свои цели и показатели, применимые к вашей организации.
Назначить ответственного за принятие стандартов . Это также может быть несколько человек или даже отдел в случае большой организации. Важно то, что все, кто отвечает за стандартизацию, будут:
- достаточно профессионально, чтобы увидеть всю картину
- достаточно влиятельны, чтобы иметь дело с командами и помочь им принять / обсудить изменения
Разработайте тренинги, охватывающие как стандарт, который вы хотите принять, так и его особенности, применимые к вашей организации. И это действительно важно, поскольку все люди, которые не были обучены, потенциально устойчивы к изменениям. Например, когда я работал в крупной компании, я инструктировал всех новых сотрудников о процессах обеспечения качества, CMMI, ISO и системе управления качеством. Такое обучение было обязательным. Это помогло улучшить знания о процессах управления качеством и повысить осведомленность сотрудников о важной проблеме качества программного обеспечения.
Обсудить изменения и адаптировать общепринятые методы для ваших конкретных потребностей. Это поможет избежать бюрократии и реализации тяжеловесных процессов, которые никому не нужны.
Установите мониторинг того, как внедряются улучшения процесса, поддерживаются ли они и являются ли они достаточно эффективными в вашей организации.

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

— чередующееся
источник

6

Пара мыслей из школы тяжелых ударов:

1) Большинство инициатив по улучшению процессов тратят 80% своего времени на разработку процессов и 20% на образование и социализацию. Отразить эти проценты. Посредственный стандарт, который следует, превосходит идеальный, который не соответствует.

2) Определите четкие причины, по которым вы просите людей изменить свою работу. Какой бизнес-кейс? В идеале это приносит пользу каждой команде индивидуально. Иногда это просто системное улучшение. В любом случае, сделайте случай видимым.

3) Упростите, затем стандартизируйте, а не наоборот.

4) Вы не можете полностью делегировать это PMO. Прямые менеджеры должны быть куплены, и руководитель бизнес-единицы должен будет разорвать связи, когда поступают жалобы.

5) Найдите дружелюбных ранних последователей. Люди будут жаловаться на то, сколько времени это займет. Вам нужен кто-то, на кого вы можете указать и сказать: «Это заняло у них всего 15 минут»

6) Для метрик, настаивайте на количественном, а не на качественном. В противном случае у вас есть проекты, которые являются зелеными до дня, предшествующего Go Live, когда все падает на месяц.

7) Подчеркните методы над инструментами. Хорошее планирование важнее, чем MS Project.

8) Поставьте уровень процесса относительно потребностей. Каждый ресторан нуждается в обработке, но Nobu и французская прачечная нуждаются в другом виде, чем McDonalds. То же самое с фирмами-разработчиками программного обеспечения.

Удачи!

— MathAttack
источник

1

Отличный ответ - я также добавлю, что будьте очень осторожны с процессом, который вы вводите, - убедитесь, что вы не попали в ловушку выполнения того, что лучше для процесса, а не того, что лучше для клиента - т.е. процесс должен быть ориентирован на клиента. Кроме того, будьте осторожны с тем, что вы измеряете - по определению, что является мерой, важно, а что не измеряется, не имеет значения. Измеряйте неправильные вещи (SLOC / Day, Bugs / SLOC и т. Д.), И вы не получите улучшения, но измерения покажут, что вы есть.

— Mattnz

1

@mattnz - я не знаю, ошибка / SLOC может быть полезной метрикой, если вы правильно ее примените. Если кто-то скажет, что он в среднем составляет 1 ошибку / 10 SLOC, я, вероятно, буду обеспокоен. Хитрость заключается в том, что вы должны знать, где бары, что может быть трудно.

— rjzii

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

— Математическая атака

1

Измеряйте меня по ошибкам / SLOC, SLOC / day, и вы удивитесь, насколько многословно я могу сделать свой исходный код, не добавляя ничего полезного. Например, размещение фигурных скобок на новой строке всегда - чем больше строк, тем меньше статистика, тем лучше я становлюсь программистом. Дайте мне ЛЮБУЮ меру, и я покажу вам, как я могу сделать это измерение, чтобы я выглядел лучше.

— Mattnz

1

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

— rjzii

2

Скорее всего, хорошая идея сосредоточить свои усилия на CMMI, даже если вы не проходите аттестацию и не проходите официальную проверку и оценку. Доступно много литературы о CMMI , CMMI и других методах улучшения процессов, таких как Lean и Six Sigma , а также CMMI и гибкой разработке программного обеспечения . SEI имеет целый набор ресурсов , некоторые доступны бесплатно, о различных аспектах CMMI и руководства для различных типов организаций.

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

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

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

— Томас Оуэнс
источник

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

— rjzii

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

— Томас Оуэнс

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

— rjzii

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

— Томас Оуэнс

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

— rjzii

0

Для каждого изменения:

Назовите 1 изменение и как это улучшит развитие.
Реализуйте изменения.
Продемонстрировать улучшение
Удалить изменения, которые не продемонстрировали улучшения

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

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

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

— dietbuddha
источник