×

Мой взгляд на Scrum

Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті

По мотивам заметки на Хабре «Мой взгляд на Scrum» habrahabr.ru/post/150203 у меня завязалась дискуссия с товарищем, и я хотел бы поделиться «своим взглядом на Scrum».

По-моему, Скрам Срам (дальше для точности и краткости я буду использовать такое название) — это типичная en.wikipedia.org/wiki/Cover_your_ass практика, позволяющая всем участникам процесса найти рациональные объяснения, почему они все просрали.

И хотя в самой методологии есть интересные моменты, в основном Срам создан для оправдания неудач («мы все делали по Сраму») и трудоустройства целой армии Срам-тренеров.

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

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

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

В СССР эта роль отводилась КПСС, в «классическом» менеджменте — МБА, в современном IT — Сраму.

Соблюдай ритуалы, заваливай один проект за другим, и гарантированно не поСрамишься!

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn

Найкращі коментарі пропустити

Как бы эта методолгия подразумевает self-organized команду с достаточным уровнем мотивации и направлена на получение быстрого feedback. Если нету ни мотивации, ни желания, ни возможности решать проблемы повлекшие за собой провал итерации, то никакая методология не поможет.

Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

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

Scrum нормальная методолгия разработки. Единственное чего не хочется, так это попасть на проект где ПМ адепт церкви скрама
загнать разработчика в overclock mode,
разбить марафонскую дистанцию на спринтерские отрезки,
и гнать-гнать.
ПМ адепт церкви скрама
и тут, что характерно, дело не в скраме, а в адепте. Оставь адепт, замени скрам и ПМ на любую методологию / позицию с возможностью влияния — и ад готов :)
Как-то на скрам тренинге, тренер сравнил работу по скраму с игрой в регби... Только, вот, на вопрос знает ли он, что средняя продолжительность карьеры профессионального регбиста == 3-4 года (не считая квотербэков) ответа у него не нашлось
(dou.ua/...ic/6135/#233895)
в точку.
загнать разработчика в overclock mode,
разбить марафонскую дистанцию на спринтерские отрезки,
и гнать-гнать.
Многие тут возмутятся, мол дело не в методологии, а в отдельных неудачных имплементациях. Только вот подобные оценки мне очень напоминают рассуждения про Конституцию Украины, которая якобы вся такая распрекрасная, «просто ее никто не выполняет».
© T.S.
адепты Срама оч напоминают Отца Онуфрия, рассуждающего о Заповедях.
тернист их путь к Bugatti Veyron

Можно процитировать Жванецкого? А ладно, не дождусь разрешения и напишу:

«Давайте спорить о вкусе устриц и кокосовых орехов с теми, кто их ел...»

Вот хочется перейти на личности (хотя казалось бы «зачем порождать трололо?») и спросить: «А сколько вы проектов сделали по Скраму?» и «Какую роль Вы в этом проекте выполняли?»

Люди склонны осуждать то, чего не понимают или то, что понимают поверхностно. Мое изначальное отношение к Скраму (4 года назад) было примерно такое же. Я заявлял «О, хоспади, очередное надувательство!». Потом я увидел команды, где это работает и захотел «попробовать по-настоящему». И знаете, заработало! И неоднократно :)

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

Потрібно просто розуміти, що чистий скрам розрахований на професіоналів( міркую не потрібно пояснювати це слово?) в вакуумі.

В реальному житті сильно впливають такі фактори:
1 злагодженість команди (психологічна сумісність в команді).

2 кваліфікація команди

Успіх скраму теж залежить від project manager-а та власника проекту.

Як показує практика при порушені вище окреслених пунктів скрам перетворюється в тягар і балаган.

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

Так що з вашої сторони, краще пояснити, що Ви маєте на увазі під цим словом більш точніше і без зайвих емоції?

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

Мое мнение — проблема скрама и таких топиков в том, что как для новой методологии, сторонники скрама вынуждены говорить «он лучше чем что-то другое» и это вызывает естественное недовольство. Но если Вы считаете что переход на скрам не даст преимущества — то считаете ли Вы, что переход со скрама на «водопад» может дать преимущества?
Я веду к тому, что это только один из инструментов, который надо применять грамотно. ИМХО большую ошибку делают те, кто ожидают что применение СКРАМа достаточно для создания качественного продукта. Для этого нужна команда хороших разработчиков, адекватный менеджер, и т.д., иначе проект одинаково успешно провалится по любой методологии.

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

