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

Рецензии на книги | Книга про 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
29 комментариев
Так Мосбиржа давно уже в ИТ-части работает по Скраму. 
Radovid the Stern, ну я ж не знал))
Книги по всему этому делу достаточно мутные — это точно подмечено. Схема простая и объясняется на пальцах руки фрезеровщика, а они любят её раздувать, целые семинары устраивать, конференции собирать :)
avatar
в трелло же канбан-доска, которую еще в тойоте придумали в середине прошлого века
а почему имено скрам? его не выгодно внедрять если размер компании маленький, это больше корпоративная история для компаний типа Северсталь или Сбербанк
для маленьких компаний скрам будет дорого обходиться
avatar
meat, Спорно, скрам отлично работает на небольших проектах, а масштабируется плохо, приходится изобретать новые фреймворки. 

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

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

Проще один раз нормально сделать, чем хуяк-хуяк и потом сидеть ночами переделывать забесплатно. Не работает так сейчас. Если не говорить про студию из 5 человек, которые шлёпают одинаковые сайты-визитки.
avatar
Stan Sokolov, проще один раз нормально сделать, только пока вы это делать будуте нормально, 1) вас уволят за тормознутость, 2) компания недополучит прибыль которую получила бы с хуёвой фичи но уже в проде (та самая бизнес-ориентированность которая отличает сеньоров от джунов) и та самая гибкость (тот самый аджайл про который вы говорите).
avatar
Vlad, судя по вашему комментарию вы никогда не работали по скраму\эджайлу. То что вы описали это просто хрень которую назвали красивым модным словом, чтобы продать дороже клиенту.
avatar
Stan Sokolov, я по аджайлу/канбану/скраму 10 лет работаю. Начальству глубоко похуй что вы там решили, сколько задач выделили, какие задачи придумали и т.п. Выделили вы 10 задач на спринт, а потом прибигает начальство и говорит вот срочно надо ещё 20 задач до завтра сделать и хрен что вы скажете что это не по скраму и т.п. Будет ответ: не сделаешь — увольняйся. Похоже что вы просто джун ещё, мало где поработали. :-)
avatar
Vlad, зачем работать в такой компании по «псевдо эджайлу\скраму» и жаловаться, ничего более адекватного нет?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Я в общем понимаю о чём вы. Я жил в городе 160 тыс населения, были другие компании где была полная задница в плане подходов и процессов. Я попал изначально в хорошую компанию и развивался вместе с ней. Эти процессы не появляются одномоментно, их строят. Сейчас я переехал в Киев, т.к пару лет как уже достиг потолка в моей первой компании и мне стало не интересно. У меня от этого выгорание, а не от переработок, если они редко и по серьёзным причинам.
avatar
 Тимофей, ты не отметил ещё один важный принцип — саморегуляция и самоулучшение команды. В конце итерации (каждые 2 недели) команда обсуждает что было так, что не так и что можно попробовать в работе изменить. И что из того что изменили стоит оставить, а что отбросить. Плюс можно смотреть метрики от уровня удовлеьворения команды, до объёма сделанной работы. Идея в том что команда сама себя развивает. Сама себе планирует работу (в основном) и сама отвечает за косяки.
avatar
SCRUM методика
avatar
Ого, я это 10 лет назад проходил…
avatar
суть — это тотальное сокращение интервала между получением результата и его проверкой.
но тут как бы требуется усилие со стороны руководства (командой, проектом,… тысячи их): постановка самостоятельных, согласованных и проверяемых подзадач. любимый метод чайки не подходит.
avatar
Сбер довольно давно так работает. Как обычно, в реальной жизни все не так гладко, как в книге…
Спасибо за рецензию, теперь не надо читать, а то куда не глянь везде требуется знание этого scrum.
avatar

теги блога Тимофей Мартынов

....все тэги



UPDONW