Comments 50
Заинтриговали… Чем дело то закончилось? Или еще в процессе? Продолжение будет?
Думаю к лету может что-то получиться. Опишу и результаты и ошибки и, может быть, рекомендации.
А если за чесность и попытки изменить ценности компании уволняют программиста, значит ли это, что программист хороший?
У программистов, как бы, ещё и другие полезные умения должны быть, кроме честности и попыток изменить ценности компании.
Отличие от скрам мастера: программиста нанимают для разработки, а скрам мастера для улучшения процесса разработки. В нормальной организации скрам мастеру кроме обязанностей дадут и права на возможность изменения и улучшения. И сразу за инициативы не уволят. В конторах, которые «покупают Аджайл» ничего обычно улучшать не собираются — нужен маркетинговый булшит для клиентов.
А какие профессиональные качества программиста существуют в отрыве от процесса разработки? Спрашиваю не шутки ради, а потому что каждый человек по-разному представляет себе "правильный" набор профессиональный качеств.
Если говорить про веб и мобильную разработку, то лично мне сложно рассматривать профессионализм программиста в отрыве от процесса. Только лишь технические навыки не позволят выпускать продукт часто и с меньшим количеством ошибок. Если в компании принято "перебрасывать" продукт от программистов в тестирование и забывать о нем, то насколько бы хорошо программист не владел техниками написания тестов, его в такой компании скорее всего "сожрут", потому что он идет против существующих ценностей. Если в компании программисты отдают код в эксплуатацию и их не волнует его дальнейшая судьба, то новому программисту даже не дадут шанса провести созданный им код до боевого окружения самостоятельно, потому что это работа другого отдела. Если руководитель команды никому не доверяет декомпозицию user story, а только спускает на программистов конкретные задачи, то как бы программист не хотел взять на себя ответственность за оценку, декомпозицию и выполнение всей user story, ему эту ответственность не дадут, потому что он посягает на работу руководителя.
Или программист, который прикладывает все силы, чтобы выпустить в срок качественный продукт, который точно будет работать на боевом окружении — это ненастоящий профессионал?
Каждый член scrum-команды должен стремиться к достижению не личных целей, не к решению его персональных задач, но к достижению целей, поставленных перед его командой и к решению командных задач.
Я правильно понял, что вы предлагаете программистам молчать тряпочку и писать код, пока скрам мастер имеет право на изменения. Если программист будет инициативным, то его быстрее уволят чем скрам мастера, потому что от последнего это ждут.
Просто такое мнение кажется и рушит, то что скрам пытается построить. В итоге скрам-мастер для руководства становится "менеджером", а разработчик "исполнителем" и первый имеет право диктовать свои условия команде, а второй как бы нет.
Если не читали 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-е поддержали предложенное "социалистическое соревнование", выкладываются по-полной, чтобы получить желанную премию. И парочка халявщиков, которым плевать. Ну вот плевать и всё: типа "вам надо, вы и рвите себе жилы, а мы будем как прежде работать — и это в лучшем случае, если не будете на нас возникать; а будете звиздеть (черепаху из анекдота помните?) — так вобще ничего делать не будем, и работайте втроём за пятерых — а мы всё равно с вас будем премию иметь!".
Если подобный сценарий случится, то ведь дело запахнет расслоением коллектива и множеством конфликтов между "активниками" и "халявщиками"… "Активные" захотят, как минимум, отмежеваться от "халявщиков", требуя перетасовки людей по разным командам, желая работать с себе подобными, ну а "халявщики" соответственно будут против — иначе с кого же им премии иметь :)
А ещё могут найтись "личности", которые ради скорости выполнения планов будут жертвовать качеством кода, и в итоге качество всей самой системы через какое-то время начнёт падать, а сложность (/время/стоимость) разработки со временем станет повышаться… И ведь все эти проблемы тоже как-то надо решать...
Ежедневный стендап со стандартным вопросом (среди прочих) "Какие проблемы возникли?" помогает научить людей взаимопомощи. Обычно команда накидывает идей и старается помочь. Если конечно в команде не одни упыри, которые отмалчиваются и всегда не знают что посоветовать. Но такой жопности, я думаю, достичь удастся не многим, ибо это уже смерть команде.
Ещё мы дедали по два стендапа в день, чтобы чаще происходила коммуникация — в обед и вечером. Это пока команда не сыгралась.
Очень интересно почитать как удалось заставить людей помогать друг другу
Заставить помогать — это сильно… Невозможно заставить делать добро…
Будем ждать продолжения… любого. Даже если не получится — всё равно интересно. А то про то, как у них всё классно получилось — пишут все, а как «рассыпаться» начинает — никто.
Дальше — «ошибка выжившего» и далеко не факт, что правильные советы…
Корни всех проблем — в голове собственника, а про него как раз ни слова. Копайте глубже!
Вот кажется это ценное мнение. Столкнулся с такой же проблемой. Пришел скрам мастер, и не смотря на то что он проповедовал взаимоуважение и командную работу, привел всех к формализму, который был только у него в голове. И вместо развития, я столкнулся только со стогнацией (не скажу про команду, только про свою). И так как все мои попытки не привели к изменению ситуации, пришлось покинуть эту фирму.
Agile это не только способ управления задачами и требованиями и его суть не в итерациях. Его суть в непрерывной адаптации всего ко всему
Частые изменения не являются зоной комфорта для многих людей (естественное, мое мнение). Были у нас такие ковбои методологии, что-то постоянно меняли: «А почему у вас нет клевой доски для развешивания задач на бумажечках? А что-то не видно, кто делает задачу. Аватарки на бумажках будет само то! А что это у вас разработчики БД не пишут CSS для фронтенда? Как-то не эджайл… Нам нужен ретроспектив, на котором мы укрепим работу команды построением башни из макарон!»
Когда заезжие гастролеры наконец-то оставили нас в покое, люди начали заниматься тем, для чего их нанимали: писать код,… ь.
А когда люди стали заниматься любимым делом, то они стали проявлять инициативу.
Комфорт, это когда ты получаешь удовольствие от работы. Что здесь плохого?Ничего если ваша задача — работа на конвеере. Неважно каком: конвеере по выпуску автомобилей или web-сайтов на Wordpress'е.
Однако если от вам требуется выпускать что-то новое регулярно, то, увы, работа в зоне комфорта не годится: нельзя научиться ничему новому не набив шишек.
И вот это-то изначальное деление, как правило, при внедрении Agile, Scrum'а и прочих всяких «модных» методик пропускают.
Либо пытаются организовать из «середнячков заточенных под „не высовываться“» инновационную компанию (а это не работает), либо заствляют людей, ориентированных на новинки «строем ходить» (это работает — но с отвратительным КПД).
Однако если от вам требуется выпускать что-то новое регулярно, то, увы, работа в зоне комфорта не годится
Часто работаю над чем-то новым и интересным в отличной команде. Если команда занята чем-то серьезным, то скрам-мастер предоставить возможность выбора: стендап сейчас, позже или сегодня не нужен. Новые фичи продакт-менеджер приходит просто обсудить в комнату к команде, когда это надо, а не парит заранее назначенными на полгода вперед митингами груминга.
Это моя зона комфорта, это agile, а не та хайповая фигня, которую нам тюхали до этого.
Если команда занята чем-то реально серьезным (аврал или сломалось что), то и у скрам-мастера есть чем заняться и на стендапы отвлекать никто не будет. Если давать возможность выбора, в большинстве случаев ответ будет "стендап не нужен".
- То есть вы предпочитаете, когда к вам внезапно врываются и прерывают рабочий процесс, чем заранее назначенное время для разговоров о будущих фичах?
Слышал несколько историй немецких фирм, которые продают один продукт на протяжении многих лет и удивляются, что все приходит в упадок: «как так, это же работало на протяжении последних 20 лет».
Видел многих олд-скульных специалистов, которые были когда-то очень хороши в какой-то области знаний, но вместо того, чтобы учиться чему-то новому сидели в зоне комфорта и, в конечном итоге, перестали быть востребованными рынком.
Да, выход из зоны комфорта очень часто болезнен, но (человек — это такая скотина, что ко всему привыкает) очень скоро нахождение вне зоны комфорта становится достаточно комфортным.
которые были когда-то очень хороши в какой-то области знаний, но вместо того, чтобы учиться чему-то новому
Проблема часто бывает не в людях, а всё-таки в технологии и её внедрении. Олдскульный специалист потратил многие годы для того, чтобы стать профессионалом в своём наборе технологий и рабочих практик. Переход на новые обязательно означает некоторый временный провал, поэтому совершенно рациональным поведением будет не делать этого, если мы не ожидаем в итоге существенного роста производительности. А он не всегда есть, т.к. многие новые технологии (не все, конечно) являются эволюционным развитием старых и лишь немного модернизируют процесс.
Видел многих олд-скульных специалистов, которые были когда-то очень хороши в какой-то области знаний, но вместо того, чтобы учиться чему-то новому сидели в зоне комфорта
Учиться надо всю жизнь, но это не то, о чем я говорил в своем первом комменте и о чем веду речь. И швец, и жнец, и на дуде игрец — таких людей очень мало и нельзя просто скрамом нагнуть всех уметь делать все. «Архитектура должна разрабатываться под команду, которая ее будет реализовывать».
Некоторые должностные лица отнеслись к внедряемым изменения откровенно негативно — хотя при разговоре лицом к лицу или согласно кивали или просто молчали.
Мне кажется это такая прослойка менеджерского звена, которая «ни рыба, ни мясо». Они даже могут быть и линейными менеджерами, но по факту их роль выше, но ниже уровня, где можно принимать фундаментальные решения в их отделе. Такие должности могут возникать как в ответ на увеличение штата нижнего звена, так и под влиянием различных попыток хоть как-то исправить ситуацию.
В итоге формируется устойчивый костяк менеджеров, которые
— умело контактируют с топ-менеджерами (поэтому они с такой радостью вам кивают в ответ на предложение об изменениях — боссы хотят изменений и они обязаны делать вид, что их поддерживают)
— формируют круговую поруку и почти никогда не бывают виноваты
— транслируют линейным сотрудникам, что «ну, вы же знаете, какая у нас компания» и грамотно фильтруют ваш фидбек
Если такие люди находятся достаточно долго в компании, то всё становится очень плачевно — всё больше людей оказывается вовлечено, топы не готовы изменить почти весь «средний класс» менеджеров, линейные сотрудники всё видят и понимают бессмысленность изменений
Никто толком не разобрался в нем, прочитали buzzword-ы — спринты, покер, ретроспективы, демо, и начали лепить как умеем. Народ в панике, еще вчера все работали по плану индивидуальному, а сегодня пришло руководство и объявило «всеконторский Agile». Оценивать никто не умеет, в сроки не укладываются, спринты факапятся, заказчик злится.
«Ну чот не поперло», решило руководство, и придумало новую мульку, вернее откатилось к старой. И проходит некоторое время, а воз и ныне там. Оценивать никто не научился. «Долги» после Agile-а остались. После нескольких пожаров, и тушение их баблом, нормальные разработчики, болевшие душою за проект «сгорели» и решили уйти. А они с самого начала пытались донести до власть имущих позицию по разработке.
Проект вошел в фазу вялотекущего допиливания, докостыливани того, что уже утекло на продакшен. Заказчик немного ворчит, но уже потратил на Вас сотни нефти и искать новых исполнителей ему лень. Поэтому бабки есть и направление в общем на плаву. И нафига там кому-то напрягаться.
Вот так и делается Agile. Хотя, кто мешает поискать информацию, поискать людей знающих, почитать рекомендации, продумать план внедрения, и по-тихоньку претворять в жизнь, сначала в отдельно взятой команде, а затем и во всей конторе.
История является моим сугубо оценочным суждением, все совпадения случайны.
Вы позиционируете себя как специалиста по созданию команд, но в статье нет ни одного приема agile по командообразованию…
Перед вами была поставлена большая и сложная цель, но не понятно как вы ее достигали?! Витаминками и кружками?
В статье с таким названием хотелось бы видеть какие практики вы применили, что конкретно было сделано, чтобы решить поставленную перед вами задачу, как построителя команд!
Если вы что-то сделали и это не сработало, то почему не сработало?! Если вы такой профессионал в своем деле, то почему вас никто не слышит и не хочет этого делать?!
Сейчас, я так понимаю, цель поставленная перед вами не достигнута, и, более того, даже с места стронуться не получилось… Хотя, может, как специалисту со стороны, вам просто требовалось проанализировать ситуацию, и поняв, что scrum не работает в этой команде, предложить иной подход к работе? Сделать все возможное, чтобы сплотить людей и научить их работать как надо, достучаться до каждого, провести активную работу со всеми сотрудниками и сделать так, чтобы вас услышали, поддержали и пошли за вами к желаемой цели, но увы…. «Воз и ныне там!»…
Не знаю насколько достоверно вами проведен анализ, но вашей работы в данном большом деле, как специалиста по командообразованию, не видно…
Вы неплохо раскритиковали и вывернули наизнанку текущее положение в компании, но ведь именно вашей задачей было все исправить, я так понимаю?!
Пока видно только, как вы жалуетесь, что у вас ничего не получается, вините в этом своего работодателя (отмечу, который вас кормит и, наверное, неплохо!!!), который попросил вас о помощи и доверился вам, но разве в этом причина?! Может все таки в ком-то ином?
Есть над чем задуматься, неправда ли…
Она не об изменениях, которые я внедряю и она не описывает наличия или отсутствия прогресса.
Но я вас узнал, здравствуйте. Пора меняться, иначе останемся посредственной компанией с посредственными сотрудниками и посредственными руководителями. И я сделаю для этого всё что в моих силах.
Scrum внедрили, agile — забыли