Павел, я согласен с тем, что вы написали.

Я никогда не ожидал, что:

применение СКРАМа достаточно для создания качественного продукта.

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

«Евангелисты» СКРАМа и те, кто внедряют его в своих командах, нередко полагают, что СКРАМ позволит сделать из вчеращней «творческой мастерской» надежный конвейер, бесперебойно выдающий на-гора новые продукты и новую функциональность.

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

технология не нова.
люди смотрят на нее как на панацею.

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

Новее, чем waterfall, и менее известна. Я к тому, что не видно людей, которые учат «вотерфолл лучше чем все остальное, потому что ...», а в другую сторону это актуально. То есть, никто не ожидает что waterfall принесет результат вопреки всем проблемам, а реклама скрама такое (ошибочное) мнение вызывает.

может быть потому, что хуже чем вотерфол ничего быть не может.

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

Может:
en.wikipedia.org/...i/Cowboy_coding
Хороший вотерфол гораздо лучше чем плохой аджайл.

Большинство «плохих» проектов на самом деле делается как халтура (без внятной методики). На скрам, вотерфол или любой процесс ПМы ссылаются с умным видом что бы прикрыть свой зад.

Коментар порушує правила спільноти і видалений модераторами.

слова не юноши, а мужа! ©

я рад, что не один такой. но думаю вам будет лучше смириться с тем, что IT уже лет 5ть как перешло в разряд — «станки, станки, станки». Так что IT-номенклатура уже есть и она уже навязана. Просто у них там то же свои разборки регулярно происходят. Что бы в тонусе были и не забывали доказывать свою необходимость.

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

Сейчас работаю без какого либо скрама, и мне того скрама нехватает :-)

Для меня тот скрам давал две позитивные вещи:
-Ощущение действа, непрерывного девелопмента, «паравоза прогресса», и ты как часть этого на острие.

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

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

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

Коментар порушує правила спільноти і видалений модераторами.

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

знатно подловил =)

так а в чем состоит сравнение?

Как-то на скрам тренинге, тренер сравнил работу по скраму с игрой в регби...
в потогонно-соковыжимательном смысле ))

почему в теме так мало фанатиков? ведь это же очень полезная методология, которая может заменить 10 программистов и 4 БА

Подождите, они еще не вышли из ступора, после того как кто-то посягнул на их священную корову. Вот сейчас, только, слегка попустит и начнется... :-)

А может «Scrum» и подобное, это сценарий варки каши из топора? (или из булыжников лукового супа, в аналогичной французской сказке)

Тогда вполне годная штука. Если крестьяне не были бедны конечно :)

а какую здоровую альтернативу вы предлагаете?

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

По методологии scrum или agile я не работал, а может быть и работал, но не знаю об этом, но моё интуитивное мнение, после поверхностного знакомства с манифестом и схемами работы, выглядит так:

Существующие методологии разработки призваны максимально формализовать отношения между Заказчиком и Разработчиком, и одновременно снять с Разработчика любую ответственность за проект в целом. Несмотря на уход в сторону «живого общения» это так, хотя и нет многостраничного ТЗ.

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

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

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

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

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

Опять же интуитивно, гибкие методологии идеально подходят к программированию бессмысленных программ. То есть программ с собственной логикой, тех которые не автоматизируют существующие производственные или социальные структуры, а создают вместо них свои. Иногда удачно, но чаще нет. Например, сама по себе элетронная книга удобна как доступ к печатному тексту и его хранение, но вряд ли кто-то будет спорить, что процесс чтения, его внеконтекстная эргономика сильно отличается от листания обычной книги. Скрам идеально подходит для создания ридера, но он не подходит для того чтобы сделать что-то лучше, чем чтение обычной книги. В результате, все задачи Заказчика будут удовлетворены, все спринты закончены, но конечный пользователь получит унылый, мёртвый дивайс, который правда будет хорошо продаваться. И все получат свою зарплату и начнут новый проект. Что не так уж и плохо.

В целом правильно. Один из секретов успеха Скрама как раз в том, что 80% функционала большинства программ нужны только 20% юзеров.

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

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

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

