Эдак с месяца 3-4 уже сижу на Скруме. Маленькие записки по поводу него я уже писал, но постепенно набрались новые мысли и ощущения.
Из новых ощущений
- Очень понравилось то, что не пытаешься планировать в какие-то бесконечные дали, а решаешь текущие проблемы, оставляя будущие проблемы на будущее (причем это относится как к product managment’у, так и к программированию).
- Понравились burnchart’ы – гораздо более объективная и простая методика видеть, как движется проект (по сравнению с нереально тяжким и неточным MS Project).
А вот теперь то, что НЕ понравилось
- Узаконенное не планирование архитектуры.
Молодые/плохие разработчики с удовольствием работают в пределах user story. Приемочные критерии пройдены, а остальное их не сильно волнует. Проблема возникает в том, что они могут писать код, который является полным говном. И когда, даже внутри того же спринта сталкиваешься с другой user story в которой нужно использовать их код, приходится – разобраться в нем, отрефакторить, проверить, что старая US не поломана и что новая сделана. И это в результате выходит дольше, чем сделать хорошо сраз.
В основном проблема тут в том, что задачи (например продумывание архитектуры) вероятность которых выполнения в этом спринте больше определенной нельзя откладывать на потом.
Впрочем проблема тут не только в Скруме, но просто в Скруме она узаконена.
Вторая вещь, которая меня напрягает насчет Скрума, что менеджеры ее могут считать волшебной палочкой, которая решает все проблемы. Типа “вот вам команда Скрум, а теперь делайте все сами, а я будут только наблюдать, чтобы оно шло внутри этого процесса”. Все таки, Скрум – это всего лишь методика управления проектами. Вне этой методики остаются вопросы мотивации, бизнес вопросы, улучшение процессов, технические вопросы и т.п. Ну и соответственно, если забить на эти вопросы – то ждать хороших результатов не стоит.
Помоему вопрос качества архитектуры лежит полностью на тимлиде, на том, как он мониторит код который пишут остальные, к скраму это не относится.
Вполне можно то же проектирование вынести в отдельный таск, пусть он и будет выбиваться из “общего” подхода.
Да и как-то не узрел я требования в скраме НЕпроектировать, это больше к XP относится, а применять практики XP по отдельности, да еще не особо граммотными разработчиками, только проекту вредить (если не убивать).
Подчеркну, это имхо.
>Помоему вопрос качества архитектуры лежит полностью на тимлиде,
Абсолютно согласен. Вопрос только, что в Scrum даже не введено такое понятие как team lead. Наоборот есть попытка унифицировать всех членов команды.
>Да и как-то не узрел я требования в скраме НЕпроектировать, это больше к XP относится
Прямого требования к НЕпроектированию нету. Но и требования к проектированию тоже нету.
Одно дело коллективное владение кодом, регламентируемое скрамом, другое дело пропустить важнейшую стадию разработки. И четко побуквенно следовать рекомендациям скрама, помоему слишком самоуверенно.
Возможно отказ от чистого проектирования как такового возможен, но при условии, что в команде все разработчики очень высокого уровня (как минимум необходим выская культура разработки) иначе ой.
Согласно внутренней динамики команды, всегда будет тимлид-серый кардинал, с мнением которого будут считаться, независимо от используемой методологии.
Хорошо, когда есть тимлид – серый кардинал. С другой стороны, когда с него снимают эти обязанности, команде объявляют, что не планирование – наш новый путь, то как раз ой и может легко наступить.
Я полностью согласен, либо нужны разработчики высокого уровня, которые могут на ходу принимать хорошие архитектурные решения, либо люди которые съели собаку на рефакторинге, который постоянно проводить.
Возможно я неправильно выразился. Имел ввиду, что даже если в команде отказываются от такой роли, как тимлид/архитектор, ее в обязательном порядке возьмет на себя один из разрабочиков, не афишируя и всячески отрицая. А если этого не происходит, то либо команде наплевать на продукт, который они создают, либо им настолько “внушили” основные постулаты скрама, что они по своему сделать боятся. В любом случае все проблемы лезут из менеджмента(скрам-мастера) и к скраму отношения не имеют.
Конкретно по приведенной ситуации, думаю здесь проблема не в том что “скрам/не скрам”, а в том, что суть работы ПМа остается абсолютно одинаковой, меняется только форма и название. И скрам всего лишь не описывает этот момент, вероятно полагаясь на то, что разработка архитектуры может быть выделена в отдельный спринт, раздроблена на несколько частей, как части различных спринтов, либо размазана по всем спринтам равномерным слоем, на усмотрение скрам-команды. Каждый из этих вариатов требует различный уровень и набор квалификаций, чем незаметней этап проектирования, тем выше требования к команде.
Согласен со всем кроме одного пункта – “обязательном порядке возьмет на себя один из разрабочиков”. Самоорганизация в командах не всегда происходит.
Для этого в команде должен оказаться толковый, опытный и энергичный человек.
в догонку.
Многие менеджеры и водопад считают волшебной палочкой
По типу “вот вам картинка с процентами по стадиям”, чтоб уложились и можно дальше идти пить кофе
Есть такое дело
Вообще приятней сидеть и пить кофе, чем возится с противными разработчиками
абсолютно согласен. по обоим негативным и позитивным фактам. сейчас работаю в МС и первый негативный пункт широко распространен в коммандах, которые используют скрам (скрум это как-то по-ирландски
). убедить, что нужно сделать архитектуру очень сложно. вообще чуть что сразу следует “мы же аджайл”, бесит реально. имхо что waterfall, что scrum требуют просто адекватных людей. и про волшебную палочку согласен, про scrum слышал, про waterfall никогда.
А что такое MC?
>вообще чуть что сразу следует “мы же аджайл”
Есть такое.
Причем, я понимаю, если бы речь шла о том, что месяц планировать архитектуру. Действительно это может быть слишком, но обычно даже день не хотят на это тратить.
МС – это мелокомягкие.
. все зависит от продукта. в моей практике есть 2 месяца на дизайн по сути трех классов (основные классы для СДК), добротный сервер меньше, чем за неделю очень сложно задизайнить (это я по минимуму).
месяц-неделя-день, вот тут я с вами не соглашусь, как вы определили много или нет ?
Насчет много или мало я исходил из того, что в Scrum – средняя продолжительная Sprint – 3-4 недели. И дизайн равный неделе в Scrum считался бы достаточно большим, а месяц – вообще неприемлемым.
Спасибо за предоставленный опыт. Пригодится.
Кажется open-id не работает, комментарии просто пропадают
Та я никак не разберусь с этой проблемой. Если пытаться написать комментарий еще не залогиневшись по openid – то там, что-то не работает.
Привет, Витя. Не знал, что ты уже давно ведёшь свой блог, да ещё такой интересный! Подписался – буду читать
По статье – интересная, сам недавно начал практиковать скрам. С плюсами согласен. С минусами вобщем-то тоже. По непланированию архитектуры: имхо конечно же её надо планировать, и чем раньше тем лучше, но, как говориться, без фанатизма. Я бы сказал, важно выбрать правильный курс, подходы, способы организации, и дальше развивать их по ходу проекта.
Привет
> да ещё такой интересный!
Спасибо
>По непланированию архитектуры: имхо конечно же её надо планировать, и чем раньше тем >лучше, но, как говориться, без фанатизма.
Именно-именно. Я как раз за это ратую. То есть планировать слегка вперед, не забегая совсем уж далеко, но и не оставляя ее на тот момент, когда уже поздно.
Кстати, если вдруг захочешь почитать, что я писал раньше, то погляди Most Popular Articles. Единственной – что тяжелее слон или кит и где же ты искусственный интеллект, можно спокойно пропустить. Они хотя вверху, но попали туда случайно.