День 2300. #УрокиРазработки Уроки 50 Лет Разработки ПО
Урок 51. Остерегайтесь «менеджмента по Businessweek». Начало Разочарование неутешительными результатами — мощная мотивация попробовать другой подход. Однако при этом важно иметь уверенность, что любая новая стратегия, которую вы примете, имеет хорошие шансы на успех в решении вашей проблемы. Организации иногда выбирают модные решения и горячие новинки в области разработки ПО, считая их волшебным эликсиром, способным решить их задачи.
Руководитель может прочитать о многообещающей, но, возможно, чересчур разрекламированной методологии и настаивать на немедленном принятии её в организации. Этот феномен называют «менеджмент по Businessweek». Либо разработчик, посетив конференцию, узнаёт о новом способе решения своих задач и торопится попробовать его. Стремление к совершенствованию похвально, но вы должны направить эту энергию в правильное русло и оценить, насколько хорошо потенциальное решение соответствует вашей культуре, прежде чем принять его.
За прошедшие годы люди изобрели бесчисленное множество парадигм, методологий и систем управления разработкой ПО: - анализ и проектирование структурированных систем; - объектно-ориентированное программирование; - информационная инженерия; - быстрая разработка приложений; - спиральная модель; - разработка через тестирование; - рациональный унифицированный процесс; - DevOps.
Методология Agile-разработки во многих её вариациях (экстремальное программирование, адаптивная разработка, разработка на основе функциональности, Scrum, Lean, Kanban, Scaled Agile Framework и др.) ещё один пример стремления к идеальным решениям.
Увы, как учит дядюшка Брукс, «серебряной пули не существует». Все вышеперечисленные подходы имеют свои достоинства и недостатки и должны применяться к соответствующим задачам правильно подготовленными командами и руководителями. В качестве примера далее рассмотрим некий новый подход к разработке ПО под названием «Метод Х».
Сначала проблема, потом решение В статьях и книгах, написанных изобретателями и первыми последователями «Метода Х», восхвалялись его преимущества. Некоторые компании выбрали «Метод Х», желая создавать продукты, которые лучше удовлетворяют потребности клиентов. Хотите быстрее доставлять полезное ПО? (А кто не хочет?) «Метод Х» поможет в этом. Хотите уменьшить количество дефектов, раздражающих клиентов и отнимающих у команды время на доработку? (Опять же, кто не хочет?) «Метод Х» придёт на помощь! В этом суть совершенствования процессов: постановка целей, выявление препятствий и выбор методов, которые, по вашему мнению, могут помочь их устранить.
Однако прежде, чем выбрать какой-либо новый подход к разработке, спросите себя: «Что мешает нам добиться таких же результатов, которые он обещает, уже сегодня?» Если вы хотите быстрее доставлять продукты, что вам мешает? Если цель — уменьшить количество дефектов, то почему сегодня их много? И т.п. Т.е., если «Метод Х» является решением проблем, в чём их причина?
Не все организации тщательно анализируют первопричины, прежде чем хвататься за решения, выглядящие многообещающими. Постановка целей совершенствования — отличное начало, но, помимо этого, важно понимать, какие препятствия стоят на пути к этим целям. Лечить нужно причины, а не симптомы. Если вы не понимаете причины проблем, то выбор любого нового подхода — выстрел в пустоту.
Предположим, вы хотите поставлять программные продукты, хорошо удовлетворяющие потребности клиентов. Вы прочитали, что в командах, применяющих «Метод Х», есть роль под названием «гуру», который отвечает за то, чтобы продукт достиг желаемого результата. «Отлично! — думаете вы. — Гуру позаботится о том, чтобы мы создали правильный продукт. Клиенты будут счастливы». Проблема решена? Может быть, но, прежде чем изменять процессы, ваша команда должна понять, почему ваши продукты не вызывают восторга у клиентов уже сейчас.
Окончание следует…
Источник: Карл Вигерс “Жемчужины Разработки”. СПб.: Питер, 2024. Глава 7.
День 2300. #УрокиРазработки Уроки 50 Лет Разработки ПО
Урок 51. Остерегайтесь «менеджмента по Businessweek». Начало Разочарование неутешительными результатами — мощная мотивация попробовать другой подход. Однако при этом важно иметь уверенность, что любая новая стратегия, которую вы примете, имеет хорошие шансы на успех в решении вашей проблемы. Организации иногда выбирают модные решения и горячие новинки в области разработки ПО, считая их волшебным эликсиром, способным решить их задачи.
Руководитель может прочитать о многообещающей, но, возможно, чересчур разрекламированной методологии и настаивать на немедленном принятии её в организации. Этот феномен называют «менеджмент по Businessweek». Либо разработчик, посетив конференцию, узнаёт о новом способе решения своих задач и торопится попробовать его. Стремление к совершенствованию похвально, но вы должны направить эту энергию в правильное русло и оценить, насколько хорошо потенциальное решение соответствует вашей культуре, прежде чем принять его.
За прошедшие годы люди изобрели бесчисленное множество парадигм, методологий и систем управления разработкой ПО: - анализ и проектирование структурированных систем; - объектно-ориентированное программирование; - информационная инженерия; - быстрая разработка приложений; - спиральная модель; - разработка через тестирование; - рациональный унифицированный процесс; - DevOps.
Методология Agile-разработки во многих её вариациях (экстремальное программирование, адаптивная разработка, разработка на основе функциональности, Scrum, Lean, Kanban, Scaled Agile Framework и др.) ещё один пример стремления к идеальным решениям.
Увы, как учит дядюшка Брукс, «серебряной пули не существует». Все вышеперечисленные подходы имеют свои достоинства и недостатки и должны применяться к соответствующим задачам правильно подготовленными командами и руководителями. В качестве примера далее рассмотрим некий новый подход к разработке ПО под названием «Метод Х».
Сначала проблема, потом решение В статьях и книгах, написанных изобретателями и первыми последователями «Метода Х», восхвалялись его преимущества. Некоторые компании выбрали «Метод Х», желая создавать продукты, которые лучше удовлетворяют потребности клиентов. Хотите быстрее доставлять полезное ПО? (А кто не хочет?) «Метод Х» поможет в этом. Хотите уменьшить количество дефектов, раздражающих клиентов и отнимающих у команды время на доработку? (Опять же, кто не хочет?) «Метод Х» придёт на помощь! В этом суть совершенствования процессов: постановка целей, выявление препятствий и выбор методов, которые, по вашему мнению, могут помочь их устранить.
Однако прежде, чем выбрать какой-либо новый подход к разработке, спросите себя: «Что мешает нам добиться таких же результатов, которые он обещает, уже сегодня?» Если вы хотите быстрее доставлять продукты, что вам мешает? Если цель — уменьшить количество дефектов, то почему сегодня их много? И т.п. Т.е., если «Метод Х» является решением проблем, в чём их причина?
Не все организации тщательно анализируют первопричины, прежде чем хвататься за решения, выглядящие многообещающими. Постановка целей совершенствования — отличное начало, но, помимо этого, важно понимать, какие препятствия стоят на пути к этим целям. Лечить нужно причины, а не симптомы. Если вы не понимаете причины проблем, то выбор любого нового подхода — выстрел в пустоту.
Предположим, вы хотите поставлять программные продукты, хорошо удовлетворяющие потребности клиентов. Вы прочитали, что в командах, применяющих «Метод Х», есть роль под названием «гуру», который отвечает за то, чтобы продукт достиг желаемого результата. «Отлично! — думаете вы. — Гуру позаботится о том, чтобы мы создали правильный продукт. Клиенты будут счастливы». Проблема решена? Может быть, но, прежде чем изменять процессы, ваша команда должна понять, почему ваши продукты не вызывают восторга у клиентов уже сейчас.
Окончание следует…
Источник: Карл Вигерс “Жемчужины Разработки”. СПб.: Питер, 2024. Глава 7.