Один из секретов успеха Скрама как раз в том, что 80% функционала большинства программ нужны только 20% юзеров.
Так вот опытный представитель разработчиков — очень даже хорошо просекает эти 80% функционала, и аккуратно так отсекает. Без всякого Скрама. Стопицот способами.
Если Скрам помогает в этом деле неопытному — тогда толковая штука.
Если разрабатывается, скажем, медицинское ПО, где все по стандартам и математическим моделям
Мат модели, не мат модели, но если отсутствие функционала, который используется в 1% случаев приведет к смерти пациента — ох да.
Такое же можно сказать о бортовом ПО самолетов, ПО для атомных станций, и т.д.
То есть там где последствия отсутствия фичи — очень тяжелы и осязаемы.

В бизнес ПО, для пользователей, отсутствие «80%» приводит обычно просто к многоэтапному использованию тех 20% что есть. Вместо одной кнопки нужно нажать три в определенном порядке. Конечно, если эти 20% действительно верно выявлены как базовые, как аксиоматика. Без любой из которых — программа в целом нах никому не нужна.
Хотя, я так часто, как пользователь, встречал нелепую невозможность и пятью кнопками сделать логичную вещь в известных программах, что даже такая ошибка — успеху не помеха :)

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

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

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

Что интересно в апологетике аджала, Scrumа — так это полный идиотизм использующих иные виды планирования. Они описываются как тупоголовые, бьющиеся головой об стену плана, и ничего и никого старающиеся не замечать, а строго, буква в букву следовать ТЗ, плану, срокам, ..., ..., ...

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

В итоге заказчику как бы никто ничего не обещал сделать (ни по срокам, ни по фичерам). Обещали только работать пока он платит и делать «сколько успеем».

Вот-вот. Это я тоже понял, что заказчиков для аджайла и т.п. еще повыискать нужно. :)

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

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

Но честно, рассписывать слабости ажайл и т.п. мне неинтересно.
Слишком много религии, чтобы это имело позитивный смысл

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

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

Еще заказчики любят НЕ вникать, отмазываться — «я занят, давайте позже», «обратитесь к моему начальнику, подчиненному с этим вопросом» и т.д.

Есть заказчики, который сами работают по аджайлу, понимают его правила, заинтересованны в результате и готовы «вникать». С такими Скрам работает замечательно. Команда работает весело, а клиент получает именно то, что ему нужно, быстро (2 недели) и всегда может поменять (еще за 2 недели).
Беда в том, что ИТ компании аджайл очень выгоден именно своей «безответственностью». Поэтому она пытается его внедрить даже с «нехорошими» клиентами. В итоге получается халтурный проект, вечно недовольный клиент, злой ПМ и «выдрюченная» команда.
Чувствую, что начинаю повторяться, лучше дам ссылку:

dou.ua/...ic/5290/#178381

Есть заказчики, который сами работают по аджайлу,

Конечно есть. Только обычно сама деятельность таких заказчиков — далека от проектной. Это серийная, потоковая деятельность.

А создание ПО — проектная.

и готовы «вникать»

Чем больше организация, тем дальше каждый ее сотрудник от целей и бенефитов этой организации. Когда Я один и хозяин киоска, и продавец в нем — ох я буду вникать! Когда Я хозяин, а жена продавец, то тоже буду.

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

Беда в том, что ИТ компании аджайл очень выгоден именно своей «безответственностью».

Я видел в 90ые, как вчерашние отделы АСУ оставшись без работы, ибо их заводы стали, пытались стать продуктовыми компаниями. Работая — так же, по тем же принципам. Подавляющее большинство постиг провал. Не из-за отсутствия денег. Оказывается создавать ПО они не умеют, хотя — отличные, опытные программисты. А создавать не умеют — потому что процессы то не те.

Не думайте что идеи Скрам это нечто новое :)

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

Рабочие процессы предназначенные для эксплуатации конвейера, НЕ годятся для — создания этого конвейера.

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

Почитал. Да, в целом, подходом к рассуждению об Agile там согласен.

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

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

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

В теории проект растет от «простого к сложному». Т.е. сначала делаем «а лоб», а потом на следующем спринте рефачим, вводим абстракции и т.д.
На практике я видел 2 варианта:
1. Вначале толковыми людьми (в идеале архитектом) проектируется некоторый архитектурный «каркас» (например DDD Onion Model). Задаются правила его «роста». Потом команда наполняет его реализацией а ответственный за архитектуру следит что бы не накосячили. Если возникает проблема — тогда приходится менять архитектуру и много рефакторить.
2. Код пишется сразу «на коленке». Рефакторить потом некогда, поэтому получается как уже написали:

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

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

ниже уже написал правда,

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

