Рецензии на книги

Рецензии на книги | Книга про Scrum - отзыв

Книга про Scrum - отзыв
Я не люблю такие книги. Много баек-прибауток, много самопиара, мало по сути дела.
Мало подчеркиваний полезных моментов на страницах книги.

Чел якобы придумал методику управления проектами. Придумал ей название — Scrum.
И обещает чудо — применение скрама позволит повысить производительность на 200-400%.
Причем сам он является основателем консалтинговой компании, которая как раз продает услуги по оптимизации бизнеса.
Ну а книга раскрывает не метод, а продает услуги этой компании.

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

Что я понял, так это то, что я и так все в смартлабе делал по скраму:)
Так что книга и сам метод наверное больше актуальны для мегамонстров, которые тратят кучу бабок и времени на разработку всякого дорогущего софтового барахла. В госструктуры типа Сбер, РЖД, Почта такое точно надо внедрять!

В чем суть скрама?

1. Не ставишь долгую мегазадачу. Ставишь задачу так, чтобы уже через 2-3 недели был результат, который можно пощупать и которым можно пользоваться. В 20% готовности уже может быть 80% функциональной полезности.

2. Делишь задачу на части, каждую часть поручаешь командам по 7±2 человека. Больше 9 никак нельзя, эффективность группы начинает резко падать.

3. Кайдзен. Постоянное самосовершенствование, непрерывное улучшение… через PDCA цикл. Взято у Toyota.

4. Для того, чтобы PDCA работал, короткие этапы разработки делятся на интервалы 2-3 недели, которые автор назвал спринты. В конце спринта каждый член команды должен отчитаться, что сделано, что не сделано и что мешает. Ну и каждый день тоже надо устраивать летучки, чтобы в течение 15 минут команда обсудила продвижение.

5. Фокус важен. Нельзя делать задачи параллельно. Только последовательно. иначе резко снижается производительность.

Еще идеи.
1. Скрам доска. Я уже кстати такую использую и так, до прочтения книжки. Юзаю trello.com
2. Замер индекса счастья сотрудников. Именно этот показатель был главным опережающим индикатором будущего положения компании. стр.171
3. Принцип полной открытости 
4. Нашел ошибку или брак при производстве? Надо устранять сразу же. Если отложить на неделю, затраты на устранение могут вырасти в 10 раз.

Ставлю 4 из 5. на 5 точно не тянет.
Для меня пользы балла на 3 максимум.
Ставлю 4, потому что всяким Ростелекомам, Россетям, Мосбирже такое просто обязательно надо читать
Хотя и мне было полезно лишний раз в своей голове все эти принципы прогнать

★9
Так Мосбиржа давно уже в ИТ-части работает по Скраму. 
Radovid the Stern, ну я ж не знал))
Книги по всему этому делу достаточно мутные — это точно подмечено. Схема простая и объясняется на пальцах руки фрезеровщика, а они любят её раздувать, целые семинары устраивать, конференции собирать :)
avatar

Dmitryy

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

meat

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

Radovid the Stern, скрам сложнее и плодит кучу ненужных сущностней, для небольших проектов лучше канбан
avatar

meat

Многие IT компании работают по SCRUM. 
avatar

Value

avatar

astray

эджайл нужно посмотреть. 
avatar

Григорий

Григорий, это абсолютно то же самое говно :-)
avatar

Vlad

Vlad, старый-добрый PMBOK?
avatar

Григорий

 Будь-то это аджайл, скрам, канбан, xp, водопад, или ещё какая-то херня, с точки срезния сотрудников это всё одна херня: у задачи есть два статуса, «новая», «в работе», и «завершена» на что сотруднику уже пох.
Скрам это тупо летучки утром по 5 минут где каждый день пересказываешь текст задачи.
Суть скрама в не загрузке сотрудников на 100%, спринт должен быть загружен процентов на 80% чтобы оставшиеся 20% были на исправление, обсуждение, в общем та самая гибкость (от английского agile).
Также если сотрудник сделал все задачи в рамках спринта, но не надо ему давать другие т.к. теряется мотивация делать быстро и будет не качественно.
Но как всегда русский скрам испохаблен. В итоге как всегда получается всё через жопу: не гибкое, с переработками, с некачественным кодом, со стрессом сотрудников, с дебилом начальником, со срывом сроков и т.п.
avatar

Vlad

Vlad, а на западе работает на ура?
avatar

Григорий

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

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

Vlad

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

