— Нет. – угрюмо ответил Джон.
— Ты помнишь, почему я взял тебя в тимлиды? – Боб отвернулся от Джона и уставился в окно.
Вид с двадцать пятого этажа открывался шикарный, но, похоже, Боб его не видел.
— У меня своя версия. – тихо сказал Джон. – Кажется, дело было в скраме.
— Да, дело было в скраме. – кивнул Боб, все еще глядя в окно. – И я, если честно, уже не могу про него слышать. Не хочу говорить высокопарных слов, но ты меня обманул.
— Я? – недоуменно спросил Джон.
— Ты и скрам. Твой скрам. Твоя инициатива. – Боб повернулся и в упор уставился на Джона. Которая будет стоит мне проекта. И кучи денег.
Джон опустил глаза в пол. Он понимал, к чему клонит директор.
— Я… Я понимаю, о чем вы говорите. – неуверенно промямлил Джон.
— Вот… Ты молодец, Джонни, ты понимаешь. – на лице Боба появилась недовольная гримаса. – А мне что делать? Я бы с радостью выгнал тебя прямо сейчас! Ты это понимаешь?
— Да. – не поднимая головы, тихо сказал Джон.
— Но у меня руки связаны! Этот проект просто некому передать! Все команды загружены под завязку, а до дедлайна – всего месяц. Месяц, Джон! – Боб начал краснеть, что неудивительно при его комплекции – вес под триста фунтов, одышка, проблемы с сердцем.
— Мы постараемся, приложим усилия. – голову Джон так и не поднял.
— Как? Ну, объясни мне? Что ты еще придумаешь? Скрам ты уже придумал, теперь что? Канбан? Девопс? Перья страусиные в задницу вставите? – все больше распалялся Боб.
— Будем работать без выходных, по шестнадцать часов в сутки. – продолжал мямлить Джон.
— Зачем? Чтобы команда сгорела? Чтобы кто-то начал в обмороки падать?
— Надо – значит надо, мы готовы к тому, чтобы выложить все силы на этот проект…
— Это ты готов, Джон! – Боб показал пальцем на Джона, и тому пришлось поднять голову, чтобы не быть невежливым.
— Ребята тоже готовы. – Джон, как мог, придал уверенности голосу. – Я с ними разговаривал, все понимают, насколько это важно, и что наша судьба…
— Твоя судьба, Джон! – крикнул Боб. – В провале проекта виноват только ты! Команда здесь ни причем, они – просто разработчики, они делают то, что ты скажешь! Как ты стадо гонишь, так оно и идет, понимаешь, Джон?
— Понимаю… — сокрушенно сказал Джон и снова опустил голову.
— Ты был прекрасным разрабом, и я никогда не думал о том, чтобы сделать из тебя тимлида. – продолжал Боб на повышенных тонах. – Это азбука, аксиома: хороший разраб – это не хороший тимлид. Но ты меня… Нет, не обманул – просто запудрил мне мозги своим скрамом, и я решил – вот, вот он, тимлид нового поколения! Инициативный, вдумчивый, ищущий, не замкнутый в стереотипах! Тот, кто мне нужен! Как же я ошибся!
Джон молчал, не зная, что ответить. Чувство безысходности было настолько всеобъемлющим, Боб был настолько прав во всем, что Джону в голову не приходило ни одной идеи, как бы защититься, или, хотя бы, перевести разговор в какое-нибудь другое русло.
— Я устал, Джон. – гнев Боба внезапно стих. – Я не знаю, что делать. Ты поставил меня в тупик.
Джон лишь кивал головой, как провинившийся ребенок, которого на школьном совете ругают за разбитое в классе окно.
— Я, наверное, в каком-то смысле тебя даже понимаю. – Боб опять уставился в окно. – Я ведь тоже поверил в эту хрень. Я про скрам. Я тоже думал, что он поможет нам быстрее делать проекты. Дьявол побери, об этом написано на обложке этой чертовой книги! В четыре раза быстрее!
— Там трактовки отличаются… — промямлил, наконец, Джон. – Мы работали по манифесту, и…
— Да знаю я. – махнул рукой Боб. – Но ты же разраб, чистый разраб, хоть и работаешь тимлидом. Тебя в скраме что заинтересовало?
— Ну, там процесс, вроде, правильный, я примерил на нашу команду этот фреймворк, и…
— Вот-вот. – закивал Боб и снова повернулся к Джону и даже улыбнулся. – Я же говорю – разраб. Для вас главное – процесс, что там внутри. Технология, апи, абстрактность. Ну, как эти ваши холивары вечные, реакт или ангуляр, джава или пхп, на фронте или на бэке. А мне что важно, знаешь?
— Нет. – покачал головой Джон.
— А заказчику что важно, знаешь? – с усталой улыбкой продолжил Боб.
— Ну, наверное, проект чтобы вовремя был сдан.
— Именно. – Боб поднял палец вверх. – И ему, по большому счету, кроме редких случаев, нет никакой разницы, что за средства вы применили. Причем, речь и о фреймворках, на которых работает сервис, и о технологиях, которыми управлялся проект. Есть прекрасные проекты, которые мы сделали на реакте. Есть чудесные, высокорентабельные сервисы, которые мы запилили на ангуляре. И есть – провальные, сожравшие кучу денег поделки, за которые никто не заплатил – и на реакте, и на ангуляре. Понимаешь?
— Да. – с готовностью кивнул Джон. – Я понимаю, что дело не в технике и не в технологии.
— Ну, не совсем. – поморщился Боб. – Технология, все-таки, важна. По крайней мере, технология управления разработкой, и проектом в целом. Вот, теперь мы знаем, что от скрама, как от технологии управления проектом, толку мало. Согласен?
— Ну… — потянул Джон. – Все-таки, я бы не стал…
— Ага, вот оно что. – нахмурился Боб. – Ты чего-то не понимаешь, что ли, Джонни? Я плохо объясняю?
— Да я понимаю, просто… — начал было Джон.
— Послушай, услышь и запомни: я уволю тебя к чертям! – перешел Боб на крик. – Я не могу терять столько денег! Дон просто меня самого выгонит, ты это понимаешь? Мы и так у него не на лучшем счету, не хватало только еще одного просранного проекта!
Джон тяжело вздохнул и уставился на Боба. Взгляд его был не умоляющий – чего уж тут умолять. Еще минуту назад какая-то надежда теплилась – на то, что разговор перейдет в русло технологий и методов работы, а когда вот так, прямо, в лоб, как из ведра холодной водой – что уж тут попишешь. Надо принимать судьбу, как есть.
— Если ты думаешь, что у нас тут лаборатория экспериментальная, или университет, где ты можешь учиться, пробовать, ошибаться и снова пробовать – то ты что-то перепутал! – продолжал Боб. – Я допускаю эти ваши изыскания, пробы новых технологий, но только в одном случае – если это будет полезно бизнесу! У любого эксперимента есть начало, середина, и конец, понимаешь? Твоему эксперименту – конец! Моему эксперименту – конец! Ты – мой неудачный эксперимент. И скрам – мой неудачный эксперимент!
— Возможно, мы где-то ошиблись, применяя методы скрама. – Джон, поняв, что терять уже нечего, начал говорить смелее. – Не может быть, чтобы он не давал никакого видимого результата. Вот вам же нравилось, что мы стали чаще и стабильнее делать релизы. И заказчик вроде доволен был.
— Конечно доволен! Потому что до этого он вообще ничего не получал! – со злобной гримасой на лице продолжал Боб. – А сейчас вы кормите его этими релизами, как печеньками! А он хочет мяса! Понимаешь? Огромный, вкуснейший стейк – вот, что ему надо! Вот, что он заказал! А не печеньки, соусы, закуски и пиво!
— Ну и прозрачность повысилась, вы же сами говорили, как удобно стало оценивать остаток работ по проекту. – как ни в чем не бывало, продолжал Джон. – Я про сторипойнты.
— Я про сторипойнты. – передразнил Боб, потом вернулся к более серьезному тону. – Безусловно, польза от СП есть, и я хотел бы их оставить, даже когда мы выкинем скрам.
— Точно выкинем? – нахмурившись, спросил Джон. – Ведь столько пользы от него, например…
— Точно, Джон. – кивнул Боб. – Скрам мертв. И у нас, и вообще. От него нет никакой пользы. Это была пустышка.
— Мне кажется, рано делать выводы, по крайней мере, только на основе работы моей команды. – ответил Джон.
— А я не только по вашей команде сужу. – пожал плечами Боб. – Консультантов помнишь?
— Да.
— Они у нас три месяца торчали, и в итоге сказали, что у нас правильный скрам. – улыбнулся Боб. – Но, сколько бы я с ними не разговаривал, они не смогли мне точно ответить, как же, все-таки, делать проекты быстрее. Понимаешь? У них за плечами – годы работы с этой методикой, сотни проектов и команд, сертификаты какие-то выдают, а толку-то?
Такое ощущение, что это – какие-то сектанты, причем – уровня детского сада. С вами, разрабами, у них здорово получается разговаривать – вы уши развесите, рот откроете, и внимаете сказкам о том, как у вас теперь будет весело, интересно и здорово.
А когда с этими сектантами разговаривают серьезные люди, вроде меня, и темой разговора становятся деньги, а не эфемерные проекты, сервисы, продукты и сторипойнты, они сразу как-то теряются, увиливают, чуть ли не сбегают.
— Да, я понимаю. – кивнул Джон.
— Понимает он. – усмехнулся Боб. – Я и на семинар съездил – ну, где они собирают бизнесменов и директоров, вроде меня, и лечат на тему того, как хорош скрам, как он повысит прибыльность, скорость закрытия проектов, как мы конкурентов всех в гроб загоним. И знаешь, что?
— Что?
— А… Ничего. – поднял брови Боб. – Там, конечно, куча народу нового была, это их любимая публика, им можно в голову впихивать свои бредовые идеи.
Но были и такие, как я. Знаешь, как таких отличить? По взгляду, по смеси надежды и отчаяния. Мы приезжаем на такие мероприятия, чтобы найти! Хоть что-нибудь найти, понимаешь? Найти, что мы упустили. Найти тех, у кого что-то получилось – не доски ваши со стикерами развесить, а в бизнесе, денег зарабатывать больше получилось!
Найти себе, самому себе, оправдание, в конце концов! Ну не могу же я быть таким идиотом, который отдал кучу денег за хрен пойми что, ничего полезного не получил взамен, кроме очередной игрушки для разрабов и тимлидов! Понимаешь? Это очень тягостное, давящее, неприятное чувство, и его невозможно скрыть.
Кто-то, конечно, продолжает сам себя зомбировать – эгегей, у меня все хорошо! У меня скрам! Но это – до первой пьянки. Я ходил, потом, после семинара, в бар, подсел к одним – тоже эгегей которые, и что бы ты думал? После двух бутылок виски все встало на свои места. Та же проблема, тот же непонимающий взгляд, чуть ли не слезы, понимаешь? Каждый ведь понимает, что купил кота в мешке, потратил деньги собственника, и теперь в глаза ему стыдно смотреть.
И самое поганое – ни у кого не хватает смелости этого кота выбросить, утопить, вместе с мешком! А эти твари, психологи хреновы, это понимают! Еще как понимают! Оттого и гребут все больше денег, все время отодвигая горизонт – не бойтесь, эгегей, все будет хорошо! Скрам развивается! Не получается? Ничего страшного! Вот, еще вот этот метод попробуйте! Он отлично сочетается со крамом! Вот, тут только подпишите… И ждем предоплаты.
— А у вас, получается, смелости хватает? – улыбнулся Джон.
— У меня здравого смысла хватает. – пожал плечами Боб. – Я – такой же наемный работник, как и ты. Если меня ты залечил, то Дона я залечить не смогу, даже пытаться не буду. Не тот человек. Слишком… Нормальный. Простой, прямой. И умеет считать деньги. Плюс – мы не единственный его бизнес. Остальные, как ты знаешь, не связаны с айти и вебом.
— Ясно. – кивнул Джон. – Так что в итоге?
— А ты не понял? – поднял брови Боб.
— Понял, но хочется от вас услышать. – пожал плечами Джон. – А то опять не так пойму. Скрам – все?
— Скрам мертв. Для нас. – с серьезным видом сказал Боб. – Я больше ничего не хочу слышать о нем. Чтобы к вечеру не было досок на стенах.
— А как работать? – нахмурился Джон.
— Просто. Нормально. Работать. – чеканя каждое слово, сказал Боб.
— Ясно. – кивнул Джон. – Все?
— Все.
Джон встал со стула и пошел в сторону выхода. Дойдя до двери, остановился, потому что услышал голос Боба.
— Думай своей головой, Джон.
P.S. Продолжение нужно?
Комментарии (149)
cmd01
05.10.2018 08:53Как бы пока вообще не ясно .., идея вроде видна, но суть
agarus
05.10.2018 17:41Даже интрига скорее видна, чем идея — основной мысли не видно — дальше можно фантазировать в сторону любых недостатков: скрама, Джона, Боба, заказчика, происков конкурентов, провайдера интернета, поставщика оборудования…
cmd01
05.10.2018 08:55Как создать подходящий под свой бизнес формат? Без проблем и ошибок не будет… Все равно… и этот товарищ не может не понимать, не бывает решения идеального
Alexeyslav
05.10.2018 11:44Бывает. Уволится и разогнать всех — почему-то это отрабатывает без ошибок.
cmd01
05.10.2018 11:53ничего кроме большой траты времени не гарантирует такой подход «уволить ВСЕХ»
dipsy
05.10.2018 09:06+1И тут они выбросили скрам и стали просто работать, через полгода успешно завалив очередной проект. Возможно не кровати надо двигать…
ЗЫ. В обратную сторону тоже работает, если у вас было всё нормально, проекты более-менее сдавались, и тут вы ввели скрам, то всё станет не особо хуже (благодаря великому скраму, конечно же).ApeCoder
06.10.2018 14:23через полгода успешно завалив очередной проект
Тогда они скажут "просто работать is dead"!
shadson
05.10.2018 09:27Какой вменяемый CEO Боб.
Жаль, в жизни таких почему-то не бывает…mayorovp
05.10.2018 10:14+1Вменяемый? Сам поставил тимлида переросшего свой предел компетентности, сам остался без резервов по ресурсам, а теперь орёт на подчиненных и обвиняет во всем скрам…
DenimTornado
05.10.2018 12:38Рыли? СЕО и виноват в ситуации, бросил разраба во все тяжкие с непроверенной методологией и спохватился только когда всё к херам пошло.
shadson
05.10.2018 12:48Ну не совсем «разраба», а вполне себе тимлида, да еще и (если я правильно прочитал буквы) скрам-евангелиста.
Да, скрам здесь не зашёл, но это не только и не столько вопрос к СЕО — у него иные материи. Большинство из них (не все) даже не будут пытаться разобраться, в скраме ли дело — Джон за дверь, Джек теперь вместо него.
gennayo
05.10.2018 09:50А вот люди говорят, что скрам работает даже в 1С infostart.ru/public/911946
achekalin
05.10.2018 21:04+10Хоть что-то в 1с работает!
Anynickname
07.10.2018 00:58А что у вас в 1с не работает?
achekalin
07.10.2018 15:30Все работает, спасибо.
Но требует на это сил на порядок больше, чем любой другой софт. Порой, знаете ли, впечатление, что люди ни памятью управлять, ни с БД работать не умеют на уровне, приличном для столь популярного софта (я про саму платформу), но у них даже нет стимула прокачивать скил: купить купят любое, ответственности за качество кода ни перед кем нести, обновления — и те только за денежку можно получать… В общем, жить можно, но гордиться нечем.
Характерно, что сами разработчики на 1с называют "большими" БД и число юзеров столько небольшие (ссылаясь на саму платформу), что прямо ещё грустные делается. Я понимаю, на 1с писать Фейсбук никто не станет, но все же просить под столько клиентов воооот такую по мощности железку — кажется, об оптимизации разговора нет в принципе.
Как нет разговора ни о чем современном. Облака? Резервирование? Географически разнесенных кластер? На костылях из прошлого века такое не построить, а новее там ничего не видно. Повторюсь, я про платформу.
Про механику лицензирования можно было сказать больше и грубее, но — годами там в лучшую сторону ничего не меняется. Собственно, девиз видится так — "нужно больше золота", и только закон и угроза штрафа (а не уважение к производителю, скажем) позволяют это золото ещё получать.
Но это я так. Спасибо, что спросили!
Dr_XaoS
05.10.2018 09:52для тех кто не понял — дело не в скраме
cmd01
05.10.2018 11:59можно раскрыть причину?)
l27_0_0_1
05.10.2018 15:46Когда писал магистерскую диссертацию проштрудировал довольно много репортов других людей которые описывали свой опыт применения agile/lean и если честно можно просто рандомно проставлять результаты, разницы с реальностью не много будет. В реальности если команда сработалась и ей не мешать, можно хоть скрам, хоть не скрам — проблем не будет. А если нет, тут уже никакая методология не спасет кроме самых формализованных, пожалуй.
HappyGroundhog
05.10.2018 09:53«А что это? Это беклог. А что такое беклог? Это Скрама. А кто такой Скрам? Scrum is dead, baby, Scrum is dead...»
Навеяло заголовком)
mmMike
05.10.2018 10:08Когда то очень давно (2005-2006) было увлечение UML. Предлагалась как панацея и ответ на "The Ultimate Question of Life, the Universe, and Everything".
До сих пор помню (такое не забыть) пример использования UML в бизнесе из книги (доке кажется) от Rational Software (Ration Rose).
Содержание примера (почти дословно):
Жила была семья со своим мелким бизнесом. И что что то у них не шло с бизнесом. Прочитали они учебник по UML. Купили продует Rational Rose. Нарисовали в нем диаграмму (картинка диаграммы сценариев использования на 5-6 объектов со стрелочками) и тут у них КАК ПОПЕРЛО в бизнесе!
После прочтения этой главы у меня закралось подозрение… а не дурят ли меня.
Как показало время, подозрение было обоснованным.tangro
05.10.2018 11:18Это как с Форексом, где единственный способ заработать — продавать книги и организовывать учебные курсы по Форексу. Я думаю Rational Rose отлично денег срубил на своих книгах и продуктах. Знаю компании, которые их покупали.
sergegers
06.10.2018 12:39Ну Гради Буч вообще подошёл к делу с размахом. Во перывых он собрал всех чуваков, которые делали хоть мало мальски вменяемые тулзы для построения визуализованных спецификаций и таким образом пропылесосил рынок. Потом они вместе написали UML, RUP, сделали Rational Rose и всю линейку для командной разработки. А потом пробили правило, что тот, кто пользуется продуктами Rational Software автоматически сертифицируется на CMM 5. А требование сертификата CMM довольно часто указывается при размещении заказов на разработку, особенно госзаказов.
Так что хоть какая-то польза от Rational Rose есть.
acmnu
05.10.2018 14:00Я видел примеры грамотного приложения UML: авиационный софт. Логика примерно такая. Есть инженер, который понимает, какие сигналы (в широком смысле этого слова) нужны для некоторого события/действия. Он ресует UML, а с этого UML генерится C код. При чем генратор протестирован и верифицирован. Т.е. гарантируется, с некоторым уровнем покрытия, что генератор работает правильно.
Собственно на этой логике огромное количество самолетов летают и по сей день.
Подозреваю, что во многих областях производства это актуально.
Xandrmoro
06.10.2018 00:45+1Суть-то по итогу в том, что какую-то технологию или методику пытаются натягивать на всё подряд вне зависимости от применимости, а когда она начинает от такого обращения по швам трещать — "%TECH_NAME% DEAD!!!" и кидаются заниматься тем же самым со следующей технологие/методикой.
JuniorNoobie
05.10.2018 10:28А почему проект провалился-то? Только из-за методологии управления проектом? Они ввели новую технологию (SCRUM) на какой-то очень важный проект, никогда при этом не пользовавшись данной методикой до этого? Такое себе решение. Им понравилась прозрачность и частые релизы, но они так и не поняли почему провалили проект? Если там видно, что на реализацию той или иной задачи уйдет столько-то времени и эта информация обновляется каждую неделю, то как именно SCRUM помешал реализовать проект вовремя?
Singaporian
05.10.2018 10:57У скрама есть одна неприятная скрытая особенность — необходимость митингов. Стэндапы каждый день, груминг, планинг, демо, ретро. Сами по себе они ничем не мешают. Но склонные к флуду люди растягивают эти митинги на 100%-е покрытие времени.
Конечно же, скрам тут не причем. Эти люди и так найдут с кем попить кофе и покурить. Но, ввиду того, что теперь у людей есть выбор быть на этих митингах или нет, часть группы начнет работать, потому что не все любят митинги.
Я лично ушел из Ситибанка только из-за Скрама. Потому что мне было интересно что-то делать, но большинству было интересно тереть языками в переговорках и я был обязан там сидеть.
Скрам сегодня, за редким исключением, стал карго-культом. Он мертв из-за того, что слишком требователен к дисциплине.tangro
05.10.2018 11:21Пользуемся в команде чем-то типа псевдо-скрама без дейликов. Остальные типы митингов — раз в две недели и они скорее полезны, чем вредны. На все эти вопросы про «что делаешь? что будешь делать?» отлично отвечает Джира.
HappyGroundhog
05.10.2018 11:33К слову, заблуждение, что на дейли-скраме все должны отвечать на вопрос «Что делаешь, что будешь делать» это не более чем заблуждение! В том же скрамгайде эти вопросы просто приведены для примера. А сам дейли-скрам (или летучка, в терминах медиков или других не айтишных организаций) сделан для синхронизации. Синхронизации, где можно быстро осознать, туда ли вы все идете, поднять вопрос «мне нужно api для задачи, а Вася со вчера мне его так и не передал» и отправиться работать дальше. Повторюсь, у опытных команд на это уходит 5 минут. И при этом совершенно не обязательно каждому как обезьянка механически отвечать «Я делал, я делаю, я буду делать...».
tangro
05.10.2018 12:12Ну так даже и в этом описании это звучит тупо. Зачем мне ждать сутки, чтобы дёрнуть Васю на счёт этой апишки? Я что, не могу его так спросить? Или задача — опозорить Васю перед командой? Тоже как-то тупо.
Если описать скрам псевдокодом, то будет как-то типа:
while (true) { Sleep(1day); DiscussProblems(); }
Вместо схемы:
while (true) { WaitForNextProblem(); SolveProblem(); }HappyGroundhog
05.10.2018 12:40+2Вы удивитесь, но сплошь и рядом встречаются ситуации
"Как там моя задача?
Ну я Васю позавчера попросил <......>, жду!
А ты сегодня спрашивал?
А что я, девочка за ним бегать? Я жду."
Или джун реально стесняется обратиться к архитектору за решением своей проблемы по задаче. Дейли не столько процессная встреча, сколько еще и психологическая, где от твоего вопроса или требования не отмахнутся «потом, я щас страшно занят».neit_kas
05.10.2018 17:33Ну, джун и на стендапе может также молчать. Или упомянуть проблему на одном стендапе, но оставлять за бортом на следующих. У нас кстати для таких «висяков» собираются шефы и менеджеры в конце недели, проходятся по задачам и у конкретных людей выясняют, почему какая-то из задач повисла. После пинают кого надо. Оказалось, довольно действенно.
И, опять таки, если мне нужно api от Васи, я ставлю задачу на Васю по разработку данного api, у своей задачи выставляю is blocked by XXX и на всякий в комментах отписываю что-нибудь вроде: «Приостанавливаю работу, т.к. нужно такое-то api, которое делается в таске XXX». Далее уже все вопросы к Васе.
stanislavkulikov
05.10.2018 12:43Ну если вы такой инициативный, то вы молодец. А многие будут сидеть и думать, что им никто не поможет. Плюс могут быть очевидные вещи для одного, но сложные для другого. А есть ещё те, кто принципиально хочет сам во всё разобраться.
Ну и больше это нужно не из за озвучивания проблем, а для синхронизации. Т.е. я, например, на дейли говорю: я вот начал переделывать этот сервис. И тут Петя из моей команды: подожди, но я вот только что завязался на старую логику этого сервиса. (Пример условный, поэтому немного корявый, но суть доносит). И без ежидневных дейли Петя узнал бы об этом только после моего коммита, который бы всё ему разломал.
extempl
05.10.2018 12:54Или задача — опозорить Васю перед командой?
Насколько я понимаю, именно так. Точнее не опозорить, а заставить Васю работать. Так-то вы ему скажете, Вася отмахнётся, пообещает, может даже запишет где-то себе. Но он вроде как никому ничего не должен. А через неделю окажется что и вовсе забыл.
А так — максимум два дня, первый на передачу блокера Васе (Вы не можете работать над задачей пока он не даст Апи), второй на передачу задачу Вам (условно день) с готовым Апи.
Как-то так.
defaultvoice
05.10.2018 12:58Зачем мне ждать сутки, чтобы дёрнуть Васю на счёт этой апишки?
Дак никто не запрещает тебе дёргать Васю. Просто твоей команде неплохо бы знать, что если вдруг ты не успеешь вовремя доделать свою часть, то это потому, что Вася тебе апишку не предоставил и что все гарантированно в курсе твоей проблемы.
Handy
06.10.2018 00:29Больше скажу, если не ошибаюсь, то в скрам гайде примеры вопросов приведены как-то вроде:
— что я сделал для достижения цели спринта?
— что мне мешает в достижении цели спринта?
С остальным согласен полностью, если обсуждать реальный синк о том что блокирует и кого уже разблокировал, то 5-15 минут хватает и картина становится полностью ясной.
HappyGroundhog
05.10.2018 11:23При этом опытный скрам-мастер вам расскажет, что тот же Daily должен быть не более 15 минут. А многие команды укладываются в 5. И эти 15 минут явно прописаны в скрам-гайде.
Это вопрос культуры, как и с обычными совещаниями, на которых можно решить все важные вопросы за 20 минут, а можно убить 2 часа и уйти ни с чем.Singaporian
05.10.2018 11:50+2Именно — это вопрос культуры. Потому скрам и мало применим, что требователен к культуре. И нет никаких защитных механизмов от бескультурья, недисциплинированности и прочих человеческих факторов.
DaneSoul
05.10.2018 20:52И нет никаких защитных механизмов от бескультурья, недисциплинированности и прочих человеческих факторов.
А есть ли вообще какая-то методология, которая бы имела такие защитные механизмы от человеческих факторов?Singaporian
05.10.2018 20:56Мне нечем крыть :-)
Наверно лучше переформулировать тогда:
И нет никаких защитных механизмов от бескультурья, недисциплинированности и прочих человеческих факторов.
И слишком велика зависимость результата от культуры, дисциплины и прочих человеческих факторов.
JediPhilosopher
05.10.2018 13:56Очень, очень сложно модерировать собрания чтобы уходило 15 минут. Ни в одной конторе, где я работал, не справлялись с этим при размере команды больше 2-3 человек. Везде все растягивалось минимум на час, причем обычно пара человек о чем-то жарко спорят, остальные глядят в потолок или в телефончик.
Вообще интересно что это называется «стендапом» и предлагается делать стоя, чтобы не затягивать. Но опять же нигде я такого не встречал, все сидят в переговорках в удобных креслах, прямо провоцирующих с утра подремать под унылый бубнеж коллег. Может если бы все реально стояли на ногах, воды в разговорах было бы меньше.TheShock
05.10.2018 14:02Может если бы все реально стояли на ногах, воды в разговорах было бы меньше.
Да. Когда мы начали стоять на стендапах, то модерировать их стало значительно легче. Теперь вся команда не даст спорить двум людям — всем хочется побыстрее закончить и сесть
stanislavkulikov
05.10.2018 14:12Очень, очень сложно модерировать собрания чтобы уходило 15 минут.
У нас в команде дейли ни разу не занимали больше 20 минут.
причем обычно пара человек о чем-то жарко спорят
Просто останавливаю такие споры и создаю этим спорящим людям отдельное собрание. Так и время других не тратится и к этим встречам люди лучше готовятся и они проходят эффективнее.
HappyGroundhog
05.10.2018 14:20В случае, если спор затягивается, то грамотный скрам мастер, а потом и команда просто запоминают проблему и переносят её в отдельную дискуссию. Это может быть ретро, а может и просто совещание по проблеме.
Знаю ребят, которые на дейли стояли в планке) Вот что реально мотивирует побыстрее закончить! Если что, это было совместное решение всей команды)
staticlab
05.10.2018 15:38У нас реально уходит 15-20 минут при команде 8-10 человек (иногда некоторые уважительно отсутствуют). И да, это стендап — проводим его стоя.
Aquahawk
05.10.2018 15:54Мячик. Говорит только тот у кого в руке мячик. 3-5 минут на 10-12 человек.
Eldhenn
05.10.2018 16:09Полминуты на человека? О чём полезном можно рассказать за полминуты?
JediPhilosopher
05.10.2018 17:59А стендап не для того, чтобы рассказывать что-то полезное. Он для того, чтобы в двух словах обрисовать что ты делаешь и какие проблемы возникли, если они есть, в масштабе 1-2 дней.
А вот любители растекаться мыслью по древу и вещать по десять минут — они как раз и приводят к затягиванию митингов на часы. Если человеку есть что сказать больше чем на полминуты — это обычно либо какой-то узкоспециальный вопрос, по которому требуется консультация — и тогда он решается уже после собрания узким кругом заинтересованных. Либо это какая-то общая болтовня, на которую не стоит тратить время. Либо какое-то объявление для команды, которому возможно лучше посвятить отдельное время или вообще обойтись рассылкой по почте или группе в слаке или еще где.
neit_kas
05.10.2018 17:40Кстати да, опять же вопрос в кол-ве народу. 15 мин. на 2-3 человека или 15 мин на 20 человек.
JediPhilosopher
05.10.2018 18:00Ну адепты скрама вроде говорят что он работает для небольших команд, человек в пять. Уж точно не больше десяти.
neit_kas
05.10.2018 18:10Тогда значит ошибка тех организаций, в которых работал. В одной из них пытались применять скрам явно на команду из 12 человек.
Handy
06.10.2018 00:36+1Из скрам гайда
Having more than nine members requires too much coordination. Large Development Teams generate too much complexity for an empirical process to be useful.
Для больших команд существуют различные способы масштабирования скрама, например Nexus — для него тоже есть гайд на scrum.org.
Так что это точно ошибка тех организаций, в которых вы работали.
solver
05.10.2018 14:15Зачем вообще тратить даже эти 15 мин?
Что такого полезно в том, что все по очереди говорят «я делал то-то»?
Кому это нужно? Кому интересно? Какую пользу приносит проекту?
Только не надо заученными фразами из книги шпрехать. Расскажите про реальную пользу.
P.S. Это я еще молчу, что эти 15 мин выбивают еще на полчаса из контекста…stanislavkulikov
05.10.2018 14:23Выше уже писал. Это нужно во-первых для синхронизации, что бы каждый участник команды понимал, что делает другой и как это его затронет. Во-вторых для исправления каких-то мелких недопаниманий на лету. Т.е. кто-то не так понял какую-нибудь часть задачи и его тут же поправят, а не на этапе тестирования. В-третьих, что бы у продакта было понимание прогресса и он мог вносить корректировки.
solver
05.10.2018 14:32что бы каждый участник команды понимал, что делает другой и как это его затронет
Ну это же лукавство в общем случае. Чтобы понять как затронет работу, работа другого человека, не достаточно чтобы он сказал «я делаю сохранение документа». Там надо вникать и разбираться, что и как он делает. 15 минут «синхронизации» не хватит чтобы это всё прояснить. И опять же, «я делаю сохранение документа» никак не помогает понять прогресс. А если с задачей есть проблемы, то вменяемый разработчик не будет ждать сутки, чтобы сказать о проблеме. Он сразу скажет продакту о проблеме.stanislavkulikov
05.10.2018 14:41Перед каждым спринтом делается груминг — это встреча, когда по каждой задаче в общих чертах обсуждается как она будет сделана. Груминг как-раз и проводится для того, что бы каждый участник понимал реализацию. После этого 15 минут хватает за глаза.
Многим не нравится, что груминг + планирование иногда может занимать весь день. Но как показывает практика (хотя бы вот и сейчас), один потраченный день экономит в последствии намного больше времени за весь спринт.solver
05.10.2018 18:42Какие-то у вас очень простые задачи. Раз вы за день можете не только спланировать, но и даже определить реализацию для каждой из них…
А, еще оказывается всё сделать так, чтобы каждый участник понял реализацию. Поделитесь экспресс методами обучения людей за несколько часов? Или у вас все в командах матерые профи?time2rfc
05.10.2018 18:47+1Если задачу невозможно оценить за день, можно заранее взять задачу на проработку и исследование. Как оценивать задачи, если вы не можете объяснить реализацию за день ?
solver
05.10.2018 19:02+1Вот в этом и проблема. Как их оценивать?
Оценивать просто, когда ты на конвеере делашь одно и тоже. Какие нибудь сайтики на вордпресе. А когда вообще непонятно куда идти и что делать? На сколько я вижу, скрам хорошо работает только в случае конвеера, когда всё известно и надо только планы прикинуть к команде.
Для проектов в которых нифига непонятно и каждая вторая задача на ресёрч — скрам только мешает.time2rfc
05.10.2018 19:08Скрам как мои ботинки 45 размера, не всем подойдет.
Для проектов в которых нифига непонятно
Чтобы стало понятно что-то, необходимо провести работы — сделать понятно. Попробывать протатип, посмотреть видео итд.
TheShock
05.10.2018 19:16Это какие к примеру проекты? Я в свое время был на острие JS, делал игру на самописном фреймворке на html5 canvas в WarGaming, до того, как вообще кто-то такое делал в браузерах. И все-равно все задачи можно приблизительно оценить. Да, некоторые задачи могут сорваться — тут описываешь свои риски менеджменту, говоришь приблизительный «от и до» в часах или закладываешь сложность в стори-поинты. Но вцелом большинство задач, даже довольно новых, опытным разработчиком оцениваются довольно точно.
Главная причина пропуска сроков в таких компаниях — это изменения в беклоге, когда по результатам работы с пользователями выясняется, что какая-то фича получилась неудачно. ГД ее переписывают, художники перерисовывают, программисты переписывают, тестеры перетещивают и вот серьёзный кусок времени выпал, по глобальным срокам уже не успеваем и понимаем это уже в этот момент.
Обычно менеджеры садятся, думают, что выкинуть или можно ли перенести сроки. Если оставляют как есть в надежде «авось прокатит», то, обычно, не прокатывает.
То есть как с этим работают. На майлстоун есть 50% обязательных фич и 50% желательных. Если майлстоун занимает два месяца, то обязательные фичи после всех подсчетов должны получатся не больше чем на месяц. Тогда будет хорошая, стремительная разработка без авралов.
Обратите внимание, у нас, на разработке игры менеджмент уже за пару месяцев понимал, с чем мы влезаем по срокам, какие риски могут сработать и, в идеале, даже имел план на такие вещи. И, уверяю вас, это совершенно не конвеер.
neit_kas
05.10.2018 17:50Что мешает сделать всё это вне стендапа?
что бы каждый участник команды понимал, что делает другой и как это его затронет
По информации из jira, от тимлидов и менеджеров всё ясно.
Во-вторых для исправления каких-то мелких недопаниманий на лету.
Обсуждение в частном порядке или в формате мини совещания от этого спасает.
Т.е. кто-то не так понял какую-нибудь часть задачи и его тут же поправят, а не на этапе тестирования.
Это обычно от тестеров в частном порядке приходит.
В-третьих, что бы у продакта было понимание прогресса и он мог вносить корректировки.
Опять же, jira в помощь. От него исходит линейка задач, он всегда и в курсе происходящего.stanislavkulikov
05.10.2018 18:50+1Что мешает сделать всё это вне стендапа?
Да ни что не мешает. Но просто то, что вы описали — это классический водопад с матричной структурой управления. И тут каждый выбирает то, что ему больше нравится.
Просто представьте, что некоторые живут без менеджеров и тимлидов. Вот им так больше нравится, самим рулить проектом.
neit_kas
05.10.2018 17:28Честно говоря, дзен скрам стендапов я так и не постиг. Фичи или проблемы за 20 мин. не обсудишь. Оно требует более целенаправленного обсуждения. Кто чем занят — я это при необходимости из jira и истории коммитов в курсе (это как раз регулярно просматриваю). Тут как-то была статья про канбан стендапы. Было бы интересно попробовать, но кажется в крупном проекте может далеко не на 20 мин. растянуться.
anonymous
05.10.2018 17:45По мне так все сводится к:
«Задача сделать кнопку красной»
---А сегодня товарищи мы будем обсуждать вчерашнее обсуждение)))
ValertonGT
05.10.2018 10:52Вполне себе рассказ. А вот это выражение: «Просто. Нормально. Работать.» — прямо как слоган с конвейера! И надеюсь с Сергеем не конец) Очень сильно хочется продолжения ВСЕХ направлений!!!
usego
05.10.2018 12:05Только вот про работать над чем именно не сказано. А скрам ведь именно про беклог, а не стендапы. Если же СЕO видит беклог, но ни фига его не понимает, это уже не проблемы скрама, а компетенции людей на местах, либо способности найти нужных людей, которые могут сложить 2+2.
maxxannik
05.10.2018 11:02+1Прочитал. Спасибо :) Прям собран весь русский опыт внедрения SCRUM. И вся боль которая из этого опыта выливается.
Однако стоит учитывать ряд важных моментов:
1. Если есть проект и дидлайн, по которому отчитывают за SCRUM — то это вывих головного мозга. Надо лечить мозг того кто эти вещи сочетает, а не обвинять SCRUM.
2. Проекты и дидлайны бывают. Но там применяются проектные методы. Классические. Без SCRUM. SCRUM — это иная история. При определенном умении их можно сочетать. Но получается это далеко не у каждого.
3. Про консультантов — в точку. В РФ именно такие. Бегают кричат про SCRUM. А по факту просто деньги сосут и портят процессы. Но опять же это не проблема SCRUM. Это специфика русских SCRUM-консультантов.
4. Видел десятки команд в РФ которые гордо заявляли что у них уже SCRUM или что они его внедряют. Но что то похожее на настоящий SCRUM видел только у 2х команд. Реально по опыту в РФ судить о этой идеологии не стоит. Тут слишком мало тех у кого хватает ума понять что это такое и как его готовить.
5. В качестве альтернативной точки зрения стоит почитать книгу про Automattic «Год без костюма». Там про то как выглядит реальный Agile. От которого один шаг до SCRUM. Но те кто по настоящему сумел освоить силу простоты Agile — редко переходят на SCRUM.
Сам по себе SCRUM не даст крутые результаты. Скорее наоборот — станет только хуже.
Выгоду дает умение играть SCRUM. Чувствуете разницу?
Плохие результаты не потому что SCRUM плохой, а птм что люди плохо умеют играть SCRUM.
Это как обвинять гитару в том что у тебя получается плохая музыка. Но если тот кто играет — «рукожоп» — то даже лучшая гитара в мире будет давать ужасную музыку в его руках.
Коммент чисто для обозначения альтернативной точки зрения. Ну и для ссылки на книгу где описана не вымышленная, а реальная компания, с реальным опытом, которая добилась тех самых 4х-10х результатов относительно конкурентов описанных в книге про SCRUM.nmivan Автор
05.10.2018 11:08а где ссылка-то?
maxxannik
05.10.2018 21:24п. 5
если под ссылкой понимать url то можно сделать так
www.google.ru/search?ei=Say3W7X6GcjKrgSrvbWAAw&q=Automattic+%D0%93%D0%BE%D0%B4+%D0%B1%D0%B5%D0%B7+%D0%BA%D0%BE%D1%81%D1%82%D1%8E%D0%BC%D0%B0&oq=Automattic+%D0%93%D0%BE%D0%B4+%D0%B1%D0%B5%D0%B7+%D0%BA%D0%BE%D1%81%D1%82%D1%8E%D0%BC%D0%B0&gs_l=psy-ab.3...3664.3664.0.4201.1.1.0.0.0.0.63.63.1.1.0....0...1c.1.64.psy-ab..0.0.0....0.ZfhRDAdFjLk
Krat0S
05.10.2018 11:47Как-то много текста)
Если упростить:
- Виноват не Скрам, а вон тот чувак.
- Виноват не Скрам, это не всем дано.
- Виноват не Скрам, а вон те чуваки.
- Виноват не Скрам, а малое количество мозгов в РФ.
- Виноват не Скрам, читайте Agile.
Таки может всё же не повара готовить не умеют, а просто блюдо специфическое и очень на любителя?JediPhilosopher
05.10.2018 14:07Скрам он как коммунизм. На бумаге идея замечательная, но почему-то уже много лет ни у кого не получается ее приготовить. Но это не идея плохая и нереалистичная, нет, это просто они готовить не умеют. И вот они. И вот эти тоже. И вообще никто. Но сама идея хорошая.
time2rfc
05.10.2018 14:30Что делать людям которые живут в скрам командах успешно ?
JediPhilosopher
05.10.2018 18:06Радоваться. Ну я допускаю что такие есть, но пока их не видел. И знакомые мои не видели. И большинство комментаторов тут — тоже. Все что попадается на глаза — это «срам», когда от скрама только куски — бесполезные затянутые митинги и сторипоинты в джире, а в итоге все тот же хаотический «фигак-фигак и в продакшен».
time2rfc
05.10.2018 18:30Спасибо, стараюсь так и поступать.
В 2013 году на тренинге по scrum, услышал вопрос который поставил меня в тупик. Он был очень простой — Если сегодня, огромный рынок разработки ПО, высокие зарплаты и мало кадров, то зачем работать в месте где вас что-то не устраивает?
С тех пор большую часть времени я проработал в scrum командах, без менеджеров и тех.лидов.
Не могу сказать что это каждый раз был идеальный scrum, но он был довольно близок к чистому без перегибов. Не хочу говорить что это серебрянная пуля, но комфортнее работать я пока не вижу возможности.
Брат жив.
solver
05.10.2018 19:08Тут есть очень важный момент.
«Мы живем в скрам командах успешно» и «Наша команда успешна благодаря скраму»
Это знаете ли две большие разницы.
P.S. После того, не означает в следствии того ;)
stanislavkulikov
05.10.2018 14:29Нет, проблема в том, что берут методологию, потом начинается «здесь немного не так будем», «здесь у нас всегда затягивается», «А это вообще нафиг не нужно». И из хорошей идеи получается полная хрень. И тут действительно виноват не скрам, потому что его там уже и не остаётся, одно название.
JediPhilosopher
05.10.2018 18:08Ну это тоже как мне кажется беда методологии — неустойчивость к внешним воздействиям. Очень трудно построить сферический идеальный процесс в вакууме, всегда вмешиваются какие-то обстоятельства и мешают. И хочется чтобы методология при этом продолжала работать хоть как-то, а не превращалась в типичный «срам», который можно наблюдать во многих ИТ-компаниях.
Продолжая аналогию с коммунизмом (да простят ее мне любители политики и истории), можно тоже сказать что идеология-то хорошая, просто все время тут люди не очень умные попадаются, там не очень честные, и в итоге все разваливается.
playnet
05.10.2018 15:28оно deadline а не didline ))
1 — вообще именно проект и его сроки первичны, скрам — вторичен. Цель — сделать продукт, а не кодить ради кодинга.
Я бы сказал так — скрам хорош для крупных компаний, где все эти «неделю жду от соседнего отдела апи» и «субординация» во всей красе, а в мелких пользы особо не будет.
С субординацией сталкивался на одной из работ — там где надо было потратить 2 недели через начальства, я напрямую всё решил за 2 часа. И получил выговор.
Singaporian
05.10.2018 19:06Прям собран весь русский опыт внедрения SCRUM
Это наднациональная проблема. Она есть во всех странах. Причем, чем южнее страна, тем более запущена проблема. В Израиле, например, с этим вообще катастрофа. Скрам сжирает города.
tangro
05.10.2018 11:23Это азбука, аксиома: хороший разраб – это не хороший тимлид.
А ну-ка расскажите мне, из кого тогда сделать хорошего тимлида, если не из хорошего разраба? Из плохого разраба? Из хорошего ПМ-а? Из QA? Из человека без опыта вообще?HappyGroundhog
05.10.2018 11:39У хорошего тимлида, в отличие от разраба, на первое место выходят софтскилы или навыки общения с людьми. А учитывая, что обычно идеальный разраб — суровый интроверт, мы получаем тимлида с полностью отсутсвующими навыками общения. Которые нужно потом с нуля растить и развивать и то, это не всегда возможно. У Стартоплана есть целый цикл статей на эту тему, отлично подтверждающихся моим опытом и опытом знакомых коллег-руководителей.
tangro
05.10.2018 12:14Это всё отлично, но всё же где ответ на вопрос из кого нужно делать лида, если не из разраба?
HappyGroundhog
05.10.2018 12:36хороший разраб – это не хороший тимлид.
Тимлида делать из разраба. Но то, что он лучший разраб, отнюдь не означает, что из него получится лучший тимлид. Иногда лучший тимлид получится из посредственного разраба (всё, правда, зависит от того, что входит в обязанности тимлида у вас).
MaximChistov
05.10.2018 12:59из так себе разработчика, уход которого в тим лиды не подкосит продуктивность команды)
по крайней мере, в реальной жизни многие делают именно так
Dimash2
07.10.2018 04:06Все зависит от случая, но если строить идеальный мир, то Тимлид должен быть самоорганизованным разработчиком. Вы когда-нибудь видели лидера спецназа, который был бы не спецназовцем? Так же должен быть менеджер — продажник, который ведет проект и на митингах не должно быть всей команды, дискутировать должен Тимлид и продажник, можно только между собой, а можно — оба с клиентом. Тогда никаких проблем.
Иначе, кто именно в команде будет решать путь развития в техническом смысле?
Я думаю, что идеальной правильной формы нет и все зависит от размера бизнеса.
tangro
05.10.2018 11:27-1Я вот думаю о том, что было бы интересно пойти на вот такой эксперимент: давать каждому разработчику в команде по очереди месяц «без методологий разработки». Без скрама, без канбана, без джиры, без митингов и без отчётов вообще. Пусть сам себе выберет инструменты, задачи, план работы и месяц работает. И не трогать человека этот месяц. Потом пусть расскажет, над чем работал и что получилось. Сравнить результат со средним результатом разработчика основной команды, которая «бежала» этот месяц по скраму.
Интересно, что получится.MikeTolkachev
05.10.2018 11:59+1Что-то получится, это точно. И, как показывает практика, получается технически идеальная хрень, для последующий работы с которой нужен менеджер уровня того самого разработчика. Более того, после эксперимента вы потеряете программиста. Представим, что заказчик не примет проект. Вы обратно к программисту — давай переделывать. А это его творение и для него оно идеально, а заказчик м… к и ничего не понимает. А Вы, как начальник, тоже м… к, не смогли отстоять "правильное" решение
tangro
05.10.2018 12:19«технически идеальная хрень» не должна требовать каких-то сверхусилий на последующую поддержку, а то она не «технически идеальна» по определению. Я подозреваю, что в 3/4 случаев на выходе будет пшик, велосипед или любимый только автором уродец. Но всё же самые важные и выдающиеся опенсорс проекты — они же создавались примерно в таком режиме работы: без давления сверху, на собственных идеях и энтузиазме. Возможно, и тут иногда работало бы.
Потом, после того, как каждый в команде использует свой месяц — «неудачников» можно посадить обратно на конвеер, а хорошие идеи внедрить в продукт и дать их авторам бюджет, команду, свободу.
Dimash2
07.10.2018 03:58Такие программисты чаще работают во фрилансе, так как самоорганизованные люди более гибки не только в рабочих процессах, но и в зарабатывании денег в целом. Кто работает в офисе от звонка до звонка не готов к таким свободам. Большинство людей не будет себя организовывать.
Я согласен с вами в одном — что слишком много инструментов контроля и управления, их действительно нужно сводить к минимуму. Но, все-таки, это зависит от бизнеса и команды, например, я не приемлю в команду людей, которым нужна «игровая модель» управления и подстегивания, но я могу себе позволить выбирать, в больших «корпорациях» нехватка кадров и им приходится стимулировать разных людей и тут ваш подход о свободах не поможет )
BigEl
05.10.2018 12:03-1P.S. Продолжение нужно?
Есть вопрос? Есть ответ! ))
Данный рассказ на любителя… ну или на тонко-знающего предметную часть.
Было в комментариях выше, «А как же Серега?»
Пользуясь случаем, жду продолжение циклов «Проще, чем кажется» и «Корпоративная шизофрения» )
time2rfc
05.10.2018 12:28Спасибо за очередную дозу приятных впечатлений.
Очень порадовал тимлидом, потому что в scrum нет такой роли.
Боб котрый играет во взрослого тоже очень типичен.DoctorMoriarty
05.10.2018 13:15>нет такой роли
То, что в документах по скраму эта роль называется другим словом, не значит, что роли нет.
>играет во взрослого
Если кто-то осознал, что надо не играть в «море кода волнуется раз!», а просто писать код — он таки реально повзрослел.time2rfc
05.10.2018 13:49То, что в документах по скраму эта роль называется другим словом, не значит, что роли нет.
а каким словом называеться тимлид в scrum документах ?
Если кто-то осознал, что надо не играть в «море кода волнуется раз!», а просто писать код — он таки реально повзрослел.
Кому за что платят, мне платят не за код а за решения проблемм бизнеса. Иногда нужно посидеть и обсудить интеграцию, иногда архитектуру порисовать, иногда в CI поковыряться, если повезло с соседней командой то и в "море волнуеться раз" поиграть.
Позиция "ваши разговоры мешают мне писать код", имеет право на существования, как и любая другая. Просто как ботинки 46 размера она не всем подходит.
DoctorMoriarty
06.10.2018 06:29>а каким словом называеться тимлид
Называется словом scrum-master, не?Artyomcool
07.10.2018 17:09Не, scrum-master вообще в теории не входит в команду, а стоит сбоку и бдит за соблюдением этого самого скрама.
Hokum
08.10.2018 11:34а каким словом называеться тимлид в scrum документах ?
Если я правильно понимаю, то в гибких методология нет иерархии, т.е. там нет тимлида. Предполагается, что уровень в команде ± одинаковый и все участники команды разработки равноправны. Владелец-продукта — это не начальник, он отвечает, за набор задач и их приоритет, но вмешиваться в дела команды не имеет права. Ну а SM — это вообще наблюдатель, который хоть и является членом команды, но может только советовать/рекомендовать. А следовать его советам или нет — это уже решать остальным участникам.
stanislavkulikov
05.10.2018 14:18Если кто-то осознал, что надо не играть в «море кода волнуется раз!», а просто писать код — он таки реально повзрослел.
Опять же, чем скрам мешает писать код?
stanislavkulikov
05.10.2018 12:31+1Ну как обычно, неадекватный руководитель, неадекватные сроки, непонимание методологии, а виноват конечно SCRUM.
Команда здесь ни причем, они – просто разработчики, они делают то, что ты скажешь!
Первая ошибка. Скрам работает только тогда, когда это нужно всей команде. И прикол в том, что вся команда должна принимать решения. Да и при такой модели тимлид то и не нужен. Все его функции должны быть чисто административные.
В четыре раза быстрее!
Это только в условиях постоянно меняющегося ТЗ и по сравнению с водопадом полного цикла (написание ТЗ->Разработка->Тестирование->Внедрение) Т.е. скорость увеличивается за счёт того, что при изменение требований по результатам внедрения можно не ждать пока полностью ТЗ напишут, а сразу делать.
не хватало только еще одного просранного проекта!
Т.е. у них и так всё плохо и они надеялись на какую-то волшебную методологию?
Вот вам же нравилось, что мы стали чаще и стабильнее делать релизы
Ну и прозрачность повысилась, вы же сами говорили, как удобно стало оценивать остаток работ по проекту.
Т.е. плюсы они понимают.
Просто. Нормально. Работать.
И вот что изменится? Что их в скраме то тормозило?
Ну т.е. на лицо явное неумение Боба руководить: благодоря скраму он прекрасно видел прогресс и прекрасно должен был понимать дату релиза. Если это дата оказывалась после дедлайна он должен был либо уменьшить число фич, либо подключить ещё одну команду. И кстати, в стиле «Просто. Нормально. Работать.» об этом бы узнали только когда уже все сроки были бы просраны. И что по итогу? Ничего из мер не было предпринято, а виноват оказался самый толковый, и скорее всего самый полезный разработчик.
DenimTornado
05.10.2018 12:40+2Я правильно понял, они срок до дедлайна разделили на 4, потому как SCRUM ускоряет в 4 раза и теперь CEO рвёт на попе волосы?)
TheShock
05.10.2018 13:27То есть в этой фирме скрам, судя по статье, не ускорил разработку в четыре раза, но, зато, и не замедлил её. При этом принёс кучу других преимуществ. К примеру вот:
как удобно стало оценивать остаток работ
То есть, я так понимаю, скрам виноват в том, что не стал серебрянной пулей, не порешал все проблемы а лишь слегка улучшил ситуацию. Не говорите директору, что его жена какает, он сделает виноватой и её!
raingo
05.10.2018 14:16Хочу отметить, что компания то в рассказе аутсорсинговая. В аутсорсе скорость важнее качества, дизайна, надежности, масштабируемости, ui/ux, маркетинговых фич и прочее.
Боб опять уставился в окно. – Я ведь тоже поверил в эту хрень. Я про скрам. Я тоже думал, что он поможет нам быстрее делать проекты.
ИМХО scrum вообще не про скорость. Как раз про все остальное.
eugenvz
05.10.2018 16:55— Твоя судьба, Джон! – крикнул Боб. – В провале проекта виноват только ты! Команда здесь ни причем, они – просто разработчики, они делают то, что ты скажешь! Как ты стадо гонишь, так оно и идет, понимаешь, Джон?
— Понимаю… — сокрушенно сказал Джон и снова опустил голову.
— Ты был прекрасным разрабом, и я никогда не думал о том, чтобы сделать из тебя тимлида. – продолжал Боб на повышенных тонах. – Это азбука, аксиома: хороший разраб – это не хороший тимлид. Но ты меня… Нет, не обманул – просто запудрил мне мозги своим скрамом, и я решил – вот, вот он, тимлид нового поколения! Инициативный, вдумчивый, ищущий, не замкнутый в стереотипах! Тот, кто мне нужен! Как же я ошибся!
После вышеприведённого блока я окончательно убедился, что автор заметки не знает/понимает, что такое Scrum. Дальше читать не стал.
На Хабре тема «обсёра чего-то отдалённо напоминающего Scrum» довольно хайповая, поэтому не удивлён в количестве плюсов у данного опуса.JediPhilosopher
05.10.2018 18:04Ну так никто похоже не понимает, что такое скрам. Во всяком случае ни я сам, ни многие авторы комментариев не видели «труъ скрама», но видели много неудачных попыток. Scrum он как коммунизм — абстрактная прекрасная идея, которая при попытке внедрения на практике практически всегда вырождается либо во что-то довольно уродливое и неэффективное, либо чисто формальное.
lxsmkv
05.10.2018 20:59+1У меня тимплид — я эффективнее человека не видел. Он просто сидит с шести утра до шести вечера и фигачит. И что я у него заметил — он все прерывания обрабатывает по фифо. Тут же берет и решает твой вопрос. Чтобы голова всегда была свободна. Никогда не откладывает ничего «на потом».
Тебе надо уточнить вопрос на который он не знает ответа — пишет тут же емейл кому надо, ты еще договорить не успел. Или, ты еще не договорил, он уже набирает чей-то номер или уже пишет кому-то указания в джиру. Необходимые шаги для решения вопроса предприняты. Голова свободна.
Не делегировать не хранить задачи в списках, а напрямую решать поставленную задачу. Здесь и сейчас, самым кратчайшим путем.
Да, конечно, в этом есть что-то уникальное от самого человека. Такое стопроцентное, постоянное присутствие сознания и концентрация — не уверен, что этому можно полностью научиться. Но вот технику «питейного рога» (который нельзя отставить в сторону) — вполне можно освоить.
И мне кажетсяв именно в том чтобы «напрямую решать поставленную задачу, здесь и сейчас, самым кратчайшим путем» и заключается смысл гибкой разработки. Все остальное шелуха.
Он еще, например, против любой работы которая не улучшает напрямую конечный продукт. Как он выражается «мы не продаем %xyz%, мы продаем продукт». Все так просто. Почему это так трудно понять? Нужно делать все, что непосредственно является целью бизнеса и не делать ничего остального. В книге Голдратта, в принципе, говорится о том же.
Есть у такого подхода и недостатки. Его код, конечно, отличается решениями «в лоб». Но какую претензию ему можно предьявить, если он твой баг пофиксил еще до того как ты его нашел.vsb
06.10.2018 01:32Основная претензия — говнокод сложно и дорого поддерживать и развивать. Но не всякому проекту это нужно.
Dimash2
05.10.2018 21:06+1Почему все носятся с этими досками, как с каким-то мега скилом тимлида? Они вроде всегда были в разных формах, спокойно себе юзаю доски для себя и для команды — всю жизнь, в древность — они были в эксель, при том даже в далеком 2008 — молодые годы, никто ничего про «скрам» не читал, просто работали. Теперь же все молодые в очках произносят эти слова и делают умный вид, а проекты рушаться, потому что никто не думает головой про реальность бытия, менеджер должен не задачи по команде крутить (по сути команда и так сама это делать должна), а понимать суть происходящего не только в команде, но и по взаимоотношению с клиентами.
Правильно расставлять приоритеты.
C Тимлидами происходит примерно тоже самое, что с разработчиками после курсов, если ты в IT — ты сразу модный ) и можешь часами медитировать над Agile )
KarazeyAndrey
05.10.2018 21:13+1Ну если ребята проваливали регулярно проекты без скрама, то он их особо не спасет. Да и вообще странно, что выбирают скрам исходя из соображения скорости разработки. В моём опыте скрам всегда выбирался, когда заказчик имел весьма пространное представление о том, что он хочет получить на выходе. Есть куча неопределенностей? Пилим по скраму, в процессе проясняем все непонятные моменты. Практически всегда вылетаем за первоначальные оценки (за счет новых фич, что докидывает заказчик в процессе), но еще ни разу вроде заказчик не был в результате недоволен. Все продукты за последние несколько лет сделанные по скраму в лайве, работают и приносят заказчику денежку. В тех редких случаях, когда заказчик чётко знает, что он хочет получить (до мельчайших подробностей) пилим по вотерфолу. Из сроков практически никогда не вылетаем, заказчик получает именно то, что хотел вначале. Но если в процессе решил что-то переделать — тут уж извини.
isironn
05.10.2018 21:13Бред какой-то написан. Какая разница какими методами ПМ не может добиться от команды результата? Ну давайте запустим его в каскадную модель. Он так же будет заваливать дедлайны. Программисты очень часто увлекаются программированием, а не конечной реализацией. И хоть стреляйте меня, но лучше бы ПМ не быть программистом.
gohan
06.10.2018 00:22Боб тут напоминает Платова из прошлогодней истории на хабре. Помните совещание в xored на ютуб выкладывали? Краткое содержание: «Контора абсолютно угандошена! И мы все в этом виноваты, а я теперь буду вас материть». Если не видели, вбиваете «xored платов» в поиск на ютубе.
Видимо, Боба как Белоснежку усыпили яблочком на пару лет, а когда его поцеловал принц, он смог-таки заехать в офис и присмотреться к отчётам о работе.
funca
06.10.2018 00:28Это сказ про то, как воспитывать персонал? Слово "скрам" можно заменить любым другим, сценарий от этого не меняется.
Habra_nik
06.10.2018 00:46-1Scrum как покер. Правила можно понять за 10 минут, а играть будешь учиться всю жизнь. И не факт, что когда-нибудь получится стабильно выигрывать. «Попробовать скрам», это гарантированные деньги на ветер; на роль скраммейстера необходимо нанимать человека, который уже умеет. Я пару раз имел удовольствие такого наблюдать.
Alew
06.10.2018 04:48Непонятно как скрам помог ухудшить результат. Если народ на работе фигней страдает, а скрам делает это очевидным, то возможно некоторое ускорение работы. Но чтоб в обратную сторону? Заставляли по пол дня берндаун диаграммы вместо работы рисовать? Автор, тема как скрам помог завалить проект не раскрыта. Вообще, надо заменить термин скрам на микросервисы, тогда будет жизненно.
FYR
06.10.2018 13:18Да элементарно: благодаря скраму они еще до факапа поняли, что будет факап. Ну и конечно в этом виноват скрам.
Все эти аджайлы и скрамы они не про скорость. Они про что угодно, но не скорость.
Предсказуемость, гибкость, понимание как изменение изначальных договоренностей изменят срок. Примерно понять какой срок будет реален. Про "мы команда" (вот кстати в РФ именно командная работа хромает: очень часто слышу не МЫ сделали плохо, а Он/ВЫ сделали плохо)ApeCoder
06.10.2018 14:11Книжка Джефа Сазерленда (одного из авторов скрам) так и называется «Scrum: The Art of Doing Twice the Work in Half the Time». Т.е. у самих авторов маркетинговое обещание именно такое — в 4 раза быстрее.
Hwd
06.10.2018 09:29На мой взгляд, данная заметка скорее вредна, чем полезна. Вредна она тем, что на эмоциях преподносится якобы доказанная на практике бесполезность скрама. При этом сама ложь искусно замаскирована и заключается в том, что «во всём скрам виноват», «толку от скрама нет» и т.п. В этой «пьессе» не предоставлено ни одного объективного аргумента о бесполезности скрама.
Скрам позволяет вам чётко видеть, на каком этапе вы находитесь, что сделано, а что нет, кто чем занимается и какие у кого проблемы возникают в ходе работы. Не вижу, чем скрам может быть причиной провала проекта. Причина провала проектов не в скраме. Она, скорее, либо в плохом планировании (т.е. запланировали меньше времени, чем на самом деле необходимо), либо в плохо продуманной архитектуре приложения (т.е. сами себе граблей раскидали по дороге), либо в том, что заказчик хотел пингвина, а ему сделали попугая.
Я работал в команде где скрама не было и сейчас работаю в команде, где он есть. Для меня польза скрама очевидна. Да и для начальников, насколько я вижу, тоже: каждый начальник (да и разработчик тоже) всегда хочет чётко понимать, что уже сделано, над чем идёт работа сейчас, в какой она стадии, что в рамках скрама будет сделано ещё и какие проблемы возникают в ходе работы.
ApeCoder
06.10.2018 12:11— Да я понимаю, просто… — начал было Джон.
— Послушай, услышь и запомни: я уволю тебя к чертям! – перешел Боб на крик.Боб, похоже, хамло — перебивает и кричит,.
Боб, похоже, тупой — вместо того, чтобы разобраться в чем причина провала, сразу делает выводы.
И заказчик вроде доволен был.
— Конечно доволен! Потому что до этого он вообще ничего не получал!То есть у заказчика есть печеньки а до этого не было ничего? Если вернуть как было, от этого будет не ничего, а кусок мяса?
— А как работать? – нахмурился Джон.
— Просто. Нормально. Работать. – чеканя каждое слово, сказал Боб.Боб, похоже, тупой — эти три слова никак не описывают как работать. У них будет какой-то процесс работы, просто не будет никакого слова, как он называется.
То, что Боб не понимает, что этих слов недостаточно, чтобы описать, что собственно он хочет, еще один признак того, что он тупой.
Мой вывод — Боб, тупое хамло практически неспособное сказать ничего по сути и заменяющее анализ и аргументацию потоком эмоций. Ответственность за организацию работы он на себя брать не хочет.
borv
06.10.2018 14:38+1У нас скрам, но через месяц дедлайн??? Это как? Завернули итеративную разработку в фикскост и продали клиенту? Ну и м… молодцы. Я бы пожалуй ответил Бобу следующее:
- Старик, я понимаю что ты на стрессе и все такое, но давай по честному, ок? Ты как опытный менеджер почуял грядущую жопу и ищешь виноватого. Слава Богу у тебя достаточно адеквата чтобы виноватым оказался ангуляр, докер, скрам, кофемашина или на худой конец не особо ценный сотрудник из линейного менеджмента. Если тебе так легче — пусть виноватыми будут скрам и я. Но даже Дон уже понимает что проблема не там. Да, мы долбоклюи. Мы начали делать итеративную разработку внутри фикскост проекта. Мы объяснили все Дону, а он сказал "да мне пофигу, как, просто пишите код". Вот тогда нам следовало объяснить Дону что у любой методологии плюсы и минусы. Что поезд хорошо держит рельсы, а мотоцикл быстро едет и хорошо поворачивает. Возить мебель на мотоцикле или устраивать гонки на поездах это хреновые идеи. И либо ему надо отразить итеративность в отношениях с заказчиком, либо нам надо не выпендриваться а расчехлить мспроджект и поставить ПМ ов на бюджет из расчёта 1 на 5 подчинённых. Но мы ничего из этого не сделали. Мы (вообще говоря вы) продали фиксированные обязательства, выкинули весь менеджмент оверхед из оценок (у нас скрам, какие менеджеры!), тем самым занизили стоимость, забили болт на трекинг (на деме поговорим, ага) и теперь ты на меня орёшь про близящийся дедлайн. Дедлайн, Боб! Это вообще слово из другой книжки! Ты врубаешься какой это долбаный цирк! А теперь позволь предложить как клоун клоуну: давай наденем взрослые штаны и начнём решать проблему конструктивно. А почему черт подери мы не можем двинуть этот хренов дедлайн?
mskotyn
07.10.2018 21:15Остро не хватает объяснения, что же на самом деле ожидалось от тимлида. Попадание в сроки определенные до начала проекта? Так скрам не про это. Отвертка вообще плохо подходит для забивания гвоздей, равно как и молоток не тот инструмент который нужен для заворачивания шурупов. Скрам хорош для контроля производительности при тайм-энд-материал проектах. А для фиксед прайс — больше подходит руп или тот же ватерфолл. И вообще-то там есть понятие НИОКР (R&D) проектов для неясных случаев. Когда фиг его знает — достижимы ли заявненные цели в задекларированных условиях в принципе. Ну а когда менеджмент подписывает контракт с фиксированной стоимостью и сроками и допускает внесение изменений в объем работ без пересмотра этой самой стоимости и сроков — это клиника. Тут самый лучший исполнитель ничего не сможет сделать. Есть конечно варианты когда исполнитель самовольно соглашается на изменение объема работ — но это опять таки ошибка менеджера допустившего такую самодеятельность. Ну и цинично отмечу, что тимлид это не менеджер, ему желательно, но не обязательно знать все вышесказанное. А уж свежеповышенный тимлид тем более.
Вообще, если планируется работать с лидом дальше — нужен нормальный анализ ошибок проекта с выделением областей применимости вышеупомянутых инструментов и техник. А в приведенной форме это выглядит как классическая манипуляция с созданием чувства вины у выбранного стрелочника и последущим забалтыванием для затирания аргументации и закрепления чувства вины. Поэтому я и не люблю работу в офисе с коммуникацией не подразумевающей ведение истории (правда у меня значительный опыт удаленной работы аутсорсером и есть возможность сравнивать). Личностей мнящих себя непревзойденными манипуляторами (или просто очень хитрыми и умными) — множество, тратить время на борьбу с манипуляциями не очень то и продуктивно. А наличие истории общения по крайней мере сдерживает самых тупых — потому что полные идиоты выпиливаются моментально.
Aquahawk
Продолжение про зомби в виде скрамбана?