Этому отделу отдадут под ключ новый продукт — и начнется очередной цикл — латаем, дописываем, ...,

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

В теории проект растет от «простого к сложному»

Правильно. Я так и слышал, что — эволюционно.

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

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

требование на количество фич, заплаток в квартал — тоже обычно отсутствует, а «по степени давления пара из ушей пользовательских начальников»

Вот там и Скрам приживется, или такое же подобное. да хоть ЛУРВы 1Совские, в которых и план, и подпись конкретного представителя заказчика, в которых фичи, их сумма, их приоритет, срок, и — обсуждение, до хрипоты, между начальниками пользователя перед лицом плательщика «Нам это важней!» «Нет, всему предприятию нужна именно эта фича, что у нас!». В которых и место для даты и подписи по приемке фичи заказчиков. И этот ЛУРВ(лист учета рабочего времени — термин франчей) — как основание счета для оплаты.

1. ... то есть, как понимаю уже не чистый

Ага, такой себе «нечистый», демонический Скрам.
Но «чистый» Скрам это как святой человек без грехов. Существует только в писании.

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

Ага, такой себе «нечистый», демонический Скрам.

Так дело ж в том что апологеты Скрам постоянно каких-то чистых, демонических планерщиков приводят :)

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

И тогда Скрам не нужен, утрировано говоря.
Или — масло маслянное :)
Потому что все равно будет — бюрократия, распределение и делегирование ответственностей, планирование ресурсов и сроков.
Будут и порки на ковре, штрафы и премии, поиски козла отпущения, и раздача орденов непричастным.

Еще и до диаграмм Ганта дойдет, с «все этапы разработки» :)

И где Скрам..., что такое Скрам... когда «все этапы жизни проекта»....

Если нечто (инструмент, распорядок дня, способ действия или мышления, ..., ..., ; далее в тексте Н) приводит к успеху редких субъектов, то это означает что причина успеха либо в свойствах самих этих редких, либо в редкости ситуации, когда это Н оказалось самым адекватным.
Причем, в первом случае — сами эти субъекты могут и не осознавать, что Н просто формализация их редкости, а во втором — уникальности ситуации.

(«стань миллиардером, я же стал, делая вот так и так», «у них нет хлеба, так пусть едят пирожные», ...)

