TG Telegram Group & Channel
.NET Разработчик | United States America (US)
Create: Update:

День 2202. #ProjectManagement
10 Признаков Того, Что Проект на Пути к Провалу. Продолжение

Начало

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

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

Что делать?
Измерять реальные результаты:
- Сколько времени требуется для поставки изменений в производство?
- Довольны ли пользователи?
- Минимально ли количество ошибок и быстро ли они устраняются?
Эти вещи сложнее измерить, но они гораздо важнее. Поэтому, если ваш проект измеряется по тому, насколько хорошо вы содействуете какому-то процессу, но вы не можете ответить на вопросы вроде перечисленных выше, это предупреждающий знак, что вы сбиваетесь с пути. Начните измерять вещи, которые действительно имеют значение, а затем принимайте решения на основе результатов этих измерений.

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

Красный флаг
Чрезмерная бюрократия или отсутствие доверия командам разработчиков в принятии собственных решений.

Что делать?
Предоставить разработчикам автономию для принятия решений по проектированию и реализации, не дожидаясь одобрения на каждом этапе.

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

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

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

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

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

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

Окончание следует…

Источник:
https://youtu.be/-6KHhwEMtqs

День 2202. #ProjectManagement
10 Признаков Того, Что Проект на Пути к Провалу. Продолжение

Начало

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

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

Что делать?
Измерять реальные результаты:
- Сколько времени требуется для поставки изменений в производство?
- Довольны ли пользователи?
- Минимально ли количество ошибок и быстро ли они устраняются?
Эти вещи сложнее измерить, но они гораздо важнее. Поэтому, если ваш проект измеряется по тому, насколько хорошо вы содействуете какому-то процессу, но вы не можете ответить на вопросы вроде перечисленных выше, это предупреждающий знак, что вы сбиваетесь с пути. Начните измерять вещи, которые действительно имеют значение, а затем принимайте решения на основе результатов этих измерений.

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

Красный флаг
Чрезмерная бюрократия или отсутствие доверия командам разработчиков в принятии собственных решений.

Что делать?
Предоставить разработчикам автономию для принятия решений по проектированию и реализации, не дожидаясь одобрения на каждом этапе.

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

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

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

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

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

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

Окончание следует…

Источник:
https://youtu.be/-6KHhwEMtqs
👍8


>>Click here to continue<<

.NET Разработчик




Share with your best friend
VIEW MORE

United States America Popular Telegram Group (US)