Pull to refresh

Comments 50

Заинтриговали… Чем дело то закончилось? Или еще в процессе? Продолжение будет?

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

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

Нет — но и не значит, что плохой.

У программистов, как бы, ещё и другие полезные умения должны быть, кроме честности и попыток изменить ценности компании.
Это ничего не говорит о профессиональных качествах программиста. Может говорит скорее о его небезучастности к тому месту где он работает и к не планктонным коллегам. И то при определенных условиях: что изменения направлены на оздоровление коллектива, что результаты изменений в будущем помогут бизнесу получать больше прибыли. Это как в balanced scorecard изменения не только для улучшения финансовых показателей…

Отличие от скрам мастера: программиста нанимают для разработки, а скрам мастера для улучшения процесса разработки. В нормальной организации скрам мастеру кроме обязанностей дадут и права на возможность изменения и улучшения. И сразу за инициативы не уволят. В конторах, которые «покупают Аджайл» ничего обычно улучшать не собираются — нужен маркетинговый булшит для клиентов.

А какие профессиональные качества программиста существуют в отрыве от процесса разработки? Спрашиваю не шутки ради, а потому что каждый человек по-разному представляет себе "правильный" набор профессиональный качеств.


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


Или программист, который прикладывает все силы, чтобы выпустить в срок качественный продукт, который точно будет работать на боевом окружении — это ненастоящий профессионал?

Программист, работающий в команде, должен, как минимум, уметь работать с другими людьми, уважать коллег. Это значит, что нужно уметь договариваться, вырабатывать соглашения: как писать код, как комментировать коммиты, как работать с системой контроля версий в целом, как документировать свою работу. Нередка проблема, когда программист способный и производительный, но только если работает самостоятельно. Когда речь идёт о работе в команде, начинаются проблемы и появляются поводы для раздражения коллег.
Каждый член scrum-команды должен стремиться к достижению не личных целей, не к решению его персональных задач, но к достижению целей, поставленных перед его командой и к решению командных задач.

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


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

UnDelete конечно вы неправильно поняли. У каждой роли свой фокус. Давать отзыв и советы должна вся команда. Скрам мастер не менеджер, а роль ответственная за скрам процесс и его улучшения. К слову скрам мастер вообще не обязан уметь программировать, у него и без этого достаточно работы. То что совмещают роль разработчика и скрам мастера — не от хорошей жизни и часто вызывает конфликт интересов. И в скраме нет места менеджерам и PM — это попытки натянуть новый процесс на старый глобус
То что вы описываете — как не должно быть, но происходит повсеместно. И как раз лежит в области убеждений собственников и негласных корпоративных ценностей. Иерархия же не может без бюрократии и привычного им процесса…

Если не читали Extreme Programming Explained: Embrace Change (2nd Edition), то очень советую с ней ознакомиться, особенно с главами, которые касаются ценностей и принципов. Книга почти полностью про взаимоотношения людей, а не про технологии и техники и в вашей ситуации может пригодиться. Вот несколько цитат, чтобы заинтересовать еще больше:


I took two lessons from that experience. One is that no matter what the client says the problem is, it is always a people problem. Technical fixes alone are not enough. The other lesson I took was how important it is to sit together, to communicate with all our senses.

The biggest problem I encounter in what people “just know” about software development is that they are focused on individual action. What actually matters is not how any given person behaves as much as how the individuals behave as part of a team and as part of an organization.

Value in software is created not just by what people know and do but also by their relationships and what they accomplish together. Ignoring the value of relationships and trust just to simplify the scheduling problem is false economy.

In software development, “perfect” is a verb, not an adjective. There is no perfect process. There is no perfect design. There are no perfect stories. You can, however, perfect your process, your design, and your stories.

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

Я как стараюсь вовлечь каждого для реализации изменений. Один человек тут не справится. Спасибо за рекомендацию.
Может быть и изменение своего взгляда на вещи) Спасибо за рассказ с самого начала!
Статья выглядит как некоторые современные фильмы. Только вроде всё начинается и тут уже титры… Рассчитывал прочитать еще и рассказ про то, как же всё было изменено в этой компании.

Выводы все таки сделаны, но тема экшена конечно не раскрыта...

Очень интересно почитать как удалось заставить людей помогать друг другу
Работая в одной из компаний ввели коллективные премии:
Если план на команду выполнен, то все получают премию, нет — нет.