Кажущиеся или действительные простота или сложность Н — не имеют никакого значения("не умеют готовить«, «винить Н глупо», «это уже не Н, не чистый, не настоящий Н») для оценки качества Н. Редкость успеха при применении Н может еще и быть показателем фундаментального изъяна. Если пытаться выявить эти изъяны Н, то нужно исходить не из успехов применения, а искать причины провалов.
(«Коммунизм — прекрасная идея, просто людей для него нет. Даже сами его творцы, как-то не очень тянули на образ нового, коммунистического человека, с их склочностью, мелочностью и просто обывательством»
«Раздельное питание — замечательная диета, только через годик запросто отравишься кусочком обычной еды»

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

Простота Н подкупает как в анекдоте:
— Что ищешь тут, под фонарем.
— Да ключи, там, в темноте потерял, но тут светлее.

Н — замечателен тем что мы будем искать под фонарем!

Сложность Н подкупает исключительностью, «гуровщиною»:
Ну раз так сложно, значит точно это Особое Тайное Н для Избранных! А кто не хочет быть избранным? Кому нравится быть сереньким, как все?

«Если ты делал как раньше, то почему делая и сейчас так, надеешься на другой результат? Используй Н, он сооовсем ни на что не похож, вот потому и сложный!»

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

Руководству головного офиса срочно пришлось вводить суровую бюрократию. А через годик, попустить малость, когда наладилось.

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

Был как-то на сводном семинаре, где получился очень замечательный диспут, между «евангелистами», почему то сплошь юными, и среднего и чуть выше менеджерского звена из вполне известных компаний. Вторые вначале просто фыркали, а потом лениво начали задавать вопросы... Конкретные, «а вот как в такой ситуации?» «А в такой?»

Весь текст — ну просто рахат-лукум! :)

Вот dou.ua/...ums/topic/6139 альтернатива скраму или как?

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

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

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

Вот так и получаются что из-за ошибки в ПО банковская сеть лежит по два дня.

Продакт оунер скажет «мне, б_лядь, на завтра нужна эта большая красная кнопка, ты понял?»

Да, понял, скажет скрам мастер и отменит несколько фич, на которые эта кнопка влияет. В конце итерации овнер спросит: а где фичи — то, мегаважные и главные?
Не успели, скажет скрам мастер — делали красную кнопку, ты ж сам просил.

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

Какие претензии к скрам мастеру? А никаких! Он сделал ровно то, что попросили предупредив о последствиях.

Какие претензии к скрам мастеру? А никаких! Он сделал ровно то, что попросили предупредив о последствиях.

Вот именно! Никаких претензий. Ни к скрам-мастеру, ни к продакт-оунеру. Но десяток-другой таких спринтов и продукт гарантированно превратится в говно. Зато все участники процесса в шоколаде. Поэтому я и называю Скрам en.wikipedia.org/.../Cover_your_ass практикой.

Да, понял, скажет скрам мастер и отменит несколько фич, на которые эта кнопка влияет.

Не может без ведома продукт овнера.

Да что тут делать, б_лядь, скажет овнер.

Или может сказать такое: Неипет!

Ваши аргументы? (даю наводку, ответ будет «Неипет!»)

Все просто. Если представитель бизнеса адекватный, то не нужен не какой скрам. Если нет, то у него есть непробиваемый аргумент «Надо! И неипет.»

если вам продакт овнер говорит такое — то это уже не скрам.

Господа, вы чо, сговорились срачи разводить?

Господа, вы чо, сговорились срачи разводить?

У вас есть идея лучше?

эээ... Не разводить?
\\Ваш К.О.

Не разводить?

Я не альтернативный спрашивал, а лучше. Чем отсутствие срача лучше чем срач? Срач это по крайней мере весело.

Ну все...теперь вас растерзают служители культа. P.S.: Каждый раз, когда что-то слышу про скрам, вспоминаю демотиватор с подписью: «скрам мастер оптимизирует орбиту Земли за деньги заказчика»

вся эта песня напоминает бородатый анекдот.

«Вот все говорят: „Карузо! Карузо!“ А я послушал — так ничего особенного» — «Вы слышали Карузо?!» — «Нет. Мне Рабинович напел»

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

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

Плохо — это Скрам-фундаментализм и Скрам-фэнбои.

Когда эти два явления соединяются, получаем быстро растущий слой бестолковой IT-номенклатуры.

И это объективная реальность, как бы мы не оценивали содержательную часть Скрама.

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

Я думаю, что автор просто не умеет его (Scrum) готовить. Сам работаю по скраму с 2010 года. Впечатления крайне положительные. Тут вам и прозрачность, и разумный уровень контроля и командная работа и мотивация. Да в чистом виде, полагаю, скрам мало где применяется, но если правильно использовать основные моменты методологии то все будет ок. Насчет неадекватных заказчиков, ну тут можно на любой методологии подорваться если работать с неадекватами и не лобировать свои интересы.

Я думаю, что автор просто не умеет его (Scrum) готовить.

Из моего уютного мира видно что «его не умеют готовить» 99.999% людей.

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

Было бы хорошо, если бы между применением скрама (конкретных техник, а не вообще) и успехом дела была какая-то корреляция.

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

не более и не менее, чем ваше.

вы где-то в моем сообщении увидели мнение?

ну если вы такой упертый — то в вашем мнении одни тезисы

это ложь. В моём коменте одно мнение и несколько вопросов. Причем мнение очень второстепенно по отношению к вопросам.

Вполне естественная реакция на практику навязывание «аджайла» руководством. В этом весь парадокс внедрения «аджайла» в нашем ИТ. Изначально идея аджайла — освободить команды профессионалов от формализма и рутины и дать им возможность работать в свое удовольствие. Девелопмент становится как бы командной игрой — отсюда фан, мотивация и повышение производительности. И Скрам — всего лишь один из множества возможных вариантов правил такой «игры», а не номенклатурная «инструкция по разработке».
Но вот как это видит менеджмент: Мы написали спеку, заэстимейтили проект на полтора года, набрали команду ньюбов и они не успевают даже формошлепать. Клиент недоволен. Но есть волшебный модный «аджайл», где не нужно спеки, эстимейтов и при этом девелоперы работают быстро и хорошо. Поэтому надо всем срочно внедрить какой-нибудь аджайл (например Скрам). Позовем самого голосистого «мастера» и пусть он всех научит правильно работать.

В результате как раз и получается то, что описано. Но винить в этом Скрам глупо.

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

командной игрой

то что хорошо для 23 летних синиоров не означает что хорошо для всех.

мне лично кажется что в детский сад попал и мотивация пропадает...

Навеяло. «- Товарищи женщины!.. — вдруг вдохновенно заорал он. — Революция освободила вас. Вы должны навсегда забыть свое проклятое прошлое — как в семейной жизни, так и в труде. У вас нет теперь хозяина. И называйте меня просто товарищ Сухов. Вы будете свободно трудиться, и у каждой будет собственный супруг.»

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

Так же и здесь. Когда айти стала в ряд отраслей с массовым производством, встала проблема, чтобы любой дятел, выбившийся в бригадиры, не чувствовал себя некомфортно. «Вот тут и начинают появляться служители святого свитка. Те, кто отдает свои жизни, чтобы защитить некий образ мыслей, становятся служителями этого образа.» © :)

