Книга про 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, потому что всяким Ростелекомам, Россетям, Мосбирже такое просто обязательно надо читать!
Хотя и мне было полезно лишний раз в своей голове все эти принципы прогнать
а почему имено скрам? его не выгодно внедрять если размер компании маленький, это больше корпоративная история для компаний типа Северсталь или Сбербанк
для маленьких компаний скрам будет дорого обходиться
https://ru.wikipedia.org/wiki/%D0%9A%D0%B0%D0%BD%D0%B1%D0%B0%D0%BD_(%D1%80%D0%B0%D0%B7%D1%80%D0%B0%D0%B1%D0%BE%D1%82%D0%BA%D0%B0)
https://habr.com/ru/company/hygger/blog/351048/
Скрам это тупо летучки утром по 5 минут где каждый день пересказываешь текст задачи.
Суть скрама в не загрузке сотрудников на 100%, спринт должен быть загружен процентов на 80% чтобы оставшиеся 20% были на исправление, обсуждение, в общем та самая гибкость (от английского agile).
Также если сотрудник сделал все задачи в рамках спринта, но не надо ему давать другие т.к. теряется мотивация делать быстро и будет не качественно.
Но как всегда русский скрам испохаблен. В итоге как всегда получается всё через жопу: не гибкое, с переработками, с некачественным кодом, со стрессом сотрудников, с дебилом начальником, со срывом сроков и т.п.
В конторах работающих под заказ это не катит т.к. там чем быстрее закрываешь задачу, тем больше маржа (надо сотрудникам меньше платить). В итоге весь этот скрам летит нахрен.
Один из основных моментов скрама — самодостаточность команды плюс саморегуляция. Команда решает сколько задач на итерацию (обычно около 2 недель) и на весь релиз (обычно месяц-полтора) она может взять. До этого команда сама оценивает трудозатраты на каждую задачу.
От этого пляшет планирование по каждой команде и в целом по компании.
Проще один раз нормально сделать, чем хуяк-хуяк и потом сидеть ночами переделывать забесплатно. Не работает так сейчас. Если не говорить про студию из 5 человек, которые шлёпают одинаковые сайты-визитки.
Джуном мануального QA я был в 2011 году. Прошёл путь до тимлида автоматизатора за 3 года. Затем свичнулся в BA. Сейчас Product Owner.
Мне ни разу не говорили не сделаешь — увольняйся. Сейчас у меня в команде процесс очень близкий к «книжному».
Задачи готовятся, грумятся и оцениваются за месяц-два до разработки. Если команда по капасити не может взять задачу сверху — она её не берёт, руководство адекватное, многие процессы внутри команды мы строим сами как нам удобно и они отличаются от команды к команде.
Зачем — чтобы было на что поесть купить. Я не говорю что вообще более адекватного нет. В регионах действительно ничего нет, пара веб-студий на город с заказной разработкой.
Стандартная практика когда вешают лычки вместо повышения зарплаты. 22-летние тимлиды млин.
Ну значит у вас всё впереди. Это не всегда так прямо. Выделяемое время на задачи сжимается. Например выделяют 30 минут, когда эту задачу надо делать весь день. Просят сделать клон фейсбука за день. Потом говорят что ты не справляешься, фиг тебе а не повышения зарплаты, а потом нанимают студентов за еду за 10к в месяц а тебя просят свалить по собственному. Или начинаются переработки, потом люди выгорают и сваливают. Или хотят чтобы вы впахивали за 10 человек.
Ну я ж говорю что это и работает в больших продуктовых компаниях где много бабла. Судя по тому что у вас много команд — ваша как раз такая.
Смотря как работать. Я когда начинал сидел в офисе до 11-12 ночи и выходил по субботам. Учился и прокачивал знания. Первым кто начал вводить автоматизацию тестирования и распространял это на всю компанию. Разбирался и настраивал CI. Выступал на внутренних семинарах и затем на местных IT конфах. Повышения ЗП я ни разу не просил сам. Меня сами продвигали вверх и повышали постепенно ЗП.
Студент за 10к не сделает того что сделаю я. И в общем то, что написано тут упирается в адекватность руководства и возможность работников доносить и аргументировать своё мнение. То же касается и клиентов, мне приходилось доносить мнение и объяснять зачем нужен рефакторинг и выбивать на это несколько недель каждые 4-6 месяцев.
Большую часть жизни я проработал в компании аутсорсере на стартапах и тому подобном. И там тоже были команды (отделы), 4-5 шт.
Я в общем понимаю о чём вы. Я жил в городе 160 тыс населения, были другие компании где была полная задница в плане подходов и процессов. Я попал изначально в хорошую компанию и развивался вместе с ней. Эти процессы не появляются одномоментно, их строят. Сейчас я переехал в Киев, т.к пару лет как уже достиг потолка в моей первой компании и мне стало не интересно. У меня от этого выгорание, а не от переработок, если они редко и по серьёзным причинам.
но тут как бы требуется усилие со стороны руководства (командой, проектом,… тысячи их): постановка самостоятельных, согласованных и проверяемых подзадач. любимый метод чайки не подходит.