Проще один раз нормально сделать, чем хуяк-хуяк и потом сидеть ночами переделывать забесплатно. Не работает так сейчас. Если не говорить про студию из 5 человек, которые шлёпают одинаковые сайты-визитки.
avatar

Stan Sokolov

Stan Sokolov, проще один раз нормально сделать, только пока вы это делать будуте нормально, 1) вас уволят за тормознутость, 2) компания недополучит прибыль которую получила бы с хуёвой фичи но уже в проде (та самая бизнес-ориентированность которая отличает сеньоров от джунов) и та самая гибкость (тот самый аджайл про который вы говорите).
avatar

Vlad

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

Stan Sokolov

Stan Sokolov, я по аджайлу/канбану/скраму 10 лет работаю. Начальству глубоко похуй что вы там решили, сколько задач выделили, какие задачи придумали и т.п. Выделили вы 10 задач на спринт, а потом прибигает начальство и говорит вот срочно надо ещё 20 задач до завтра сделать и хрен что вы скажете что это не по скраму и т.п. Будет ответ: не сделаешь — увольняйся. Похоже что вы просто джун ещё, мало где поработали. :-)
avatar

Vlad

Vlad, зачем работать в такой компании по «псевдо эджайлу\скраму» и жаловаться, ничего более адекватного нет?

Джуном мануального QA я был в 2011 году. Прошёл путь до тимлида автоматизатора за 3 года. Затем свичнулся в BA. Сейчас Product Owner.

Мне ни разу не говорили не сделаешь — увольняйся. Сейчас у меня в команде процесс очень близкий к «книжному».

Задачи готовятся, грумятся и оцениваются за месяц-два до разработки. Если команда по капасити не может взять задачу сверху — она её не берёт, руководство адекватное, многие процессы внутри команды мы строим сами как нам удобно и они отличаются от команды к команде.
avatar

Stan Sokolov

Stan Sokolov, 

зачем работать в такой компании по «псевдо эджайлу\скраму» и жаловаться, ничего более адекватного нет?

Зачем — чтобы было на что поесть купить. Я не говорю что вообще более адекватного нет. В регионах действительно ничего нет, пара веб-студий на город с заказной разработкой.

Джуном мануального QA я был в 2011 году. Прошёл путь до тимлида автоматизатора за 3 года. Затем свичнулся в BA. Сейчас Product Owner.

Стандартная практика когда вешают лычки вместо повышения зарплаты. 22-летние тимлиды млин.

Мне ни разу не говорили не сделаешь — увольняйся. Сейчас у меня в команде процесс очень близкий к «книжному».

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

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

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

Vlad

Vlad, 
Стандартная практика когда вешают лычки вместо повышения зарплаты. 22-летние тимлиды млин.

Смотря как работать. Я когда начинал сидел в офисе до 11-12 ночи и выходил по субботам. Учился и прокачивал знания. Первым кто начал вводить автоматизацию тестирования и распространял это на всю компанию. Разбирался и настраивал CI. Выступал на внутренних семинарах и затем на местных IT конфах. Повышения ЗП я ни разу не просил сам. Меня сами продвигали вверх и повышали постепенно ЗП.

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

Студент за 10к не сделает того что сделаю я. И в общем то, что написано тут упирается в адекватность руководства и возможность работников доносить и аргументировать своё мнение. То же касается и клиентов, мне приходилось доносить мнение и объяснять зачем нужен рефакторинг и выбивать на это несколько недель каждые 4-6 месяцев.

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

Большую часть жизни я проработал в компании аутсорсере на стартапах и тому подобном. И там тоже были команды (отделы), 4-5 шт.

Я в общем понимаю о чём вы. Я жил в городе 160 тыс населения, были другие компании где была полная задница в плане подходов и процессов. Я попал изначально в хорошую компанию и развивался вместе с ней. Эти процессы не появляются одномоментно, их строят. Сейчас я переехал в Киев, т.к пару лет как уже достиг потолка в моей первой компании и мне стало не интересно. У меня от этого выгорание, а не от переработок, если они редко и по серьёзным причинам.
avatar

Stan Sokolov

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

Stan Sokolov

SCRUM методика
avatar

Павел

Ого, я это 10 лет назад проходил…
avatar

InvisibleInvestor

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

bwc

Сбер довольно давно так работает. Как обычно, в реальной жизни все не так гладко, как в книге…
Спасибо за рецензию, теперь не надо читать, а то куда не глянь везде требуется знание этого scrum.
avatar

ANTI_Finsov


....все тэги
2010-2020
UPDONW