часть процесса по созданию IT-номенклатуры.

Дык она уже создана. Скорее по цементированию её пьедестала.

Уважаемый автор, а вы сами работали по Скраму?

Нет, автор видимо работал по Сраму

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

1. В большинстве случаев авторитарный характер принятия решений сохраняется.

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

2. Скрам помогает избавиться от овертайма.

Когда задания лежат не в одной огромной куче, а порционно разделены, каждому отдельному человеку намного легче планировать свое время. Еще очень помогают организоваться ежедневные митинги — у человека в голове появляется план на день — что он должен успеть сделать. А еще очень приятно видеть финишную прямую — что через 2 недели мы закончим спринт и будет маленький праздник. Это очень мотивирует.

3. Кросс-функциональных команд практически не бывает.

Ну или бывает в оочень маленьких командах на 2-3 девелопера. Как только количество людей увеличивается, кросс-функциональность пропадает.

4. Если просрали, то скрамом не оправдаешься.

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

Это все мои личные наблюдения. Может быть где-то есть кросс-функциональная команда из 8 человек, которая делает все в срок и принимает все решения по спринту сама. Просто я ее не видела.

Возможно имеет смысл не работать с таким начальником.

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

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

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

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

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

Навіть, якщо той, від кого чули — Alistair Cockburn?

особенно если от него ;)

Скрам — это всего лишь одна из разновидностей гибкой методологии разработки.

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

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

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

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

а я видел самолет без крыльев, а еще он по воде плавал и вообще назывался кораблем, а не самолетом

обсудим это на ретроспективе

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

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

рекомендации надо соблюдать только если они действительно помогают в работе, а не тупо

чтобы работать по скраму

иначе это не скрам

если работа выполняется в полном объеме и вовремя то кого это волнует?

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

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

10 заповедей тоже выглядят оптимально,

но крестовые походы, инквизиция и РПЦ сильно портят пейзаж.

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

Я когда книжку Бека прочел, то почему-то возник такой образ заказчика для ХРкоманды

Какому-то научному коллективу, или НИОКР отделу корпорации требуется хитровывернуто-специализированное ПО, или интеграция CADов с бухглатерией, плюс B2B подсистемой КИС.
То есть — и проект, ох не прост технически, «ни на что не похожий», а потому спланировать точненько функционал и сроки — поди попробуй. И персонал — адекватный, на треть из PhD или около, и очень, кровно заинтересован в успехе.

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

возможно вы имели ввиду ScrumBut ? ;))
да и вообще Scrum не является такой себе «серебряной пулей», есть случаи когда эта методология вообще не применима
Знаю много случаев, когда «игра в скрам» превращается в культ карго
ru.wikipedia.org/wiki/Культ_карго

Вот тут еще обсуждается подобная проблема:

dou.ua/...niya-proektami

Да, Юра хорошо написал. Смешно про «Management 2.0» и «Motivation 3.0». :-)

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

Скрам повышает эффективность хороших команд, как он влияет на плохие команды я затрудняюсь представить

А я в предыдущем скрамосраче задавал вопрос Посвящённым: чем он может помочь не то, чтобы плохой, но команде без опыта, преимущественно из новичков.
Ответ был примерно «проблемы новичков умудрённых скрамистов не волнуют».
Вчера смотрел Динамо-Боруссию. И в который раз вспоминал Динамо образца 1997-1999 годов. Когда пришёл Тренер и за год из тех, кто был под рукой, безо всяких закупок на пяти континентах, сделал команду, которой аплодировал вщент заполненый Ноу Камп. Вот у него была — Методика. У нынешнего тренера методики нет, но у него есть боль-мень квалифицированные игроки, собираемые не первый год, поэтому время от времени они у кого-то выигрывают. Не исключено, что именно тогда, когда играют вопреки установкам своего тренера.

