Scrum is dead

    — За что тебя приняли, за то и уволят. – тяжело вздохнув, сказал Боб. – Слышал такую фразу?

    — Нет. – угрюмо ответил Джон.

    — Ты помнишь, почему я взял тебя в тимлиды? – Боб отвернулся от Джона и уставился в окно.
    Вид с двадцать пятого этажа открывался шикарный, но, похоже, Боб его не видел.

    — У меня своя версия. – тихо сказал Джон. – Кажется, дело было в скраме.

    — Да, дело было в скраме. – кивнул Боб, все еще глядя в окно. – И я, если честно, уже не могу про него слышать. Не хочу говорить высокопарных слов, но ты меня обманул.

    — Я? – недоуменно спросил Джон.

    — Ты и скрам. Твой скрам. Твоя инициатива. – Боб повернулся и в упор уставился на Джона. Которая будет стоит мне проекта. И кучи денег.

    Джон опустил глаза в пол. Он понимал, к чему клонит директор.

    — Я… Я понимаю, о чем вы говорите. – неуверенно промямлил Джон.

    — Вот… Ты молодец, Джонни, ты понимаешь. – на лице Боба появилась недовольная гримаса. – А мне что делать? Я бы с радостью выгнал тебя прямо сейчас! Ты это понимаешь?

    — Да. – не поднимая головы, тихо сказал Джон.

    — Но у меня руки связаны! Этот проект просто некому передать! Все команды загружены под завязку, а до дедлайна – всего месяц. Месяц, Джон! – Боб начал краснеть, что неудивительно при его комплекции – вес под триста фунтов, одышка, проблемы с сердцем.

    — Мы постараемся, приложим усилия. – голову Джон так и не поднял.

    — Как? Ну, объясни мне? Что ты еще придумаешь? Скрам ты уже придумал, теперь что? Канбан? Девопс? Перья страусиные в задницу вставите? – все больше распалялся Боб.

    — Будем работать без выходных, по шестнадцать часов в сутки. – продолжал мямлить Джон.

    — Зачем? Чтобы команда сгорела? Чтобы кто-то начал в обмороки падать?

    — Надо – значит надо, мы готовы к тому, чтобы выложить все силы на этот проект…

    — Это ты готов, Джон! – Боб показал пальцем на Джона, и тому пришлось поднять голову, чтобы не быть невежливым.

    — Ребята тоже готовы. – Джон, как мог, придал уверенности голосу. – Я с ними разговаривал, все понимают, насколько это важно, и что наша судьба…

    — Твоя судьба, Джон! – крикнул Боб. – В провале проекта виноват только ты! Команда здесь ни причем, они – просто разработчики, они делают то, что ты скажешь! Как ты стадо гонишь, так оно и идет, понимаешь, Джон?

    — Понимаю… — сокрушенно сказал Джон и снова опустил голову.

    — Ты был прекрасным разрабом, и я никогда не думал о том, чтобы сделать из тебя тимлида. – продолжал Боб на повышенных тонах. – Это азбука, аксиома: хороший разраб – это не хороший тимлид. Но ты меня… Нет, не обманул – просто запудрил мне мозги своим скрамом, и я решил – вот, вот он, тимлид нового поколения! Инициативный, вдумчивый, ищущий, не замкнутый в стереотипах! Тот, кто мне нужен! Как же я ошибся!

    Джон молчал, не зная, что ответить. Чувство безысходности было настолько всеобъемлющим, Боб был настолько прав во всем, что Джону в голову не приходило ни одной идеи, как бы защититься, или, хотя бы, перевести разговор в какое-нибудь другое русло.

    — Я устал, Джон. – гнев Боба внезапно стих. – Я не знаю, что делать. Ты поставил меня в тупик.
    Джон лишь кивал головой, как провинившийся ребенок, которого на школьном совете ругают за разбитое в классе окно.

    — Я, наверное, в каком-то смысле тебя даже понимаю. – Боб опять уставился в окно. – Я ведь тоже поверил в эту хрень. Я про скрам. Я тоже думал, что он поможет нам быстрее делать проекты. Дьявол побери, об этом написано на обложке этой чертовой книги! В четыре раза быстрее!

    — Там трактовки отличаются… — промямлил, наконец, Джон. – Мы работали по манифесту, и…

    — Да знаю я. – махнул рукой Боб. – Но ты же разраб, чистый разраб, хоть и работаешь тимлидом. Тебя в скраме что заинтересовало?

    — Ну, там процесс, вроде, правильный, я примерил на нашу команду этот фреймворк, и…

    — Вот-вот. – закивал Боб и снова повернулся к Джону и даже улыбнулся. – Я же говорю – разраб. Для вас главное – процесс, что там внутри. Технология, апи, абстрактность. Ну, как эти ваши холивары вечные, реакт или ангуляр, джава или пхп, на фронте или на бэке. А мне что важно, знаешь?

    — Нет. – покачал головой Джон.

    — А заказчику что важно, знаешь? – с усталой улыбкой продолжил Боб.

    — Ну, наверное, проект чтобы вовремя был сдан.

    — Именно. – Боб поднял палец вверх. – И ему, по большому счету, кроме редких случаев, нет никакой разницы, что за средства вы применили. Причем, речь и о фреймворках, на которых работает сервис, и о технологиях, которыми управлялся проект. Есть прекрасные проекты, которые мы сделали на реакте. Есть чудесные, высокорентабельные сервисы, которые мы запилили на ангуляре. И есть – провальные, сожравшие кучу денег поделки, за которые никто не заплатил – и на реакте, и на ангуляре. Понимаешь?

    — Да. – с готовностью кивнул Джон. – Я понимаю, что дело не в технике и не в технологии.

    — Ну, не совсем. – поморщился Боб. – Технология, все-таки, важна. По крайней мере, технология управления разработкой, и проектом в целом. Вот, теперь мы знаем, что от скрама, как от технологии управления проектом, толку мало. Согласен?

    — Ну… — потянул Джон. – Все-таки, я бы не стал…

    — Ага, вот оно что. – нахмурился Боб. – Ты чего-то не понимаешь, что ли, Джонни? Я плохо объясняю?

    — Да я понимаю, просто… — начал было Джон.

    — Послушай, услышь и запомни: я уволю тебя к чертям! – перешел Боб на крик. – Я не могу терять столько денег! Дон просто меня самого выгонит, ты это понимаешь? Мы и так у него не на лучшем счету, не хватало только еще одного просранного проекта!

    Джон тяжело вздохнул и уставился на Боба. Взгляд его был не умоляющий – чего уж тут умолять. Еще минуту назад какая-то надежда теплилась – на то, что разговор перейдет в русло технологий и методов работы, а когда вот так, прямо, в лоб, как из ведра холодной водой – что уж тут попишешь. Надо принимать судьбу, как есть.

    — Если ты думаешь, что у нас тут лаборатория экспериментальная, или университет, где ты можешь учиться, пробовать, ошибаться и снова пробовать – то ты что-то перепутал! – продолжал Боб. – Я допускаю эти ваши изыскания, пробы новых технологий, но только в одном случае – если это будет полезно бизнесу! У любого эксперимента есть начало, середина, и конец, понимаешь? Твоему эксперименту – конец! Моему эксперименту – конец! Ты – мой неудачный эксперимент. И скрам – мой неудачный эксперимент!

    — Возможно, мы где-то ошиблись, применяя методы скрама. – Джон, поняв, что терять уже нечего, начал говорить смелее. – Не может быть, чтобы он не давал никакого видимого результата. Вот вам же нравилось, что мы стали чаще и стабильнее делать релизы. И заказчик вроде доволен был.

    — Конечно доволен! Потому что до этого он вообще ничего не получал! – со злобной гримасой на лице продолжал Боб. – А сейчас вы кормите его этими релизами, как печеньками! А он хочет мяса! Понимаешь? Огромный, вкуснейший стейк – вот, что ему надо! Вот, что он заказал! А не печеньки, соусы, закуски и пиво!

    — Ну и прозрачность повысилась, вы же сами говорили, как удобно стало оценивать остаток работ по проекту. – как ни в чем не бывало, продолжал Джон. – Я про сторипойнты.

    — Я про сторипойнты. – передразнил Боб, потом вернулся к более серьезному тону. – Безусловно, польза от СП есть, и я хотел бы их оставить, даже когда мы выкинем скрам.

    — Точно выкинем? – нахмурившись, спросил Джон. – Ведь столько пользы от него, например…

    — Точно, Джон. – кивнул Боб. – Скрам мертв. И у нас, и вообще. От него нет никакой пользы. Это была пустышка.

    — Мне кажется, рано делать выводы, по крайней мере, только на основе работы моей команды. – ответил Джон.

    — А я не только по вашей команде сужу. – пожал плечами Боб. – Консультантов помнишь?

    — Да.

    — Они у нас три месяца торчали, и в итоге сказали, что у нас правильный скрам. – улыбнулся Боб. – Но, сколько бы я с ними не разговаривал, они не смогли мне точно ответить, как же, все-таки, делать проекты быстрее. Понимаешь? У них за плечами – годы работы с этой методикой, сотни проектов и команд, сертификаты какие-то выдают, а толку-то?

    Такое ощущение, что это – какие-то сектанты, причем – уровня детского сада. С вами, разрабами, у них здорово получается разговаривать – вы уши развесите, рот откроете, и внимаете сказкам о том, как у вас теперь будет весело, интересно и здорово.

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

    — Да, я понимаю. – кивнул Джон.

    — Понимает он. – усмехнулся Боб. – Я и на семинар съездил – ну, где они собирают бизнесменов и директоров, вроде меня, и лечат на тему того, как хорош скрам, как он повысит прибыльность, скорость закрытия проектов, как мы конкурентов всех в гроб загоним. И знаешь, что?

    — Что?

    — А… Ничего. – поднял брови Боб. – Там, конечно, куча народу нового была, это их любимая публика, им можно в голову впихивать свои бредовые идеи.

    Но были и такие, как я. Знаешь, как таких отличить? По взгляду, по смеси надежды и отчаяния. Мы приезжаем на такие мероприятия, чтобы найти! Хоть что-нибудь найти, понимаешь? Найти, что мы упустили. Найти тех, у кого что-то получилось – не доски ваши со стикерами развесить, а в бизнесе, денег зарабатывать больше получилось!

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

    Кто-то, конечно, продолжает сам себя зомбировать – эгегей, у меня все хорошо! У меня скрам! Но это – до первой пьянки. Я ходил, потом, после семинара, в бар, подсел к одним – тоже эгегей которые, и что бы ты думал? После двух бутылок виски все встало на свои места. Та же проблема, тот же непонимающий взгляд, чуть ли не слезы, понимаешь? Каждый ведь понимает, что купил кота в мешке, потратил деньги собственника, и теперь в глаза ему стыдно смотреть.

    И самое поганое – ни у кого не хватает смелости этого кота выбросить, утопить, вместе с мешком! А эти твари, психологи хреновы, это понимают! Еще как понимают! Оттого и гребут все больше денег, все время отодвигая горизонт – не бойтесь, эгегей, все будет хорошо! Скрам развивается! Не получается? Ничего страшного! Вот, еще вот этот метод попробуйте! Он отлично сочетается со крамом! Вот, тут только подпишите… И ждем предоплаты.

    — А у вас, получается, смелости хватает? – улыбнулся Джон.

    — У меня здравого смысла хватает. – пожал плечами Боб. – Я – такой же наемный работник, как и ты. Если меня ты залечил, то Дона я залечить не смогу, даже пытаться не буду. Не тот человек. Слишком… Нормальный. Простой, прямой. И умеет считать деньги. Плюс – мы не единственный его бизнес. Остальные, как ты знаешь, не связаны с айти и вебом.

    — Ясно. – кивнул Джон. – Так что в итоге?

    — А ты не понял? – поднял брови Боб.

    — Понял, но хочется от вас услышать. – пожал плечами Джон. – А то опять не так пойму. Скрам – все?

    — Скрам мертв. Для нас. – с серьезным видом сказал Боб. – Я больше ничего не хочу слышать о нем. Чтобы к вечеру не было досок на стенах.

    — А как работать? – нахмурился Джон.

    — Просто. Нормально. Работать. – чеканя каждое слово, сказал Боб.

    — Ясно. – кивнул Джон. – Все?

    — Все.

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

    — Думай своей головой, Джон.

    P.S. Продолжение нужно?
    Поделиться публикацией
    Комментарии 194
      +7
      Продолжение про зомби в виде скрамбана?
        +1

        Как бы пока вообще не ясно .., идея вроде видна, но суть

          +2
          Даже интрига скорее видна, чем идея — основной мысли не видно — дальше можно фантазировать в сторону любых недостатков: скрама, Джона, Боба, заказчика, происков конкурентов, провайдера интернета, поставщика оборудования…
            +9

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

              0

              Отнюдь. Если все понимают, что проект заваливается, но никто ничего не делает, значит всем, включая заказчика, это зачем-то нужно.

                0
                А скрам здесь причём? «Профакапить» можно точно так же и без него.
              +10
              А как же Сергей? «Сергей — всё»? :-D
                0

                Как создать подходящий под свой бизнес формат? Без проблем и ошибок не будет… Все равно… и этот товарищ не может не понимать, не бывает решения идеального

                  +2
                  Бывает. Уволится и разогнать всех — почему-то это отрабатывает без ошибок.
                    0
                    ничего кроме большой траты времени не гарантирует такой подход «уволить ВСЕХ»
                      0
                      Траты времени — ровно на оформление увольнения…
                        0
                        а кто же будет проект-то допиливать, еще и в срок?
                          0
                          «Зафиксировать убытки» это называется. Некоторые могут себе это позволить. Вон Гугл+ закрывается например.
                  +4
                  Хотелось бы увидеть продолжение.
                  +18
                  И тут они выбросили скрам и стали просто работать, через полгода успешно завалив очередной проект. Возможно не кровати надо двигать…
                  ЗЫ. В обратную сторону тоже работает, если у вас было всё нормально, проекты более-менее сдавались, и тут вы ввели скрам, то всё станет не особо хуже (благодаря великому скраму, конечно же).
                    +1
                    через полгода успешно завалив очередной проект

                    Тогда они скажут "просто работать is dead"!

                    +1
                    Какой вменяемый CEO Боб.
                    Жаль, в жизни таких почему-то не бывает…
                      +20
                      Вменяемый? Сам поставил тимлида переросшего свой предел компетентности, сам остался без резервов по ресурсам, а теперь орёт на подчиненных и обвиняет во всем скрам…
                        +9
                        Рыли? СЕО и виноват в ситуации, бросил разраба во все тяжкие с непроверенной методологией и спохватился только когда всё к херам пошло.
                          +1
                          Ну не совсем «разраба», а вполне себе тимлида, да еще и (если я правильно прочитал буквы) скрам-евангелиста.
                          Да, скрам здесь не зашёл, но это не только и не столько вопрос к СЕО — у него иные материи. Большинство из них (не все) даже не будут пытаться разобраться, в скраме ли дело — Джон за дверь, Джек теперь вместо него.
                        0
                        А вот люди говорят, что скрам работает даже в 1С infostart.ru/public/911946
                          +16

                          Хоть что-то в 1с работает!

                            0
                            А что у вас в 1с не работает?
                              0

                              Все работает, спасибо.


                              Но требует на это сил на порядок больше, чем любой другой софт. Порой, знаете ли, впечатление, что люди ни памятью управлять, ни с БД работать не умеют на уровне, приличном для столь популярного софта (я про саму платформу), но у них даже нет стимула прокачивать скил: купить купят любое, ответственности за качество кода ни перед кем нести, обновления — и те только за денежку можно получать… В общем, жить можно, но гордиться нечем.


                              Характерно, что сами разработчики на 1с называют "большими" БД и число юзеров столько небольшие (ссылаясь на саму платформу), что прямо ещё грустные делается. Я понимаю, на 1с писать Фейсбук никто не станет, но все же просить под столько клиентов воооот такую по мощности железку — кажется, об оптимизации разговора нет в принципе.


                              Как нет разговора ни о чем современном. Облака? Резервирование? Географически разнесенных кластер? На костылях из прошлого века такое не построить, а новее там ничего не видно. Повторюсь, я про платформу.


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


                              Но это я так. Спасибо, что спросили!

                                0
                                Это обманчивое впечатление. 1С не пряник, но я работал с тем же DAX. Они ГОД делали учет счет-фактур (это был 12 год вроде и большие изменения в законодательстве). И вот после этого с DAX работать перестал. Хотя платформа там одна из лучших.

                                Да, платформа у них не самая лучшая и нафига делать встроенный механизм расчета уравнений =))

                                «Я понимаю, на 1с писать Фейсбук никто не станет, но все же просить под столько клиентов воооот такую по мощности железку — кажется, об оптимизации разговора нет в принципе.»

                                на 5000 юрезов в 1С нужен что то типа супер-дома. Правда тот же DAX на 5000 пользователей стоит как 10 таких супер-домов =)))

                                Извините если что, это я так ответил.
                          +10
                          для тех кто не понял — дело не в скраме
                            0
                            можно раскрыть причину?)
                              +2
                              судя по всему в управлении ожиданиями
                                +25
                                Когда писал магистерскую диссертацию проштрудировал довольно много репортов других людей которые описывали свой опыт применения agile/lean и если честно можно просто рандомно проставлять результаты, разницы с реальностью не много будет. В реальности если команда сработалась и ей не мешать, можно хоть скрам, хоть не скрам — проблем не будет. А если нет, тут уже никакая методология не спасет кроме самых формализованных, пожалуй.
                                  0
                                  Вот это самый верный комментарий. Полностью согласен.
                                    0
                                    Тоже поддерживаю. И вообще вместо Скрама можно подставить любой новомодный в какое-то время инструмент — инжиниринг процессов, ре-инжиниринг бизнес-процессов, кайдзен, lean — смысл истории будет таким же.

                                    Кстати, интересно, а какая тема диссертации была — работает ли agile? И какие результаты в итоге получились?
                                      0
                                      Изначально планировал сделать метаанализ, но как оказалось необходим был какой-то более практический результат. В итоге сделал общий обзор методологий и к нему реализацию канбан доски на джанге, кажется. Моё личное мнение после прочтения всей вышеозначенной макулатуры (и теперь коммерческого опыта разработки) примерно такое: в целом реальный вклад конкретной методологии минимален, но lean мне нравится больше всего — он по сложности и количеству церемоний вокруг процесса где-то между абстрактными заповедями agile manifesto и конкретными правилами в этом вашем scrum.
                                        0
                                        Если собрать людей в кучу и назвать их Agile командой, ничего не изменится. Если игнорировать практики, толку будет ровно в том контексте, что описали. Agile Management отличается от Project Management лишь фокусом на людей вместо проектов. И когда этой трансформации не происходит, ни одна из церемоний не спасет; shu-ha-ri никто не отменял.
                                          0
                                          Разве в Agile вообще есть проекты? Agile — это же как ремонт, который нельзя закончить, а можно только прекратить. А проект имеет чёткие рамки времени, бюджета и функциональности.
                                            0
                                            Конечно есть. Разница лишь в том, что в PM на бенче сидят люди, а в AM — проекты. Действуют все те же инструменты, что и в проектном управлении, но с некоторыми метаморфозами (см. Management 3.0). Тот же «scutter plot» c «Monte Carlo» позволяют стоить планы на основе статистики команд, т.е. для сработанной команды можно довольно точно предсказывать вхождение в треугольник: время, цена, объем задач. У Agile команд очень даже заданы временные рамки каденцией итераций, и определен бюджет — команда не меняется. Вопрос лишь в том, насколько менеджер вместе с командой и заказчиком смогут договориться об объеме и степени детализации приемки проекта.
                                            В случае, если у компании свой продукт, то проектами могут выступать эпики или проектные инициативы (стримы).
                                              0
                                              Ну вот эпик типа «инфраструктура для CRUD сущностей домена и реализация MVP на её базе». Есть какой-то набор требований, есть список сущностей, есть какая-то команда, которая готова это сделать. Если есть дедлайн, то разве можем мы применять аджайл? А если нет дедлайна — проектное управление?
                                              0
                                              Each Sprint may be considered a project with no more than a one-month horizon. Like projects, Sprints are used to accomplish something. Each Sprint has a goal of what is to be built, a design and flexible plan that will guide building it, the work, and the resultant product increment.
                                                0
                                                «может считаться» и «является» всё-таки разные вещи. Тот же скрам не заявляет «основной подход — выделяем из текущего скоупа задач набор более-менее связанных на период не более одного месяца и применяем проектное управление к ним».
                                                  0

                                                  Мне кажется, я могу найти соответствие между спринтом и определениями:


                                                  Проект в управленческой деятельности (соответствует англ. project от лат. projectus «брошенный вперёд, выступающий, выдающийся вперёд») — временное предприятие, направленное на создание уникального продукта, услуги или результата (см. PMBOK)[3]:3.

                                                  Управление проектами — область деятельности, в ходе которой определяются и достигаются чёткие цели проекта при балансировании между объёмом работ, ресурсами (такими как деньги, труд, материалы, энергия, пространство и другими), временем, качеством и рисками (PMBoK)
                                  +8
                                  «А что это? Это беклог. А что такое беклог? Это Скрама. А кто такой Скрам? Scrum is dead, baby, Scrum is dead...»
                                  Навеяло заголовком)
                                    +16

                                    Когда то очень давно (2005-2006) было увлечение UML. Предлагалась как панацея и ответ на "The Ultimate Question of Life, the Universe, and Everything".


                                    До сих пор помню (такое не забыть) пример использования UML в бизнесе из книги (доке кажется) от Rational Software (Rational Rose).


                                    Содержание примера (почти дословно):


                                    Жила была семья со своим мелким бизнесом. И что что то у них не шло с бизнесом. Прочитали они учебник по UML. Купили продует Rational Rose. Нарисовали в нем диаграмму (картинка диаграммы сценариев использования на 5-6 объектов со стрелочками) и тут у них КАК ПОПЕРЛО в бизнесе!


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

                                      +11
                                      Это как с Форексом, где единственный способ заработать — продавать книги и организовывать учебные курсы по Форексу. Я думаю Rational Rose отлично денег срубил на своих книгах и продуктах. Знаю компании, которые их покупали.
                                        0
                                        Ну Гради Буч вообще подошёл к делу с размахом. Во перывых он собрал всех чуваков, которые делали хоть мало мальски вменяемые тулзы для построения визуализованных спецификаций и таким образом пропылесосил рынок. Потом они вместе написали UML, RUP, сделали Rational Rose и всю линейку для командной разработки. А потом пробили правило, что тот, кто пользуется продуктами Rational Software автоматически сертифицируется на CMM 5. А требование сертификата CMM довольно часто указывается при размещении заказов на разработку, особенно госзаказов.
                                        Так что хоть какая-то польза от Rational Rose есть.
                                        +7

                                        Я видел примеры грамотного приложения UML: авиационный софт. Логика примерно такая. Есть инженер, который понимает, какие сигналы (в широком смысле этого слова) нужны для некоторого события/действия. Он ресует UML, а с этого UML генерится C код. При чем генратор протестирован и верифицирован. Т.е. гарантируется, с некоторым уровнем покрытия, что генератор работает правильно.


                                        Собственно на этой логике огромное количество самолетов летают и по сей день.


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

                                          +2
                                          Суть-то по итогу в том, что какую-то технологию или методику пытаются натягивать на всё подряд вне зависимости от применимости, а когда она начинает от такого обращения по швам трещать — "%TECH_NAME% DEAD!!!" и кидаются заниматься тем же самым со следующей технологие/методикой.
                                          +2
                                          Для документирования он вроде даже ничего так.
                                          +4
                                          То есть у них все хорошо, но неадекватный изначальный дедлайн, да?)
                                            +3
                                            Скорее, неадекватные отношения между заказчиком, CEO и разработчиками.
                                            +1
                                            А почему проект провалился-то? Только из-за методологии управления проектом? Они ввели новую технологию (SCRUM) на какой-то очень важный проект, никогда при этом не пользовавшись данной методикой до этого? Такое себе решение. Им понравилась прозрачность и частые релизы, но они так и не поняли почему провалили проект? Если там видно, что на реализацию той или иной задачи уйдет столько-то времени и эта информация обновляется каждую неделю, то как именно SCRUM помешал реализовать проект вовремя?
                                              +6
                                              У скрама есть одна неприятная скрытая особенность — необходимость митингов. Стэндапы каждый день, груминг, планинг, демо, ретро. Сами по себе они ничем не мешают. Но склонные к флуду люди растягивают эти митинги на 100%-е покрытие времени.
                                              Конечно же, скрам тут не причем. Эти люди и так найдут с кем попить кофе и покурить. Но, ввиду того, что теперь у людей есть выбор быть на этих митингах или нет, часть группы начнет работать, потому что не все любят митинги.

                                              Я лично ушел из Ситибанка только из-за Скрама. Потому что мне было интересно что-то делать, но большинству было интересно тереть языками в переговорках и я был обязан там сидеть.

                                              Скрам сегодня, за редким исключением, стал карго-культом. Он мертв из-за того, что слишком требователен к дисциплине.
                                                +4
                                                Пользуемся в команде чем-то типа псевдо-скрама без дейликов. Остальные типы митингов — раз в две недели и они скорее полезны, чем вредны. На все эти вопросы про «что делаешь? что будешь делать?» отлично отвечает Джира.
                                                  +5
                                                  К слову, заблуждение, что на дейли-скраме все должны отвечать на вопрос «Что делаешь, что будешь делать» это не более чем заблуждение! В том же скрамгайде эти вопросы просто приведены для примера. А сам дейли-скрам (или летучка, в терминах медиков или других не айтишных организаций) сделан для синхронизации. Синхронизации, где можно быстро осознать, туда ли вы все идете, поднять вопрос «мне нужно api для задачи, а Вася со вчера мне его так и не передал» и отправиться работать дальше. Повторюсь, у опытных команд на это уходит 5 минут. И при этом совершенно не обязательно каждому как обезьянка механически отвечать «Я делал, я делаю, я буду делать...».
                                                    –1
                                                    Ну так даже и в этом описании это звучит тупо. Зачем мне ждать сутки, чтобы дёрнуть Васю на счёт этой апишки? Я что, не могу его так спросить? Или задача — опозорить Васю перед командой? Тоже как-то тупо.

                                                    Если описать скрам псевдокодом, то будет как-то типа:
                                                    while (true)
                                                    {
                                                    Sleep(1day);
                                                    DiscussProblems();
                                                    }

                                                    Вместо схемы:
                                                    
                                                    while (true)
                                                    {
                                                    WaitForNextProblem();
                                                    SolveProblem();
                                                    }

                                                      +13
                                                      Вы удивитесь, но сплошь и рядом встречаются ситуации
                                                      "
                                                      Как там моя задача?
                                                      Ну я Васю позавчера попросил <......>, жду!
                                                      А ты сегодня спрашивал?
                                                      А что я, девочка за ним бегать? Я жду."

                                                      Или джун реально стесняется обратиться к архитектору за решением своей проблемы по задаче. Дейли не столько процессная встреча, сколько еще и психологическая, где от твоего вопроса или требования не отмахнутся «потом, я щас страшно занят».
                                                        +5
                                                        Ну, джун и на стендапе может также молчать. Или упомянуть проблему на одном стендапе, но оставлять за бортом на следующих. У нас кстати для таких «висяков» собираются шефы и менеджеры в конце недели, проходятся по задачам и у конкретных людей выясняют, почему какая-то из задач повисла. После пинают кого надо. Оказалось, довольно действенно.
                                                        И, опять таки, если мне нужно api от Васи, я ставлю задачу на Васю по разработку данного api, у своей задачи выставляю is blocked by XXX и на всякий в комментах отписываю что-нибудь вроде: «Приостанавливаю работу, т.к. нужно такое-то api, которое делается в таске XXX». Далее уже все вопросы к Васе.
                                                        0
                                                        Ну если вы такой инициативный, то вы молодец. А многие будут сидеть и думать, что им никто не поможет. Плюс могут быть очевидные вещи для одного, но сложные для другого. А есть ещё те, кто принципиально хочет сам во всё разобраться.
                                                        Ну и больше это нужно не из за озвучивания проблем, а для синхронизации. Т.е. я, например, на дейли говорю: я вот начал переделывать этот сервис. И тут Петя из моей команды: подожди, но я вот только что завязался на старую логику этого сервиса. (Пример условный, поэтому немного корявый, но суть доносит). И без ежидневных дейли Петя узнал бы об этом только после моего коммита, который бы всё ему разломал.
                                                          0
                                                          Или задача — опозорить Васю перед командой?

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

                                                            +4
                                                            Зачем мне ждать сутки, чтобы дёрнуть Васю на счёт этой апишки?

                                                            Дак никто не запрещает тебе дёргать Васю. Просто твоей команде неплохо бы знать, что если вдруг ты не успеешь вовремя доделать свою часть, то это потому, что Вася тебе апишку не предоставил и что все гарантированно в курсе твоей проблемы.
                                                            0
                                                            Больше скажу, если не ошибаюсь, то в скрам гайде примеры вопросов приведены как-то вроде:
                                                            — что я сделал для достижения цели спринта?
                                                            — что мне мешает в достижении цели спринта?
                                                            С остальным согласен полностью, если обсуждать реальный синк о том что блокирует и кого уже разблокировал, то 5-15 минут хватает и картина становится полностью ясной.
                                                          +3
                                                          При этом опытный скрам-мастер вам расскажет, что тот же Daily должен быть не более 15 минут. А многие команды укладываются в 5. И эти 15 минут явно прописаны в скрам-гайде.
                                                          Это вопрос культуры, как и с обычными совещаниями, на которых можно решить все важные вопросы за 20 минут, а можно убить 2 часа и уйти ни с чем.
                                                            +5
                                                            Именно — это вопрос культуры. Потому скрам и мало применим, что требователен к культуре. И нет никаких защитных механизмов от бескультурья, недисциплинированности и прочих человеческих факторов.
                                                              0
                                                              И нет никаких защитных механизмов от бескультурья, недисциплинированности и прочих человеческих факторов.
                                                              А есть ли вообще какая-то методология, которая бы имела такие защитные механизмы от человеческих факторов?
                                                                0
                                                                Мне нечем крыть :-)

                                                                Наверно лучше переформулировать тогда:
                                                                И нет никаких защитных механизмов от бескультурья, недисциплинированности и прочих человеческих факторов.
                                                                И слишком велика зависимость результата от культуры, дисциплины и прочих человеческих факторов.
                                                                  +1
                                                                  Я думаю тут вопрос не в методологии. Если у команды с культурой все в порядке, то они и без скрама будут отлично работать. А если с культурой проблемы, то и скрам не поможет
                                                              +5
                                                              Очень, очень сложно модерировать собрания чтобы уходило 15 минут. Ни в одной конторе, где я работал, не справлялись с этим при размере команды больше 2-3 человек. Везде все растягивалось минимум на час, причем обычно пара человек о чем-то жарко спорят, остальные глядят в потолок или в телефончик.

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

                                                                Да. Когда мы начали стоять на стендапах, то модерировать их стало значительно легче. Теперь вся команда не даст спорить двум людям — всем хочется побыстрее закончить и сесть
                                                                  +2
                                                                  Очень, очень сложно модерировать собрания чтобы уходило 15 минут.
                                                                  У нас в команде дейли ни разу не занимали больше 20 минут.
                                                                  причем обычно пара человек о чем-то жарко спорят
                                                                  Просто останавливаю такие споры и создаю этим спорящим людям отдельное собрание. Так и время других не тратится и к этим встречам люди лучше готовятся и они проходят эффективнее.
                                                                    +2
                                                                    В случае, если спор затягивается, то грамотный скрам мастер, а потом и команда просто запоминают проблему и переносят её в отдельную дискуссию. Это может быть ретро, а может и просто совещание по проблеме.
                                                                    Знаю ребят, которые на дейли стояли в планке) Вот что реально мотивирует побыстрее закончить! Если что, это было совместное решение всей команды)
                                                                      +1
                                                                      30 секунд на выступление)
                                                                        0

                                                                        Надо взять на вооружение:)

                                                                        0

                                                                        У нас реально уходит 15-20 минут при команде 8-10 человек (иногда некоторые уважительно отсутствуют). И да, это стендап — проводим его стоя.

                                                                          0
                                                                          Мячик. Говорит только тот у кого в руке мячик. 3-5 минут на 10-12 человек.
                                                                            0
                                                                            Полминуты на человека? О чём полезном можно рассказать за полминуты?
                                                                              +2
                                                                              А стендап не для того, чтобы рассказывать что-то полезное. Он для того, чтобы в двух словах обрисовать что ты делаешь и какие проблемы возникли, если они есть, в масштабе 1-2 дней.

                                                                              А вот любители растекаться мыслью по древу и вещать по десять минут — они как раз и приводят к затягиванию митингов на часы. Если человеку есть что сказать больше чем на полминуты — это обычно либо какой-то узкоспециальный вопрос, по которому требуется консультация — и тогда он решается уже после собрания узким кругом заинтересованных. Либо это какая-то общая болтовня, на которую не стоит тратить время. Либо какое-то объявление для команды, которому возможно лучше посвятить отдельное время или вообще обойтись рассылкой по почте или группе в слаке или еще где.
                                                                                +4
                                                                                А стендап не для того, чтобы рассказывать что-то полезное.
                                                                                Ключевой момент.
                                                                                +1
                                                                                — Работаю с X, всё по плану, сегодня закончу.
                                                                                — Работаю с Y, от Пети из соседнего отдела нет аппрува, пока временно на Z.
                                                                                — Вчера сделал F,G,H, на сегодня в стеке только R и выглядит несложно, нужно больше тасков.
                                                                                — О, а мне как раз нужна помощь от человека кто разбирается в R, можешь мне помочь?

                                                                                ну и типа того. А обсуждать и решать проблемы нужно уже отдельно, на дейли они только озвучиваются но не обсуждаются.
                                                                              0
                                                                              Кстати да, опять же вопрос в кол-ве народу. 15 мин. на 2-3 человека или 15 мин на 20 человек.
                                                                                0
                                                                                Ну адепты скрама вроде говорят что он работает для небольших команд, человек в пять. Уж точно не больше десяти.
                                                                                  0
                                                                                  Тогда значит ошибка тех организаций, в которых работал. В одной из них пытались применять скрам явно на команду из 12 человек.
                                                                                    –1
                                                                                    Обычно это уже минимум две скрам-команды.
                                                                                      +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.
                                                                                      Так что это точно ошибка тех организаций, в которых вы работали.
                                                                                      0

                                                                                      7+-2, если я правильно помню

                                                                                  +3
                                                                                  Зачем вообще тратить даже эти 15 мин?
                                                                                  Что такого полезно в том, что все по очереди говорят «я делал то-то»?
                                                                                  Кому это нужно? Кому интересно? Какую пользу приносит проекту?
                                                                                  Только не надо заученными фразами из книги шпрехать. Расскажите про реальную пользу.

                                                                                  P.S. Это я еще молчу, что эти 15 мин выбивают еще на полчаса из контекста…
                                                                                    0
                                                                                    Выше уже писал. Это нужно во-первых для синхронизации, что бы каждый участник команды понимал, что делает другой и как это его затронет. Во-вторых для исправления каких-то мелких недопаниманий на лету. Т.е. кто-то не так понял какую-нибудь часть задачи и его тут же поправят, а не на этапе тестирования. В-третьих, что бы у продакта было понимание прогресса и он мог вносить корректировки.
                                                                                      +6
                                                                                      что бы каждый участник команды понимал, что делает другой и как это его затронет

                                                                                      Ну это же лукавство в общем случае. Чтобы понять как затронет работу, работа другого человека, не достаточно чтобы он сказал «я делаю сохранение документа». Там надо вникать и разбираться, что и как он делает. 15 минут «синхронизации» не хватит чтобы это всё прояснить. И опять же, «я делаю сохранение документа» никак не помогает понять прогресс. А если с задачей есть проблемы, то вменяемый разработчик не будет ждать сутки, чтобы сказать о проблеме. Он сразу скажет продакту о проблеме.
                                                                                        0
                                                                                        Перед каждым спринтом делается груминг — это встреча, когда по каждой задаче в общих чертах обсуждается как она будет сделана. Груминг как-раз и проводится для того, что бы каждый участник понимал реализацию. После этого 15 минут хватает за глаза.
                                                                                        Многим не нравится, что груминг + планирование иногда может занимать весь день. Но как показывает практика (хотя бы вот и сейчас), один потраченный день экономит в последствии намного больше времени за весь спринт.
                                                                                          0
                                                                                          Какие-то у вас очень простые задачи. Раз вы за день можете не только спланировать, но и даже определить реализацию для каждой из них…
                                                                                          А, еще оказывается всё сделать так, чтобы каждый участник понял реализацию. Поделитесь экспресс методами обучения людей за несколько часов? Или у вас все в командах матерые профи?
                                                                                            +3

                                                                                            Если задачу невозможно оценить за день, можно заранее взять задачу на проработку и исследование. Как оценивать задачи, если вы не можете объяснить реализацию за день ?

                                                                                              +1
                                                                                              Вот в этом и проблема. Как их оценивать?
                                                                                              Оценивать просто, когда ты на конвеере делашь одно и тоже. Какие нибудь сайтики на вордпресе. А когда вообще непонятно куда идти и что делать? На сколько я вижу, скрам хорошо работает только в случае конвеера, когда всё известно и надо только планы прикинуть к команде.
                                                                                              Для проектов в которых нифига непонятно и каждая вторая задача на ресёрч — скрам только мешает.
                                                                                                +2

                                                                                                Скрам как мои ботинки 45 размера, не всем подойдет.


                                                                                                Для проектов в которых нифига непонятно

                                                                                                Чтобы стало понятно что-то, необходимо провести работы — сделать понятно. Попробывать протатип, посмотреть видео итд.

                                                                                                  +2
                                                                                                  Это какие к примеру проекты? Я в свое время был на острие JS, делал игру на самописном фреймворке на html5 canvas в WarGaming, до того, как вообще кто-то такое делал в браузерах. И все-равно все задачи можно приблизительно оценить. Да, некоторые задачи могут сорваться — тут описываешь свои риски менеджменту, говоришь приблизительный «от и до» в часах или закладываешь сложность в стори-поинты. Но вцелом большинство задач, даже довольно новых, опытным разработчиком оцениваются довольно точно.

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

                                                                                                  Обычно менеджеры садятся, думают, что выкинуть или можно ли перенести сроки. Если оставляют как есть в надежде «авось прокатит», то, обычно, не прокатывает.

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

                                                                                                  Обратите внимание, у нас, на разработке игры менеджмент уже за пару месяцев понимал, с чем мы влезаем по срокам, какие риски могут сработать и, в идеале, даже имел план на такие вещи. И, уверяю вас, это совершенно не конвеер.
                                                                                          0
                                                                                          Что мешает сделать всё это вне стендапа?
                                                                                          что бы каждый участник команды понимал, что делает другой и как это его затронет

                                                                                          По информации из jira, от тимлидов и менеджеров всё ясно.
                                                                                          Во-вторых для исправления каких-то мелких недопаниманий на лету.

                                                                                          Обсуждение в частном порядке или в формате мини совещания от этого спасает.
                                                                                          Т.е. кто-то не так понял какую-нибудь часть задачи и его тут же поправят, а не на этапе тестирования.

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

                                                                                          Опять же, jira в помощь. От него исходит линейка задач, он всегда и в курсе происходящего.
                                                                                            +1
                                                                                            Что мешает сделать всё это вне стендапа?
                                                                                            Да ни что не мешает. Но просто то, что вы описали — это классический водопад с матричной структурой управления. И тут каждый выбирает то, что ему больше нравится.
                                                                                            Просто представьте, что некоторые живут без менеджеров и тимлидов. Вот им так больше нравится, самим рулить проектом.
                                                                                      0
                                                                                      Честно говоря, дзен скрам стендапов я так и не постиг. Фичи или проблемы за 20 мин. не обсудишь. Оно требует более целенаправленного обсуждения. Кто чем занят — я это при необходимости из jira и истории коммитов в курсе (это как раз регулярно просматриваю). Тут как-то была статья про канбан стендапы. Было бы интересно попробовать, но кажется в крупном проекте может далеко не на 20 мин. растянуться.
                                                                                        0
                                                                                        По мне так все сводится к:
                                                                                        «Задача сделать кнопку красной»
                                                                                        ---А сегодня товарищи мы будем обсуждать вчерашнее обсуждение)))
                                                                                      +1
                                                                                      Вполне себе рассказ. А вот это выражение: «Просто. Нормально. Работать.» — прямо как слоган с конвейера! И надеюсь с Сергеем не конец) Очень сильно хочется продолжения ВСЕХ направлений!!!
                                                                                        0
                                                                                        Только вот про работать над чем именно не сказано. А скрам ведь именно про беклог, а не стендапы. Если же СЕO видит беклог, но ни фига его не понимает, это уже не проблемы скрама, а компетенции людей на местах, либо способности найти нужных людей, которые могут сложить 2+2.
                                                                                          0

                                                                                          Обычно это называется что-то вроде "ибош пока не помрёш"

                                                                                          +3
                                                                                          Прочитал. Спасибо :) Прям собран весь русский опыт внедрения 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.
                                                                                            0
                                                                                            а где ссылка-то?
                                                                                            +3
                                                                                            Как-то много текста)
                                                                                            Если упростить:
                                                                                            1. Виноват не Скрам, а вон тот чувак.
                                                                                            2. Виноват не Скрам, это не всем дано.
                                                                                            3. Виноват не Скрам, а вон те чуваки.
                                                                                            4. Виноват не Скрам, а малое количество мозгов в РФ.
                                                                                            5. Виноват не Скрам, читайте Agile.


                                                                                            Таки может всё же не повара готовить не умеют, а просто блюдо специфическое и очень на любителя?
                                                                                              +5
                                                                                              Скрам он как коммунизм. На бумаге идея замечательная, но почему-то уже много лет ни у кого не получается ее приготовить. Но это не идея плохая и нереалистичная, нет, это просто они готовить не умеют. И вот они. И вот эти тоже. И вообще никто. Но сама идея хорошая.
                                                                                                +3

                                                                                                Что делать людям которые живут в скрам командах успешно ?

                                                                                                  +2
                                                                                                  Радоваться. Ну я допускаю что такие есть, но пока их не видел. И знакомые мои не видели. И большинство комментаторов тут — тоже. Все что попадается на глаза — это «срам», когда от скрама только куски — бесполезные затянутые митинги и сторипоинты в джире, а в итоге все тот же хаотический «фигак-фигак и в продакшен».
                                                                                                    0

                                                                                                    Спасибо, стараюсь так и поступать.
                                                                                                    В 2013 году на тренинге по scrum, услышал вопрос который поставил меня в тупик. Он был очень простой — Если сегодня, огромный рынок разработки ПО, высокие зарплаты и мало кадров, то зачем работать в месте где вас что-то не устраивает?
                                                                                                    С тех пор большую часть времени я проработал в scrum командах, без менеджеров и тех.лидов.
                                                                                                    Не могу сказать что это каждый раз был идеальный scrum, но он был довольно близок к чистому без перегибов. Не хочу говорить что это серебрянная пуля, но комфортнее работать я пока не вижу возможности.
                                                                                                    Брат жив.

                                                                                                    +1
                                                                                                    Тут есть очень важный момент.
                                                                                                    «Мы живем в скрам командах успешно» и «Наша команда успешна благодаря скраму»
                                                                                                    Это знаете ли две большие разницы.

                                                                                                    P.S. После того, не означает в следствии того ;)
                                                                                                      0

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

                                                                                                        0
                                                                                                        Методологии типа водопада или скрама нацелены, по-моему, на контроль процессов, на достоверную оценку вероятности успеха или провала. И, что важно, на унифицированную оценку.
                                                                                                          0
                                                                                                          по-моему, на контроль процессов, на достоверную оценку вероятности успеха или провала

                                                                                                          Очень глупо нацеливаться на заведомо неразрешимую (с практической точки зрения) задачу.


                                                                                                          Кроме того, мне кажется, это заявление по-просту ложно. Где в скраме, водопаде или еще какой-либо методологии, указаны конкретные способы расчетов указанной вероятности? Нету их.


                                                                                                          Если говорить о том, зачем вообще нужны методологии — то ответ, ни за чем. Не существует некоего единственного назначения у методологий в общем. Следование какой-либо методологии вынуждает производственный процесс обладать какими-то свойствами. В зависимости от самого процесса, его участников, его назначения и других подобных вещей — те или иные свойства могут быть либо полезными в данном конкретном случае (с-но логично выбрать методологию, которая форсирует их выполнение), либо нет. Т.о. в каждой ситуации у каждой методологии есть своя функция.


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

                                                                                                          0

                                                                                                          Это довольно спорное заявление. Если конкурент выпускает на вашем рынке продукт за 3 месяца а вы за 2 года, то есть большой шанс пролететь мимо.

                                                                                                            0
                                                                                                            Подмена понятий, крайности, сплошная демагогия. А к чему это?
                                                                                                              0

                                                                                                              Коль вы меня в них осуждаете, удосужтесь развить мысль и указать где вы все это увидели.

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

                                                                                                      Продолжая аналогию с коммунизмом (да простят ее мне любители политики и истории), можно тоже сказать что идеология-то хорошая, просто все время тут люди не очень умные попадаются, там не очень честные, и в итоге все разваливается.
                                                                                                    –3
                                                                                                    оно deadline а не didline ))
                                                                                                    1 — вообще именно проект и его сроки первичны, скрам — вторичен. Цель — сделать продукт, а не кодить ради кодинга.

                                                                                                    Я бы сказал так — скрам хорош для крупных компаний, где все эти «неделю жду от соседнего отдела апи» и «субординация» во всей красе, а в мелких пользы особо не будет.
                                                                                                    С субординацией сталкивался на одной из работ — там где надо было потратить 2 недели через начальства, я напрямую всё решил за 2 часа. И получил выговор.
                                                                                                      0
                                                                                                      Прям собран весь русский опыт внедрения SCRUM

                                                                                                      Это наднациональная проблема. Она есть во всех странах. Причем, чем южнее страна, тем более запущена проблема. В Израиле, например, с этим вообще катастрофа. Скрам сжирает города.
                                                                                                      –1
                                                                                                      Раньше все носились с CRM теперь все носятся со SCRUM.
                                                                                                        0
                                                                                                        А завтра все будут носиться с очередной технологией. Со времени x86 ни чего в этом не изменилось.
                                                                                                        +4
                                                                                                        Это азбука, аксиома: хороший разраб – это не хороший тимлид.

                                                                                                        А ну-ка расскажите мне, из кого тогда сделать хорошего тимлида, если не из хорошего разраба? Из плохого разраба? Из хорошего ПМ-а? Из QA? Из человека без опыта вообще?
                                                                                                          +4
                                                                                                          У хорошего тимлида, в отличие от разраба, на первое место выходят софтскилы или навыки общения с людьми. А учитывая, что обычно идеальный разраб — суровый интроверт, мы получаем тимлида с полностью отсутсвующими навыками общения. Которые нужно потом с нуля растить и развивать и то, это не всегда возможно. У Стартоплана есть целый цикл статей на эту тему, отлично подтверждающихся моим опытом и опытом знакомых коллег-руководителей.
                                                                                                            –1
                                                                                                            Это всё отлично, но всё же где ответ на вопрос из кого нужно делать лида, если не из разраба?
                                                                                                              +2
                                                                                                              хороший разраб – это не хороший тимлид.

                                                                                                              Тимлида делать из разраба. Но то, что он лучший разраб, отнюдь не означает, что из него получится лучший тимлид. Иногда лучший тимлид получится из посредственного разраба (всё, правда, зависит от того, что входит в обязанности тимлида у вас).
                                                                                                                0
                                                                                                                из так себе разработчика, уход которого в тим лиды не подкосит продуктивность команды)
                                                                                                                по крайней мере, в реальной жизни многие делают именно так
                                                                                                              0
                                                                                                              Все зависит от случая, но если строить идеальный мир, то Тимлид должен быть самоорганизованным разработчиком. Вы когда-нибудь видели лидера спецназа, который был бы не спецназовцем? Так же должен быть менеджер — продажник, который ведет проект и на митингах не должно быть всей команды, дискутировать должен Тимлид и продажник, можно только между собой, а можно — оба с клиентом. Тогда никаких проблем.

                                                                                                              Иначе, кто именно в команде будет решать путь развития в техническом смысле?

                                                                                                              Я думаю, что идеальной правильной формы нет и все зависит от размера бизнеса.
                                                                                                              0
                                                                                                              Я вот думаю о том, что было бы интересно пойти на вот такой эксперимент: давать каждому разработчику в команде по очереди месяц «без методологий разработки». Без скрама, без канбана, без джиры, без митингов и без отчётов вообще. Пусть сам себе выберет инструменты, задачи, план работы и месяц работает. И не трогать человека этот месяц. Потом пусть расскажет, над чем работал и что получилось. Сравнить результат со средним результатом разработчика основной команды, которая «бежала» этот месяц по скраму.
                                                                                                              Интересно, что получится.
                                                                                                                +1

                                                                                                                Что-то получится, это точно. И, как показывает практика, получается технически идеальная хрень, для последующий работы с которой нужен менеджер уровня того самого разработчика. Более того, после эксперимента вы потеряете программиста. Представим, что заказчик не примет проект. Вы обратно к программисту — давай переделывать. А это его творение и для него оно идеально, а заказчик м… к и ничего не понимает. А Вы, как начальник, тоже м… к, не смогли отстоять "правильное" решение

                                                                                                                  +3
                                                                                                                  «технически идеальная хрень» не должна требовать каких-то сверхусилий на последующую поддержку, а то она не «технически идеальна» по определению. Я подозреваю, что в 3/4 случаев на выходе будет пшик, велосипед или любимый только автором уродец. Но всё же самые важные и выдающиеся опенсорс проекты — они же создавались примерно в таком режиме работы: без давления сверху, на собственных идеях и энтузиазме. Возможно, и тут иногда работало бы.

                                                                                                                  Потом, после того, как каждый в команде использует свой месяц — «неудачников» можно посадить обратно на конвеер, а хорошие идеи внедрить в продукт и дать их авторам бюджет, команду, свободу.
                                                                                                                    0
                                                                                                                    ну как минимум будет CLI и конфиг файлы вместо гуя. При этом это будет овергибкая система, но разруливание взаимовлияния настроек (вплоть до завязки узлом всей системы) будет в голове пользователя. Потому, что «ну он что, дурак что ли — не понимал что ставит?»
                                                                                                                      0
                                                                                                                      Собираю вот сейчас движок V8 из исходников и инструкций Гугла — вот именно так оно там всё и устроено :) А гляди ж какая полезная штука вышла.
                                                                                                                  0
                                                                                                                  Такие программисты чаще работают во фрилансе, так как самоорганизованные люди более гибки не только в рабочих процессах, но и в зарабатывании денег в целом. Кто работает в офисе от звонка до звонка не готов к таким свободам. Большинство людей не будет себя организовывать.

                                                                                                                  Я согласен с вами в одном — что слишком много инструментов контроля и управления, их действительно нужно сводить к минимуму. Но, все-таки, это зависит от бизнеса и команды, например, я не приемлю в команду людей, которым нужна «игровая модель» управления и подстегивания, но я могу себе позволить выбирать, в больших «корпорациях» нехватка кадров и им приходится стимулировать разных людей и тут ваш подход о свободах не поможет )
                                                                                                                  –1
                                                                                                                  P.S. Продолжение нужно?

                                                                                                                  Есть вопрос? Есть ответ! ))
                                                                                                                  Данный рассказ на любителя… ну или на тонко-знающего предметную часть.
                                                                                                                  Было в комментариях выше, «А как же Серега?»
                                                                                                                  Пользуясь случаем, жду продолжение циклов «Проще, чем кажется» и «Корпоративная шизофрения» )
                                                                                                                    +5
                                                                                                                    Просто. Нормально. Работать.

                                                                                                                    Пиши. Код. Блеадь.
                                                                                                                      0
                                                                                                                      Да, да я тоже подумал про programming-motherfucker.com (http://macode.ru/)
                                                                                                                      каждый раз я возвращаюсь к тому, что ребята правы — надо фигачить и это единственное средство которое реально движет проект к цели. Как в киберспорте — если ты проседаешь по индивидуальному скиллу или по командному взаимодействию — пошел вон. Без церемоний лишних. Никто тебя на себе тащить не будет. Почему у нас не так. Выкинуть всех дармоедов к чертям. И будет норм. Какой процент дармоедов у вас в команде? У нас около 15 процентов. Те люди отсутствия которых проект вообще никак не заметит.

                                                                                                                      Мне часто думается, что радикальный подход Егора Бугаенко (zerocracy.com, xdsd.org) во многом верен. Все что нужно — это багтрекер и код.
                                                                                                                        0
                                                                                                                        Если бы это было верно, естественный отбор давно выкосил бы команды с «дармоедами», и остались бы только программирующие мазафаки. Но я что-то не знаю ни одной успешной конторы без «дармоедов».
                                                                                                                          0
                                                                                                                          естественный отбор давно выкосил бы команды с «дармоедами»
                                                                                                                          Нет. Ведь наличие «паразита» не убивает «хозяина». Если остальные вкалывают за троих, то можно брать «дармоедов» и проекты все равно будут успешными.
                                                                                                                            0
                                                                                                                            Так если эти «дармоеды» получают деньги да еще и мешают работать, конторы без них должна иметь конкурентное преимущество, которое должно как-то отражаться на больших выборках. Но я не видел таких контор ни в больших выборках, ни в малых. Значит, не некоторые люди дармоеды, а некоторые другие люди — фантазеры и максималисты.
                                                                                                                              0
                                                                                                                              А кто сказал, что оно не отражается, на, например, финансовых результатах компаний или дохода их топов? А так на рынке могут бесконечно долго существовать компании, ведущие деятельности на грани рентабельности или даже за ней, если есть постоянный приток капитала снаружи компании, например из родительского холдинга.
                                                                                                                                0
                                                                                                                                А я говорю не про количественное, а качественное отражение: сколько на практике жизнеспособных компаний с «дармоедами» и без. Где вообще компании без «дармоедов», у которых только «багтрекер и код»? Ау!
                                                                                                                                  0
                                                                                                                                  Zerocracy ведет дела именно так. Нет deliverables (артефактов) — нет оплаты.
                                                                                                                                  Хотя он и делает оговорку, что в проектах которые имеют долгострочную направленность такой подход может и не работать.
                                                                                                                                    0
                                                                                                                                    Нашли одну контору без долгосрочных проектов. Ну круто. Расходимся.
                                                                                                                      +2

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

                                                                                                                        –1
                                                                                                                        >нет такой роли
                                                                                                                        То, что в документах по скраму эта роль называется другим словом, не значит, что роли нет.

                                                                                                                        >играет во взрослого
                                                                                                                        Если кто-то осознал, что надо не играть в «море кода волнуется раз!», а просто писать код — он таки реально повзрослел.
                                                                                                                          +1
                                                                                                                          То, что в документах по скраму эта роль называется другим словом, не значит, что роли нет.

                                                                                                                          а каким словом называеться тимлид в scrum документах ?


                                                                                                                          Если кто-то осознал, что надо не играть в «море кода волнуется раз!», а просто писать код — он таки реально повзрослел.

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


                                                                                                                          Позиция "ваши разговоры мешают мне писать код", имеет право на существования, как и любая другая. Просто как ботинки 46 размера она не всем подходит.

                                                                                                                            –1
                                                                                                                            >а каким словом называеться тимлид
                                                                                                                            Называется словом scrum-master, не?
                                                                                                                              0
                                                                                                                              Не, scrum-master вообще в теории не входит в команду, а стоит сбоку и бдит за соблюдением этого самого скрама.
                                                                                                                              0
                                                                                                                              а каким словом называеться тимлид в scrum документах ?

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

                                                                                                                              +1
                                                                                                                              Если кто-то осознал, что надо не играть в «море кода волнуется раз!», а просто писать код — он таки реально повзрослел.
                                                                                                                              Опять же, чем скрам мешает писать код?
                                                                                                                                0
                                                                                                                                Производственными совещаниями.
                                                                                                                              0
                                                                                                                              Тимлид обычно должность, а не роль.
                                                                                                                              +6
                                                                                                                              Ну как обычно, неадекватный руководитель, неадекватные сроки, непонимание методологии, а виноват конечно SCRUM.
                                                                                                                              Команда здесь ни причем, они – просто разработчики, они делают то, что ты скажешь!
                                                                                                                              Первая ошибка. Скрам работает только тогда, когда это нужно всей команде. И прикол в том, что вся команда должна принимать решения. Да и при такой модели тимлид то и не нужен. Все его функции должны быть чисто административные.
                                                                                                                              В четыре раза быстрее!
                                                                                                                              Это только в условиях постоянно меняющегося ТЗ и по сравнению с водопадом полного цикла (написание ТЗ->Разработка->Тестирование->Внедрение) Т.е. скорость увеличивается за счёт того, что при изменение требований по результатам внедрения можно не ждать пока полностью ТЗ напишут, а сразу делать.
                                                                                                                              не хватало только еще одного просранного проекта!
                                                                                                                              Т.е. у них и так всё плохо и они надеялись на какую-то волшебную методологию?
                                                                                                                              Вот вам же нравилось, что мы стали чаще и стабильнее делать релизы
                                                                                                                              Ну и прозрачность повысилась, вы же сами говорили, как удобно стало оценивать остаток работ по проекту.
                                                                                                                              Т.е. плюсы они понимают.
                                                                                                                              Просто. Нормально. Работать.
                                                                                                                              И вот что изменится? Что их в скраме то тормозило?
                                                                                                                              Ну т.е. на лицо явное неумение Боба руководить: благодоря скраму он прекрасно видел прогресс и прекрасно должен был понимать дату релиза. Если это дата оказывалась после дедлайна он должен был либо уменьшить число фич, либо подключить ещё одну команду. И кстати, в стиле «Просто. Нормально. Работать.» об этом бы узнали только когда уже все сроки были бы просраны. И что по итогу? Ничего из мер не было предпринято, а виноват оказался самый толковый, и скорее всего самый полезный разработчик.
                                                                                                                                +10
                                                                                                                                Я правильно понял, они срок до дедлайна разделили на 4, потому как SCRUM ускоряет в 4 раза и теперь CEO рвёт на попе волосы?)
                                                                                                                                  –1
                                                                                                                                  То есть в этой фирме скрам, судя по статье, не ускорил разработку в четыре раза, но, зато, и не замедлил её. При этом принёс кучу других преимуществ. К примеру вот:
                                                                                                                                  как удобно стало оценивать остаток работ


                                                                                                                                  То есть, я так понимаю, скрам виноват в том, что не стал серебрянной пулей, не порешал все проблемы а лишь слегка улучшил ситуацию. Не говорите директору, что его жена какает, он сделает виноватой и её!
                                                                                                                                    0
                                                                                                                                    метьте статью тегом литературное творчество, думал что-то серьезное…
                                                                                                                                      +3
                                                                                                                                      там обычно тег «художественная литература» стоит.
                                                                                                                                      0
                                                                                                                                      Хочу отметить, что компания то в рассказе аутсорсинговая. В аутсорсе скорость важнее качества, дизайна, надежности, масштабируемости, ui/ux, маркетинговых фич и прочее.

                                                                                                                                      Боб опять уставился в окно. – Я ведь тоже поверил в эту хрень. Я про скрам. Я тоже думал, что он поможет нам быстрее делать проекты.
                                                                                                                                      ИМХО scrum вообще не про скорость. Как раз про все остальное.
                                                                                                                                        0
                                                                                                                                        Ждем продолжения
                                                                                                                                          –1
                                                                                                                                          — Твоя судьба, Джон! – крикнул Боб. – В провале проекта виноват только ты! Команда здесь ни причем, они – просто разработчики, они делают то, что ты скажешь! Как ты стадо гонишь, так оно и идет, понимаешь, Джон?

                                                                                                                                          — Понимаю… — сокрушенно сказал Джон и снова опустил голову.

                                                                                                                                          — Ты был прекрасным разрабом, и я никогда не думал о том, чтобы сделать из тебя тимлида. – продолжал Боб на повышенных тонах. – Это азбука, аксиома: хороший разраб – это не хороший тимлид. Но ты меня… Нет, не обманул – просто запудрил мне мозги своим скрамом, и я решил – вот, вот он, тимлид нового поколения! Инициативный, вдумчивый, ищущий, не замкнутый в стереотипах! Тот, кто мне нужен! Как же я ошибся!


                                                                                                                                          После вышеприведённого блока я окончательно убедился, что автор заметки не знает/понимает, что такое Scrum. Дальше читать не стал.
                                                                                                                                          На Хабре тема «обсёра чего-то отдалённо напоминающего Scrum» довольно хайповая, поэтому не удивлён в количестве плюсов у данного опуса.
                                                                                                                                            –1
                                                                                                                                            Ну так никто похоже не понимает, что такое скрам. Во всяком случае ни я сам, ни многие авторы комментариев не видели «труъ скрама», но видели много неудачных попыток. Scrum он как коммунизм — абстрактная прекрасная идея, которая при попытке внедрения на практике практически всегда вырождается либо во что-то довольно уродливое и неэффективное, либо чисто формальное.
                                                                                                                                            0
                                                                                                                                            Просто. Нормально. Работать.


                                                                                                                                            Это ведь сарказм?
                                                                                                                                              +1
                                                                                                                                              У меня тимплид — я эффективнее человека не видел. Он просто сидит с шести утра до шести вечера и фигачит. И что я у него заметил — он все прерывания обрабатывает по фифо. Тут же берет и решает твой вопрос. Чтобы голова всегда была свободна. Никогда не откладывает ничего «на потом».

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

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

                                                                                                                                              Да, конечно, в этом есть что-то уникальное от самого человека. Такое стопроцентное, постоянное присутствие сознания и концентрация — не уверен, что этому можно полностью научиться. Но вот технику «питейного рога» (который нельзя отставить в сторону) — вполне можно освоить.

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

                                                                                                                                              Он еще, например, против любой работы которая не улучшает напрямую конечный продукт. Как он выражается «мы не продаем %xyz%, мы продаем продукт». Все так просто. Почему это так трудно понять? Нужно делать все, что непосредственно является целью бизнеса и не делать ничего остального. В книге Голдратта, в принципе, говорится о том же.

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

                                                                                                                                                  Это не фифо, это стек. То есть он решает рабочую задачу, ты подошел он занялся твоей, ты не успел отойти, подошел Вася — он уже отложил твою и занялся Васиной.
                                                                                                                                                  Фифо это ты подошел со своим вопросом, а он тебе «Вон у меня стопочка, напиши свой вопрос на листочек и положи снизу».
                                                                                                                                                  +1
                                                                                                                                                  Почему все носятся с этими досками, как с каким-то мега скилом тимлида? Они вроде всегда были в разных формах, спокойно себе юзаю доски для себя и для команды — всю жизнь, в древность — они были в эксель, при том даже в далеком 2008 — молодые годы, никто ничего про «скрам» не читал, просто работали. Теперь же все молодые в очках произносят эти слова и делают умный вид, а проекты рушаться, потому что никто не думает головой про реальность бытия, менеджер должен не задачи по команде крутить (по сути команда и так сама это делать должна), а понимать суть происходящего не только в команде, но и по взаимоотношению с клиентами.

                                                                                                                                                  Правильно расставлять приоритеты.

                                                                                                                                                  C Тимлидами происходит примерно тоже самое, что с разработчиками после курсов, если ты в IT — ты сразу модный ) и можешь часами медитировать над Agile )
                                                                                                                                                    +1
                                                                                                                                                    Ну если ребята проваливали регулярно проекты без скрама, то он их особо не спасет. Да и вообще странно, что выбирают скрам исходя из соображения скорости разработки. В моём опыте скрам всегда выбирался, когда заказчик имел весьма пространное представление о том, что он хочет получить на выходе. Есть куча неопределенностей? Пилим по скраму, в процессе проясняем все непонятные моменты. Практически всегда вылетаем за первоначальные оценки (за счет новых фич, что докидывает заказчик в процессе), но еще ни разу вроде заказчик не был в результате недоволен. Все продукты за последние несколько лет сделанные по скраму в лайве, работают и приносят заказчику денежку. В тех редких случаях, когда заказчик чётко знает, что он хочет получить (до мельчайших подробностей) пилим по вотерфолу. Из сроков практически никогда не вылетаем, заказчик получает именно то, что хотел вначале. Но если в процессе решил что-то переделать — тут уж извини.
                                                                                                                                                      +1
                                                                                                                                                      Бред какой-то написан. Какая разница какими методами ПМ не может добиться от команды результата? Ну давайте запустим его в каскадную модель. Он так же будет заваливать дедлайны. Программисты очень часто увлекаются программированием, а не конечной реализацией. И хоть стреляйте меня, но лучше бы ПМ не быть программистом.
                                                                                                                                                        +1
                                                                                                                                                        Боб тут напоминает Платова из прошлогодней истории на хабре. Помните совещание в xored на ютуб выкладывали? Краткое содержание: «Контора абсолютно угандошена! И мы все в этом виноваты, а я теперь буду вас материть». Если не видели, вбиваете «xored платов» в поиск на ютубе.

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

                                                                                                                                                          Это сказ про то, как воспитывать персонал? Слово "скрам" можно заменить любым другим, сценарий от этого не меняется.

                                                                                                                                                            –4
                                                                                                                                                            Scrum как покер. Правила можно понять за 10 минут, а играть будешь учиться всю жизнь. И не факт, что когда-нибудь получится стабильно выигрывать. «Попробовать скрам», это гарантированные деньги на ветер; на роль скраммейстера необходимо нанимать человека, который уже умеет. Я пару раз имел удовольствие такого наблюдать.
                                                                                                                                                              +1
                                                                                                                                                              Непонятно как скрам помог ухудшить результат. Если народ на работе фигней страдает, а скрам делает это очевидным, то возможно некоторое ускорение работы. Но чтоб в обратную сторону? Заставляли по пол дня берндаун диаграммы вместо работы рисовать? Автор, тема как скрам помог завалить проект не раскрыта. Вообще, надо заменить термин скрам на микросервисы, тогда будет жизненно.
                                                                                                                                                                0

                                                                                                                                                                Да элементарно: благодаря скраму они еще до факапа поняли, что будет факап. Ну и конечно в этом виноват скрам.
                                                                                                                                                                Все эти аджайлы и скрамы они не про скорость. Они про что угодно, но не скорость.
                                                                                                                                                                Предсказуемость, гибкость, понимание как изменение изначальных договоренностей изменят срок. Примерно понять какой срок будет реален. Про "мы команда" (вот кстати в РФ именно командная работа хромает: очень часто слышу не МЫ сделали плохо, а Он/ВЫ сделали плохо)

                                                                                                                                                                  0
                                                                                                                                                                  Книжка Джефа Сазерленда (одного из авторов скрам) так и называется «Scrum: The Art of Doing Twice the Work in Half the Time». Т.е. у самих авторов маркетинговое обещание именно такое — в 4 раза быстрее.
                                                                                                                                                                  0
                                                                                                                                                                  Любая методология требует выделения ресурсов на её поддержку. Митинги те же различные: планирование спринта, ежедневные, ретро. Поддержка бэклога.
                                                                                                                                                                  0
                                                                                                                                                                  Был на месте Джона, но ушел сам до разговора с Бобом.
                                                                                                                                                                    0
                                                                                                                                                                    На мой взгляд, данная заметка скорее вредна, чем полезна. Вредна она тем, что на эмоциях преподносится якобы доказанная на практике бесполезность скрама. При этом сама ложь искусно замаскирована и заключается в том, что «во всём скрам виноват», «толку от скрама нет» и т.п. В этой «пьессе» не предоставлено ни одного объективного аргумента о бесполезности скрама.

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

                                                                                                                                                                    Я работал в команде где скрама не было и сейчас работаю в команде, где он есть. Для меня польза скрама очевидна. Да и для начальников, насколько я вижу, тоже: каждый начальник (да и разработчик тоже) всегда хочет чётко понимать, что уже сделано, над чем идёт работа сейчас, в какой она стадии, что в рамках скрама будет сделано ещё и какие проблемы возникают в ходе работы.
                                                                                                                                                                      –1
                                                                                                                                                                      Нужно.
                                                                                                                                                                        0
                                                                                                                                                                        — Да я понимаю, просто… — начал было Джон.

                                                                                                                                                                        — Послушай, услышь и запомни: я уволю тебя к чертям! – перешел Боб на крик.

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


                                                                                                                                                                        И заказчик вроде доволен был.
                                                                                                                                                                        — Конечно доволен! Потому что до этого он вообще ничего не получал!

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


                                                                                                                                                                        — А как работать? – нахмурился Джон.
                                                                                                                                                                        — Просто. Нормально. Работать. – чеканя каждое слово, сказал Боб.

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


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


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

                                                                                                                                                                          +1

                                                                                                                                                                          У нас скрам, но через месяц дедлайн??? Это как? Завернули итеративную разработку в фикскост и продали клиенту? Ну и м… молодцы. Я бы пожалуй ответил Бобу следующее:


                                                                                                                                                                          • Старик, я понимаю что ты на стрессе и все такое, но давай по честному, ок? Ты как опытный менеджер почуял грядущую жопу и ищешь виноватого. Слава Богу у тебя достаточно адеквата чтобы виноватым оказался ангуляр, докер, скрам, кофемашина или на худой конец не особо ценный сотрудник из линейного менеджмента. Если тебе так легче — пусть виноватыми будут скрам и я. Но даже Дон уже понимает что проблема не там. Да, мы долбоклюи. Мы начали делать итеративную разработку внутри фикскост проекта. Мы объяснили все Дону, а он сказал "да мне пофигу, как, просто пишите код". Вот тогда нам следовало объяснить Дону что у любой методологии плюсы и минусы. Что поезд хорошо держит рельсы, а мотоцикл быстро едет и хорошо поворачивает. Возить мебель на мотоцикле или устраивать гонки на поездах это хреновые идеи. И либо ему надо отразить итеративность в отношениях с заказчиком, либо нам надо не выпендриваться а расчехлить мспроджект и поставить ПМ ов на бюджет из расчёта 1 на 5 подчинённых. Но мы ничего из этого не сделали. Мы (вообще говоря вы) продали фиксированные обязательства, выкинули весь менеджмент оверхед из оценок (у нас скрам, какие менеджеры!), тем самым занизили стоимость, забили болт на трекинг (на деме поговорим, ага) и теперь ты на меня орёшь про близящийся дедлайн. Дедлайн, Боб! Это вообще слово из другой книжки! Ты врубаешься какой это долбаный цирк! А теперь позволь предложить как клоун клоуну: давай наденем взрослые штаны и начнём решать проблему конструктивно. А почему черт подери мы не можем двинуть этот хренов дедлайн?
                                                                                                                                                                            0
                                                                                                                                                                            А точно буква «р» нужна в этом слове?
                                                                                                                                                                              0
                                                                                                                                                                              Остро не хватает объяснения, что же на самом деле ожидалось от тимлида. Попадание в сроки определенные до начала проекта? Так скрам не про это. Отвертка вообще плохо подходит для забивания гвоздей, равно как и молоток не тот инструмент который нужен для заворачивания шурупов. Скрам хорош для контроля производительности при тайм-энд-материал проектах. А для фиксед прайс — больше подходит руп или тот же ватерфолл. И вообще-то там есть понятие НИОКР (R&D) проектов для неясных случаев. Когда фиг его знает — достижимы ли заявненные цели в задекларированных условиях в принципе. Ну а когда менеджмент подписывает контракт с фиксированной стоимостью и сроками и допускает внесение изменений в объем работ без пересмотра этой самой стоимости и сроков — это клиника. Тут самый лучший исполнитель ничего не сможет сделать. Есть конечно варианты когда исполнитель самовольно соглашается на изменение объема работ — но это опять таки ошибка менеджера допустившего такую самодеятельность. Ну и цинично отмечу, что тимлид это не менеджер, ему желательно, но не обязательно знать все вышесказанное. А уж свежеповышенный тимлид тем более.
                                                                                                                                                                              Вообще, если планируется работать с лидом дальше — нужен нормальный анализ ошибок проекта с выделением областей применимости вышеупомянутых инструментов и техник. А в приведенной форме это выглядит как классическая манипуляция с созданием чувства вины у выбранного стрелочника и последущим забалтыванием для затирания аргументации и закрепления чувства вины. Поэтому я и не люблю работу в офисе с коммуникацией не подразумевающей ведение истории (правда у меня значительный опыт удаленной работы аутсорсером и есть возможность сравнивать). Личностей мнящих себя непревзойденными манипуляторами (или просто очень хитрыми и умными) — множество, тратить время на борьбу с манипуляциями не очень то и продуктивно. А наличие истории общения по крайней мере сдерживает самых тупых — потому что полные идиоты выпиливаются моментально.
                                                                                                                                                                                0
                                                                                                                                                                                А разделять диалоги вставкой пустых строк — это что бы объем солиднее был?
                                                                                                                                                                                  0
                                                                                                                                                                                  объем измеряется в знаках. Несколько лишних ПК погоды не делают.
                                                                                                                                                                                  Мне кажется, так читать удобнее.
                                                                                                                                                                                    0
                                                                                                                                                                                    Не в знаках, а в авторских листах. И то, только в издательстве. А читать неудобно.
                                                                                                                                                                                      0
                                                                                                                                                                                      Не в знаках, а в авторских листах.

                                                                                                                                                                                      Это у вас? Или у меня? Или у кого?
                                                                                                                                                                                      Как там измеряют в издательстве, дело ихнее.

                                                                                                                                                                                      Про удобно или неудобно — надо знать чье-то еще мнение. Вы первый, кто обратил внимание на переносы.
                                                                                                                                                                                        0
                                                                                                                                                                                        >Это у вас? Или у меня? Или у кого?
                                                                                                                                                                                        Это везде ))
                                                                                                                                                                                        Объём измеряют по-разному. В знаках и авторских листах — в издательстве при оплате. А при чтении — в страницах.

                                                                                                                                                                                        ЗЫ. Я понимаю ваше уязвленное авторское самолюбие, но текст — ни о чём. Без обид.
                                                                                                                                                                                          0
                                                                                                                                                                                          если б у меня было уязвленное авторское самолюбие, то я бы
                                                                                                                                                                                          — либо ругался и спорил со всеми комментаторами;
                                                                                                                                                                                          — либо бросил бы писать ниочемные тексты.

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

                                                                                                                                                                                          Но, к сожалению, емуНравится && емуНеудобно = 0.
                                                                                                                                                                                            0
                                                                                                                                                                                            >либо ругался и спорил со всеми комментаторами;
                                                                                                                                                                                            При чём здесь все? Речь идёт о моем комментарии. Со мной вы уже спорите (причём, неконструктивно) и вот-вот готовы перейти на ругань. Так что с уязвленным самолюбием я почти не промахнулся.
                                                                                                                                                                                              0
                                                                                                                                                                                              так я с вами, как со всеми разговариваю. Вы же представитель определенного класса комментаторов — самого распространенного.
                                                                                                                                                                                                0
                                                                                                                                                                                                Т.е., спорите не только со мной? Очередное подтверждение правоты моего тезиса об уязвленном самолюбии.

                                                                                                                                                                                                ЗЫ. На этом извольте раскланяться. На будущее вам — не пишите больше. Или пишите, но не сюда.
                                                                                                                                                                                                  0
                                                                                                                                                                                                  да, спасибо, и вам удачи.
                                                                                                                                                                                  0
                                                                                                                                                                                  Да, напишите плз. продолжение. 25 этаж не просто же так описан?
                                                                                                                                                                                    0
                                                                                                                                                                                    Тот самый случай, когда комментарии к публикации полезнее самой публикации.

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