Кхм, я некомпетентен в Scrum и Agile, публикацию прочитал с интересом, и Ваш комментарий тоже :)


Но вот вопрос — а описанная из Вашего опыта практика коллективных премий насколько была успешна, и не было ли проблем? И если были проблемы, то как решались?


Прошу прощения, но что-то мне сразу в голову настойчиво стучится следующий сценарий: есть некая "команда" из, допустим, 5-и человек. Из них 3-е поддержали предложенное "социалистическое соревнование", выкладываются по-полной, чтобы получить желанную премию. И парочка халявщиков, которым плевать. Ну вот плевать и всё: типа "вам надо, вы и рвите себе жилы, а мы будем как прежде работать — и это в лучшем случае, если не будете на нас возникать; а будете звиздеть (черепаху из анекдота помните?) — так вобще ничего делать не будем, и работайте втроём за пятерых — а мы всё равно с вас будем премию иметь!".
Если подобный сценарий случится, то ведь дело запахнет расслоением коллектива и множеством конфликтов между "активниками" и "халявщиками"… "Активные" захотят, как минимум, отмежеваться от "халявщиков", требуя перетасовки людей по разным командам, желая работать с себе подобными, ну а "халявщики" соответственно будут против — иначе с кого же им премии иметь :)
А ещё могут найтись "личности", которые ради скорости выполнения планов будут жертвовать качеством кода, и в итоге качество всей самой системы через какое-то время начнёт падать, а сложность (/время/стоимость) разработки со временем станет повышаться… И ведь все эти проблемы тоже как-то надо решать...

Вы не учитываете лидера. Обычно лидер использует свое влияние для того, чтобы привести команду к единому пониманию. Если у лидера в команде 3 человека трудятся, а 2 фрирайдят — то это не команда, а что-то другое.

Но даже и без учета лидера, кто деливерит — тот и заказывает музыку.

Ежедневный стендап со стандартным вопросом (среди прочих) "Какие проблемы возникли?" помогает научить людей взаимопомощи. Обычно команда накидывает идей и старается помочь. Если конечно в команде не одни упыри, которые отмалчиваются и всегда не знают что посоветовать. Но такой жопности, я думаю, достичь удастся не многим, ибо это уже смерть команде.
Ещё мы дедали по два стендапа в день, чтобы чаще происходила коммуникация — в обед и вечером. Это пока команда не сыгралась.

Очень интересно почитать как удалось заставить людей помогать друг другу

Заставить помогать — это сильно… Невозможно заставить делать добро…
«Заставить помогать»—это сильная идея. Вообще, у русских проблема с навыками кооперации, договора и компромисса. Автор статьи ходит вокруг да около, не называя вещи своими именами.
без усилий даже у нерусских работа сама не делается
Поставил плюс, хотя статья, конечно, недописана.

Будем ждать продолжения… любого. Даже если не получится — всё равно интересно. А то про то, как у них всё классно получилось — пишут все, а как «рассыпаться» начинает — никто.

Дальше — «ошибка выжившего» и далеко не факт, что правильные советы…
Отличная статья, даже для таких как я ещё студентов, так как один из самых больших страхов выпускников, это тот, что пройдя собеседование он окажется 1 на 1 со сложными новыми задачами и не справится, или справиться с лишком медленно и его за это выгонят.

Корни всех проблем — в голове собственника, а про него как раз ни слова. Копайте глубже!