Так оно де-то и со скрамом.

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

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

«мотивированные» новички могут и сами организоватся без всяких тренеров.

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

навіть не знаю що заперечити, тому що в моїй команді скрам працює дуже добре

Как бы эта методолгия подразумевает self-organized команду с достаточным уровнем мотивации и направлена на получение быстрого feedback. Если нету ни мотивации, ни желания, ни возможности решать проблемы повлекшие за собой провал итерации, то никакая методология не поможет.

Золотые слова, Юрий Венедиктович ©

Получается какой-то «суп с топором» с этим Скрамом. И хорошая команда нужна, и мотивация. Так в том-то и дело, что с хорошей командой и мотивацией никакой Скрам не нужен, а Скрам проявляет себя именно как карго-культ.

перечислю пункты, которые мне импонируют:
— быстрый feedback и частые релизы
— fixed scope во время итерации
— не сильно углубляться в детализацию фич, при долгосрочном планировании

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

Очень часто неудачи и негативные отзывы относятся не к Scrum, а к ScrumBut itknowledgeexchange.techtarget.com/...-or-a-bad-thing

без скрама многое может завязатся узлом на менеджменте/заказчиках.

Если я скажу, что ЛЮБАЯ методология подразумевает самоорганизованность и мотивированность команды, а при их отсутствии НИКАКАЯ не поможет, я сильно ошибусь?

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

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

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

Конкретно у нас кое-как довели до ума локальный скрам, а потом разогнали часть разработчиков и добавили еще несколько команд в других странах. По-моему, у нас сейчас всё это не очень хорошо работает.

Consumer Health Тechnologies?

ваша краткость вас подвела — я не понял вопроса

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

Однако её ошибочность лишний раз показывает, что она не одинока в таком грустном развитии событий ))

А что вы думаете про Срам?

Как-то так: poiskslov.com/word/срам

По сути, у нас на одном из проектов переход на Scrum дал примерно +200% к деливери не смотря на уменьшение команды. И примерно столько же к мотивации.

Так что вы со своими «поливаниями» можете изощряться сколько угодно.

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

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

вы бы уже для полноты картины привели еще пример как этот самый Scrum/Срам (не без помощи Project Office) недавно чуть не завалил целый проект в циклуме ((

Может подскажете что это был за проект?

По сути, у нас на одном из проектов переход на Scrum дал примерно +200% к деливери не смотря на уменьшение команды. И примерно столько же к мотивации.

У любой религии есть свои «саксесс сториз». Например, про 5000 человек, накормленных 5-ю хлебами и 2-я рыбинами. А 200% прирост (в стори пойнтах, хе-хе?) может объясняться хотя бы даже уменьшением команды. Часто это позволяет перейти от политике к разработке. И, уверен, методология тут не причем.

По сути, у нас на одном из проектов переход на Scrum дал примерно +200% к деливери не смотря на уменьшение команды. И примерно столько же к мотивации.

или же:
— после n-го количества времени до заказщика дошло чего ему таки нада, и все вздохнули легче.
— меньше людей — лучше взаимодействие между оставшимися. Например не надо думать чем кого озадачить. Бывает время когда можно найти задачи для сотни людей, бывает что и десять — это очень очень много.
— обратный вариант: меньше людей => больше нагрузки на каждого, при подходящем составе можно повернуть в «нас мало, но мы прорвемся», плюс модное слово Scrum, как панацея для всего, и вот уже горят глаза и все рвутся в бой.

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

я думаю это из оперы бытие определяет сознание или сознание бытие?

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

Достоверно известно, что сознание одних определяет бытие других ;-)

Вы правы, только вот 98% людей все же упорно исходят от обратного.

да, это был риторический вопрос с намёком :) СРАМ — это бытие. СКРАМ — сознание :) или «заставь дурака богу молиться — лоб себе расшибёт».

И вообще, Эджайл это не столько про АйТи, сколько про HR в Айти. Как по мне успешное внедрение Аджайл методик на 50% упирается в софт-скилз, и только на 50% в хард-скилз. Часто первое напрочь игнорируется и лежит за пределами сознания. А относительно хард-скилз — про ньюбов и говнокодеров здесь уже написали немало.

Підписатись на коментарі