Первым делом, чтобы не забывать, пишу о том, что проект Партии Позитивных Пессимистов о покидающих Украину развивается полным ходом. Свои мнения и истории оставили уже много людей и эти истории активно публикуются. Может быть одна из этих историй станет последней каплей и для вас?
Кстати, моя история там тоже уже есть.
Ну и теперь, возвращаемся к Scrum’у.
1) Один из тезисов Scrum’а состоит в том, что все что нужно — это дать команде самоорганизовать и она станет максимально эффективной. Вот скажите мне, если нанять 10 забулдыг, которые компьютер в жизни не видели, будет ли какой-то эффект от их самоорганизации? Ok, а если дать возможность 10 junior’ам самоорганизоваться, то станут ли они от этого вдруг производить высококачественный код и хорошо разбираться в архитектуре?
Так, вот, то что быстро всплыло в комментариях к прошлой статье — это то, что SCRUM должен хорошо работать на идеальных людях. Да, если есть команда отличных профессионалов, с хорошим опытом, умных, добрых и честных и единственное, что им не давало работать гнетущий их подлец и мерзавец менеджер, то действительно, убрав менеджера и дав им самим организоваться вдруг станет все лучше. А с другой стороны, если они все такие добрые и умные, то думаю и большинство других методологий покажет себя неплохо.
То есть, возникает вопрос. Какова должна быть команда, чтобы эффективность от самоорганизации хорошо прыгнула вперед. Где собственно описание того, на какой команде наиболее эффективно работает SCRUM, вопрос того, как нанять такую команду или что делать с текущей командой, для того, чтобы сделать из нее такую, на которой все будет хорошо работать? Об всем это Scrum скромно молчит.
2) Продолжаю тему команды. Все члены команды считаются team member’ами. Разделения между Dev и QA не проводится. Как вы понимаете, это происходит только на бумаге. QA не может эффективно делать Dev работу, а Dev не может эффективно делать QA работу. Почему мне не слишком нравиться эту ситуация, когда на бумаге одно, а в реальности другое? В такой ситуации значит, что хотели сказать что-то другое, но говорить напрямую было бы неприлично и поэтому мысль замаскировали. Так вот, мысль которую я хотели сказать (да и в сказали таки в многих местах), что Dev + QA __коллективно__ ответственны за проект и не имеют право валить на кого-то другого вину за неправильное или плохое исполнение.
Честно говоря, я не супер большой любитель коллективной ответственности. Опять же, это продолжение пункта N1. Коллективная ответственность хорошо работает на умных, добрых и ответственных людях и она может дать ооочень
плохие результаты (гораздо хуже чем при waterfall management’е) при безответственных и злонамеренных людях.
3) В прошлой статье я написал пример о том, что проект который уже ведется тяжело переводить на Scrum. Я с него и продолжу.
Итак ситуация такова, есть продукт с плохим (или средним) кодом, у этого продукта нету никаких тестов (ни unit, ни ui и ничего другого). А также этот продукт уже активно используют заказчики достаточно часто находя в нем баги (скажем несколько за неделю). Эти баги менеджеры очень хотят пофиксить быстрее, так как заказчики капризные и могут и нафиг послать. Ситуация естественно типична не для все фирм, но для множества продуктовых фирм.
Тут есть две проблемы — одна как работать с багами (которую я опишу тут) и вторая, как выпускать новые версии, которую я опишу в следующем пункте.
С багами можно работать тремя методами
а) Мы таки их по ходу включаем в Sprint. Обычно это учитывают с помощью focus factor (мы называли overhead). В целом работать может неплохо, если багов немного. Как только багов становится много (например команда тратит 30-60% от каждого sprint’а на них), то начинаются проблемы с тем, что sprint’ы становятся слишком непредсказуемы.
б) Можно команду разделить на Scrum — те, кто работают над новым и на support (которые будут работать по какой-то другой методике).
в) Можно таки попытаться откладывать баги на потом и планировать их по честному в следующий Sprint. Сразу скажу, что менеджмент и customer support будет против.
Тут в целом ничего военного, но тем не менее, в классическом описании Scrum’а — об этой проблеме не написано.
4) Когда команда работает над проектом с плохим кодом и без автоматизации тестирования, очень остро становится вопрос, как же сделать так, чтобы в конце Sprint’а можно было отдать заказчикам продукт. Проблема заключается в том, что для того чтобы отдать продукт нужно не просто протестировать 2 новые фичи, которые были сделаны, а еще регрессионно протестировать весь продукт, чтобы проверить ничего ли не было сломано.
Опять же решений несколько:
а) Отдельно от Scrum сидит команда тестировщиков, которые постоянно гоняют регрессионные тесты (до тех пор пока не будет достаточно количество автоматизированных и unit test’ов. Замечу, чаще всего обнаруживается, что QA очень сильно не хватает и нужно нанимать дополнительных людей (что не всегда по душе менеджменту).
б) Таки в конце sprint’а продукт не является shippable. И раз в 3-4 sprint’а таки делают большое перетестирование и пофикс багов. В результате получается скорее модифицированный waterfall, чем Scrum.
И моя стандартная фраза в этой статье — «Как обычно об этом тоже молчит Scrum»
Продолжение следует…
Не согласен с автором насчёт: «а) Отдельно от Scrum сидит команда тестировщиков, которые постоянно гоняют регрессионные тесты (до тех пор пока не будет достаточно количество автоматизированных и unit test’ов. Замечу, чаще всего обнаруживается, что QA очень сильно не хватает и нужно нанимать дополнительных людей (что не всегда по душе менеджменту).»
Даже когда проект покрыт Unit тестами, имеется ввиду покрытие кода, QA специалсты должны регрессивно продолжать тестирование.
«б)Таки в конце sprint’а продукт не является shippable. И раз в 3-4 sprint’а таки делают большое перетестирование и пофикс багов. В результате получается скорее модифицированный waterfall, чем Scrum.»
Тестирование, debugging, shipment, configuration management, debug version testing, release testing всё должно быть в спринтах, на то они и спринт что он включает в себя все шаги waterfall, только на него объём меньше берётся по задачам и scope.
Согласен по поводу а). Да, действительно unitTest’ов не ндостаточно. Желательно еще и UI test’ы. Когда есть и те и другие, все равно нужно делать регрессионное тестирование, но чаще всего можно уменьшить количество тестов и выполнять их реже.
По поводу б). Собственно говоря я таки и сказал, что если делать раз в 3-4 — то получается модифицированный waterfall. Действительно от Scrum остается мало чего.
Может, в случае б) получается таки RUP, а не модифицированный Waterfall?
Не знаю, по RUP’у не работал.
> Где собственно описание того, на какой команде наиболее эффективно
> работает SCRUM, вопрос того, как нанять такую команду или что делать
> с текущей командой, для того, чтобы сделать из нее такую, на которой
> все будет хорошо работать?
«Скрам работает только на самомотивированных командах.» И где внешний менеджмент сводится не к распределению задач, а в поиске и повышении мотивации для каждого сотрудника.
Первоисточник не назову, равно как и полное определение.
Да, безусловно, где-то эта мысль озвучивалась.
Но, все равно методология абсолютно не касается, по моему мнению ключевого вопроса — как нанять самомотивированную команду, как из текущей немотивированной сделать самомотивированную..
Так как, частенько, утром приходит Scrum Master в компанию и видит разброт и шатание. Половине людней, что Scrum, что waterfall, что youtube смотреть. И что делать дальше?
мотивирование, разброд, шатания — эти проблемы решаются не с помощью скрама, он тут не при чем. если что «водка что пулемет главное чтобы бошку сносило» — увольнять, ставить на другие задачи, сделать втык, масса способов — к каждому свой подход. вот только скрам тут не при чем.
И все таки Scrum тут причем.
Scrum это инструмент. И на этом инструменте достаточно плохо прописано
а) Ограничения его использования
б) Его использование в неидеальных условиях
Иначе я могу завтра написать методологию, в которой все должны быть гениями и работать за бесплатно. А то, что у вас нет такой команды, ну так простите — делайте всем втыки, убирайте зарплату и растите гениев.
По п.3 — мне кажется разумно тут разделить ресурсы которые тратятся на саппорт и на девелопмент — за 3-4 спринта можно вполне понять сколько именно требует ресурсов саппорт продакшна и заранее в планируемых спринтах отводить на это время/ресурсы. Поток высокоприоритетных багов безусловно ломает спринт, но со временем мне кажется можно научится прогнозировать сколько ресурсов требуется на поддержку и планировать спринты с учетом этого фактора.
Далеко не любая команда может работать по скраму — мотивированность, способность работать в коллективе и разделять общие цели, сбалансированность технических и личностных скиллов внутри команды и наверное что то еще. Скрам — далеко не для всех и не всегда, и отнюдь не лекарство от всех болезней. Скрам не отвечает на многие вопросы имхо потому что данные вопросы не относятся к скраму как к методологии напрямую — для конкретной ситуации из реальной жизни можно подобрать паттерн решения который будет включать в себя что-то из скрам, а можно подобрать и не-скрам решение — выбирать надо исходя из эффективности для конечного результата.
Все таки потом багов очень плохо прогнозируемая вещь. В одном месяце ничего нет, а в другом продали продукт новой компании с новым envinronment и начинает сыпаться. Или в старой компании делают массовый upgrade soft’а и т.п. Поэтому поток может различаться в разы.
Насчет тех, кто может работать по Scrum и не может работать по Scrum. В целом, это бы и хотелось видеть в описании методологии — хорошо работает на таких-то параметрах. Как пример, я прочел X радужных книжек и наступил на Y граблей, до того, как самому понять эти параметры. Никто не говорит о том, чтобы описывать решение на каждый чих, но вот с 10 стандартных сложных моментов (которые вероятней всего будут в большинстве компаний) можно было бы и описать.
Кстати, когда я говорю сложных моментов, я именно имею в виду моментов, которые рушат идею Scrum’а, а не аккуратненько вписываются в нее.
Собственно читал книжку недавно Agile Management with Scrum. И там приведено несколько десятков проблемных примеров. Но честно говоря, такое впечатление, что каждый пример выбран специально, чтобы подчеркнуть, какой Scrum хороший и добрый.
Ну было бы странно если бы в Agile managment for Scrum приводились примеры когда скрам не работает, тогда бы это была другая книга с названием Scrum — when it doesn’t work and why you shouldn’t use it. Скрам — нехороший и не добрый ни разу — коллективная ответственность подстегивает гораздо больше обычных кнутов и пряников — команда сама выставила себе такие сроки и несет на себе ответственность за их выполнение. Нельзя свалить всё на менеджемнет который навалил задач и наставил нереальных сроков. От менеджмента идут приоритезированные таски, сроки ставят девелоперы. Они же за них и отвечают. Доброго и хорошего тут немного )
Если поток багов сильно меняется от спринта к спринту надо взять наиболее пессемистическую оценку по потоку ( в разумных пределах ) и планировать спринт с учетом ее, если получится так что поток багов будет сильно меньше то будет overdelivery по девелопменту, это конечно не есть хорошо ( ибо говорит о кривом планировании ), но это сильно лучше чем оправдываться за то что неуспели сделать. тем более что причина перевыполнения плана вполне разумная.
скрам хорошо работает в случае хорошо мотивированной команды в которой есть баланс по техническим скиллам, команда разделяет одни и те же цели, члены команды достаточно коммуникативны. Важно что есть продукт овнер, что менеджмент понимает что в течении спринта в бэклог измнения не вносятся — под баги я напомню мы отвели достаточно времени то есть запланировали баги которые найдутся посреди спринта.
специально залез в конспекты тренинга никиты филиппова(рекомендую кстати!) — итак команда должна быть — кроссфункциональная, хорошо сбалансированная , иметь общую цель, правильный скиллы, мотивированная, хорошо организованная, самодисциплинировованная. идеальные люди в идеальных условиях, но тем не менее. если чего то не хватает — ожидайте там проколов, подкладывайте солому заранее. у топ менеджмента тоже должно быть определённое понимание того что от них требуется раз в спринт смотреть на продукт и давать по нему качественный фидбэк, расставлять приоритеты у задач. просто сбросить в вольном виде таску — сделать все как у Х — не получится.
Еще раз. Отлично хвучит должно быть то, должно быть это. Откуда все это берется и что делать когда чего-то из этого нету?
«скрам хорошо работает в случае хорошо мотивированной команды в которой есть баланс по техническим скиллам, команда разделяет одни и те же цели, члены команды достаточно коммуникативны.»
при таком раскладе и другие методики вполне ничего могут работать.
Откуда будем только брать хорошо мотивированную команду с всеми этими параметрами.
Вы еще забыли, то что SCRUM не подходит для некторых видов бизнеса (имееться в виду деление на — заказная разработка, продуктовая разработка, интеграторы, внутренняя разработка не IT предприятия). И если говорить более детально SCRUM не применим для контрактов fix price (все их разновидности), и будет работать только по t&m.
Да, согласен не для всего IT подходит Scrum.