+1
сколько фирм сменил, во всех одна история — люди во всём транслируют отношение директора, и это не переломить, директор сам себя не поменяет, другого не поставят :) так что только валить из таких мест. только беда что везде такая петрушка :)
Когда впервые столкнулся с внедрением эджайлов и скрамов на описанный манер, то сначала все это возненавидел. В понимании многих менеджеров эти практики просто подразумевают тонны отчетов и коммуникации, возможности жестко вручную управлять специалистами, на хожу меняя задачу и т.д., а не про устранение иерархии, развитие инициативы, гибкость процессов и прочие описанные прексрасные свойства. Только потом почитав какие-то ститьи и книжки я понял, что, оказывается, проблема не в идеях, а в людях и реализации. Тут как с емократией — в идеях и бумагах подразумевается светлый мир, а на деле что имеем, то имеем. (:

Вот кажется это ценное мнение. Столкнулся с такой же проблемой. Пришел скрам мастер, и не смотря на то что он проповедовал взаимоуважение и командную работу, привел всех к формализму, который был только у него в голове. И вместо развития, я столкнулся только со стогнацией (не скажу про команду, только про свою). И так как все мои попытки не привели к изменению ситуации, пришлось покинуть эту фирму.

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

Частые изменения не являются зоной комфорта для многих людей (естественное, мое мнение). Были у нас такие ковбои методологии, что-то постоянно меняли: «А почему у вас нет клевой доски для развешивания задач на бумажечках? А что-то не видно, кто делает задачу. Аватарки на бумажках будет само то! А что это у вас разработчики БД не пишут CSS для фронтенда? Как-то не эджайл… Нам нужен ретроспектив, на котором мы укрепим работу команды построением башни из макарон!»
Когда заезжие гастролеры наконец-то оставили нас в покое, люди начали заниматься тем, для чего их нанимали: писать код,… ь.
А когда люди стали заниматься любимым делом, то они стали проявлять инициативу.
Жизнь слишком коротка, чтобы просиживать ее в зоне комфорта.
А, ну да, надо обязательно «в гамаке и на лыжах»(с) Комфорт, это когда ты получаешь удовольствие от работы. Что здесь плохого?
Комфорт, это когда ты получаешь удовольствие от работы. Что здесь плохого?
Ничего если ваша задача — работа на конвеере. Неважно каком: конвеере по выпуску автомобилей или web-сайтов на Wordpress'е.

Однако если от вам требуется выпускать что-то новое регулярно, то, увы, работа в зоне комфорта не годится: нельзя научиться ничему новому не набив шишек.

И вот это-то изначальное деление, как правило, при внедрении Agile, Scrum'а и прочих всяких «модных» методик пропускают.

Либо пытаются организовать из «середнячков заточенных под „не высовываться“» инновационную компанию (а это не работает), либо заствляют людей, ориентированных на новинки «строем ходить» (это работает — но с отвратительным КПД).
Однако если от вам требуется выпускать что-то новое регулярно, то, увы, работа в зоне комфорта не годится

Часто работаю над чем-то новым и интересным в отличной команде. Если команда занята чем-то серьезным, то скрам-мастер предоставить возможность выбора: стендап сейчас, позже или сегодня не нужен. Новые фичи продакт-менеджер приходит просто обсудить в комнату к команде, когда это надо, а не парит заранее назначенными на полгода вперед митингами груминга.
Это моя зона комфорта, это agile, а не та хайповая фигня, которую нам тюхали до этого.
  1. Если команда занята чем-то реально серьезным (аврал или сломалось что), то и у скрам-мастера есть чем заняться и на стендапы отвлекать никто не будет. Если давать возможность выбора, в большинстве случаев ответ будет "стендап не нужен".


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

Слышал несколько историй немецких фирм, которые продают один продукт на протяжении многих лет и удивляются, что все приходит в упадок: «как так, это же работало на протяжении последних 20 лет».

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

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

Проблема часто бывает не в людях, а всё-таки в технологии и её внедрении. Олдскульный специалист потратил многие годы для того, чтобы стать профессионалом в своём наборе технологий и рабочих практик. Переход на новые обязательно означает некоторый временный провал, поэтому совершенно рациональным поведением будет не делать этого, если мы не ожидаем в итоге существенного роста производительности. А он не всегда есть, т.к. многие новые технологии (не все, конечно) являются эволюционным развитием старых и лишь немного модернизируют процесс.
Грамотный коуч построит работу так что изменения будут идти от самих программистов. И тогда эти изменения будут комфортны и обоснованы. Насаждать изменения сверху — верный способ получить кучу негатива. Но есть одна вещь, которая требует насаждения, убеждения и прочих активных действий — идеология. Как только идеология непрерывной адаптации внедрена — всё, можно отходить в сторону и просто наблюдать.
Видел многих олд-скульных специалистов, которые были когда-то очень хороши в какой-то области знаний, но вместо того, чтобы учиться чему-то новому сидели в зоне комфорта

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


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

В итоге формируется устойчивый костяк менеджеров, которые
— умело контактируют с топ-менеджерами (поэтому они с такой радостью вам кивают в ответ на предложение об изменениях — боссы хотят изменений и они обязаны делать вид, что их поддерживают)
— формируют круговую поруку и почти никогда не бывают виноваты
— транслируют линейным сотрудникам, что «ну, вы же знаете, какая у нас компания» и грамотно фильтруют ваш фидбек

Если такие люди находятся достаточно долго в компании, то всё становится очень плачевно — всё больше людей оказывается вовлечено, топы не готовы изменить почти весь «средний класс» менеджеров, линейные сотрудники всё видят и понимают бессмысленность изменений
Если Сам утверждает витаминки и наушники, то у него нет времени думать о стратегии, в лучшем случае будет закрывать возникающие текущие проблемы. Фирма — корабль без карты и компаса. Взрослого человека (Самого) переделать вряд-ли удастся. Поэтому финал предсказуем на 98%. 2% на счастливый случай, что дело кому-то другому более толковому продаст или по наследству оставит.
Так и есть. Закрывает текущие дела.
А я Вам скажу, что пошло не так со Scrum-ом.
Никто толком не разобрался в нем, прочитали buzzword-ы — спринты, покер, ретроспективы, демо, и начали лепить как умеем. Народ в панике, еще вчера все работали по плану индивидуальному, а сегодня пришло руководство и объявило «всеконторский Agile». Оценивать никто не умеет, в сроки не укладываются, спринты факапятся, заказчик злится.
«Ну чот не поперло», решило руководство, и придумало новую мульку, вернее откатилось к старой. И проходит некоторое время, а воз и ныне там. Оценивать никто не научился. «Долги» после Agile-а остались. После нескольких пожаров, и тушение их баблом, нормальные разработчики, болевшие душою за проект «сгорели» и решили уйти. А они с самого начала пытались донести до власть имущих позицию по разработке.

Проект вошел в фазу вялотекущего допиливания, докостыливани того, что уже утекло на продакшен. Заказчик немного ворчит, но уже потратил на Вас сотни нефти и искать новых исполнителей ему лень. Поэтому бабки есть и направление в общем на плаву. И нафига там кому-то напрягаться.

Вот так и делается Agile. Хотя, кто мешает поискать информацию, поискать людей знающих, почитать рекомендации, продумать план внедрения, и по-тихоньку претворять в жизнь, сначала в отдельно взятой команде, а затем и во всей конторе.

История является моим сугубо оценочным суждением, все совпадения случайны.
Интересно будет прочесть продолжение истории, каким бы оно ни было. Но уже сам факт привлечения компанией специалиста по созданию команд позволяет сделать предположение, что не все потеряно. Удачи
Какое громкое и интересное название статьи «Scrum внедрили, agile — забыли», а что в содержании?
Вы позиционируете себя как специалиста по созданию команд, но в статье нет ни одного приема agile по командообразованию…
Перед вами была поставлена большая и сложная цель, но не понятно как вы ее достигали?! Витаминками и кружками?
В статье с таким названием хотелось бы видеть какие практики вы применили, что конкретно было сделано, чтобы решить поставленную перед вами задачу, как построителя команд!
Если вы что-то сделали и это не сработало, то почему не сработало?! Если вы такой профессионал в своем деле, то почему вас никто не слышит и не хочет этого делать?!
Сейчас, я так понимаю, цель поставленная перед вами не достигнута, и, более того, даже с места стронуться не получилось… Хотя, может, как специалисту со стороны, вам просто требовалось проанализировать ситуацию, и поняв, что scrum не работает в этой команде, предложить иной подход к работе? Сделать все возможное, чтобы сплотить людей и научить их работать как надо, достучаться до каждого, провести активную работу со всеми сотрудниками и сделать так, чтобы вас услышали, поддержали и пошли за вами к желаемой цели, но увы…. «Воз и ныне там!»…
Не знаю насколько достоверно вами проведен анализ, но вашей работы в данном большом деле, как специалиста по командообразованию, не видно…
Вы неплохо раскритиковали и вывернули наизнанку текущее положение в компании, но ведь именно вашей задачей было все исправить, я так понимаю?!
Пока видно только, как вы жалуетесь, что у вас ничего не получается, вините в этом своего работодателя (отмечу, который вас кормит и, наверное, неплохо!!!), который попросил вас о помощи и доверился вам, но разве в этом причина?! Может все таки в ком-то ином?
Есть над чем задуматься, неправда ли…
Данная статья об исследовании и о выводах, почему не заработал скрам. Не более того.
Она не об изменениях, которые я внедряю и она не описывает наличия или отсутствия прогресса.
Но я вас узнал, здравствуйте. Пора меняться, иначе останемся посредственной компанией с посредственными сотрудниками и посредственными руководителями. И я сделаю для этого всё что в моих силах.
Sign up to leave a comment.

Articles