Как стать автором
Обновить

Панацея ли Scrum? Давайте рассуждать вместе, где он нам полезен

Время на прочтение 4 мин
Количество просмотров 8.7K
Начну я просто — поясню, что такое Scrum и зачем он нужен, что бы те люди, кто с ним пока не сталкивался, могли с интересом прочесть данную заметку и понять о чём собственно идёт речь.

Итак, Scrum, это популярная (модная, если хотите) сегодня методология ведения программных проектов. Другими словами, как управлять командой разработчиков, что бы программный проект завершился успешно. Что и как документировать, как, с кем и как часто обсуждать детали проекта, как ставить задачи людям и как контролировать результат. Всё это попадает под термин “методология управления программным проектом”.

Вам понятно? Отлично! А теперь... я честно скажу, что я и сам не знаю что такое скрам. Но я знаю, что все разработчики его очень любят. Почему? Ну, наверное, потому что скрам крайне неформальный подход к разработке, предполагающий минимум документирования и много общения. Вы часто видели разработчиков, которым нравится писать отдельную документацию на свой собственный код? Я – редко.

Помните такой старый анекдот – руководство некоего института решило провести эксперимент: предложить студентам самим принимать экзамены у своих сокурсников (вместо преподавателей). И что вы думаете? Эксперимент себя полностью оправдал – в зачётках студентов только хорошие и отличные оценки!

Вернёмся к скраму. Скрам есть одна из популярных методологий, относящихся к классу Agile. И, следующих принципам XP (Extreme Programming). Вот тут хотелось бы внятно пояснить, что такое XP, Agile и Scrum. Ну, разумеется, так как я сам это понимаю (да вы сильно не пугайтесь, некое количество букварей я из вежливости прочёл, а те, кто прочёл больше, я знаю, обязательно меня тактично поправят).

Итак – XP.

Когда возникла вселенная, и люди только начали писать компьютерные программы, они относились к этому очень просто. Примерно как к созданию самолёта. Дело плёвое. Взлетит, не взлетит… да куда он денется. Ну а если ёбн… не взлетит в смысле, чтож, значит ошиблись где-то в расчётах. Бывает. Делать просто, это в смысле – делать всё последовательно. То есть садятся опытные, как правило уже седые мужики (как я примерно), и тщательно планируют всё наперёд. Иногда, сдуру, садились неседые, но у них, обычно всё-таки получалось хуже. Да. И эти мужики планируют работу по принципу: мужик сказал – мужик сделал! А мужик сказал просто, сегодня мы выжимаем из этих грёбанных заказчиков всё что они про ЭТО знают (а фуля, это же им надо!). Завтра, наши аналитики тщательно ЭТО фиксируют в спецификациях, и затем, самые наши аналитичные аналитики предлагают лучшие подходы, что бы сделать всё как ИМ надо в лучшем виде. Строго и после затем, из моря выходят архитекторы и подбирают наиболее подходящую архитектуру. И, ну теперь-то всё понятно. Налетают мальчишки кодеры, быстро всё это надиктовывают на… да это уже и не важно то на чём. И на выходе получаем конфетку.

В чём особенность такого подхода? А в том, что всё делается строго последовательно. Как в армии: подъём, зарядка, завтрак, построение на плацу… То есть, мы медленно… медленно спустимся с горы и тщательно перее… Я хотел сказать, что проект неукоснительно и бесповоротно следует к финишу, как вода падает со скалы. Подход так и называется – водопад (waterfall). Всё спланировано, всё предопределено, сроки размечены наперёд с точностью до часа. Всё бы хорошо, но… Нашлись наглые и дерзкие заказчики, которые почему то не захотели называть результат конфетой. Вкус им, видите-ли, не понравился. Чёрт с ним как они это назвали (не к обеду будь упомянуто), но они и платить то не хотели. Что уже не очень и хорошо.

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

Принципы эти таковы:

— Заказчику спуску не даём! Мы сразу берём небольшую паузу на то, что бы сделать правильную декомпозицию объектов, спроектировать интерфейсы к программным модулям, забить их заглушками за недели три, и далее выкатить первые визуальные формы

— Мы держим заказчика за хвост и показываем ему эти формы хотя бы раз в неделю. Заказчик начинает осознавать, что и как он действительно хотел и как ему в самом деле удобно. Его уже не пугает ничего. Он начинает мыслить!

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

— Мы понимаем, что нагородим много плохо работающего кода. Посему самые умные из нас изначально пишут тесты на предмет проверки того, что бы проверить, что всё это работает так как вроде бы хотел заказчик. И мы всегда проверяем каждый пук (зачёркнуто), нашу работу этими тестами (test driven development)

— Мы, в душе, понимаем, что код должен хорошо выглядеть. Посему мы периодически его чистим. Не меняя его суть и не перепроектируя. По умному — делаем рефакторинг. Что бы в итоге не напартачить, на всякое изменение гоняем тесты.

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

В чём отличие? А отличие в том, что мы не просто согласовываем с заказчиком как будет выглядеть деревянное изделие на выходе. Нет. Хотя и это тоже. Мы шаг за шагом снимаем стружку, пусть даже и не обрабатывая изделие наждачкой, но мы настойчиво суём его под нос заказчику с завидной регулярностью, что бы он проникся и не сказал потом, что этот выточенный хрен выглядит совершенно иначе, чем он представлял его в своих мечтах.

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

Да. Вот это и есть ХР. Набор технических принципов, как сделать разработку чувствительной к внешним требованиям. Это ещё не методология управления, а именно и только набор полезных технических подходов.

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

Поскольку пиво закончилось, то продолжение последует позже. :-)
Теги:
Хабы:
+60
Комментарии 62
Комментарии Комментарии 62

Публикации

Истории

Работа

Ближайшие события

Московский туристический хакатон
Дата 23 марта – 7 апреля
Место
Москва Онлайн
Геймтон «DatsEdenSpace» от DatsTeam
Дата 5 – 6 апреля
Время 17:00 – 20:00
Место
Онлайн