Я решил освежить и систематизировать свои знания по SDLC models/Software development methods/Software development models. Я признаюсь честно, будучи программистом я с отвращением относился ко всем этим методологиям и тем кто их продвигает. У меня всю жизнь была предельно простая методология разработки: Нормально делай, нормально будет! Ну а сейчас думаю - негоже мне быть невеждой до старости, надо просветится.
Вы знаете - почитав весь вечер про все эти Agile/Scrum/Lean/Kanban у меня ощущение как будто я методичек от Лайк Центра начитался. Успешный успех повсюду. По сути все эти "методы" - маркетинг чистой воды. Бородатые мужики в 1960-х придумали предельно простые вещи - чтобы написать какой-то софт тебе нужно:
- Собрать требования к софту
- Спроектировать его
- Спланировать разработку
- Разработать
- Протестировать что ты понаписал
- Задеплоить в прод
- Поддерживать
Все эти безчисленные методы строятся на том чтобы выполнять отдельные операции / группы операций из этого списка либо паралельно, либо инкрементально + в цикле. Ну и конечно навалить сверху кучу маркетинга, так чтобы на книжку хватило, переназвать все понятия и потом до самой пенсии колесить по миру - выступать на конференциях объясняя что значат новые термины которые ты ввел.
Специально для тех бедолаг кому больше нечем заняться кроме чтения моего недоблога, спецкурс - история развития software development methods за 5 минут. Не благодарите.
- Waterfall - вот как раньше мосты разрабатывали, так и софт будем писать. Собрали требования, спроектировали, построили, сдали в эксплуатацию. Все по порядку, никакого agile. Ну что вы хотели, мосты ведь не agile ни разу.
- Prototyping - эту методологию тоже из традиционной инженерии взяли. Прежде чем огромный мост бабахать, может маленький сделать из говна и палок ? Так быстрее будет гораздо, и заодно поймем какой нам мост нужен прежде чем все в полный рост делать
- Iterative and incremental development - ну это первый метод разработки который придумали именно для софта. Додумались что в отличии от моста, софт можно писать по частям. То есть выкатил первую версию с одной фичей, потом собрал требования для второй фичи, разработал и выкатил вторую фичу. В общем мы все до сих пор примерно так и работаем
- Spirital development - вот первая ласточка технического маркетинга, буллшита по нашему. Из 1986 года напомню. Чувак(Barry Boehm) подумал - а что если мы будем задачу решать в цикле, и на каждой итерации этого цикла, будем проводить оценку рисков и выбирать наиболее подходящую методологию разработки для данной итерации. В общем чувак добавил бюрократии в виде оценки рисков, ну и все остальное как в iterative and incremental development. Но главное его изобретение я считаю - он изобрел технический маркетинг в методологиях разработки. Ибо после него маркетингового буллшита стало в разы больше
- Rapid Application Development (RAD) - в 1991 году James Martin понял невероятное - клиентам гораздо проще пальцем показывать чем читать/писать огромный толмуды с требованиями. Напомним что в классическом waterfall - тебе нужно на первом этапе выдать разработчикам все требования ко всем фичам в формализованном виде(в виде текста), а потом подписать их своей кровью и не менять их после этого. Какая-то немыслимая херня по нашим временам. А James Martin понял что если сначала, на этапе сбора требований быстро сделать на коленке что-то, что выглядит примерно как тот софт который тебе нужно написать (прототип), и заставить клиента расписаться кровью на прототипе - то вероятность того что в итоге клиент получит именно то что он хочет, сильно повышается по сравнению с 500-страницами требований в виде текста. Ну и еще он понял что потом этот прототип не обязательно выкидывать после, его можно улучшать итеративно, и даже давать клиенту им пользоваться. В общем prototype + iterative and incremental development+marketing = RAD. Причем этот маркетинг я уже застал в своей программистской карьере. Borland Delphi, Borland C - это все было уже RAD-остным.
- Extreme programming - вот где маркетинговый буллшит развернулся в полную силу. Kent Beck решил, а что если мы возьмем все хорошее, что есть в существующих методологиях разработки ПО и сделаем это на максималках(extreme)? Чем не новая методология ? К примеру code review на максималках - это pair programming. Что, до него pair programming никто не занимался ? Неужели чтобы сесть вместе с джуном и показать ему как писать код, тебе нужна новая методология ? Что самое интересное, Kent Beck разработал эту методологию когда работал в Chrysler над их бухгалтерской системой. Начал он там работать в 1996, в 1999 написал книгу про extreme programming, а в феврале 2000-го этот проект закрыли. Прям успешный успех, не правда ли ? В это же время саму Chrysler купила Mercedes Benz. Наверное потому что в Mercedes набирали программистов которые по одному умели работать, а в Chrysler все по двое сидели.
- Scrum - а дальше ребята подумали, iterative and incremental development звучит слишком понятно, по этому книжку не напишешь. А что если мы это все пере-назовем своими словами и добавим ритуалов по вкусу ? Чем не новая религия для программистов ? Сказано -сделано, так и появился scrum. Ребята отличились тем что изобрели новую профессию - scrum-master. Типа как scrum-священник. Ведь у каждой религии должен быть священник который бы следил чтобы все ритуальные митинги соблюдались ?
- Lean software development - а дальше Mary Poppendieck and Tom Poppendieck прочитали книжку про Toyota и ее систему управления производством. И тут они подумали - что если взять все хорошее из существующих методологий, переназвать терминами из книг по TPS, то получится вполне себе новая методология. Поэтому не долго думая в 2003 году они выпустили книгу Lean Softwware Development и подружились с тусовкой agile-балоболов и счастливо колесят по миру продавая свое "изобретение".
- Kanban development - а дальше случилось мое любимое изобретение, Kanban. Ребята "изобрели" kanban доску и построили вокруг этого не хухры-мухры а целую методологию. Цитата из википедии - "Kanban approach aims to manage work by balancing demands with available capacity, and by improving the handling of system-level bottlenecks". А то до вас никто не балансировал запросы на IT capacity с ее фактической доступностью. Вы первые такое придумали. Увидели что на kanban доске куча задачь в QA зависла. Собрали совещание - что же нам делать ? Наверное нужно количество тестировщиков увеличить! Бинго!
На этом у меня все. Ждем новых методологий разработки.
Комментариев нет:
Отправить комментарий