Олексий

к сожалению, адекватной альтернативы слова

коучинг

к скраму и правда накопилось в индустрии много претензий. но давайте разбираться:

на моем опыте половина из них вызвана просто непониманием самих принципов (это лечится тренингами, отчасти), вторая половина тем, что компании, заявляющие о внедрении скрам, на самом деле не хотят меняться вовсе. и поэтому адаптируют каркас, не понимая, его сути. это опасно.

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

есть такая метафора, что скрам — дает зеркало. это так, если его правильно внедрить. без всего мусора, с которым он ассоциируется.

а то, что потом в этом зеркале видны кривые рожи (не примите лично!) — ну да, некомфортно, но ведь они там и раньше были. просто зеркало было замыленным.

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

так, что скрам безопасен, если внедрен опытными людьми (отсюда и вся эта статья о скрам-мастерстве)

безопасен...НО! кроме случаев, когда вместо скрама подается что-то очень кривое с таким же названием. к сожалению, 80% команд и компаний украины если не больше делают скрам очень криво. и это ведет очень часто к наращиванию тех долга, эксплуатации команды, недовольству команд и проч.

вот это и нужно чинить. а не скрам.

по поводу вреда кривого скрама есть есть крутая статья апологета xp по этому поводу: ronjeffries.com/...rticles/016-09ff/defense

разница не очевидная, но есть.

на самом деле есть, как минимум, 4 стиля работы с группой (или человеком):
— фасилитация (применимо только для группы)
— коучинг
— менторинг (наставничество)
— обучение

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

agile коучинг — это по сути смешение всех приведенных 4 стилей работы, отсюда часто возникает путаница.

вижу в этом мире скопилось много обиженных «скрамом» людей. очень жаль.. и как минимум половина «озлоблённых» (как видно из комментариев) работающий скрам в глаза-то и не видела.

жаль. реально. ибо классная команда, тесно работающая с заказчиком — это прекрасное зрелище.

сходите может в гости в компании, где всё в порядке? поговорите с людьми, у которых есть позитивный опыт?

слелайте что-то с собой толковое. правда.
скептицизм — это вообще хороший знак, знак потенциала для развития.
цинизм же — нет, тупик для мозга.

решать вам.

предоставлять клиенту качественный сервис по разработке ПО

а у вас что, делание успешных продуктов не входит в спектр услуг?

согласен полностью.

но статья о том, как решать проблему уже после сейлов. конечно же, root cause — глубже.

если у вас проект на два года, но вы что-то делаете не так.

с троллингом пойди в форум.

зачем платить за то, что делать не нужно?

задачи исполнителя сделать за фиксированный бюджет максимум пользы.

2. да, и это не самая эффективный способ работать над продуктами, если интересует качество, сроки и бюджет.

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

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

людей-то вы может и научитесь оценивать, но влиять таким образом на производительность всей системы производства (системы отношений членов команды) вряд ли сможете предсказуемо.

я не видел успешных реализаций «piece work» работы для команд — оплаты за результат. я бы не пошёл работать в такой проект, думаю. хочу, как и все, стабильные деньги, раз уж я на кого-то работаю.

к тому же такой вид внешней мотивации может сильно ударить по реальной мотивации людей. появится страх, сомнения, нежелание экспериментировать.

Daniel Pink в известной книге «драйв» подробно рассматривает различие между мотивацией рабочих и креативных работников (нас): www.ted.com/...ks/dan_pink_on_motivation

Сергей, ты очень прав.

система может быть сложной:
business заказчика <-> IT заказчика <-> IT подрядчика

в этом случае «IT заказчика» является как бы заказчиком для «IT подрядчика». но это лишь по контракту. реальным же кастомером для подрядчика является «business заказчика» и вот именно с ними и нужно строить мосты путём вовлечения в процесс.

и вот как раз это и есть на мой взгляд чуть ли не самый главным момент, который подрядчик разумный (vendor sapiens) должен вложить в контракт: доступ к телу кастомера.

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