Продолжение публикации: Стыд и скрам — Чему нас учит Scream Guide.
За время, прошедшее с публикации на Инфостарте моей статьи “Стыд и Скрам”, хороший человек Владимир Меркушев не поленился и перевел Scream Guide-целиком. За что спасибо ему большое. Говорят, многие руководители проектов, читая это руководство, даже всплакнули — настолько больные темы.
Сегодня я хочу поговорить про команду разработчиков и планирование спринта, как его описывает Scream Guide — опять же, под лозунгом "в каждой шутке есть доля шутки, а все остальное — правда…" Слева приведены цитаты из первоисточника (Scrum Guide), справа — из пародии (Scream Guide), а снизу — мои комментарии.
| Команды Разработки обладают рядом характеристик: | Команды Разработки обладают рядом характеристик: |
|
• Они самоорганизующиеся: никто (даже Скрам-мастер) не может указывать Команде Разработки как превратить Бэклог Продукта в готовые к релизу Инкременты. • Они кросс-функциональны: команда обладает всеми навыками, которые необходимы для создания Инкремента Продукта. • Скрам не признает подкоманд в Команде Разработки, независимо от областей, над которыми необходимо работать (например, тестирование, архитектура, эксплуатация или бизнес-аналитика). Это правило не имеет исключений. • Команда Разработки несет коллективную ответственность за создание Инкремента Продукта. При этом отдельные члены Команды Разработки могут обладать различными специализированными навыками и экспертизой.
|
|
Если серьезно…
Во-первых, про игры с метриками — увы, часто больная тема, особенно в крупных компаниях. Могу только процитировать Максима Дорофеева:
Для любой системы KPI существует такая стратегия B, что показатели KPI при следовании этой стратегии находятся в зеленой зоне, но при этом сам проект через **пу идет в неизвестность.
Во-вторых, про "почти готово". Я думаю, что всем автоматизаторам знакома ситуация “почти готового” продукта, пребывающего в таком состоянии длительное время… У меня над столом даже висит один из моих любимых афоризмов: “Не так страшны первые 90% работы, как ее вторые 90%…”
По моему опыту, один из бонусов Agile — это фокус внимания именно на доделывании до конца. Потому что именно при выпуске в продакшн мы понимаем, будет ли тот или иной инструмент рабочим. Потому что гибкие методы — они в первую очередь про умение учиться на своих ошибках. И когда мы не видим законченный результат, не видим те проблемы и сложности, с которыми столкнулись реальные пользователи при практическом применении продукта — вот эта возможность учиться на ошибках как раз уходит…
Во-третьих, про ответственность.
Психология выделяет следующие стадии реакции человека на проблему. Начинаем мы, обычно, с первого уровня, и двигаемся дальше, если обратная связь от мироздания в ответ на нашу реакцию, нас не устраивает.
- Первая стадия — Отрицание. “Ничего не было, я в домике!!! Нет никакой проблемы, всё работает, это вам просто показалось”.
- Вторая стадия — Обвинение. “Мне сказал (менеджер, тимлид, пользователь, аналитик — нужное подчеркнуть, недостающее вписать) так сделать, он и виноват, я-то тут причем?
- Третья стадия — Оправдание. “Ну я же хотел как лучше!” (а по другому и быть не могло)
- Четвертая стадия — Самообвинение. "Ну вот я такой фиговый разработчик. Увольте меня.”
- Пятая стадия — Обязательства. “Обещаю больше никогда таких ошибок не совершать!”
- И только шестая стадия — Ответственность. Как чувство собственности за результат, и искреннего желания исправить то, что произошло.
(Вспомните притчу про Орлов, Устриц и Уток от Бодо Шефера — вот шестая стадия — это как раз и поведение Орла, который стремится достичь цели, а не Утки, которая только крякает).
Поэтому если проблему легко свалить на менеджера или еще кого-то — то стадия Ответственности заведомо не наступит, незачем, хватит Обвинения!
|
Отмена спринта |
Отмена спринта |
|
|
Если серьезно…
То здесь мы опять поднимаем вопрос ответственности. Когда у команды есть понимание, что происходит, и уверенность в завтрашнем дне — люди работают плодотворно. Большинство руководителей проектов сходятся в том, что для высокопрофессиональных разработчиков недостаточно денежной мотивации, определяющим фактором является получение удовлетворения от работы, видимость результата. И отмена Спринта — и следующие за ней вышеупомянутые неуверенность и беспорядок в команде — это самый надежный способ вот этого чувства удовлетворения от работы избежать.
| Планирование Спринта | Планирование Спринта |
|
|
Если серьезно…
В ходе онлайн “Базового курса для руководителей ИТ-проектов” который я веду сейчас на Инфостарте, мы собрали основные преимущества от привлечения команды к планированию. Получился вот такой список (дополняйте, у кого еще есть что сказать?)
- Руководитель не обладает всеми компетенциями по работам проекта (программистам виднее, сколько займет время программирование)
- Уровень владения информации по проекту повышается у членов команды
- Разные взгляды позволяют получить более объективную картину
- Конечный Исполнитель должен взять на себя ответственность за результат и затраты — это достигается совместным планированием
В моей практике работы и консультирования самых разных компаний, довольно явным маркером того, что что-то в команде/организации идет не так являлся фокус внимания не на результат, а на занятость и использование ресурсов. Настоящий Scrum как раз призывает от этого уходить. Нам не важно, сколько времени мы затратили на “почти готовый” продукт — важно, какой результат мы получили!
Поделитесь вашим опытом! С какими проблемами сталкиваетесь на практике?
В статье цитирую перевод Владимира Меркушева Scream Guide. Как быть Agile и не меняться и текст Scrum Guide с официального сайта.
Related Posts
Оценка и планирование проекта
Мысли о видах информационных систем…
Конфигурация "Выдача пропусков и учет рабочего времени"
Управление ИТ-проектами. Модуль 3: продвинутый курс по гибкому управлению проектами. Agile. Первый поток. Вебинары проходят с 11 сентября по 27 ноября 2024 г.
Загрузка/Выгрузка Excel для справочника "Графики работы сотрудников"
Онлайн-курсы по управлению ИТ-проектами от Марии Темчиной
Немножко из другой темы, но в принципе о том же
«Если серьезно…»
«Руководитель не обладает всеми компетенциями по работам проекта (программистам виднее, сколько займет время программирование)» — паровоз для машиниста? Кто принимает «проектное» решение? Кто обладает большей компетенцией, «опытом»? В данном случае «Руководитель» это не руководитель «Команды разработчиков»?
«Уровень владения информации по проекту повышается у членов команды»
— команда это все кто участвует — это же не только «программисты»?
«Разные взгляды позволяют получить более объективную картину»
— чем больше информации, тем объективней «картина» — чем больше «следов», тем легче найти «криминалисту » «преступника»
«Конечный Исполнитель должен взять на себя ответственность за результат и затраты — это достигается совместным планированием»
— тут смешиваются ЛПР и «советник» — обмениваться » впечатлениями» могут все — принимает решение»за результат и затраты» конкретный «Исполнитель» — ЛПР — пришлите мне пару лимонов 🙂 в личку укажу куда 🙂 возьмёте на себя такую ответственность за результат и затраты?
Чтобы иллюзий стало меньше — есть «технология» «Стыд и Скрам» и есть реальное их «применение» — Принцип неопределённости Гейзенбе́рга, но в экономике
Если отвественность коллективная, почему тогда зарплату не платить тоже не отдельным людям, а всему коллективу и пусть ее сами между собой делят. Только потом все друг с другом пересрутся и утопия со «срамом» закончится развалом коллектива и убытками компании
Мне тут вспоминается закон Паркинсона, который гласит: Работа заполняет все отведенное для нее время.
(3)
Это хитрый нюанс. Когда все (включая руководителей, разработчиков и заказчиков) работают в тесном контакте, то в большей степени видно, когда люди работают и дают реальный результат, а когда дурака валяют и имитируют бурную деятельность…
(1)
Про ссылку на Жванецкого — спасибо, познавательно.
Еще раз: совместно принятое решение — это более действенно, чем лично принятое соло руководителем.
Но вообще, по Agile не рекомендуется делать проекты, предполагающие кардинальные изменения архитектуры.
(5) С чего бы это размазывание ответственности вдруг стало эффективнее персональной ? Это прям какое-то новое слово в управлении…
(6)
Это очень хороший вопрос! Коллеги, поделитесь — кому удается добиться того, что команда ощущает коллективную ответственность, и за счет чего это получается?
(7) Команда может ощущать всё, что угодно. Но это всё что угодно никогда не будет эффективнее персональной ответственности каждого. Но для этого нужен качественный менеджмент… И тут мы приходим, (о, какой сюрпрайз!) к выводу, что за всеми тн «гибкими технологиями» скрывается попытка оправдать отсутствие качественного менеджмента ! :))
ps или попытку работать в условиях отсутствия такового, ага
(7) Команда ощущает коллективную ответственность если партком поддерживает решения исполкома.
(7)Я считаю, что если Руководитель не обладает необходимыми компетенциями по работам проекта и не готов брать на себя полную ответственность за его реализацию, то проект, с большой вероятностью, обречен на провал. Потому, что проект с коллективной ответственностью — как автомобиль в котором у каждого окна водитель с собственным рулем. Должен быть только один координатор проектных работ, отвечающий за конечный результат и управляющий всеми участниками проектной группы. Мне пришлось участвовать в нескольких проектах с разделенной ответственностью и коллективным принятием решений — к сожалению, не могу назвать это удачным опытом.
(4) Как правило у знающего специалиста выполнение аналогичной задачи занимает в десятки и сотни раз мньше времени, чем у неопытного. И знающий может на визуальный взгляд работать меньше, позволяя себе расслабиться. Для этого мы и получаем опыт
(8)
Собственно scrum это про «программист большой, ему виднее». Типа программисты настолько умные, что сами могут царствовать и управлять, только в реальности это ни разу не так. Программисты довольно часто ловят звезду и им кажется, что море по колено. Я думаю scrum — это оттуда
(12) король реально голый. как на любом трупаке наплодилось
мухкоучей и прочих жЫвотных… ;))(11) Более того, вот, например, сейчас, я пишу здесь, но это не значит, что я не работаю. «Потом Штирлиц проснётся … » (с) ыыыы
(15) Интересно узнать мнение Марии на этот счет. Возможно это всего лишь иммитация
(14)
Знакомая история! Вы сейчас описали роль, которую в Agile принято называть «Владелец продукта». Он отвечает за содержание работ, что делаем, что не делаем. И да — вы правильно заметили, что важно чтобы он был единой точкой входа, определяющей все работы.
Но это про состав работ, а не про выполнение!…
(15)
(16)
На эту тему полезно почитать книжку Брукса «Мифический человекомесяц». Комментарии на профессиональном форуме, конечно, не относятся непосредственно к выполнению работ. Но конструктивной работы у специалиста обычно получается 4-6 часов из 8-ми часового рабочего дня, никто не может заниматься разработкой непрерывно — технически не получается…
(18) А я считаю, что в творческих профессиях невозможно чётко разделить работу и неработу. Поэтому попытки управлять этим — шарлатанство как оно есть. 😉 Кстати научный термин «конструктивной» вообще требует отдельного описания 😉
ps Единственный способ работы в таких видах деятельности это персонифицированные договора с как можно более точным описанием желаемого результата, включая сроки его получения. Никаким скрамом тут и не пахнет.
(19)
Коллега, я все-таки призываю к меньшей категоричности! С фразой «Действенный способ работы» — более чем согласна, о да!! С фразой «Единственный способ работы» — никак нет.
(19) конструктивным может быть исправление одной строки кода за минуту. Только человек должен знать, где эта строка находится и что она делает. А это уже квалификация и опыт
(20) можете работать неэффективно, срывая сроки и не получая результат в конце. Тоже ведь работа так то
(22) а хорошо это или плохо?
(23) конечно хорошо, особенно для заказчика
(18)
Любой работой нельзя заниматься непрерывно в течении 8 часов рабочего дня, чисто технически или скорее физиологически, нужно периодически делать перерыв. Для работников интеллектуального труда можно переключиться на что-то другое. Два-три часа работаем, потом полчаса отвечаем на почту, пишем комменты на профессиональном форуме и т.д. и т.п. Потом возвращаемся со свежими силами.
Но тут главное не перегнуть палку, если сотрудник начинает отвлекаться каждые полчаса — то это уже ненормально и можно говорить о том, что форум стал мешать работе. Хотя это во многом индивидуально.
Долгая фокусировка на задаче часто мешает посмотреть на нее под другим углом. Как иногда бывает: решаем какую-то проблему пять минут, час, полтора — уперлись в тупик. Пошли выпили кофе, почитали чего нибудь и вдруг приходит понимание, что все это время мы долбились головой в стену, в то время как за углом есть калитка.
Это если решать задачу. А если искать выход из положения то задача вообще ни при чём.
А, ещё один крик души про эйджил… Болтовня на ровном месте вокруг надувания щёк с умным видом… Иллюзия систематизации работы, ага…
Вот она, единственная правда жизни. Есть волевой кулак — будет успешное внедрение. Нет такого — будет жевание соплей, конфликты и проблемы. И никкакие хитропопые технологии планирования работ не оказывают на это ни малейшего влияния. Ни ма-лей-ше-го.
(7)
Когда участники команды вовлечены в процесс принятия решения — появляется коллективная ответственность.
Эта ответственность не заменяет персональную целиком и это не противоположность, а дополнение.
(29)
Здесь возникает вопрос, а кем в итоге принимается решение? Командой? Если решение принимают все — то это значит что его не принимает никто. И появляется не «коллективная ответственность», а коллективная безответственность.
Всегда нужен руководитель, который может принять решение и нести за него персональную ответственность. Это не значит, что он не должен и не будет прислушиваться к мнению команды, но именно он должен выслушав все варианты и точки зрения принять решение, которое впоследствии станет обязательным для всех участников команды.
(28) (30)
И скрам ли тут был, или скрим до того, действительно абсолютно неважно, если есть осмысленное компетентным ЛПР решение — «Есть волевой кулак — будет успешное внедрение», ну или «волевой кулак» — только его разрушит, ведь не всем повезёт с главврачом, и отрицательный результат послужит всем наукой? И чем дальше мы погружаемся в тему, тем больше удаляемся от первоначальной постановки вопроса верить ли в новые методики- «Крик души про иллюзию внедрения Agile», или это про компетенцию заявляющих что они её придерживаются? Картинка со скрамом подозрительно напоминает каскад, итерацию, спираль. И в любом подходе «фокус внимания» подразумевает наличие положительного результата, а иначе как, завтра должно быть лучше, чем вчера. Ну и как мне кажется мнения «главврача» мы тут не услышим?
(31)
Но в этом случае мы все равно получим какой-либо результат. Даже и отрицательный. Если проект не пошел — то важно его своевременно завершить и зафиксировать убытки, а не пытаться оживить сдохшее, выбрасывая на ветер деньги и время.
«Коллективная ответственность» грозит же превратить проект в вечные 90%, когда постоянно что-то где-то доделывается, переделывается и исправляется. Особенно если в проекте возникнут какие-либо проблемы. Есть старая поговорка, которая как никогда подходит к данному случаю: у победы много отцов, поражение всегда сирота.
«Комманд Ком мертв, а мы еще нет!» — пели, обнявшись, отец Виндоуз и
командир Нортон. (с)
(20) съедобный сорт всегда один — высший
(21) молодЕж забыла этот анекдот, про телевизор, мастера, и, 10 рублей. Истории, УВЫ, свойственно повторяЦЦО !
ЗЫ и кое-кто, на этом, всегда…
(27) вокруг ага. ага. а они кажуть — мы хоть пытаемся..
(36) само ничего не систематизируется (с) Карл Линней
(37) хыхы, некто Маркс, Энгельс и, страшно подумать, Муссолини с ним нифига бы не поспорили…
(7) За счет разделения «предмета ответственности» по компетенциям участников команды в прямой зависимости от рабочей ситуации. Это общее положение. А конкретика всегда конкретна 😉
Ну например, если от клиента пришел чувак бить морду за «криво пришитые рукава», то с ним общается обаятельная девица от группы консультантов… 😉
Дальше работа администратора команды — «награждения непричастных и наказания невиновных»
Следующим выступает «невиновный», который в зависимости от сложившейся ситуации получает общую (неформально-командную) оценку своей невиновности и на конкретных условиях исправляет ситуацию.
Главным в такого рода подходах является насколько команда — КОМАНДА. А это прямая ответственность руководителя. Поскольку за результат ВСЕГДА отвечает (от слова ответственность) руководитель (как бы ему под разными предлогами не хотелось этого избежать).
Я понимаю желание автора на скрам- хайпе заработать очков.
Но при всем положительном эффекте не стоит «пудрить коллегам моск» — скрам — это один возможных способов ТЕХНОЛОГИИ работы команды (это «внутренний» процесс отдела разработки).
А хайп идет вокруг управленческих, кадровых, мотивационных и прочих подходов.
Возникает опасная ситуация, когда руководители соответствующих подразделений перекладывают свою ответственность — НЕ компетентность на «новые импортные технологии разработки» 🙁
С таким же успехом можно это делать в отношении новых «клавиатур и мышек» )))
(40) К огромному сожалению всё гораздо хуже. Так называемые «гибкие технологии разработки» ака скрам, эджайл анд соу он, разрушают само понятие «внутренний процесс» ж))
(39) ещё раз — вспоминаем, что эджайл предполагает организацию команд (трайбов, ага) по принципу заказчик [- аналитик] — исполнитель, что ПОЛНОСТЬЮ РАЗРУШАЕТ ….
(30) Когда-то давным-давно наблюдал, как это работает.
На предприятии было 2 очень хороших технических спеца — главный инженер (теоретик, конструктор) и начальник эксплуатации (практик). Технические проблемы на пересекающихся сферах решали у директора (опытный руководитель, но не тех.специалист в конкретной отрасли).
В ходе обсуждения директор молчал и давал спецам выговориться, поспорить, а вмешивался только когда они начинали переходить с конструктива на личности: еще раз формулировал тезисы каждого, просил их подтвердить, и принимал окончательное решение.
На мой взгляд, это лучший вариант «вовлечения в процесс команды», который сочетается с единоличным принятием решения и ответственностью за него (ответственные назначались тут же, контроль — на директоре).
(7)Коллеги, добрый день. По поводу коллективной ответственности — мне кажется, это явление уже сложившейся команды. Первый шаг — срабатывание команды, второй — выращивание общей цели, и как следствие — коллективная цель и коллективная ответственность.
Чем отличается коллективная ответственность в школе от коллективной ответственности в институте?
В школе тех, кто слишком хорошо успевает «награждают» занятиями с теми, кто «совсем не учится» в свободное от занятий время (вместо хобби и футбола необходимо «зажечь» алгеброй или тригонометрией).
В институте эта «премия» за хорошие конспекты и посещаемость снижается до СМС во время экзамена двух-пяти «звездочек» на группу.
Но вот мотивация другая. За помощь в школе баллы (или рейтинг в глазах учителя) добавляются, а в институте за то же самое могут и отчислить за компанию.
(41) Потому что это не технологии и не методологии, а набор ограничений, правил и, если повезёт, культуры. Любой внутренний процесс тоже включает в себя набор ограничений и правил. Никаких противоречий нет, просто некорректное использование терминологии, что всегда случается когда терминология проходит через масс-культуру и превращается в товар и «волшебную таблетку».
К тому же постоянно мешается продуктовый и проектный подход. Поэтому задаётся вопрос «Как же при этом соблюсти сроки?», а не «Как нам неизменно и непрерывно поставлять работоспособный продукт на протяжении всей разработки?». Конечно, на некорректный вопрос нет ответа. Например ответ на другой вопрос «Когда мы получим следующую работоспособную версию продукта с оговоренным инкрементом, которую сможем передать потребителям?» ответ будет простым — «В конце этого спринта (1-4 недели)».
Подходы и цели разные и инструменты по идее должны быть разные. Зачем применять продуктовый подход, если делаем не продукт (для внутреннего или внешнего пользователя), а проект, и критерием успеха является соответствие обозначенным на старте полгода назад срокам и бюджету?
«Но вообще, по Agile не рекомендуется делать проекты, предполагающие кардинальные изменения архитектуры.»
Эту фразу я долго искала, однозначно поддерживаю! А можно поподробнее, кто не рекомендует и есть ли ссылки на материал?.